Cách trở thành kỹ sư AI 30x có gu

 (pakodas.substack.com)
22 điểm bởi GN⁺ 4 giờ trước | 2 bình luận | Chia sẻ qua WhatsApp
  • Trong thời đại AI tạo mã với số lượng lớn, năng lực cốt lõi quyết định giá trị của kỹ sư không còn là tốc độ, kiến thức hay kinh nghiệm mà là “gu (taste)”, tức năng lực đánh giá để quyết định nên tạo ra điều gì
  • Các thành viên của nhóm OpenAI Codex đã độc lập đi đến cùng một kết luận rằng, chỉ cần có gu phần mềm tốt thì ai cũng có thể trở thành kỹ sư giỏi gấp 10 lần
  • Gu được chia thành ba dạng: nhận biết (recognition) · la bàn (compass) · tầm nhìn (vision), và tất cả đều quy tụ về một cơ chế duy nhất là chất lượng của hàm đánh giá nội tại
  • Giá trị tập trung phát sinh ở năm lĩnh vực: chọn vấn đề, kiến trúc hệ thống, đánh giá chất lượng, thấu cảm người dùng, giao tiếp
  • Giờ đây khi việc viết mã đã trở thành hàng hóa phổ thông, phán đoán và tư duy mới là năng lực thật sự vốn có, và cần được rèn luyện một cách có chủ đích

Thế giới đã thay đổi nhưng phần lớn kỹ sư vẫn chưa nhận ra

  • Tháng 3 năm 2025, CEO Anthropic Dario Amodei dự đoán rằng trong vài tháng tới AI sẽ viết 90% mã, điều này khi đó nghe rất vô lý
  • Boris Cherny, người tạo ra Claude Code, cho biết đến tháng 12 thì 100% mã anh commit đều do AI viết và anh chưa từng mở IDE lấy một lần
  • Andrej Karpathy, người từng gọi các công cụ lập trình AI là “slop”, đã hoàn toàn đảo ngược quan điểm vào tháng 12
    • “Tôi chưa từng cảm thấy mình tụt hậu đến vậy với tư cách một lập trình viên, và nghề này đang được tái cấu trúc một cách mạnh mẽ”
    • DHH, tác giả Ruby on Rails, thừa nhận rằng sự phản kháng trước đây là vì “mô hình chưa đủ tốt”, còn giờ thì tình thế đã đảo chiều
    • CTO Vercel Malte Ubl nhắc đến việc “chi phí sản xuất phần mềm đang tiến về 0”
  • Trong khoảng tháng 11 đến 12 năm 2025, Opus 4.5, GPT-5.2, Gemini 3 đã vượt qua một ranh giới năng lực vô hình, giúp mã do AI tạo ra đạt mức kỹ sư lành nghề trong nhiều tác vụ rộng khắp, đồng thời rút ngắn thời gian từ vài giờ xuống còn vài phút
  • Khi việc tạo mã trở thành hàng hóa phổ thông, thứ còn lại là kỹ nghệ phần mềm: phân rã vấn đề, quyết định nên xây gì, thiết kế kiểm thử·độ tin cậy·khả năng mở rộng, đánh giá trade-off — tức là gu

