Tôi ngừng review code của AI agent. Đây là cách tôi làm thay thế

Có một sự thay đổi lớn đang diễn ra trong cách các lập trình viên làm việc với AI agent. Alexey Indeev, một kỹ sư đang xây dựng nền tảng vận hành nội bộ Sightline tại Spare, đã chia sẻ trải nghiệm của mình: anh hợp nhất 562 pull request trong hai tuần, và bốn trong số những đêm đó anh đi bộ đường dài trên núi. Điều đáng chú ý là anh gần như không còn review từng dòng code do AI viết ra nữa.

Điều gì đã thay đổi?

Theo Indeev, các mô hình ngôn ngữ lớn đã tiến bộ vượt bậc trong vài tuần gần đây, đặc biệt là các phiên bản mới nhất. Cách đây không lâu, anh sẽ không bao giờ dám khuyên ai làm việc theo cách này, vì luôn cảm thấy phải tự kiểm tra chất lượng code trước khi hợp nhất.

"Bây giờ tôi cảm thấy một agent có thể tự mình hoàn thành cả một kế hoạch, miễn là hai thứ được thiết lập đúng: ý định đúng đắn và hệ thống guardrails đủ chặt để đảm bảo ý định đó thực sự được đáp ứng."

Điểm mấu chốt là vai trò của con người đã dịch chuyển. Thay vì kiểm tra code, kỹ sư giờ đây dành phần lớn thời gian để review kế hoạch và xây dựng hệ thống bảo vệ.

Guardrails mới là công việc thực sự

Indeev lập luận rằng code do AI tạo ra là phi tất định (non-deterministic) và có rủi ro — nhưng code do con người viết cũng vậy. Chúng ta từng xây dựng các hệ thống SRE để con người không mắc lỗi, và giờ đây cần những hệ thống tương tự nhưng mạnh mẽ hơn nhiều để AI agent cũng không mắc lỗi.

Mỗi pull request của Sightline phải vượt qua toàn bộ các rào cản sau trước khi được hợp nhất:

• Kiểm thử đơn vị (unit tests)
• Kiểm thử đầu-cuối (end-to-end tests)
• CI, Bugbot, Strix
• Mergify sẽ không cho PR vào hàng đợi hợp nhất cho đến khi tất cả các bước trên đều đạt

Điểm đặc biệt là các guardrails cũng tự bảo vệ lẫn nhau. Đội ngũ yêu cầu Bugbot liên tục đòi thêm kiểm thử, tạo ra vòng phản hồi khép kín trong CI. Khi có lỗi lọt qua, họ không chỉ sửa code mà còn sửa chính guardrail đã bỏ sót.

Quy trình làm việc từng bước

1. Lập kế hoạch cùng agent

Mỗi phiên làm việc đều bắt đầu giống nhau: mở Claude và cùng xây dựng kế hoạch — phân chia công việc, xác định thách thức và rủi ro. Indeev thường yêu cầu bản xem trước giao diện (UX preview) để hình dung sản phẩm trước khi bắt tay xây dựng.

Đây là nơi anh dành nhiều thời gian nhất. Anh review kế hoạch, không review code.

2. Đặt mục tiêu với một prompt cố định

Khi đã thống nhất kế hoạch, anh mở một phiên và đặt mục tiêu bằng prompt nguyên văn:

"Hoàn thành kế hoạch. Ship code bằng auto-merge. Bạn là điều phối viên. Đừng tự làm việc trực tiếp. Dùng sub-agent cho mọi thứ, và song song hóa khi có thể."

3. Giữ ngữ cảnh của điều phối viên sạch sẽ

Agent cấp cao nhất chỉ nắm giữ kế hoạch và trạng thái, nhờ đó ngữ cảnh luôn gọn gàng. Các sub-agent đảm nhận phần việc nặng và xuất hiện rồi biến mất theo tiến độ.

4. Để nó tự hợp nhất thành từng phần nhỏ

Agent được yêu cầu đánh dấu tính năng (feature-flag) mọi thứ và tự hợp nhất. Vì có thể merge, nó ship theo từng bước nhỏ: ship một thứ, chạy kiểm thử đầu-cuối, xác nhận hoạt động, rồi ship tiếp.

Indeev đưa ra một quan điểm khá gây tranh cãi:

Một PR lớn mà bạn phải liên tục sửa cục bộ có thể rủi ro hơn hai mươi PR nhỏ, mỗi cái đều đã vượt qua mọi kiểm tra.

5. Review báo cáo tiến độ, không review diff

