Từ người viết đến người quản lý: công việc của nhà phát triển thay đổi ra sao khi làm việc với agent

Agent giúp giảm đáng kể chi phí viết code. Nhưng việc hiểu chính xác cần xây dựng gì và kiểm tra kết quả thì không rẻ hơn. Vì vậy, phần đáng chú ý nhất khi làm việc với agent diễn ra trước và sau lúc viết code: ai giao nhiệm vụ, ai quyết định kết quả đạt yêu cầu, và nên giao cho agent bao nhiêu việc.

Dưới đây là cách các nghiên cứu và báo cáo trong hai năm gần đây mô tả vấn đề này: bốn cách làm việc với agent, cách chọn theo nhiệm vụ và điều thường được gọi là "ý định và chuẩn chất lượng". Nửa sau bài viết nói về việc vai trò của nhà phát triển đang mở rộng ra ngoài chuyện viết code. Dữ liệu cập nhật đến tháng 9 năm 2026. Các con số nằm trong những khung riêng kèm liên kết nguồn. Khi thuật lại quan điểm của tác giả nghiên cứu, tôi sẽ nêu tên họ; nhận định của mình cũng được đánh dấu riêng.

Bốn cách làm việc với agent

Tháng 5 năm 2026, Jared Spataro của Microsoft đưa ra khung phân loại rõ ràng nhất. Ông mô tả bốn cách con người và AI chia sẻ công việc. Khung này dễ hiểu, và nhà phát triển sẽ nhận ra trong đó chặng đường của chính mình với các công cụ.

Càng lên bậc cao, bạn càng ít tự viết code và càng phải quyết định nhiều hơn từ trước rồi kiểm tra sau. Người viết tự giữ tiêu chuẩn chất lượng trong đầu khi làm. Người chỉ đạo không còn theo dõi được code hình thành thế nào, nên mọi điều quan trọng phải được nói rõ trước khi bắt đầu và kiểm tra sau khi xong. Ở đây, vai trò điều phối chỉ được nhắc tên: đó là chủ đề lớn riêng, có bộ công cụ riêng, phù hợp khi ba cách đầu đã vận hành ổn định.

Chọn cách theo nhiệm vụ, không phải leo bậc

Rất dễ coi khung này như một chiếc thang: trước tiên bạn là người viết, sau đó tiến lên vai trò điều phối, và càng cao càng tốt. Spataro nói rõ điều ngược lại. Mục tiêu không phải chuyển mọi nhiệm vụ sang cách thứ tư, mà là chọn cách phù hợp cho từng luồng công việc.

Trên thực tế, việc lựa chọn xoay quanh bốn câu hỏi:

• Mục tiêu rõ đến đâu? Nếu chính bạn còn chưa biết kết quả cần đạt là gì thì chưa nên giao trọn nhiệm vụ;
• Có thể kiểm tra kết quả tự động không? Test tốt giúp bạn giao agent nhiều quyền chủ động hơn, vì hệ thống kiểm tra sẽ bắt lỗi thay vì trông chờ vào sự chú ý của bạn;
• Sai sót gây tốn kém thế nào? Lỗi chính tả trong tooltip dễ sửa, còn tính sai tiền thì cái giá phải trả cao hơn;
• Nhiệm vụ có lặp lại không? Dựng quy trình riêng cho việc chỉ làm một lần thường không đáng, còn việc lặp lại hằng tuần thì hoàn toàn đáng.

Thử áp dụng vào một vài nhiệm vụ cụ thể:

Theo tôi, nên ghi nhớ những con số này. Đa số thận trọng không có nghĩa là tụt hậu: mọi người chọn cách làm dựa trên cái giá của sai sót, và như vậy là hợp lý. Nếu bạn đóng vai trò biên tập viên trong một nhiệm vụ mà sai sót rất tốn kém, điều đó không có nghĩa là bạn "chưa tận dụng hết" agent.

