Các nhà phát triển hiện đang dành 11,4 giờ mỗi tuần để xem xét mã do AI tạo ra, vượt qua con số 9,8 giờ mà họ tự viết, theo một cuộc khảo sát năm 2026 trên 2.900 kỹ sư. Điểm nghẽn đã chuyển từ “liệu AI có thể tạo ra mã không?” sang “liệu chúng ta có thể tin tưởng mã mà nó tạo ra không?” và các nhóm đang chuyển hướng sang quy trình làm việc AI đa tác nhân (multi-agent AI workflows), hứa hẹn các dấu vết quyết định rõ ràng hơn và sự tin cậy cao hơn.

Cuộc khảo sát khơi mào cho cuộc thảo luận

Bản câu hỏi, được thực hiện vào đầu năm nay, đã hỏi các nhà phát triển về cách họ phân bổ thời gian giữa việc viết mã mới và kiểm tra mã do AI tạo ra. Những người tham gia cho biết việc xem xét hiện đang mất nhiều thời gian hơn so với việc tạo ra ban đầu. Họ cũng cho biết đang phải xoay xở với hai đến bốn trợ lý AI khác nhau trong cùng một dự án, và 70% cho biết việc này đã trở thành thói quen thường nhật.

Những con số này phản ánh một sự thất vọng ngày càng tăng: một mô hình đa năng duy nhất có thể viết một hàm chỉ trong vài giây, nhưng nó cũng đưa ra các lựa chọn ẩn về cấu trúc dữ liệu, xử lý lỗi và tối ưu hóa hiệu suất mà không để lại bất kỳ hồ sơ nào. Các nhà phát triển cuối cùng phải thực hiện kỹ thuật đảo ngược (reverse-engineering) các quyết định đó, một quá trình có thể tiêu tốn cả một ngày làm việc.

Tại sao một mô hình duy nhất không còn đủ nữa

Trong nhiều năm, quy trình làm việc điển hình diễn ra như thế này: một nhà phát triển nhập một câu lệnh (prompt), mô hình tạo ra một tệp, và nhà phát triển sao chép nó vào kho mã nguồn (codebase). Cách làm đó hiệu quả cho các bản demo nhanh, nhưng phần mềm thực tế (production software) đòi hỏi nhiều hơn là một kết quả đầu ra tức thì (one-shot output). Ví dụ, khi mô hình quyết định sử dụng danh sách liên kết (linked list) thay vì mảng (array) hoặc âm thầm nuốt các ngoại lệ (exceptions), những lựa chọn đó sẽ được nhúng vào mã và biến mất khỏi tầm mắt của người xem xét.

Vì quá trình suy luận nội bộ của mô hình không được ghi lại (log), các nhóm thường phải hỏi “tại sao AI lại chọn mẫu (pattern) này?” sau khi sự việc đã rồi. Câu trả lời thường đòi hỏi phải đào sâu qua các chú thích được tạo ra, chạy lại câu lệnh với các cài đặt nhiệt độ (temperature settings) khác nhau, hoặc thậm chí là tái lập lại toàn bộ bước tạo mã. Sự không chắc chắn đó hiện đang biểu hiện dưới dạng các giờ xem xét bổ sung trong cuộc khảo sát.

Chia nhỏ công việc: các hệ thống đa tác nhân giúp ích như thế nào

Các thiết lập đa tác nhân mô phỏng một nhóm phát triển nhỏ. Thay vì một mô hình xử lý mọi thứ, các tác nhân riêng biệt sẽ đảm nhận các trách nhiệm khác nhau:

  • Tác nhân Kiến trúc (Architect agent): tạo tài liệu thiết kế cấp cao, phác thảo các mô hình dữ liệu, hợp đồng API và các chiến lược xử lý lỗi.
  • Tác nhân Thực thi (Implementation agent): viết mã tuân thủ chính xác kiến trúc, sử dụng các thông số kỹ thuật như một danh sách kiểm tra (checklist).
  • Tác nhân Xác minh (Verification agent): tạo các bài kiểm thử đơn vị (unit tests), chạy phân tích tĩnh, hoặc thiết lập các đường ống CI/CD, chỉ tập trung duy nhất vào việc đảm bảo chất lượng.

Đầu ra của mỗi tác nhân là một tạo tác (artifact) riêng biệt, vì vậy lý do đằng sau một quyết định nằm ngay trong chính tạo tác đó. Việc xem xét kiến trúc trước khi bất kỳ dòng mã nào được viết ra sẽ tốn ít chi phí hơn nhiều so với việc sửa một lỗi phát sinh từ lựa chọn thiết kế sai lầm. Khả năng truy xuất nguồn gốc (traceability) cũng làm hài lòng các nhóm tuân thủ (compliance teams), những người cần biết ai (hoặc cái gì) đã quyết định một chi tiết triển khai cụ thể.