Gu thực chất là gì

  • Trong cách các đội ngũ kỹ thuật hàng đầu nói về gu, có ba định nghĩa khác nhau, nhưng thực ra là cùng một năng lực được nhìn từ các góc độ khác nhau

  • Gu như sự nhận biết (Recognition)

    • Năng lực cảm nhận được bên nào tốt hơn khi nhìn vào hai cách triển khai, ngay cả trước khi giải thích được lý do
    • Emma Tang: việc một hệ thống có thật sự gọn gàng, có thể mở rộng, không trùng lặp và dễ hiểu hay không là vấn đề của gu
    • Giống như đầu bếp nếm nước sốt và biết ngay nó thiếu độ chua trước cả khi xác định được điều đó một cách có ý thức, so khớp mẫu hoạt động nhanh hơn suy luận có ý thức
    • Trường hợp nhóm Codex chọn Rust thay vì TypeScript cho CLI
      • Cả hai đều hoạt động, nhưng họ nhận ra rằng các ràng buộc của Rust (kiểu mạnh, quản lý bộ nhớ tường minh, phụ thuộc tối thiểu) không chỉ mang lại lợi thế kỹ thuật mà còn tạo ra hiệu ứng văn hóa kỹ thuật trong nhóm
      • Đó không phải là phán đoán kiểu “ngôn ngữ vượt trội về mặt kỹ thuật”, mà là “ngôn ngữ định hình hành vi mà nhóm mong muốn”
    • Gu tệ: chọn Rust chỉ vì nó đang là xu hướng, hoặc vì đọc blog thấy nó nhanh mà không hiểu các hiệu ứng bậc hai

  • Gu như la bàn (Compass)

    • Đây là dạng mà Tibo nói rằng kỹ sư cần có “la bàn của riêng mình”: không phải đánh giá thứ đã tồn tại mà là biết điều gì cần được tạo ra tiếp theo
    • Là kiểu kỹ sư có thể nói “đây không phải tính năng đúng đắn” trước cả khi viết một dòng mã
    • Trường hợp Boris Cherny làm tính năng danh sách todo cho Claude Code trong hai ngày với khoảng 20 nguyên mẫu
      • Anh thử todo nội tuyến, UI dạng ngăn kéo, pill tương tác, hiển thị ở cuối màn hình... rồi hội tụ về một hình thức tạo cảm giác không phải ngẫu nhiên mà là tất yếu
      • Về sau anh có thể giải thích vì sao phương án cuối tốt hơn, nhưng chính sự không hài lòng ban đầu với các phương án trung gian mới là gu đóng vai trò như la bàn
    • Gu kiểu la bàn hiếm hơn gu kiểu nhận biết vì nó hoạt động ở thượng nguồn trước cả khâu thực thi

  • Gu như tầm nhìn (Vision)

    • Được thể hiện qua câu nói của SQ Mah rằng “con người định nghĩa tiến hóa”, đây là dạng khó nhất: biết điều gì sẽ trở nên quan trọng sau 2 năm, chứ không chỉ điều gì tốt ở hiện tại
    • Peter Steinberger, tác giả OpenClaw, chạy đồng thời 5~10 agent và dành phần lớn thời gian cho kiến trúc và thiết kế hệ thống
      • Ông nói rằng “phần lớn mã chỉ là chuyển đổi dữ liệu nhàm chán, hãy dồn năng lượng vào thiết kế hệ thống”
    • Ưu tiên tiếp theo của nhóm Codex là lập kế hoạch dựa trên ngữ cảnh phong phú, thứ đòi hỏi thông tin ngoài codebase như mục tiêu kinh doanh, động lực thị trường, ưu tiên của nhóm
      • Đây là gu kiểu tầm nhìn được áp dụng vào chiến lược sản phẩm hướng tới tương lai nơi mô hình không chỉ tạo mã tốt hơn, mà còn hiểu vì sao phần mềm tồn tại

  • Định nghĩa tích hợp

    • Cả ba dạng đều quy tụ về một cơ chế duy nhất: gu là chất lượng của hàm đánh giá nội tại
    • Với nhận biết, hàm đánh giá hoạt động trên thành phẩm; với la bàn, nó hoạt động trên khả năng và phương hướng; với tầm nhìn, nó hoạt động trên tương lai và quỹ đạo
    • Trong thế giới nơi AI tạo mã, công việc của con người là đánh giá: quyết định nên xây gì, phán đoán đầu ra đã đủ tốt hay chưa, phát hiện thời điểm cần thay đổi kiến trúc — và việc đánh giá chính là công việc

