Agent của tôi đã đẩy 3 PR chỉ trong một buổi tối. 40% tin nhắn của tôi là để chỉnh sửa.

Agent lập trình dựa trên AI của tôi đã đẩy ba pull request chỉ trong một buổi tối, nhưng 40% trong số 30 tin nhắn tôi gửi đi là để chỉnh sửa.

Phiên làm việc đã tạo ra một MCP client, một Azure AI Agent và một M365 Copilot Agent. Các bước kiểm tra tự động đã thông qua cả ba PR, và tôi chưa từng phải chỉnh sửa một dòng code nào. Tuy nhiên, bản ghi chép lại kể một câu chuyện khác: trong tổng số 710 tin nhắn, tôi đã nhập 30 tin, và 12 trong số đó là để đưa agent trở lại đúng hướng. “Tỷ lệ điều hướng” (steering rate) – tỷ trọng các tin nhắn chỉnh sửa của tôi – nằm ở mức 40%.

Cách thiết lập pipeline

  • Claude phác thảo một kế hoạch triển khai cấp cao.
  • DeepSeek V4-Flash đóng vai trò là bộ điều phối (orchestrator), xem xét kế hoạch.
  • Codex tạo ra mã nguồn thực tế.
  • Bộ điều phối kiểm tra mã nguồn và mở các pull request.

Vai trò dự kiến của bộ điều phối thuần túy là kết nối – nó nên giải quyết các xung đột giữa các thành phần, chứ không phải tự viết code. Trên thực tế, agent đã tạo ra 3.500 dòng code thông qua ba PR trong khoảng 40 phút, nhưng nó cũng mắc phải hai loại lỗi lặp đi lặp lại.

Hai nhóm lỗi chính

  1. Vi phạm quy trình làm việc – thỉnh thoảng bộ điều phối lại đảm nhận luôn bước lập trình, phớt lờ vai trò "kết nối" (glue role) của mình và tự viết các chi tiết triển khai.
  2. Lỗi truy xuất ngữ cảnh – mặc dù đã có hướng dẫn rõ ràng, agent vẫn chọn sai SDK hoặc phiên bản. Thông tin chính xác đã có sẵn trong ngữ cảnh của prompt, nhưng mô hình đã không thể đưa nó ra đúng thời điểm.

Đây không phải là lỗ hổng về khả năng lập luận; chúng là những lỗi kỹ thuật (engineering bugs) trong cách ràng buộc quy trình làm việc. Ngay cả một mô hình ngôn ngữ mạnh mẽ hơn cũng sẽ cần một quy tắc cứng nhắc, không thể bỏ qua để buộc bộ điều phối phải tuân thủ các nhiệm vụ không liên quan đến lập trình và bắt buộc chọn đúng SDK.

Tôi đã thay đổi gì để kiểm soát agent

Tôi đã ngừng giả định rằng hệ thống sẽ tự suy luận vai trò của nó từ danh sách các bước. Tôi đã thêm một câu khẳng định trực tiếp: “Bạn là một bộ điều phối. Bạn không được triển khai mã nguồn.” Phải mất năm tin nhắn chỉnh sửa thì hướng dẫn này mới thực sự có hiệu lực, sau đó agent đã tôn trọng ranh giới này.

Tôi cũng thắt chặt logic truy xuất ngữ cảnh. Khi một công cụ sai xuất hiện, tôi coi đó là một lỗi trong pipeline truy xuất thay vì là một sự ảo giác (hallucination), và tôi đã viết lại prompt cung cấp chi tiết SDK để đảm bảo phiên bản chính xác không thể bị bỏ sót.

Những bài học thực tế cho phát triển phần mềm với sự hỗ trợ của AI

  • Hãy đếm số tin nhắn của chính bạn. Một lượng lớn PR được chấp nhận có thể che lấp một quy trình đang bị lỗi. Số lượng tin nhắn chỉnh sửa là chỉ số báo trước cho thấy nơi mà hệ thống đang bị rò rỉ.
  • Nêu rõ vai trò một cách tường minh. Các agent không tự suy diễn danh tính từ một danh sách kiểm tra; chúng cần một hướng dẫn rõ ràng, cố định về việc chúng là ai và chúng được phép làm gì.
  • Coi lỗi chọn công cụ là lỗi kỹ thuật. Nếu agent phớt lờ một SDK đã chỉ định, lỗi nằm ở cơ chế truyền tải ngữ cảnh, chứ không phải ở "kiến thức" của mô hình.
  • Chuyển đổi sai lầm thành các kỹ năng có thể tái sử dụng. Tôi đã để agent tự tạo ra một quy trình kiểm chứng (validation routine) từ chính những lỗi của nó, biến một thất bại thành một cơ chế bảo vệ trong tương lai.

Những thách thức lớn hơn