Các công cụ giúp quy trình làm việc đa tác nhân trở nên khả thi

Các nhà phát triển đã và đang lắp ghép các đường ống (pipelines) này bằng cách kết hợp nhiều tiện ích:

  • Tích hợp IDE cho phép các tác nhân xuất hiện dưới dạng các bảng điều khiển bên cạnh (side panels), chuyển tài liệu kiến trúc cho trợ lý tạo mã chỉ bằng một cú nhấp chuột.
  • Tiện ích CLI cho phép thực hiện các chuỗi kịch bản: chạy tác nhân kiến trúc, chuyển đầu ra của nó sang tác nhân lập trình, sau đó chuyển kết quả cho tác nhân kiểm thử.
  • Các Framework cung cấp các thư viện để xây dựng các tác nhân tùy chỉnh có thể được thay thế tùy theo nhu cầu của dự án.
  • Các nền tảng ưu tiên đặc tả (Specification-first platforms) yêu cầu một tệp yêu cầu chính thức trước khi bất kỳ quá trình tạo mã nào bắt đầu, đảm bảo bước thiết kế không thể bị bỏ qua.

Con số 70% từ cuộc khảo sát cho thấy hầu hết các nhóm đã xây dựng các phiên bản tùy biến (ad-hoc) của các đường ống này. Các nền tảng mới đơn giản là chính thức hóa những gì các kỹ sư đang thực hiện một cách thủ công.

Ai sẽ được hưởng lợi — và ai có thể bị bỏ lại phía sau

Các doanh nghiệp phải đáp ứng các yêu cầu kiểm toán nghiêm ngặt, chẳng hạn như trong lĩnh vực tài chính hoặc y tế, sẽ được hưởng lợi ngay lập tức. Một chuỗi quy trình từ thiết kế đến mã nguồn (design-to-code chain) được ghi chép lại sẽ giảm thiểu rủi ro các lỗ hổng tiềm ẩn lọt vào môi trường thực tế. Các startup nhỏ hơn có thể thấy việc duy trì nhiều tác nhân là không cần thiết nếu họ chuyển động đủ nhanh để tốc độ của một mô hình duy nhất bù đắp được chi phí của việc phải làm lại đôi khi.

Một lập luận phản bác cho rằng các hệ thống đa tác nhân làm tăng thêm sự phức tạp. Việc điều phối từ ba mô hình trở lên có thể dẫn đến các lỗi tích hợp, tăng độ trễ và yêu cầu giám sát tinh vi hơn. Những đội ngũ thiếu chuyên môn để xây dựng hoặc quản lý các tác nhân tùy chỉnh có thể dành nhiều thời gian cho việc điều phối hơn là phát triển thực tế. Đối với những nhóm này, một mô hình đơn lẻ được tinh chỉnh tốt—đặc biệt là mô hình cung cấp khả năng giải thích tích hợp sẵn—có thể vẫn là lựa chọn thực tế.

Những điều cần theo dõi trong những tháng tới

  • Các định dạng nhật ký chuẩn hóa cho các sản phẩm do AI tạo ra có thể giúp việc so sánh kết quả đầu ra giữa các tác nhân khác nhau trở nên dễ dàng hơn.
  • Các gói dịch vụ trên thị trường kết hợp các tác nhân kiến trúc, lập trình và kiểm thử vào một gói đăng ký duy nhất có thể hạ thấp rào cản cho các đội ngũ không có chuyên môn AI nội bộ.
  • Các hướng dẫn về quy định đối với mã nguồn được hỗ trợ bởi AI có thể thúc đẩy nhiều tổ chức hướng tới các quy trình đa bước có thể kiểm chứng được.
  • Các tiêu chuẩn đánh giá hiệu suất đo lường tổng thời gian phát triển—chứ không chỉ tốc độ tạo—sẽ giúp các đội ngũ quyết định liệu chi phí điều phối bổ sung có mang lại hiệu quả hay không.

Những con số nổi bật từ cuộc khảo sát đã kể một câu chuyện rõ ràng: các nhà phát triển dành nhiều thời gian trong tuần để kiểm tra lại kết quả của AI hơn là viết mã mới. Các quy trình làm việc đa tác nhân xuất hiện như một phản ứng trực tiếp, cung cấp khả năng truy xuất nguồn gốc giúp chuyển đổi việc tạo mã kiểu "hộp đen" thành một quy trình có tài liệu và có thể kiểm duyệt. Liệu sự phức tạp trong điều phối tăng thêm có xứng đáng với mọi đội ngũ hay không vẫn còn phải chờ xem, nhưng xu hướng chia nhỏ các trách nhiệm AI đang tái định hình cách phần mềm được xây dựng.