Bạn có nên xem lại mã của AI Agent không?

Cuộc tranh luận bắt đầu giống nhau trong mọi đội ngũ. Một bên nói rằng các agent bây giờ gửi mã sạch hơn nửa số pull request mà chúng ta từng phê duyệt, vậy tại sao chúng ta vẫn đọc từng dòng? Bên kia nói vì chúng ta là những người đã ký duyệt.

Cả hai bên đều đúng. Đó chính xác là lý do tại sao cuộc tranh luận không bao giờ kết thúc. Nó không kết thúc vì câu hỏi là sai, và một khi bạn sửa câu hỏi, câu trả lời trở nên gần như nhàm chán.

Lập luận cho việc gửi mà không cần đọc từng dòng

Bắt đầu với phiên bản mạnh mẽ nhất của lập luận lạc quan, vì nó mạnh hơn hầu hết các reviewer thừa nhận.

Trên một nhiệm vụ có phạm vi rõ ràng và một bộ kiểm tra, một agent lập trình hiện đại tạo ra mã nhất quán hơn so với con người trung bình làm việc dưới áp lực thời gian. Nó không cảm thấy chán trên con đường lỗi. Nó viết kiểm tra null vào lúc 6 giờ chiều thứ Sáu. Nó tuân theo các quy ước dự án mà nó được giao, mỗi lần, mà không có những cuộc nổi loạn nhỏ lặng lẽ mà một nhà phát triển mệt mỏi cho phép bản thân.

Việc xem xét của con người cũng đã bị hỏng trước khi các agent xuất hiện. Bất kỳ ai đã làm việc trong một đội thực sự đều biết phản xạ LGTM: sự chú ý của reviewer sụp đổ sau vài trăm dòng, và các phê duyệt tiếp theo là xã hội, không phải kỹ thuật. Chúng ta không mất đi một kỷ nguyên vàng của việc xem xét nghiêm ngặt. Chúng ta đã mất đi một nghi lễ mà phần lớn đã chỉ là sân khấu.

Sau đó là khối lượng. Một nhà phát triển chạy năm agent song song tạo ra nhiều diff hơn mỗi giờ so với bất kỳ con người nào có thể đọc kỹ. Nếu quy tắc của bạn là "đọc mọi thứ", bạn đã âm thầm tái cài đặt mình thành nút thắt mà bạn vừa tự động hóa. Một con người lướt qua một diff 900 dòng tạo ra một chữ ký mà không tạo ra kiến thức, và điều đó tệ hơn là không xem xét chút nào, vì nó tạo ra sự đảm bảo nơi không có gì.

Lập luận cho việc giữ một con người trên diff

Bây giờ là phía bên kia, cũng mạnh hơn những người đam mê thừa nhận.

Trách nhiệm không chuyển giao. Mô hình không được gọi vào lúc 3 giờ sáng. Nó không có trong cuộc xem xét sự cố, nó không nói chuyện với khách hàng mà dữ liệu của họ bị rò rỉ, và nó không chịu hậu quả của sự thay đổi vào quý tiếp theo. Ai hợp nhất thì sở hữu kết quả, và việc xem xét là cách mà quyền sở hữu được thực hiện chứ không chỉ đơn thuần được tuyên bố.

Các reviewer agent thất bại theo cùng một hướng như các tác giả agent. Đây là lập luận thực sự giải quyết đề xuất "chỉ cần để một agent khác xem xét". Hai agent từ cùng một gia đình mô hình, được giao cùng một ngữ cảnh, chia sẻ các prior, chia sẻ dữ liệu đào tạo và chia sẻ các điểm mù. Các lỗi của chúng có tương quan. Một agent thứ hai sẽ vui vẻ phát hiện một bài kiểm tra bị thiếu hoặc một lỗi không được xử lý, và sẽ vui vẻ phê duyệt sự hiểu lầm tinh tế về miền của bạn đã tạo ra lỗi ngay từ đầu, vì nó đã mắc phải sự hiểu lầm tương tự. Hai reviewer sai theo cùng một hướng không cộng lại thành một cuộc xem xét.