Trong Claude Code, bạn có thể điều chỉnh lựa chọn này trực tiếp. Plan mode và các quy tắc quyền hoạt động như nút điều chỉnh do chính bạn kiểm soát. Với nhiệm vụ rủi ro cao, hãy bật kế hoạch trước khi sửa và yêu cầu xác nhận các thao tác nguy hiểm; với việc thường lệ, bạn có thể để agent chủ động hơn.

Ý định và chuẩn chất lượng

Càng giao nhiều việc, điều bạn nói trước khi bắt đầu càng quan trọng. Nghiên cứu của Microsoft diễn đạt như sau: những người dùng AI hiệu quả nhất sẽ không phải là người làm được nhiều việc hơn và nhanh hơn, mà là người xây dựng giá trị quanh những gì chỉ con người mới làm được. Họ đặt ra ý định rõ ràng, tức mô tả kết quả mong muốn và chuẩn chất lượng, đồng thời tính trước cách chia công việc giữa con người và AI.

Trong phát triển phần mềm, ý tưởng này vốn đã có những tên gọi quen thuộc. Ý định là đặc tả: cần làm gì và vì sao. Chuẩn chất lượng gồm các tiêu chí nghiệm thu và điều Scrum gọi là Definition of Done: danh sách điều kiện để xem công việc đã xong. Từ đây, ta gọi ngắn gọn là chuẩn hoàn thành.

Daniel Epstein của Microsoft, người xây dựng agent theo Agile, tóm tắt ý này trong bài đầu tiên trong loạt Agentic-Agile (ngày 19 tháng 5 năm 2026): "Every capability is an issue. Every issue has acceptance criteria." Mỗi tính năng là một issue, và mỗi issue đều có tiêu chí nghiệm thu.

Tiện nhất là viết nhiệm vụ cùng lúc theo hai lối diễn đạt. Với con người, giải thích vì sao cần làm và ai cần nó. Với agent, nêu rõ phải làm gì, kiểm tra bằng cách nào và không được đụng đến phần nào. Đây là ví dụ minh họa cho cùng một yêu cầu trước và sau khi viết rõ hơn. Ở phiên bản thứ hai, đoạn đầu dành cho con người, phần còn lại dành cho agent.

Trước:

Thêm tính năng xuất chi phí ra CSV cho ổn nhé.

Sau:

Lý do: mỗi tháng, kế toán phải chép chi phí của nhóm vào bảng tính riêng
bằng tay. Việc này mất một giờ và dễ nhầm số tiền.

Nhiệm vụ: thêm nút "Xuất CSV" vào trang chi phí theo tháng.

Hoàn thành khi:
- có thể mở file bằng cách nhấp đúp trong ứng dụng bảng tính, tên tiếng Việt
  hiển thị chính xác mà không cần tự chỉnh bộ mã hóa;
- mỗi dòng ứng với một khoản chi, dòng đầu tiên chứa tên các cột;
- có thể cộng các khoản tiền bằng công thức mà không cần sửa ô.

Không thay đổi: định dạng lưu trữ chi phí và màn hình danh sách hiện tại.
Trước tiên, hãy trình bày kế hoạch và cách kiểm tra từng mục.

Trong phiên bản thứ hai, agent gần như không còn gì phải đoán. Quan trọng hơn, bạn có cơ sở để đối chiếu kết quả: có thể tự kiểm tra ba tiêu chí chỉ trong vài phút. Không thể kiểm chứng từ "cho ổn" ở phiên bản đầu; bạn chỉ có thể tin vào nó.

Agent không biết thế nào là tốt

Từ đây trở đi, phần lớn là nhận định của tôi dựa trên dữ liệu, chứ không phải bản thân dữ liệu. Tôi nói rõ ngay để không biến ý kiến thành kết quả nghiên cứu.

Agent làm được rất nhiều việc: đọc một project chưa quen, tìm nguyên nhân gây lỗi, viết phần triển khai, chạy test và giải thích những gì nó đã làm. Nhưng có một việc agent không thể tự làm: quyết định "làm tốt" nghĩa là gì với những người dùng và doanh nghiệp này. Không có tiêu chí, agent sẽ chọn một phương án trung bình nghe có vẻ hợp lý rồi tự tin báo rằng đã hoàn thành. Code có thể gọn gàng, nhưng giải pháp vẫn có thể sai mục tiêu.

