Kỹ thuật xác suất và nhân viên 24/7

• Ngành phát triển phần mềm đang âm thầm chuyển từ hệ thống tất định sang hệ thống xác suất, và trong thời đại các AI agent tạo, review và merge code suốt đêm, vai trò của lập trình viên cùng cấu trúc tổ chức đang thay đổi một cách căn bản
• Bên trong các đội ngũ AI-native, vai trò vừa được đẩy lên tầng cao hơn, vừa phân hóa xuống tầng thấp hơn; đồng thời tồn tại rủi ro các công việc đơn giản kiểu quản lý đầu ra của agent sẽ bị cố định thành một nhóm nghề lương thấp mới
• Khi chi phí sinh code tiến gần về 0, sản lượng code bùng nổ theo nghịch lý Jevons, nhưng thách thức cốt lõi là việc tạo ra trở nên rẻ hơn còn việc xác minh thì không
• Các kỹ sư junior dựa vào AI để ngay từ đầu đã tạo ra code bóng bẩy, khiến khủng hoảng trong việc rèn luyện debug, năng lực phán đoán và tay nghề thủ công đã trở thành hiện thực
• Vì model hiện tại là model yếu nhất trong số những model mà tương lai sẽ dùng, tổ chức cần xây dựng một hệ thống hướng tới các model tương lai chưa ra mắt, thay vì chỉ dựa trên năng lực hiện tại

---

Chuyển dịch sang kỹ thuật xác suất

• Ngành phần mềm suốt nhiều thập niên được xây dựng trên một hợp đồng tất định — viết code, test, release là có thể bảo đảm nó sẽ hoạt động
• Hợp đồng này đang bị phá vỡ, và trong giới vận hành cấp cao ở các công ty AI-native, codebase đang chuyển thành thứ mà người ta chỉ có thể "tin rằng nó hoạt động", trong trạng thái không còn nêu ra chính xác xác suất nữa
• Trải nghiệm xây dựng side project Compound Loop là chất xúc tác cho nhận thức này — một hệ thống cho nhiều frontier model đối đầu lẫn nhau để tự động viết, review và merge code
  • Chạy hệ thống với các bài toán thực trước khi đi ngủ, rồi sáng ra sẽ triage một chồng PR tối hôm trước còn chưa tồn tại
  • Có cái rất xuất sắc, có cái có lỗi, có cái lại làm lộ ra những câu hỏi chưa từng được đặt ra
• Lần đầu tiên trong lịch sử lao động tri thức, người tan làm không còn mang theo bản sao bộ não duy nhất
• Khái niệm 9-9-6 về thực chất đã chết; nhân viên 24/7 không có nghĩa là một con người làm việc 24 giờ, mà là agent làm việc theo kiểu song song hóa ở quy mô lớn
• Đến năm 2026, đa số đội ngũ vẫn sẽ nghẽn ở điều phối (coordination) chứ không phải gõ phím, và việc tái cấu trúc tổ chức vẫn mới chỉ ở giai đoạn đầu

Sự phân hóa vai trò — đồng thời đi lên và đi xuống

• Bên trong các đội ngũ AI-native đang tồn tại một mô hình phức tạp hơn nhiều so với câu chuyện gọn gàng kiểu "ai cũng lên level"
• Dịch chuyển lên trên: kỹ sư giỏi nhất trở thành PM hiệu quả hơn, PM giỏi nhất trở thành kiến trúc sư hệ thống, kiến trúc sư giỏi nhất chuyển sang suy nghĩ về phân phối, tăng trưởng và cấu trúc thị trường
  • Với nhóm này, đây là môi trường làm việc có đòn bẩy cao nhất trong lịch sử
• Phân hóa xuống dưới: đồng thời, không phải nhiều kỹ sư hơn sẽ trở thành kiến trúc sư, mà họ sẽ chuyển thành người viết spec, reviewer, người trông agent
  • Vai trò là chuyển ý định thành prompt để máy có thể đọc, và chấm điểm công việc của máy theo những tiêu chuẩn mà chính họ cũng không hoàn toàn nắm giữ
  • Một phần là công việc quan trọng, nhưng một phần khác chỉ là phiên bản nhập liệu của năm 2026 được gói lại bằng thuật ngữ mới