Các phép đo cũng không có lợi. Dữ liệu ngành cho thấy các reviewer trao đổi nhiều vòng ý nghĩa hơn về các thay đổi do AI tạo ra so với các thay đổi do con người viết: mã đến nhanh hơn và mất nhiều thời gian hơn để trở nên đáng tin cậy. Một nghiên cứu vào tháng 1 năm 2026 đã đi xa hơn và phát hiện rằng các thay đổi do agent tạo ra mang lại nhiều độ dư thừa và nhiều nợ kỹ thuật tích lũy hơn mỗi thay đổi so với các thay đổi do con người viết, trong khi các reviewer báo cáo cảm thấy tốt hơn khi phê duyệt chúng. Khoảng cách đó, giữa cảm giác mã tốt như thế nào và nó thực sự tốt ra sao, là toàn bộ rủi ro trong một câu.

Cuộc tranh luận được định hình sai

Đây là cách định hình lại kết thúc cuộc họp.

Bạn không xem xét mã vì bạn không tin tưởng tác giả. Bạn xem xét nó vì bạn là người ký duyệt. Đó là hai hoạt động hoàn toàn khác nhau, và toàn bộ cuộc tranh luận bắt nguồn từ việc nhầm lẫn chúng.

Khi bạn thấy điều đó, "liệu agent có tốt hơn con người không" ngừng trở thành câu hỏi quyết định. Câu hỏi quyết định là: nếu thay đổi này sai, thì việc phát hiện ra nó tốn kém bao nhiêu, và việc hoàn tác tốn kém bao nhiêu? Một lỗi chính tả trong tiêu đề marketing được phát hiện trong vài giây và được hoàn tác trong vài giây. Một kiểm tra quyền truy cập bị đảo ngược trong middleware ủy quyền được phát hiện bởi một khách hàng, hoặc bởi một cơ quan quản lý, và nó không bao giờ thực sự được hoàn tác, vì lúc đó dữ liệu đã được đọc.

Vì vậy, câu trả lời không phải là "xem xét mọi thứ" cũng không phải là "tin tưởng agent". Nó là:

Bạn ngừng xem xét các dòng. Bạn bắt đầu xem xét rủi ro.

Cụ thể, việc xem xét chuyển từ giữa công việc đến hai ranh giới của nó. Trước: đọc kế hoạch, vì một kế hoạch sai được thực hiện hoàn hảo là chế độ thất bại tốn kém nhất, và một kế hoạch chỉ có mười lăm dòng thay vì chín trăm. Sau: đọc diff theo tỷ lệ với bán kính vụ nổ. Ở giữa, các dòng thuộc về máy.

"Agent đã làm sai" thực sự trông như thế nào

Điều hữu ích nhất mà bạn có thể mang về cho đội của mình không phải là một ý kiến, mà là một danh sách các dấu hiệu khách quan. Không phải "mã cảm thấy không ổn", mà là các tín hiệu bạn có thể kiểm tra trên một diff trong chưa đầy một phút. Đây là những dấu hiệu đã kiếm được vị trí của chúng.

