Khi agent viết code, việc của FDE dồn về ba chỗ: định nghĩa, ràng buộc và phán xét

Theo Addy Osmani, GitHub đã phân tích hơn 2.500 file cấu hình agent và phát hiện phần lớn chúng hỏng vì một lý do rất tầm thường: viết quá mơ hồ. Vấn đề nằm ở chỗ người viết chưa nói rõ mình muốn gì.

Phát hiện đó khớp với điều Cognition trình bày tại AI Engineer World’s Fair 2026. Theo công ty này, sinh code nhanh hơn không giải quyết hết vấn đề, vì kiểm thử, review, triển khai và bảo trì vẫn còn nguyên đó. Nút cổ chai không biến mất mà chỉ chuyển sang chỗ khác.

Với developer đang muốn chuyển sang FDE, đây là tín hiệu đáng chú ý. Gõ code nhanh không còn là kỹ năng khiến người ta trả tiền cho bạn. Phần đắt giá là ba việc agent chưa làm thay được: định nghĩa bài toán, ràng buộc agent và phán xét kết quả.

Freelancer thực thi, FDE quyết định

Trong bài luận về forward deployed AI engineering, Ghanemzadeh vạch một ranh giới rất gọn: freelancer thì thực thi, còn FDE thì quyết định. Theo cách ông mô tả, FDE là người vận hành có chính kiến về việc nên xây gì, theo thứ tự nào, xây ra sao và thành công được đo bằng gì.

Câu hỏi đầu tiên của việc định nghĩa nghe đơn giản nhưng hay bị bỏ qua nhất: người dùng là ai. Ghanemzadeh viết thẳng rằng nếu bạn không gọi tên được người dùng thì bạn chưa có một engagement FDE nào cả. Một yêu cầu kiểu “khách muốn có agent AI” mới chỉ là mong muốn, chưa đủ để thành bài toán.

Thử hình dung một ngân hàng muốn dùng agent để xử lý hồ sơ vay. “Tự động hóa thẩm định” nghe thì có vẻ cụ thể nhưng chẳng chỉ dẫn được gì.

Đổi thành “chuyên viên thẩm định ở chi nhánh, mỗi ngày mất phần lớn thời gian đối chiếu giấy tờ”, bạn lập tức biết cần đo gì, ưu tiên làm gì trước và khi nào thì coi là xong.

Agent không tự làm được bước này. Nó không ngồi cạnh chuyên viên thẩm định, không thấy họ bực ở thao tác nào. Đó là lý do định nghĩa vẫn thuộc về người đứng ở hiện trường.

Ràng buộc là một spec sống, không phải một câu prompt

Một bài trên blog fde.academy mô tả vai trò mới của kỹ sư khi làm việc với agent là định nghĩa nhiệm vụ, đặt ràng buộc rồi điều hướng agent. Đây là quan điểm của người làm nghề chứ không phải nghiên cứu.

Dù vậy, nó khớp với phát hiện của GitHub ở trên: các file cấu hình agent hỏng vì mơ hồ, tức là hỏng ngay ở khâu ràng buộc.

Osmani dẫn quan điểm spec-driven development của GitHub, theo đó spec trở thành nguồn sự thật chung, một tài liệu sống, thực thi được và thay đổi cùng dự án.

Chữ “sống” quan trọng: spec không phải văn bản viết một lần lúc kickoff rồi cất đi, mà là bản hợp đồng giữa bạn, khách hàng và agent, được cập nhật mỗi khi hiện trường cho thấy một điều mới.

Quay lại ví dụ ngân hàng. Một ràng buộc tốt có thể là “agent chỉ đánh dấu hồ sơ thiếu giấy tờ, không bao giờ tự từ chối hồ sơ”. Một câu như vậy làm được hai việc: nó giới hạn hành vi của agent, đồng thời ghi lại một quyết định nghiệp vụ mà người viết code sau này phải tôn trọng.

Viết được câu ràng buộc ấy đòi hỏi bạn hiểu rủi ro của khách hàng, không chỉ hiểu cú pháp prompt. Ràng buộc vì thế nối thẳng với định nghĩa: không biết người dùng là ai thì cũng không biết điều gì tuyệt đối không được xảy ra với họ.

Vì sao phán xét thành nút cổ chai mới?

Nếu định nghĩa và ràng buộc là đầu vào, thì phán xét là chỗ áp lực dồn lên nhiều nhất. Osmani gọi thẳng tên vấn đề: AI sinh code nhanh hơn rất nhiều so với tốc độ con người đánh giá được nó. Review đã trở thành bài toán thông lượng.

Phản xạ đầu tiên của nhiều đội là dựa vào test. Osmani đồng ý test là cần thiết, nhưng ông nói rõ test thôi chưa đủ. Test chỉ kiểm tra những gì người viết test đã nghĩ tới, còn câu hỏi “code này có đúng với điều khách hàng cần không” vẫn phải có người hiểu nó trả lời.