Thay vì đọc diff, anh quay lại và yêu cầu agent tạo báo cáo tiến độ dạng HTML: việc gì đã xong, việc gì tiếp theo, và nó cần gì ở con người. Đó là thứ anh review.

6. Để nó chạy nhiều ngày, nhiều mục tiêu song song

Đây là phần Indeev cho rằng nhiều người bỏ qua: hãy để mục tiêu chạy qua đêm, thậm chí nhiều ngày. Mục tiêu về phân quyền tùy chỉnh của họ chạy hơn một ngày. Anh thường chạy hai đến bốn mục tiêu song song trên các tính năng không liên quan để chúng không giẫm chân lên nhau.

Hãy đặt mục tiêu lớn hơn

Theo Indeev, hầu hết chúng ta vẫn dùng AI như một kỹ sư siêu tốc — triển khai từng ticket, thêm từng endpoint. Cách đó hiệu quả nhưng tư duy còn quá nhỏ. Với quy trình đặt mục tiêu, bạn có thể giao những bài toán lớn hơn hẳn:

• Thay vì "thêm trình chỉnh sửa vai trò", mục tiêu là "làm cho hệ thống phân quyền của Sightline hoạt động giống Spare ở mọi nơi".
• Thay vì "chuyển OKR vào một gói", mục tiêu là "biến Sightline thành nền tảng để các đội khác mở rộng".
• "CI của chúng ta quá chậm. Hãy làm nó nhanh hơn." — chỉ vậy thôi, để agent tự tìm nút thắt và sửa.
• "Chúng ta đang thấy chỉ số PPVH thấp ở một khách hàng doanh nghiệp. Hãy đào sâu năm ngày dữ liệu và tìm cách tối ưu."

Đó không phải là ticket, mà là kết quả đầu ra. Các mô hình hiện đã đủ giỏi để nhận một kết quả, chia nhỏ nó và theo đuổi suốt một ngày hoặc hơn.

Token trở thành nút thắt cổ chai

Khi làm việc theo cách này, token trở thành giới hạn thực sự. Các gói cá nhân không còn đủ hạn mức, và chi phí vượt mức rất đắt đỏ. Indeev đang chạy khoảng năm tài khoản Claude với giá khoảng 200 USD mỗi tài khoản, chuyển đổi qua lại bằng một công cụ gọi là Claude Swap, tự động đổi tài khoản khi một tài khoản đạt 90% hạn mức.

Cách này chưa hoàn hảo: khi đổi tài khoản, bạn mất một số tính năng như artifacts và điều khiển từ xa qua ứng dụng di động, đồng thời phải đăng nhập lại liên tục. Anh đang tìm hiểu các công cụ khác như Paseo, Orca và Superset để giải quyết vấn đề này.

Xu hướng: từ ship tính năng sang xây hệ thống tự chữa lành

Indeev cho rằng công việc của lập trình viên đang dịch chuyển khỏi việc ship từng thứ riêng lẻ, sang việc xây dựng các hệ thống tiến hóa sản phẩm. Chúng ta đặt ra ý định, rồi xây hệ thống tự chữa lành để tiến tới ý định đó.

Đội của anh đã triển khai tự động hóa sửa lỗi, tự động hóa công việc SRE, agent nghiên cứu lỗ hổng bảo mật và bước đầu tự động khắc phục rủi ro. Tiếp theo là các hệ thống phát hiện vấn đề chất lượng, hiệu năng cơ sở dữ liệu, sự bất nhất trong giao diện, cùng agent tự viết kiểm thử cho những vùng còn thiếu.

Ba việc nên thử trong tuần này

• Ngừng kiểm tra code trên một tính năng thật. Bắt đầu với việc ít rủi ro, rồi tăng dần độ phức tạp khi đã tự tin.
• Giao một vấn đề, không phải một ticket. Xem agent đi được bao xa.
• Nhìn lại phạm vi ảnh hưởng. Guardrail nào còn thiếu để agent không thể làm sai? Vòng lặp nào có thể tự sửa lỗi?

Đối với độc giả Việt Nam đang làm việc với các công cụ như Claude Code, Cursor hay GitHub Copilot, chia sẻ này gợi mở một hướng tiếp cận đáng cân nhắc: thay vì cố kiểm soát từng dòng code AI tạo ra, hãy đầu tư vào hệ thống kiểm thử, CI/CD và feature flag đủ mạnh để bản thân quy trình tự đảm bảo chất lượng. Tuy nhiên, cần lưu ý rằng cách làm này đòi hỏi hạ tầng kỹ thuật trưởng thành và chi phí token đáng kể — chưa chắc phù hợp với mọi đội nhóm.