Vì sao có kỹ sư kiếm được nhiều hơn hẳn

  • Trước thời AI, chênh lệch đãi ngộ thường được giải thích bằng ba yếu tố: công ty, thâm niên, lĩnh vực chuyên môn; nhưng AI đang xáo trộn cả ba biến số này
  • Khoảng cách giữa kỹ sư xuất sắc và kỹ sư trung bình ở startup đã nới từ 3 lần lên 10 lần, vì người giỏi hơn có thể dùng AI để tạo ra đầu ra tương đương cả một nhóm nhỏ
  • Trục của thâm niên đang dịch chuyển: kinh nghiệm viết mã kém quan trọng hơn kinh nghiệm đưa ra phán đoán đúng
    • Giá trị của việc “biết React” giảm đi, còn giá trị của việc “có thể thiết kế hệ thống đáng tin cậy dưới tải” lại tăng lên
  • Điểm chung của những kỹ sư tạo ra khoảng cách lớn là họ đưa ra các quyết định tích lũy theo lãi kép
    • Một quyết định kiến trúc tốt có thể tiết kiệm vài tháng làm việc trong suốt một năm
    • Một quyết định sản phẩm tốt có thể quyết định tính năng đó có thật sự được người dùng đón nhận hay không
  • Dù làm việc chăm chỉ hơn, bạn vẫn có thể chỉ tạo ra một nửa giá trị so với người có gu tốt hơn; chạy 2 agent vào đúng vấn đề tạo ra nhiều giá trị hơn chạy 8 agent vào sai vấn đề
  • Trong trường hợp của OpenAI, những kỹ sư năng suất nhất không phải là người tạo ra nhiều mã hơn, mà là những người chuyển trọng tâm sang trò chuyện với người dùng, định hướng sản phẩm, thấu cảm và dành nhiều thời gian hơn cho đó
    • Một số người lại quay về tab autocomplete vì cho rằng “mất cảm giác với codebase”, và cả hai phản ứng đều hợp lý

Nơi giá trị thực sự được tạo ra

  • Có năm lĩnh vực mà gu tạo ra giá trị bất cân xứng; đa số kỹ sư chỉ cạnh tranh ở một hoặc hai lĩnh vực

  • Vùng 1: Chọn vấn đề

    • Đây là quyết định về gu có đòn bẩy cao nhất: chọn làm gì, nhưng phần lớn hầu như không suy nghĩ về nó
    • Kỹ sư có gu đặt câu hỏi: “Nếu giải tốt việc này thì năm vấn đề khác có biến mất không?”
    • Peter Steinberger trao đổi qua lại lâu với agent để mài giũa kế hoạch, thách thức và phản biện; chỉ khi hài lòng mới cho agent thực thi, kế hoạch chính là công việc còn thực thi thì được ủy nhiệm
    • Trong hệ thống phân quyền của Claude Code, thay vì chọn RBAC phức tạp và chính sách chi tiết, họ chọn cách tiếp cận đơn giản nhất (yêu cầu quyền rồi ghi nhớ câu trả lời) để phát hành nhanh và trực quan

  • Vùng 2: Kiến trúc hệ thống

    • Đây là cách các mảnh ghép ăn khớp với nhau, là lĩnh vực mà thời gian bán rã của gu dài nhất; quyết định tốt vẫn sinh lời sau 2 năm, quyết định tệ tích tụ thành nợ kỹ thuật đòi phải viết lại
    • Quyết định xây vòng lặp agent của Codex dưới dạng state machine, quyết định của Claude Code là viết ít business logic nhất có thể, và sự ám ảnh với khả năng mở rộng theo mô-đun của OpenClaw đều là các quyết định gu về kiến trúc
    • Boris Cherny: “Mỗi khi có model mới, chúng tôi xóa đi rất nhiều code và để ít code nhất có thể xung quanh model”
      • Hầu hết các đội thêm code sau mỗi lần phát hành, nhưng đội Claude Code thì gỡ bỏ; model chính là sản phẩm và phần xung quanh phải mỏng nhất có thể

  • Vùng 3: Đánh giá chất lượng

    • Đây là khả năng biết đã đủ tốt để phát hành hay vẫn cần làm thêm, một lĩnh vực AI không thể giúp được (vì nó không biết mức “đủ” trong ngữ cảnh cụ thể)
    • Review code phân tầng của Codex: code không cốt lõi chỉ cần AI review, còn code agent cốt lõi bắt buộc phải có người review
      • Gu nằm ở việc biết đoạn code nào là quan trọng; hệ thống phân quyền cần mắt người, còn cập nhật README thì không cần
    • Đội Codex viết gần như mọi đoạn code bằng prompt, nhưng các bộ phận khác trong công ty chỉ ở mức khoảng 70%; 30% viết tay là phần mà đánh giá chất lượng quan trọng nhất (“quy tắc 30/70”)

  • Vùng 4: Đồng cảm với người dùng

    • Đây là việc hiểu con người ở phía bên kia thực sự cần gì, lĩnh vực mà AI yếu nhất
    • Thông báo tải theo ngữ cảnh trong Claude Code do Boris tạo ra (thay vì chỉ xoay vòng đơn giản thì hiển thị model đang làm gì) không ai yêu cầu, nhưng được làm ra vì sự khác biệt giữa chờ đợi không thông tin và chờ đợi có thông tin
    • Giá trị mặc định sandbox của Codex cũng là quyết định xuất phát từ đồng cảm người dùng; Tibo nói: “Ngay cả khi điều đó làm giảm tỷ lệ chấp nhận, chúng tôi mặc định không khuyến nghị thứ gì có thể không an toàn”
      • Điều này thể hiện sự hiểu rằng nhiều người dùng “không quá kỹ thuật” có thể vô tình làm điều không thể hoàn tác, nên họ chọn an toàn thay vì tiện lợi

  • Vùng 5: Giao tiếp và kể chuyện

    • Đây là cách bạn định khung cho thứ mình tạo ra, một lĩnh vực mà kỹ sư luôn đánh giá thấp nhưng thị trường lại tưởng thưởng
    • OpenClaw của Peter Steinberger trong tuần lan truyền đã ghi nhận lượng tìm kiếm trên Google nhiều hơn cả Claude Code và Codex cộng lại
      • Một cái tên rõ ràng, demo thuyết phục, và câu chuyện “một người tạo ra sản lượng ở quy mô cả đội” đã thúc đẩy sự lan tỏa
    • Tệp AGENTS.md của Codex (README dành cho AI agent chứ không phải con người) là gu giao tiếp thể hiện việc nhận ra rằng độc giả của tài liệu đã thay đổi và định dạng cũng phải thích ứng