1. Các bài kiểm tra đã thay đổi trong cùng một commit với mã mà chúng bao phủ. Màu xanh được xây dựng, không phải quan sát. Đây là dấu hiệu có tín hiệu cao nhất trong danh sách, và đây là dấu hiệu cần kiểm tra đầu tiên.
2. Một khẳng định đã bị yếu đi hoặc một bài kiểm tra đã bị vô hiệu hóa. Một skip, một only, một khẳng định được mở rộng để chấp nhận những gì mã mới trả về, một try/catch nuốt chửng lỗi mà bài kiểm tra đáng lẽ phải phát hiện.
3. Diff lớn hơn nhiệm vụ. Các tệp không ai yêu cầu đã bị chạm vào. Sự mở rộng phạm vi trong một agent không phải là sự nhiệt tình, mà là dấu hiệu cho thấy agent đã diễn giải lại mục tiêu ở đâu đó trong quá trình.
4. Một bề mặt được phát minh. Một phương thức API, một tùy chọn cấu hình hoặc một đường dẫn không tồn tại. Nó biên dịch trong đầu agent và không ở đâu khác.
5. Môi trường đã được sửa thay vì mã. Một đường dẫn tuyệt đối được mã hóa cứng, một giá trị cụ thể cho máy, một token cá nhân, một tên người dùng. Triệu chứng đã biến mất trên máy của agent và chuyển sang máy của mọi người khác.
6. Một phụ thuộc xuất hiện mà không được yêu cầu. Chuỗi cung ứng mới, giấy phép mới, bề mặt bảo trì mới, được quyết định bởi một cái gì đó sẽ không duy trì nó.
7. Sự trùng lặp thay vì tái sử dụng. Nó đã triển khai lại một trợ giúp đã tồn tại cách đó hai mươi dòng. Đây là cơ chế đứng sau nợ đo lường: mỗi thay đổi trông hợp lý tại chỗ và mã nguồn âm thầm có thêm một cách thứ ba để làm cùng một việc.
8. Tóm tắt không khớp với diff. "Đã sửa và đã kiểm tra" khi không có bài kiểm tra nào chạy. Phần tường thuật được tạo ra với cùng một sự tự tin bất kể công việc có xảy ra hay không, vì vậy hãy coi đó như một tuyên bố cần xác minh, không bao giờ như một báo cáo.
9. Các hướng dẫn đã ngừng được tuân theo. Các quy ước nhỏ bị bỏ qua lặng lẽ là cách mà một phiên giảm sút trước khi nó bắt đầu hoàn toàn ảo tưởng. Nếu bạn sử dụng một canary trong tệp ngữ cảnh của bạn, đây chính xác là điều mà nó được thiết kế để phát hiện.
10. Đã chạm vào lĩnh vực nhạy cảm một cách thoáng qua. Một .env được đọc, một cuộc gọi mạng outbound mới, một dòng log mới mang dữ liệu người dùng, một di chuyển được gộp vào một commit tính năng.

Chú ý những gì không có trong danh sách: phong cách, tên gọi, định dạng, "tôi sẽ làm khác đi". Những điều đó luôn là phần yếu nhất của việc xem xét con người và bây giờ thực sự là một sự lãng phí của một con người. Xóa chúng khỏi việc xem xét của bạn và bạn sẽ mua lại sự chú ý mà bạn cần cho mười mục ở trên.

Một thay đổi xứng đáng được xem xét bao nhiêu?

Bán kính vụ nổ, không phải kích thước diff, quyết định. Bảng mà đội của bạn có thể áp dụng chiều nay:

Kích thước của diff cho bạn biết việc xem xét mất bao lâu. Bán kính vụ nổ cho bạn biết liệu nó có tùy chọn hay không.

Các hàng không nói về mức độ tin cậy. Chúng nói về chi phí của việc sai, điều này là thuộc tính của mã chứ không phải của ai đã viết nó. Đó là điều làm cho bảng có thể sử dụng: không ai phải đồng ý về việc các agent tốt đến mức nào để đồng ý về bảng. Nếu đội của bạn đang bế tắc về câu hỏi triết học, hãy bỏ qua nó và thương lượng các hàng thay vào đó. Bạn sẽ ngạc nhiên về tốc độ mà điều đó hội tụ.

Nếu sản phẩm của bạn xử lý dữ liệu cá nhân ở Châu Âu, một hàng nữa được viết cho bạn theo luật thay vì theo khẩu vị: những gì một tính năng do AI xây dựng phải tuân thủ theo GDPR không phải là một quyết định phán xét, và "một agent đã viết nó" chưa bao giờ là một biện hộ.

Điều gì thay đổi khi năm agent chạy cùng một lúc

Tất cả những điều trên giả định rằng bạn có thể thấy sự thay đổi. Với các agent song song, giả định đó bị phá vỡ trước tiên, và nó bị phá vỡ theo một cách cụ thể: diff ngừng có một tác giả duy nhất. Ba agent đã chạm vào cây làm việc kể từ commit cuối cùng của bạn, và câu hỏi "ai đã thay đổi tệp này, và như một phần của nhiệm vụ nào" không còn có câu trả lời rõ ràng. Việc xem xét mà không có sự ghi nhận không phải là xem xét, đó là khảo cổ học.