• Các vai trò bị phân hóa này nhiều khả năng sẽ có lương thấp hơn, được định giá thấp hơn, và trong nhiều trường hợp trở thành ngõ cụt sự nghiệp
• Khoảng cách lương giữa 1/3 nhóm trên cùng vận hành hiệu quả cả một hạm đội agent và tầng lớp trung gian chỉ quản đầu ra sẽ còn lớn hơn cả chênh lệch lương kỹ sư - bán hàng ở thời kỳ trước
• Trong hạ tầng AI, hiệu năng kernel, thiết kế compiler, trừu tượng hóa phần cứng vẫn là các moat có thể phòng thủ — ở tầng thấp nhất của system engineering vẫn đòi hỏi độ chính xác tất định cao

Nghịch lý Jevons — phiên bản dành cho code

• Năm 1865, nhà kinh tế học William Stanley Jevons quan sát thấy động cơ hơi nước hiệu quả hơn không làm giảm tiêu thụ than mà còn làm tăng tiêu thụ — hiệu quả mở rộng phạm vi những thứ đáng để xây động cơ
• Khi chi phí biên của việc viết code tiến sát 0, phần mềm cũng đang trải qua hiện tượng tương tự — không phải viết ít hơn mà là viết nhiều hơn rất nhiều và phát hành nhiều hơn rất nhiều
• Những công ty tin rằng quy luật scaling là vô hạn đang xây dựng tương ứng, và họ sẽ là những người chiến thắng trong phân phối power-law
• Những gì đã diễn ra ngay tại hiện trường:
  • Agent mở PR, review công việc của nhau, rồi đóng lại mà không cần con người chạm vào bàn phím
  • Bộ test tự chữa lành tự viết lại khi code nền thay đổi
  • Vòng lặp thử nghiệm tự động chạy, đo lường và loại bỏ 100 giả thuyết trong lúc trước đây cả team chỉ chạy được 3
  • Tài liệu được cập nhật tự động khi merge, tận dụng kỹ năng AI tự cải thiện
• Những đội ngũ tái cấu trúc quanh agent đã đạt đầu ra gấp 3, gấp 5, gấp 10 so với một năm trước, và đường cong không hề phẳng lại mà vẫn tiếp tục đi lên
• Bài học thứ hai của Jevons: khi nguồn cung bùng nổ thì khâu chọn lọc (selection) trở thành cốt lõi
  • Người vận hành biết giao đúng vấn đề cho hạm đội agent, lọc ra thứ có giá trị từ đầu ra, rồi tích hợp kết quả thành một tổng thể nhất quán đang làm công việc đòn bẩy cao nhất trong phần mềm hiện nay
  • Giá trị của công việc không còn do nỗ lực sản xuất quyết định mà bởi định hướng, chọn lọc và tính nhất quán

Từ kỹ thuật tất định sang kỹ thuật xác suất

• Kỹ thuật tất định là hợp đồng đã thống trị gần như toàn bộ lịch sử phần mềm — viết, test, review code thì có thể hiểu được hành vi của nó trong một phạm vi đã được nắm rõ, bug là thứ có thể tái hiện
• Kỹ thuật xác suất đã xuất hiện ở các đội frontier — phần lớn codebase được tạo bởi các hệ thống xác suất, được review dưới áp lực thời gian, rồi tích hợp vào một tổng thể không do một con người duy nhất thiết kế
• Bất đối xứng cốt lõi: tạo ra đã rẻ hơn nhưng xác minh thì không
  • Agent có thể tạo một PR 500 dòng trong vòng 1 phút, nhưng để bắt những lỗi tinh vi như vấn đề đồng thời, hiểu sai spec hay triển khai lệch với ý định thì kỹ sư senior vẫn cần hơn 1 giờ
  • Review scale chậm hơn tạo sinh, và xét theo lượng đầu ra thì scale tệ hơn tuyến tính — càng nhiều codebase do agent viết, lượng ngữ cảnh cần để đánh giá từng mảnh càng tăng