Các ví dụ về gu (và sự thiếu vắng nó)

  • Chọn tech stack

    • Không có gu: “Dùng TypeScript vì nó phổ biến nhất và ai cũng biết”, biện minh bằng thói quen
    • Có gu: Boris chọn TypeScript vì với model Claude thì đó là “on distribution” (model đã xử lý tốt sẵn), tức tối ưu theo điểm mạnh của model chứ không phải độ thoải mái của đội
      • Codex chọn Rust vì muốn tối thiểu phụ thuộc để “buộc người ta nghĩ về các tiêu chuẩn kỹ thuật đã đặt ra” và có thể tự mình xem xét; cùng là quyết định chọn stack nhưng cả hai đều dựa trên ràng buộc cụ thể chứ không phải sở thích chung chung

  • Xử lý code chưa hiểu hoàn toàn

    • Không có gu: “AI tạo ra, test pass rồi thì phát hành”, không nghĩ đến độ đủ của test hay khả năng bảo trì
    • Có gu: Peter phát hành code chưa đọc hết nhưng không hề cẩu thả; ông nói “tôi biết vị trí và cấu trúc của các component, biết thiết kế toàn hệ thống, và thường như vậy là đủ”
      • Test, linting và CI local là các lớp xác minh; một bên là đánh cược, bên kia là hệ thống bảo đảm tính đúng đắn một cách có cấu trúc

  • Phản hồi yêu cầu tính năng

    • Không có gu: làm đúng theo ticket, phát hành xong rồi chuyển sang việc tiếp theo
    • Có gu: trước khi phát hành, Boris làm 20 prototype trong 2 ngày; đó không phải chậm mà là thử nghiệm nhanh để lái tới lời giải đúng, tính tất yếu là dấu vân tay của gu

  • Thiết kế cho AI agent

    • Không có gu: README thông thường với hướng dẫn thiết lập và API endpoint
    • Có gu: Codex viết AGENTS.md để chỉ cho AI cách khám phá codebase, lệnh test và cách tuân thủ chuẩn mực, cấu trúc codebase sao cho model tất yếu sẽ thành công

  • Ứng phó với làn sóng PR

    • Không có gu: PR do AI tạo ra đổ về nhưng vẫn giữ nguyên quy trình review cũ, khiến reviewer quá tải và chất lượng đi xuống
    • Có gu: đội của Emma Tang yêu cầu đính kèm prompt vào PR; nếu không có thì sẽ hỏi trên Slack “prompt là gì”
      • Trong thế giới AI, review ý định hữu ích hơn review code; Peter gọi PR là “prompt requests” và quan tâm đến prompt sinh ra code hơn chính code, vì khi đơn vị tạo sinh thay đổi thì đơn vị review cũng phải đổi theo