Ông còn đi xa hơn: giả định quen thuộc trong các tổ chức rằng code đã review là code đã được hiểu không còn đúng nữa. Khi một người duyệt hàng chục PR do agent viết mỗi ngày, nút approve chỉ xác nhận rằng code đã được nhìn qua. Nó không chứng minh có ai thực sự hiểu.

Cognition đưa câu chuyện lên tầm doanh nghiệp. Các doanh nghiệp lớn trong ngành bị quản lý chặt muốn biết hệ thống có tạo ra giá trị hay không, chứ không quan tâm nó có đang bận rộn hay không. Agent chạy suốt đêm, mở hàng trăm PR, vẫn có thể chẳng đem lại gì.

Phân biệt “bận” với “có giá trị” là một phán xét, và phán xét ấy dựa trên định nghĩa thành công đã đặt từ đầu. Bài trên fde.academy kết luận rằng lớp phán xét không bị tự động hóa chỉ vì lớp viết code đã nhanh lên. Đó là một ý kiến, nhưng các dữ kiện của Osmani và Cognition đều nghiêng về phía nó.

Ba việc, ba kiểu thất bại

Nhìn cả ba việc cùng lúc sẽ thấy mỗi việc có một kiểu thất bại riêng, và kiểu nào cũng có thể bị che đi bởi một agent làm việc rất chăm chỉ.

Việc của FDE	Câu hỏi phải trả lời	Dấu hiệu đang làm hỏng	Cách luyện
Định nghĩa	Người dùng là ai, xây gì trước, thành công đo bằng gì?	Không gọi tên được người dùng; yêu cầu chỉ là “làm agent AI”	Viết một câu mô tả người dùng và một chỉ số thành công cho mỗi ticket
Ràng buộc	Agent được làm gì, tuyệt đối không được làm gì?	File cấu hình hay spec mơ hồ; spec viết một lần rồi bỏ đó	Duy trì spec như tài liệu sống, cập nhật sau mỗi lần agent làm sai
Phán xét	Kết quả có tạo ra giá trị không, mình có hiểu code không?	Coi test pass là xong; coi đã review là đã hiểu; nhầm “bận” với “có giá trị”	Tự giải thích được từng thay đổi trước khi approve; đo kết quả theo tiêu chí đã định nghĩa

Phán xét quay về định nghĩa

Cognition mô tả việc giao hàng cho khách và phản hồi sản phẩm là cùng một vòng lặp, theo đó những gì học được ở hiện trường quay lại định hình quyết định sản phẩm. Với ba việc trên, vòng lặp ấy có hình hài rõ ràng: phán xét ở cuối đưa thông tin ngược về định nghĩa và ràng buộc ở đầu.

Một cách chẩn đoán hữu ích khi phán xét thấy kết quả không đem lại giá trị: trước khi đổ lỗi cho agent, hãy kiểm tra lại xem người dùng đã được gọi tên đúng chưa và spec có còn mơ hồ ở đâu không. Thường thì sửa đầu vào rẻ hơn sửa đầu ra.

Cũng vì thế mà ba việc này khó chia cho ba người. Người định nghĩa người dùng nên là người phán xét kết quả, nếu không sẽ chẳng ai nhận ra spec đã lệch khỏi thực tế. Đây là lý do FDE là một vai trò chứ không phải một dây chuyền.

Nhu cầu cho vai trò này đang tăng. The Pragmatic Engineer ghi nhận nhu cầu tuyển FDE rất lớn tại Google, OpenAI và Anthropic. Khi các công ty làm ra agent cũng đang tuyển người đứng giữa agent và khách hàng, có thể đoán được họ đang thiếu kỹ năng gì.

Developer Việt Nam nên luyện gì?

Nhiều developer Việt Nam trưởng thành trong môi trường outsource, nơi yêu cầu được chốt từ phía khách và đội ngũ chỉ việc thực thi. Đó đúng là mô hình mà Ghanemzadeh gọi là freelancer. Muốn sang FDE, bạn phải tập tự đặt ra những câu hỏi mà trước đây người khác trả lời thay bạn.

Hãy bắt đầu từ công việc hiện tại. Trước khi giao một ticket cho agent, viết một câu gọi tên người dùng, một tiêu chí thành công đo được và ba ràng buộc mà agent không được vi phạm. Nếu không viết được, ticket ấy chưa sẵn sàng, dù là cho agent hay cho người.

Khi đọc mô tả công việc FDE, hãy để ý các cụm như làm việc trực tiếp với khách hàng, xác định yêu cầu, chịu trách nhiệm về kết quả.

Trong CV, đừng chỉ liệt kê tính năng đã xây mà hãy kể bạn đã xác định ai là người dùng, đã đặt tiêu chí thành công nào và đã kiểm chứng ra sao rằng hệ thống tạo ra giá trị thay vì chỉ chạy.

Agent sẽ còn viết code nhanh hơn nữa. Người tuyển dụng sẽ không hỏi bạn sinh được bao nhiêu dòng code, mà hỏi bạn có biết dòng nào đáng giữ lại không.