• Vượt qua một quy mô nhất định, hệ thống sẽ tạo ra nhiều hơn mức con người có thể đánh giá một cách đáng tin cậy, và độ chính xác bắt đầu trở nên xác suất
• Ví dụ cụ thể: điều kiện tranh chấp chỉ qua được test 9 trên 10 lần, tính năng chạy hoàn hảo ở staging nhưng hỏng ở phân phối prompt không lường trước, migration âm thầm làm hỏng 1 dòng trong 10.000 dòng và chỉ bị phát hiện sau 3 tuần
• Proximal và Modular đã công bố nghiên cứu chung về các bài test tác vụ cơ bản cho hệ thống agent frontier, và các mẫu lỗi được ghi nhận khớp trực tiếp với hiện tượng này
• Chế độ thất bại không phải là sụp đổ kịch tính mà là sự xuống cấp chậm và âm thầm — tạo sinh tăng lên, chất lượng review giảm xuống, lỗi khó thấy tích tụ, niềm tin bị bào mòn lặng lẽ cho tới khi khách hàng, kiểm toán hoặc sự cố production làm lộ ra vấn đề
• Hiện chưa có công cụ nào thực sự giải quyết đúng bài toán này — các phản ứng văn hóa như merge nhỏ, gate nghiêm ngặt, hoài nghi không khoan nhượng với đầu ra bóng bẩy, khả năng quan sát và kỷ luật rollback có ích, nhưng văn hóa không scale nổi khi team vượt qua một quy mô nhất định
• Ai giải được bài toán này sẽ định nghĩa hệ điều hành cho việc phát triển phần mềm nghiêm túc trong 10 năm tới

Tốc độ chuyển đổi khác nhau theo từng ngành

• Quá trình chuyển từ kỹ thuật tất định sang kỹ thuật xác suất không diễn ra đồng đều mà phân tầng theo ngành và hồ sơ rủi ro

• Tầng tất định

  • Avionics, thiết bị y tế, hạ tầng giao dịch tài chính, hệ thống điều khiển hạt nhân, lõi của mạng thanh toán và các lĩnh vực rủi ro cao được quản lý chặt
  • Chỉ áp dụng hỗ trợ từ agent một cách thận trọng phía sau kiểm chứng hình thức, mô phỏng diện rộng và chuỗi ký duyệt của con người
  • Đây không phải thất bại của trí tưởng tượng mà là đánh giá đúng mức độ rủi ro

• Tầng xác suất

  • Phần mềm tiêu dùng, công cụ nội bộ, hệ thống marketing, phần lớn SaaS, hạ tầng nội dung, sản phẩm thử nghiệm và giai đoạn sớm
  • Chi phí của bug chỉ ở mức rollback, xin lỗi và hotfix, đổi lại họ giành được tốc độ lặp mà thế giới tất định về cấu trúc không thể theo kịp
  • Các team xác suất có thể học hỏi nhiều gấp 10 lần mỗi quý so với đối thủ tất định

• Vùng hội tụ (Convergence Zone)

  • Khi model thông minh hơn và các harness được cải thiện, ranh giới của những gì "làm theo kiểu xác suất mà vẫn đủ an toàn" tiếp tục dịch chuyển
  • Các phương pháp xác suất đang thấm dần từ dưới lên từng 10% một vào những lĩnh vực hiện còn có vẻ tất định như bảo hiểm, y tế và một phần hạ tầng enterprise
  • Những người dẫn đầu về kỹ thuật xác suất đang dựng lại các guardrail tất định — kiểm tra hình thức, critical path đã được xác minh, các hệ thống lai nơi việc tạo sinh xác suất được bao quanh bởi kiểm chứng tất định
• Người chiến thắng trong 10 năm tới sẽ là những team biết mình đang ở tầng nào, kháng cự cám dỗ giả vờ mình thuộc tầng khác, và đặt ranh giới thật chính xác ngay trong stack của mình

Hạm đội agent (Agentic Fleet)

