Bạn đã nối một agent review code AI vào pipeline của mình, và nó chạy được. Nó báo một null check bị thiếu, phát hiện một import không dùng, và để lại ba comment gọn gàng về cách đặt tên. Bạn merge. Hai ngày sau, một khách hàng gặp lỗi mà agent đã đọc thẳng qua: thay đổi đó sạch sẽ về nội tại nhưng lại làm sai việc. Agent review đã xác minh code. Nó không thể xác minh ý định.
Khoảng cách đó chính là toàn bộ câu chuyện về các agent review code AI. Chúng giỏi ở một loại vấn đề cụ thể, có thể kiểm tra được, và mù trước một loại vấn đề khác trông y hệt trong một diff. Coi sự phê duyệt của chúng như chấp nhận thì bạn sẽ ship đúng cái loại mù đó. Biết ranh giới nằm ở đâu thì bạn có một lượt duyệt đầu tiên nhanh chóng, giải phóng reviewer của mình cho những phán đoán chỉ con người mới làm được.
Bài viết này vạch ra ranh giới đó: agent review code AI có thể xác minh gì, không thể xác minh gì, và mô hình vận hành giữ hai điều đó tách bạch. Sharkly là lớp chúng ta sẽ đi qua, không gian làm việc chung nơi review của agent và chấp nhận của con người là hai trạng thái khác nhau trên cùng một Task, chứ không phải một sự phê duyệt hình thức duy nhất. Bạn đã có các coding agent; vấn đề ở đây là review đầu ra của chúng mà không giả vờ rằng một agent thứ hai có thể khép kín vòng lặp.
Agent review code AI có thể xác minh những gì
Agent review code AI là một chương trình đọc một diff, chạy các kiểm tra trên đó và báo cáo phát hiện giống như cách một reviewer con người để lại comment. Vùng đáng tin cậy của nó là mọi thứ mà một reviewer cẩn thận có thể xác nhận bằng cách đọc thay đổi cùng những phần lân cận trực tiếp:
- Tính đúng đắn máy móc: cú pháp, kiểu dữ liệu, xử lý null và biên rõ ràng, promise rejection không được xử lý, rò rỉ tài nguyên nhìn thấy được trong diff.
- Logic cục bộ: lỗi lệch một đơn vị, điều kiện bị đảo, nhánh chết, biến được đọc trước khi được gán.
- Quy ước: đặt tên, định dạng, vệ sinh import, liệu một hàm mới có test đi kèm hay không.
- Các anti-pattern đã biết: SQL dựng bằng cách nối chuỗi, secret bị commit dưới dạng plaintext, một phương thức public thiếu kiểm tra đầu vào.
Chúng có chung một đặc điểm. Bằng chứng nằm ngay bên trong diff. Agent không cần biết nghiệp vụ của bạn để bắt chúng, và nó bắt chúng nhanh hơn, nhất quán hơn một con người mệt mỏi lúc 6 giờ chiều. Đó là giá trị thật, và đó là lý do các team tìm đến những công cụ này. Hướng dẫn code review của Google coi lượt kiểm tra máy móc này là điều kiện tối thiểu để sự tập trung của con người có thể dồn vào thiết kế. Một AI reviewer là cách kiên nhẫn để dọn sạch lượt đó mỗi lần.
Những gì nó không thể xác minh
Đây là ranh giới, nói thẳng ra: agent review code AI không thể xác minh rằng thay đổi đó là thay đổi đúng. Mọi thứ dưới đây đều cần ngữ cảnh mà diff không chứa.
- Ý định so với đặc tả. Code có thể hoàn hảo và giải quyết sai vấn đề. Chỉ có tiêu chí nghiệm thu của ticket mới quyết định được điều đó, mà agent hiếm khi nhìn thấy chúng.
- Tính đúng đắn nghiệp vụ. Liệu một quy tắc giảm giá, một phép tính thuế hay một ranh giới quyền có khớp với cách công ty vận hành hay không là một phán đoán, chứ không phải một lint rule.
- Hành vi xuyên hệ thống. Một thay đổi đọc ổn trong một file có thể làm hỏng một caller cách đó ba service. OWASP Top Ten đầy những lỗi như broken access control chỉ xuất hiện khi bạn lần theo toàn bộ đường đi của request, chứ không phải diff.
- Liệu các test có trung thực không. Agent có thể xác nhận một test tồn tại và pass. Nó không thể nói cho bạn biết test có assert đúng điều quan trọng hay không, hay rằng agent viết code cũng đã viết một test được tạo hình để pass.
Điều cuối cùng đó là cái bẫy riêng của code do AI viết. Khi cùng một loại hệ thống tạo ra cả thay đổi lẫn phần review, một diff sạch và một check xanh có thể cùng đúng và cùng chẳng liên quan gì. Vì vậy, sự phê duyệt từ một agent review là một tín hiệu, không phải một quyết định. Agent báo cáo; con người chấp nhận.
Mô hình vận hành bù đắp khoảng trống
Cách khắc phục không phải là một agent review tốt hơn. Mà là một mô hình vận hành nơi việc của agent review và việc của con người là những trạng thái khác nhau, và không trạng thái nào bị bỏ qua.
Sharkly biến những trạng thái đó thành rõ ràng qua trạng thái Task. Một Task đi qua In progress, đến Ready for review, rồi Done. Quy tắc rất đơn giản nhưng mang tính nền tảng: agent đưa công việc đến Ready for review; con người đưa nó đến Done. Một agent, dù nó viết code hay review code, không bao giờ có thể đánh dấu công việc của chính mình là đã được chấp nhận. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, trao quyền và chấp nhận kết quả. Tự động hóa dừng lại ở nơi cần đến phán đoán của team.
Mỗi vai trò có một nhiệm vụ. Agent viết code tạo ra thay đổi. Agent review chạy lượt kiểm tra máy móc và đính kèm các phát hiện của nó. Reviewer con người đọc những phát hiện đó, đối chiếu thay đổi với ý định của ticket, rồi quyết định. Tất cả đều quay về Task: diff, comment của agent review, đầu ra test, và quyết định của con người nằm trên cùng một timeline thay vì rải rác khắp một PR, một đoạn chat và trí nhớ của ai đó.
Hãy dùng agent review như cổng đầu tiên khi thay đổi mang tính máy móc và khép kín — một refactor, một lần nâng cấp dependency, một bug fix được khoanh vùng rõ ràng; để nó dọn sạch nhiễu để lượt duyệt của con người diễn ra nhanh. Đừng dựa vào nó như cổng duy nhất khi thay đổi chạm đến tiền, auth, migration dữ liệu hay hợp đồng công khai; ở đó con người đọc trước và lượt duyệt của agent chỉ là một checklist, không phải một phán quyết.
Một ví dụ thực tế: từ ticket đến PR đã merge
Lấy SH-312: “Từ chối mã coupon hết hạn tại checkout.” Một người viết tiêu chí nghiệm thu và giao Task. Một Agent viết code nhận nó, làm việc trong một worktree riêng biệt, rồi trả về một diff cùng một test pass cho Task, chuyển nó sang Ready for review.
Giờ đến lượt Agent review chạy. Nó xác nhận các kiểu dữ liệu, báo một null guard bị thiếu, và ghi chú rằng test đã bao phủ trường hợp hết hạn. Lượt duyệt sạch. Theo thói quen cũ, sự phê duyệt đó sẽ được merge.
Thay vào đó, reviewer con người mở Task và đọc đối chiếu với ý định. Code từ chối coupon hết hạn, đúng y như đã viết. Nhưng tiêu chí nghiệm thu cũng ngụ ý rằng coupon đã được đổi trước đó cũng nên bị từ chối, và cả Agent viết code lẫn Agent review đều không biết điều đó, bởi nó nằm trong đầu reviewer và trong product spec, chứ không nằm trong diff. Reviewer yêu cầu thay đổi. SH-312 quay lại In progress với một ghi chú cụ thể, Agent mở rộng nó, và chỉ đến lúc đó một con người mới chuyển nó sang Done và merge pull request.
Agent review đã làm tốt công việc của nó và vẫn sẽ ship một khoảng trống. Mô hình vận hành đã bắt được điều đó, bởi chấp nhận là một hành động riêng biệt của một con người có ngữ cảnh. Đó cũng chính là kỷ luật đằng sau việc review code do AI tạo ra với bằng chứng ở cấp độ task: đơn vị review là Task cùng ý định của nó, chứ không phải diff đứng riêng lẻ.
Đặt các cổng review ở đâu
Câu hỏi thực tế không phải là có nên dùng agent review code AI hay không. Mà là ở đâu lượt duyệt của chúng được tính và ở đâu con người buộc phải đọc trước. Vài quy tắc vẫn đứng vững:
- Để agent gác style, định dạng và bug máy móc trên mọi thay đổi. Đó là lượt nó làm tốt nhất và cũng là lượt con người làm tệ nhất khi đã mệt.
- Yêu cầu cổng con người cho mọi thứ chạm đến auth, billing, migration dữ liệu hay một API công khai. Vùng mù tập trung ở đó.
- Định cỡ các cổng theo năng lực review của bạn. Agent tạo ra nhanh hơn tốc độ con người chấp nhận, nên hãy dành lượt duyệt của con người cho nơi agent bị mù.
- Biến cổng thành một trạng thái, không phải một thói quen. Một cổng phê duyệt được ghi lại thành văn bản và chặn trạng thái Done thì mới thực thi được; còn một quy ước rằng “ai đó nên xem qua” thì không. Giữ con người trong vòng lặp chỉ hiệu quả khi vòng lặp là một bước mà workflow bắt buộc.
Agent review code AI không phải là thứ thay thế reviewer con người. Nó là lượt duyệt đầu tiên giúp lượt duyệt của con người nhanh hơn và sắc bén hơn. Nếu bạn đang chạy nhiều coding agent và muốn đầu ra của chúng được review và chấp nhận ở một nơi duy nhất thay vì năm tab PR, đó chính là bài toán mà Sharkly được xây dựng để giải: giao việc, theo dõi và review công việc của agent trên các Task chung, với phát hiện của Agent review và quyết định của con người đều quay về cùng một bản ghi. Hãy giữ các coding agent và agent review bạn đang dùng, rồi thêm lớp đó để quyết định khi nào lượt duyệt của chúng là đủ.