"Tốt" không nằm trong code. Điều đó phụ thuộc vào ai sẽ dùng kết quả, điều gì quan trọng với họ và sai sót nào không thể chấp nhận. Trong ví dụ xuất file, agent hoàn toàn có thể tạo ra một file CSV đúng về mặt kỹ thuật nhưng khi kế toán mở thì chỉ thấy ký tự lỗi. Xét về code, mọi thứ đều đúng. Xét theo yêu cầu, thì không.

Kết luận rất đơn giản. Đặt tiêu chí rồi kiểm tra kết quả theo tiêu chí đó là phần việc không thể giao cho agent. Agent có thể giúp bạn diễn đạt tiêu chí, đặt câu hỏi để làm rõ và đề xuất cách kiểm tra. Nhưng quyết định tiêu chí có đúng hay không vẫn là của bạn.

Trước tiên, hãy hiểu quy trình

Tiêu chí đến từ đâu? Hầu như không bao giờ từ code. Chúng xuất phát từ quy trình nghiệp vụ: ai sẽ mở file, họ sẽ làm gì tiếp theo, điều gì xảy ra nếu một dòng bị mất hoặc số tiền bị làm tròn sai.

Yêu cầu "tên tiếng Việt phải đọc được mà không cần tự chỉnh" không xuất hiện vì đó là cách viết CSV đúng chuẩn. Nó xuất hiện vì có người hỏi kế toán cách họ mở file và thấy họ chỉ nhấp đúp, không dùng trình hướng dẫn nhập dữ liệu. Nhà phát triển hiểu quy trình sẽ viết tiêu chí này ngay từ đầu. Người chưa hiểu sẽ biết đến nó qua một lời phàn nàn một tháng sau.

Các công ty cũng đã nhận ra điều này và đang điều chỉnh lại vai trò.

Cũng có một quan điểm trái chiều đáng để biết. Chẳng hạn, công ty tư vấn Converteo trong blog của mình mô tả vai trò quản lý sản phẩm, nhà thiết kế và AI product builder là bổ trợ cho nhau chứ không cạnh tranh: người thứ nhất phụ trách câu hỏi "vì sao", người thứ hai quan tâm đến người dùng, còn người thứ ba nhanh chóng biến ý tưởng thành nguyên mẫu hoạt động được. Bản thân Converteo cũng bán dịch vụ trong lĩnh vực này. Tôi sẽ không đặt cược vào bên nào. Với bạn, kết luận thực tế vẫn vậy: nhà phát triển hiểu quy trình của khách hàng có giá trị hơn người chỉ chờ một ticket được viết hoàn hảo.

Trò chuyện cũng là công cụ làm việc

Trước đây, soft skills thường được xem là phần bổ sung dễ chịu cho kỹ năng kỹ thuật. Làm việc với agent khiến điều đó thay đổi. Tiêu chí chất lượng nằm trong đầu mọi người chứ không nằm trong repository, và chỉ có thể tìm hiểu chúng bằng cách trò chuyện.

Trên thực tế, những việc sau cũng là một phần của công việc:

• hỏi. Đừng chỉ hỏi "cần làm gì", hãy hỏi "bạn sẽ dùng kết quả này như thế nào" - câu trả lời thường cụ thể hơn;
• làm rõ. Hỏi thêm về tình huống biên trước khi nó biến thành bug: phải xử lý khoản chi chưa có danh mục thế nào?
• ghi lại. Agent không đọc được thỏa thuận chỉ nằm trong cuộc trò chuyện, còn đồng nghiệp thì có thể quên;
• thống nhất phạm vi. Việc gì thuộc nhiệm vụ, việc gì không, và nói "đó là nhiệm vụ riêng" khi có người nhờ "tiện thể sửa luôn";
• giải thích sự đánh đổi. "Có thể làm trong một ngày nếu không chọn khoảng thời gian, hoặc ba ngày nếu có lựa chọn đó" - khách hàng quyết định, nhưng bạn đưa ra các phương án.