Kế hoạch rèn gu (không phải cảm nhận)

  • Lời khuyên kiểu “hãy tích lũy thêm kinh nghiệm” vô dụng như câu “hãy tập thể dục nhiều hơn”; dưới đây là kế hoạch 90 ngày cho ba dạng khác nhau

  • Tháng 1: Xây gu nhận diện bằng tiếp xúc có cấu trúc

    • Cơ chế là tiếp xúc số lượng lớn với nhiều biến thể khác nhau, sau đó phản tư có chủ đích
    • Tuần 1–2: nghiên cứu 10 công cụ dành cho nhà phát triển mà bạn ngưỡng mộ
      • Cài Codex CLI, Claude Code, Linear, Supabase, Stripe dashboard, Vercel, Tailwind, Railway, Resend và 1 sản phẩm không phải phần mềm (một triển lãm bảo tàng được thiết kế tốt hoặc thực đơn nhà hàng)
      • Với mỗi thứ, viết trong 15 phút: bạn nhận ra điều gì trong 60 giây đầu tiên, điều gì làm bạn thấy thích thú, điều gì gây bối rối, và bạn sẽ “ăn cắp” quyết định nào
      • Công cụ tốt cho thấy kết quả trong 30 giây đầu trước khi giải thích quy trình; công cụ tệ giải thích kiến trúc trước khi cho bạn thấy tại sao phải quan tâm
    • Tuần 3–4: nghiên cứu 10 bài báo để học phương pháp luận chứ không phải khám phá
      • Bài báo gốc về điểm BLEU, bài Constitutional AI của Anthropic, bài PageRank của Google, hồ sơ Netflix Prize, các bài về Scaling Laws
      • Viết ra: điều gì khiến phương pháp trở nên thanh nhã, insight duy nhất khiến nó hoạt động, và bạn sẽ áp dụng nó vào miền của mình thế nào
      • Bạn sẽ nhận ra các nguyên tắc cấu trúc như tiêu chí đánh giá rõ ràng, công khai trung thực các giới hạn, và cách diễn đạt đơn giản thay vì phức tạp được lặp lại xuyên suốt nhiều lĩnh vực

  • Tháng 2: Xây gu định hướng bằng phân biệt chủ động

    • Bài tập hằng tuần “Side-by-Side”: tìm hai ví dụ cùng loại và viết 500 từ giải thích vì sao một cái tốt hơn (hai bộ tài liệu API, hai blog kỹ thuật, hai sơ đồ kiến trúc, hai khung đánh giá)
      • Cấm dùng “tôi thích hơn”, luôn phải nêu rõ cơ chế cụ thể bằng câu “cái này tốt hơn vì…”
      • Ví dụ: tài liệu của Stripe tốt hơn vì được tổ chức xoay quanh điều nhà phát triển muốn làm (gửi thanh toán, xử lý lỗi), chứ không phải kiến trúc nội bộ
    • Bài tập hằng ngày “Practice Noticing”: mỗi lần xem công cụ, bài báo hay code, chọn một quyết định của người tạo ra nó và ghi lại một câu “vì sao là cái này chứ không phải phương án hiển nhiên kia”; sau 30 ngày, các mẫu hình trong 30 quan sát đó chính là gu đang hình thành

  • Tháng 3: Xây gu tầm nhìn bằng áp dụng mang tính tạo sinh

    • Tuần 9: thiết kế lại thứ bạn đang sở hữu (luồng onboarding của đội, README dự án, trải nghiệm lập trình viên của pipeline đánh giá) bằng những gì đã học
    • Tuần 10: viết bài chính xác nhất bạn từng viết, không phải dài nhất hay bao quát nhất mà là bài trong đó mọi đoạn đều làm đúng phần việc của mình và thay đổi cách nghĩ của người đọc
    • Tuần 11: thiết kế một hệ thống từ đầu và giải thích mọi quyết định bằng nguyên lý đầu tiên, không phải theo tập quán (“dùng microservices vì là best practice” mà là “đội có 4 người, lưu lượng dự đoán được, và sự đơn giản khi triển khai có giá trị hơn lợi ích mở rộng mà 18 tháng nữa mới cần, nên chọn monolith”)
    • Tuần 12: chia sẻ gu, dạy sự khác biệt giữa hai cách tiếp cận và viết AGENTS.md cho chính codebase của mình; khả năng mã hóa gu vào hệ thống và tài liệu là thứ phân biệt kỹ năng cá nhân với năng lực tổ chức