• "Ca làm của nhà máy" không phải là phép ẩn dụ phù hợp — công nhân nhà máy là hệ thống bị tự động hóa, còn các chủ thể hiện tại thì không như vậy
• Phép ẩn dụ phù hợp hơn là hạm đội agent — chỉ có điều mức độ trật tự, phân cấp và độ tin cậy mà chữ "hạm đội" gợi ra vẫn là thứ thực tế chưa đạt tới
  • Trên thực tế, thứ mà đa số người vận hành đang chạy giống một đám nhà thầu mong manh hơn là một hải quân được huấn luyện tốt
  • Agent có năng lực không đồng đều, hành vi mang tính xác suất, đôi khi sai nhưng vẫn rất tự tin, và tốn kém khi chạy ở quy mô lớn
  • Lớp orchestration có thể gãy, context window có thể nổ tung, và chi phí suy luận xuất hiện trên hóa đơn mà người ta không muốn trình lên hội đồng quản trị
• Dù vậy, khái niệm hạm đội vẫn hữu ích: cấu hình (agent khác nhau cho công việc khác nhau), điều phối (handoff, phụ thuộc, leo thang), cấu trúc chỉ huy (quyết định nhiệm vụ, luật tác chiến, review kết quả), ca trực (khi chỉ huy ngủ thì hệ thống vẫn tiếp tục làm việc trong phạm vi chỉ thị và báo cáo lại vào buổi sáng)
• Tiêu chí của một hạm đội tốt không phải sản lượng mà là độ nhất quán của sản phẩm tạo ra
• Dạng công việc mới:
  • Buổi sáng triage và merge
  • Ở giữa ngày là công việc con người đòn bẩy cao — nói chuyện với khách hàng, chiến lược, quyết định sản phẩm, viết spec để điều khiển đợt chạy ban đêm
  • Buổi chiều review và chỉnh hướng khi những agent đầu tiên quay lại
  • Cuối ngày làm thứ mà thế hệ trước không làm — handoff — đưa công việc vào hàng chờ và chuyển spec cho hạm đội agent thử qua đêm; một số sẽ sai, một số sẽ tỏa sáng, và chỉ con người mới có thể phân biệt được điều đó

Hãy xây cho những model còn chưa ra mắt

• Một điểm được nhấn mạnh nhất quán trong vài năm qua: model bạn đang dùng hôm nay là model ngu nhất trong số các model bạn sẽ dùng về sau
• Dù vậy, không có gì bảo đảm tăng trưởng năng lực sẽ mượt mà — chi phí, độ trễ, độ tin cậy và giới hạn scaling có thể khiến đường cong trở nên phức tạp
• Nhưng cược vào hướng đi này vẫn được hậu thuẫn mạnh bởi những gì có thể quan sát ở tầng hạ tầng: năng lực frontier trong 6–12 tháng tới sẽ vượt hiện tại một cách có ý nghĩa, và khoảng cách giữa model tốt nhất hiện nay với model tốt nhất sau 1 năm có khả năng còn lớn hơn khoảng cách giữa năm ngoái và năm nay
• Hàm ý chiến lược: tổ chức cần xây dựng không phải quanh model hiện tại mà quanh năng lực tận dụng những model mà mình còn chưa có
  • Cách viết spec, văn hóa review, dây nối observability, vận hành hạm đội agent, các nghi thức huấn luyện để giữ kỹ năng cho junior — tất cả những điều này không phải là năng lực cho năm 2026 mà là giàn giáo cho 2027–2028
• Các công ty dựng giàn giáo này ngay bây giờ sẽ hấp thụ cú nhảy năng lực tiếp theo như một đòn bẩy; những công ty chờ công cụ trưởng thành sẽ tiêu tốn năm đầu tiên để học những gì người đi sớm đã biết
• Cần sẵn sàng đầu tư quá mức vào spec, review và kỷ luật vận hành so với mức mà model hiện tại đòi hỏi
• Sự trở nên không còn liên quan trong thời đại này không tự thông báo trước — nó đến như một sự bất lực tăng dần trong việc bắt kịp những team mà một năm trước còn chưa tốt hơn rõ rệt

Những cơ bắp sẽ bị mất đi