Không kỹ năng nào trong số này liên quan đến code, nhưng mỗi kỹ năng đều ảnh hưởng trực tiếp đến việc agent sẽ làm. Nói cách khác, chất lượng cuộc trò chuyện của bạn với mọi người quyết định chất lượng yêu cầu giao cho agent.

Ai cũng có chút vai trò CEO

Gom mọi thứ lại, bạn sẽ thấy một bức tranh quen thuộc. Đặt mục tiêu, xác định tiêu chí, phân chia công việc, kiểm tra kết quả và chịu trách nhiệm về kết quả - đó là công việc của người quản lý. Khi làm việc với agent, nhà phát triển thực hiện những việc ấy mỗi ngày, dù ở quy mô nhỏ.

Ẩn dụ CEO có một điểm đúng: nó cho thấy trách nhiệm thuộc về ai. CEO có thể giao hầu hết mọi việc, trừ trách nhiệm về kết quả. Với agent cũng vậy. Nếu agent tạo ra file xuất làm hỏng bảng tính của kế toán, người chịu trách nhiệm không phải agent.

Cũng cần nói rõ ẩn dụ này không có nghĩa gì. Đây không phải là thăng chức, và không ai trở thành quản lý chỉ vì khởi chạy ba agent. Đúng hơn, kỹ năng quản lý sẽ cần đến sớm hơn trước đây, ngay từ công việc đầu tiên. Nhưng có một rủi ro: nhà phát triển từ lâu đã tiến bộ bằng cách tự viết code, và con đường đó đang thay đổi. Bạn vẫn phải hiểu code mình nhận từ agent. Nếu không, việc kiểm tra chỉ còn là "có vẻ chạy được".

Cách đọc những dữ liệu này

Tất cả số liệu phía trên đều do các công ty bán AI hoặc sản phẩm liên quan công bố. Điều đó không làm chúng thành sai, nhưng bạn nên cân nhắc. Tóm tắt nhanh:

Tất cả tỷ lệ phần trăm ở đây đều là tự đánh giá tại một thời điểm. Chúng cho thấy mọi người nghĩ và kỳ vọng điều gì, chứ không cho biết chuyện gì thực sự đã xảy ra. Tác giả Work Trend Index 2026 nói rõ rằng các mối liên hệ trong phân tích là tương quan thống kê, không phải quan hệ nhân quả.

Với bất kỳ con số nào về AI và công việc, bạn nên đặt ba câu hỏi. Ai đã tài trợ nghiên cứu? Họ đo điều gì: ý kiến, kỳ vọng hay kết quả thực tế? Họ hỏi những ai, và những người đó có giống bạn không? Nếu câu trả lời thuyết phục, bạn có thể sử dụng con số ấy. Nếu không, nó vẫn có thể đáng quan tâm, chỉ là không nên xem trọng bằng.

Vậy điều này hữu ích gì?

Những điều nghe như ngôn ngữ báo cáo ở trên sẽ trở thành thói quen cụ thể khi làm việc với Claude Code:

• lập kế hoạch trước khi sửa - đó chính là ý định. Hãy yêu cầu agent trình bày trước những gì sẽ thay đổi và cách thực hiện, rồi đối chiếu với điều bạn mong muốn;
• đưa tiêu chí nghiệm thu vào yêu cầu - đó là chuẩn hoàn thành của bạn. Nêu hai hoặc ba điểm có thể kiểm tra thay vì "cho ổn";
• chế độ làm việc và quy tắc quyền - lựa chọn cách làm. Sai sót càng tốn kém thì agent càng nên dừng lại và hỏi thường xuyên;
• xem diff và kiểm tra nghiêm túc - đánh giá kết quả theo tiêu chí của bạn, không chỉ dựa vào báo cáo của agent;
• tóm tắt ngắn: đã làm gì, kiểm tra bằng cách nào, còn điều gì chưa kiểm tra - trách nhiệm về kết quả không thể giao cho agent.

Dữ liệu cập nhật đến tháng 9 năm 2026. Nghiên cứu trong lĩnh vực này được công bố thường xuyên, và số liệu lỗi thời nhanh hơn các kết luận.