Năm dự án để rèn gu nhanh

  • 1. Xây dựng framework đánh giá cho mã do AI sinh ra

    • Không phải linter hay test runner, mà là một framework trả lời câu hỏi “đoạn mã AI này đã đủ tốt để đưa vào production chưa”, tự định nghĩa rubric riêng (độ chính xác, khả năng bảo trì, hiệu quả, bảo mật, phong cách)
    • Áp dụng và chấm điểm trên 50 PR thực tế do AI tạo, hiệu chỉnh rubric dựa trên những điểm số gây bất ngờ, công khai kết quả, xây dựng gu ở Zone 3 (đánh giá chất lượng)

  • 2. Thiết kế lại quy trình onboarding cho dự án mã nguồn mở

    • Fork một công cụ mà bạn tôn trọng về mặt kỹ thuật nhưng có onboarding gây bức bối, thiết kế lại 5 phút đầu của trải nghiệm nhà phát triển, viết README và hướng dẫn bắt đầu, cấu trúc lại để người đóng góp mới có thể gửi PR ngay trong ngày đầu tiên
    • Đồng thời xây dựng Zone 4 (đồng cảm với người dùng) và Zone 5 (giao tiếp)

  • 3. Xây dựng “bài kiểm tra gu” cho đội ngũ

    • Viết tài liệu gồm 10 cặp cách tiếp cận triển khai, trong mỗi cặp có một bên thể hiện gu tốt hơn, hỏi 5 kỹ sư bên nào tốt hơn và vì sao
    • Kết quả thú vị không phải là đáp án đúng mà là sự bất đồng quan điểm, những điểm lệch chuẩn là nguồn gốc của bug, nợ kỹ thuật và làm lại, từ đó xây dựng gu tổ chức có đòn bẩy cao nhất

  • 4. Phát hành sản phẩm với ràng buộc 48 giờ

    • Không phải prototype mà là một sản phẩm hoạt động để người khác sử dụng, ràng buộc thời gian liên tục buộc bạn phải đưa ra các quyết định về gu (chọn thứ sẽ đưa vào và thứ sẽ cắt bỏ)
    • Nếu dành 6 giờ cho một tính năng sai, bạn sẽ đốt mất một phần tư quỹ thời gian, nên hậu quả của quyết định tồi xuất hiện ngay lập tức

  • 5. Viết blog kỹ thuật thay đổi cách tư duy

    • Không phải tutorial hay how-to, mà là bài viết tái cấu trúc một khái niệm quen thuộc để người đọc nhìn nó khác đi về sau (nhận ra gu chính là đánh giá, nhận thức rằng việc xóa mã sau mỗi lần model phát hành không phải thói quen mà là triết lý kiến trúc)
    • Xây dựng Zone 5 (giao tiếp·kể chuyện), một góc nhìn chân thực là nền tảng của mọi gu