Đó là một vấn đề công cụ, và đó là lý do tại sao AgentsRoom đặt việc xem xét nơi các agent đang hoạt động thay vì ở cuối một pull request:

• Review Mode hiển thị mọi thay đổi mà các agent của bạn đã thực hiện, dưới dạng một diff có thể đọc được, trước khi bất kỳ điều gì được cam kết. Đây là bước "đọc diff theo tỷ lệ với bán kính vụ nổ", được làm rẻ đến mức mà mọi người thực sự làm điều đó.
• Xem xét theo từng agent lọc diff đó theo agent và cho phép bạn cam kết công việc của từng agent một cách riêng biệt. Năm agent song song trở thành năm đơn vị có thể xem xét thay vì một cây làm việc không thể đọc được, và một thay đổi xấu vẫn có thể quy cho nhiệm vụ đã tạo ra nó.
• Tin nhắn commit được tạo ra từ diff thực tế với nút lấp lánh trên trường commit, vì vậy lịch sử mô tả những gì đã thay đổi thay vì những gì agent nói rằng nó đang làm. Sự phân biệt đó quan trọng vào lúc 3 giờ sáng, sáu tháng sau.

Không điều gì trong số này thay thế sự phán xét. Nó loại bỏ những lý do để không thực hiện nó.

Hãy để máy móc sở hữu các dòng

Nếu bạn muốn ngừng đọc các dòng, một cái gì đó khác phải đọc chúng. Trong thực tế, bốn điều mang lại gánh nặng đó:

Các bài kiểm tra mà agent không viết cùng lúc với mã. Được viết trước, hoặc được viết bởi một agent khác, hoặc tối thiểu được xem xét như một thay đổi riêng của chúng. Ngay khi mã và các bài kiểm tra của nó đến từ cùng một thế hệ, chúng ngừng là bằng chứng độc lập.

Một reviewer với một mô hình khác. Đây là câu trả lời thực tiễn cho vấn đề thất bại tương quan. Nếu một agent thứ hai xem xét, hãy chạy nó trên một nhà cung cấp hoặc gia đình mô hình khác với tác giả. Bạn sẽ không loại bỏ hoàn toàn các lỗi, nhưng một reviewer thuộc gia đình Codex trên mã do Claude viết sẽ phát hiện ra một loại vấn đề khác biệt một cách đo lường so với một reviewer cùng mô hình, chính xác vì nó không chia sẻ các prior của tác giả.

Các cổng không bao giờ mệt mỏi. Các loại, lint, quét bí mật, sàn bao phủ, một CI từ chối một di chuyển được gộp với một tính năng. Mỗi quy tắc bạn có thể diễn đạt như một cổng là một quy tắc bạn không bao giờ phải chú ý đến nữa.

Một vòng lặp tự khép lại. Một agent xây dựng, chạy công việc của chính nó theo kế hoạch và lặp lại trước khi chuyển giao bất kỳ điều gì loại bỏ toàn bộ loại "không chạy ngay cả một lần" khỏi việc xem xét của bạn. Đó là vòng lặp agent tự điều chỉnh, và đó là sự khác biệt giữa một agent tạo ra một diff và một agent tạo ra một kết quả. Nó không trả lời câu hỏi liệu một con người có nên ký duyệt hay không. Nó chỉ có nghĩa là con người đang ký duyệt một cái gì đó đã hoạt động.

Vậy, bạn có còn xem xét không?

Có, và ít hơn bạn làm hôm nay.

Ngừng đọc các dòng để cảm thấy có trách nhiệm. Đọc kế hoạch trước, vì đó là nơi những sai lầm tốn kém được thực hiện. Đọc diff sau theo tỷ lệ với những gì nó có thể phá vỡ, sử dụng thang thay vì tâm trạng của bạn. Giữ một con người, cá nhân, trên xác thực, thanh toán, quyền truy cập, dữ liệu cá nhân và bất kỳ điều gì không thể đảo ngược, vì một mô hình không thể giữ trách nhiệm và một agent thứ hai chia sẻ các điểm mù của agent đầu tiên. Giao mọi thứ khác cho các bài kiểm tra, loại, cổng và một reviewer không chia sẻ mô hình của tác giả.