• Giả định rằng AI hoặc sẽ phân tầng xã hội một cách quyết định, hoặc phần lớn sẽ dân chủ hóa nó — con người vốn rất giỏi tối ưu theo con đường ít kháng cự nhất
• Mệnh đề cốt lõi: nếu không tự tay xây, bạn cũng sẽ mất khả năng đánh giá thứ đã được xây
• Điều này đã thành hiện thực: các kỹ sư junior lệ thuộc vào AI từ tuần đầu tiên có thể ship nhanh và tạo ra code bóng bẩy, nhưng khi model thất bại theo cách không ai dự đoán thì họ không tìm ra bug — vì họ chưa từng xây được mô hình nội tại về hệ thống, thứ chỉ hình thành khi vật lộn với stack trace lúc 2 giờ sáng đến lần thứ một trăm
• Gu thẩm mỹ (taste) không thể học bằng cách bấm duyệt lên một bản nháp bóng bẩy, phán đoán (judgment) không thể phát triển nếu thay vì dành cả buổi chiều cho một vấn đề khó thì chỉ mất 5 giây để chấp nhận câu trả lời nghe có lý từ máy, và tay nghề (craft) không thể có được chỉ bằng cách review công việc của agent khác
• Đây là khủng hoảng đào tạo mà phần lớn tổ chức vẫn chưa nhận ra
  • Mô hình học nghề của software engineering (junior ship thứ nhỏ → senior review → junior hấp thụ gu qua những dòng mực đỏ) đang sụp đổ — junior ship thông qua agent, còn senior review đầu ra của agent chứ không còn là đầu ra của con người
  • Tay nghề của thế hệ tiếp theo sẽ đến từ đâu? Huấn luyện gu thẩm mỹ thế nào nếu không có lặp đi lặp lại? Việc mentoring sẽ được thay thế ra sao khi mentee không viết ra mọi thứ ngay từ đầu?
• Trong phần lớn tổ chức truyền thống, thế hệ kỹ sư senior hiện tại là cohort cuối cùng được đào tạo trọn vẹn theo phương pháp cũ
• Cách phản ứng cân bằng là: có chủ đích và đều đặn, với một thứ gì đó quan trọng, hãy tự làm theo cách khó mà không dùng hạm đội — đa số đồng nghiệp sẽ không giữ được nhóm cơ đó, và 10 năm nữa điều này có thể tạo ra khác biệt

Phần khiến người ta bất an

• Bài luận này cố ý không kết thúc bằng sự lạc quan — giả vờ thay đổi sẽ không đến không thể ngăn nó cập bến
• Công việc đã thay đổi vĩnh viễn, và đang tiến hóa theo cách tăng dần, tiệm tiến cùng tốc độ của AI
• Con người sẽ lấy lại ban ngày cho những việc thực sự cần đến mình, còn máy sẽ chiếm lấy ban đêm cho những việc vốn luôn chỉ là lao động đơn giản
• Những kịch bản có thể xảy ra trong vài năm tới:
  • Một tầng lớp nhân sự kiệt sức vì gánh nặng review
  • Một tầng lớp vai trò bị phân hóa mà hệ thống cần nhưng không tưởng thưởng
  • Một thế hệ junior không phát triển được tay nghề mà senior hiện nay dùng để đưa ra phán đoán
  • Những team nhầm lẫn giữa sản lượng đầu ra với chất lượng công việc, và không nhận ra khoảng cách cho tới khi sự cố xảy ra
  • Khoảng cách ngày càng nới rộng giữa các tổ chức đã xây cơ bắp vận hành cho model tiếp theo với những tổ chức chưa làm
• Thông điệp cốt lõi: hãy xây tổ chức cho những model bạn còn chưa có, thỉnh thoảng tự tay làm điều khó để nhớ cách làm, rồi phái hạm đội ban đêm đi làm và ngủ ngon khi biết công việc vẫn đang tiếp diễn — nhưng phải luôn tỉnh táo trước khả năng một phần trong số những gì quay về đang sai theo những cách mà bạn không còn được rèn luyện để nhìn ra
• Nhân viên 24/7 không phải là một lời hứa mà là một sự tái phân bổ và một cú cược vào tương lai kỹ thuật xác suất — cược rằng con người trong vòng lặp vẫn đủ sắc bén, đủ trung thực và đủ được đào tạo để xứng đáng ở trong vòng lặp, và rằng tổ chức bao quanh con người đó được xây không phải cho model hôm nay mà cho những model còn chưa ra mắt