Tối ưu hóa sự nghiệp xoay quanh gu

  • Dừng cuộc đua tốc độ

    • Khi AI viết mã với tốc độ của máy, cạnh tranh về tốc độ coding là một cuộc chơi thua cuộc; người dành 30 phút suy nghĩ xem 50 dòng nào thực sự cần thiết sẽ có giá trị hơn người tạo ra 500 dòng mỗi giờ
    • Tốc độ triển khai đã bị hàng hóa hóa, và thứ chưa bị hàng hóa hóa là phán đoán về việc nên triển khai cái gì và triển khai như thế nào

  • Đầu tư vào các ‘kỹ năng lân cận’ cần cho gu

    • Điểm chung của các kỹ sư giỏi nhất là họ không chỉ là coder đơn thuần; Boris là nhà sáng lập startup, Emma từng dẫn dắt hạ tầng dữ liệu tại Stripe trong 4 năm, Peter đã phát triển PSPDFKit thành một doanh nghiệp toàn cầu
    • Gu cần nguyên liệu thô, tư duy sản phẩm, cảm nhận thiết kế, hiểu biết kinh doanh và năng lực giao tiếp là những nguyên liệu làm cho gu trở nên khả thi

  • Chọn vai trò nơi gu được tưởng thưởng

    • Những vai trò triển khai đặc tả đã được định nghĩa rõ ràng sẽ thưởng cho tốc độ; còn những vai trò quyết định làm gì, làm như thế nào và thế nào là đủ thì trực tiếp thưởng cho gu
    • Những vai trò đặc biệt thưởng cho gu: kỹ sư sáng lập ở startup giai đoạn đầu, tech lead ở công ty sản phẩm, kỹ sư platform/hạ tầng thiết kế hệ thống để các kỹ sư khác xây dựng lên trên đó, kỹ sư trải nghiệm nhà phát triển, kỹ sư staff+ xử lý các quyết định kiến trúc liên nhóm

  • Xây dựng các sản phẩm công khai thể hiện gu

    • Trong thời đại AI, portfolio quan trọng hơn CV; bằng chứng nằm ở sản phẩm đầu ra (mã nguồn mở được thiết kế tốt, blog kỹ thuật có góc nhìn nhất quán, sản phẩm mà mọi người thực sự dùng)
    • OpenClaw của Peter nói lên nhiều điều hơn bất kỳ CV nào, và prototype Claude Code của Boris chứng minh gu tốt hơn bất kỳ câu trả lời nào trong phỏng vấn hành vi

Sự thật khó chịu

  • Gu được phân bố không đồng đều và sẽ tiếp tục như vậy; một số người đã rèn nó qua hàng nghìn quyết định trong 15 năm, tạo ra khoảng cách vạch xuất phát không thể bắt kịp chỉ bằng một kế hoạch 90 ngày
    • Đội Codex làm việc tại công ty tạo ra model với quyền truy cập token không giới hạn, còn Peter có điểm xuất phát phi điển hình với 20 năm kinh nghiệm và từng exit công ty
  • Tuy vậy, khoảng cách giữa “không có gu” và “có một chút gu” tạo ra tác động sự nghiệp rất lớn và có thể thu hẹp, bước nhảy từ người nhận ticket rồi triển khai sang người dùng user research để đề xuất nên xây gì, rồi dùng AI để triển khai cả test lẫn kiến trúc, đó chính là gu
  • Lời giãi bày chân thành của Gergely Orosz: “Cảm giác như một thứ có giá trị bỗng nhiên bị lấy mất, tôi đã bỏ ra rất nhiều công sức để trở nên giỏi coding, và những lúc đắm mình gõ ra ý tưởng là những ký ức tuyệt nhất”
    • Cảm giác mất mát khi kỹ năng code tay trở nên bớt trung tâm là có thật, nhưng khả năng biết đoạn mã nào nên tồn tại, nên được cấu trúc ra sao và thế nào là đủ mới luôn là năng lực thật sự
  • Những kỹ sư sẽ phát triển mạnh tiếp theo là những người nhận ra điều này: gu vốn luôn là công việc, chỉ là trước đây nó ẩn trong code, và AI lấy đi phần gõ phím đã làm nó lộ ra

Bài viết liên quan

2 bình luận

 
clastneo 3 giờ trước

Chà, giờ không còn là 10x nữa mà phải nghĩ đến 30x rồi hả haha
 
channprj 2 giờ trước

Tôi cũng muốn ngừng nhìn thấy những cách diễn đạt hơi cường điệu như kiểu kỹ sư x lần.. T_T
Trông có vẻ như là cách nói định lượng, nhưng thực ra cũng là một cách diễn đạt mang tính định tính.