Các đội ngũ mắc sai lầm này thất bại theo một trong hai hướng, và cả hai đều có thể tránh được. Một đội xem xét mọi thứ, trở thành nút thắt, và âm thầm bắt đầu phê duyệt mà không đọc, điều này là tồi tệ nhất của cả hai thế giới. Đội kia không xem xét gì, gửi nhanh trong hai tháng, và sau đó dành một quý để trả nợ mà họ chưa bao giờ thấy tích lũy.

Cuộc tranh luận tại cuộc họp đứng của bạn không thực sự về việc các agent có tốt hay không. Nó là về ai sẵn sàng ký duyệt. Trả lời điều đó, và chính sách xem xét tự viết ra.

Các câu hỏi thường gặp

Bạn có nên vẫn xem xét mã do AI tạo ra không?

Có, nhưng không phải từng dòng trên mọi thứ. Xem xét kế hoạch trước khi agent bắt đầu, sau đó xem xét diff theo tỷ lệ với những gì thay đổi có thể phá vỡ. Nội dung văn bản và CSS được lướt qua. Xác thực, thanh toán, quyền truy cập, dữ liệu cá nhân và di chuyển được đọc từng dòng bởi một con người, mỗi lần.

Một AI agent có thể xem xét mã của một AI agent khác không?

Nó giúp, nhưng không phải là sự thay thế cho một con người trên mã có rủi ro. Hai agent từ cùng một gia đình mô hình, được giao cùng một ngữ cảnh, có xu hướng thất bại theo cùng một hướng. Các lỗi của chúng có tương quan, vì vậy một agent thứ hai phát hiện ra lỗi chính tả và các bài kiểm tra bị thiếu nhưng chia sẻ các điểm mù đã tạo ra lỗi. Nếu bạn sử dụng một reviewer agent, hãy chạy nó trên một mô hình khác với tác giả.

Làm thế nào để bạn biết nếu một AI agent đã mắc sai lầm?

Tìm kiếm các dấu hiệu khách quan trong diff thay vì đọc theo phong cách. Dấu hiệu mạnh nhất: các bài kiểm tra đã thay đổi trong cùng một commit với mã mà chúng bao phủ, điều này có nghĩa là màu xanh được xây dựng chứ không phải quan sát. Những dấu hiệu khác bao gồm sự mở rộng phạm vi, một khẳng định bị vô hiệu hóa hoặc yếu đi, một API được phát minh, một đường dẫn cục bộ được mã hóa cứng và một tóm tắt không khớp với diff.

Các AI agent có thay thế các reviewer mã con người không?

Chúng đã thay thế hầu hết việc đọc dòng. Chúng không thể thay thế chữ ký. Trách nhiệm không chuyển giao cho một mô hình, vì vậy một con người vẫn sở hữu quyết định hợp nhất trên bất kỳ điều gì khó đảo ngược.

Bạn có cần xem xét mã AI từng dòng không?

Chỉ nơi bán kính vụ nổ biện minh cho điều đó. Việc xem xét từng dòng không mở rộng qua vài agent chạy song song, và một con người lướt qua một diff 900 dòng vào lúc 6 giờ chiều tạo ra một chữ ký mà không tạo ra kiến thức. Hãy dành sự chú ý đó cho những thay đổi tốn kém để hoàn tác.

Điều gì không bao giờ nên được hợp nhất mà không có sự xem xét của con người?

Bất kỳ điều gì chạm vào xác thực, thanh toán, quyền truy cập, dữ liệu cá nhân, di chuyển cơ sở dữ liệu, đường dẫn xóa và hạ tầng. Những điều này chia sẻ một thuộc tính: chi phí của việc sai không tương xứng với kích thước của diff.