Cách đội ngũ Claude Code làm code review

Tác giả bài gốc: Addy Osmani, Morgan Westlee Lunt, and Qing Wang (Member of Technical Staff). Đăng ngày 15/10/2026 trên claude.dev.

Chúng tôi từng chia sẻ rằng Claude viết khoảng 90 phần trăm code của chính Claude Code. Vậy chúng tôi review code thế nào với khối lượng được tạo ra như vậy? Còn ai đọc code nữa không? Và nếu có gì hỏng, ai sẽ phát hiện?

Bài viết này trình bày luồng code review trong đội ngũ Claude Code và cách nó đã thay đổi. Từ tháng 6 đến tháng 9, số pull request được merge vào codebase của Claude Code đã tăng hơn gấp đôi, trong khi tỷ lệ phải revert giảm hơn 40 phần trăm.

Chúng tôi không bỏ review. Nhưng chúng tôi đã chuyển phần lớn việc đọc code cho máy, tối ưu cho thời gian và sự tập trung của con người, đồng thời đầu tư mạnh để có thể hoàn tác sai sót một cách nhanh chóng, dễ dàng.

Suy nghĩ lại về mục đích của code review

Khi agent viết code, số lượng thay đổi tăng lên rất nhanh. Trong monorepo của Anthropic, số thay đổi được đưa vào mỗi ngày đã tăng từ khoảng 2,500 vào tháng 5 lên hơn 30,000 vào tháng 9 năm nay.

Claude Code nằm trong repo riêng, tách biệt với monorepo, nhưng cũng chịu áp lực rất lớn. Khi phát hành nhanh đến vậy, việc review code thủ công từng dòng là vô cùng khó, nếu không muốn nói là bất khả thi.

Code review làm hai việc:

1. Tìm và sửa vấn đề trước khi phát hành
2. Xây dựng context chung và hiểu biết về codebase trong toàn đội

Bài viết này chủ yếu tập trung vào việc tìm và sửa vấn đề, nhưng gần cuối chúng tôi sẽ quay lại công việc thứ hai.

Chúng tôi cho rằng câu hỏi “đã có người đọc code chưa?” chỉ là một thước đo thay thế thiếu chính xác cho câu hỏi “thay đổi này có thể gây ra chuyện gì, và bước kiểm tra nào — tự động hay do con người thực hiện — mới phù hợp để phát hiện nó?”

Đặt câu hỏi đó cũng làm thay đổi thời điểm review diễn ra. Trước đây, review là một cửa kiểm soát ở cuối đường: viết code, mở PR, đợi đồng nghiệp.

Giờ đây, review chạy liên tục, giống như kiểm tra chính tả ngay khi bạn viết. Phần lớn thay đổi đã được Claude review và sửa ít nhất một lần trước khi nhờ con người xem. Cách này phát hiện hầu hết sai sót thường gặp và dành sự tập trung của cả đội cho những câu hỏi và việc xem xét ở cấp độ cao hơn.

Nguồn lực khan hiếm: thời gian và sự tập trung của con người

Chúng tôi muốn dành thời gian và sự tập trung của con người cho những vấn đề chỉ con người mới giải quyết được, đồng thời bảo đảm các bước kiểm tra tự động phát hiện phần còn lại. Với tốc độ thay đổi hiện tại, vẫn còn một khối lượng công việc khổng lồ cần con người thực hiện, và đội ngũ chúng tôi gặp những thách thức mới gần như mỗi ngày.

Thời gian của con người bao gồm cả hai phía của chi phí review: thời gian mọi người dành để review và thời gian họ dành để khắc phục những gì code kém chất lượng làm hỏng. Giảm vế đầu chẳng giúp ích gì nếu thời gian đó chỉ chuyển sang vế sau.

Vì vậy, mục tiêu là phần lớn pull request trong các repo Claude Code (CLI, ứng dụng desktop và web, cùng các ứng dụng di động) được merge với tối đa một người tham gia, có thể chính là tác giả, mà không làm tăng số lần revert hay sự cố. Để đo thời gian của con người, chúng tôi theo dõi số lượt phê duyệt của con người trên mỗi PR (trung vị và phân vị thứ 95), bình luận của con người và thời gian PR phải chờ một người xử lý. Tỷ lệ revert và sự cố là rào chắn: nếu chúng tăng, chúng tôi chưa tiết kiệm được thời gian của con người mà chỉ chuyển nó sang chỗ khác.

Hành trình của một thay đổi

Một thay đổi điển hình, bắt đầu từ laptop của kỹ sư (hoặc một session Claude trong Slack), đi qua nhiều lớp code review.

Hình: Các bước kiểm tra của một pull request, từ trên xuống dưới. Trước pull request, công việc được kiểm chứng. Trên mỗi pull request: CI bắt buộc, Claude code review và review bảo mật, tất cả đều tự động, rồi đến bước phê duyệt dựa trên rủi ro do một người quyết định. Tiếp theo là hàng đợi merge, và sau khi merge là feature flag được dùng nội bộ trước, phát hành dần, rồi bước cuối cùng là theo dõi, sửa tiếp hoặc rollback.

Phần lớn hành trình được tự động hóa; sự tập trung của con người được dành cho nơi có rủi ro

Đi qua từng lớp

Hình: Sáu lớp xếp từ trên xuống dưới: kiểm chứng, CI bắt buộc, AI review, review bảo mật, phê duyệt của con người, và hàng đợi merge cùng các flag. Mỗi lớp có những lỗ hổng ở vị trí khác nhau. Vấn đề lọt qua một lỗ hổng sẽ bị lớp sau phát hiện; một vấn đề lọt qua lỗ hổng ở tất cả các lớp và rơi xuống bước rollback nhanh ở dưới cùng.

Mỗi lớp phát hiện một số vấn đề và bỏ sót những vấn đề khác. Rất ít vấn đề lọt qua tất cả các lớp, và rollback xử lý phần còn lại.

1. Công việc được kiểm chứng trước khi người khác xem

Phần lớn việc review giờ diễn ra trước khi có PR. Chúng tôi cung cấp cho Claude thứ gì đó nó có thể chạy — như test, một bản build hoặc ảnh chụp màn hình để đối chiếu với thiết kế — và yêu cầu nó đưa ra output thay vì nói đã xong. Sau đó, một subagent review diff với context mới hoàn toàn. Cả hai thói quen này đều đến từ hướng dẫn best practice của chúng tôi.

Trước khi mở PR, nhiều người trong chúng tôi cũng chạy một vài skill nội bộ: một skill tìm bug, một skill đơn giản hóa diff và một skill kiểm tra hành vi từ đầu đến cuối. Những thay đổi UI còn được đối chiếu với hướng dẫn thiết kế của chúng tôi.

Boris Cherny, người tạo ra Claude Code, từng gọi việc cho Claude một cách để kiểm chứng công việc của nó là có lẽ là điều quan trọng nhất để có kết quả tốt. Anh ước tính việc này giúp kết quả cuối cùng tốt hơn từ hai đến ba lần, và viết: “Việc kiểm chứng khác nhau ở mỗi lĩnh vực. Có thể chỉ đơn giản là chạy một lệnh bash, chạy một bộ test, hoặc kiểm thử ứng dụng trong trình duyệt hay trình mô phỏng điện thoại.”

Khi reviewer tự động liên tục chỉ ra cùng một vấn đề, chúng tôi sửa ngay từ gốc: trong skill, bằng một quy tắc lint, hoặc bằng cách cập nhật các file hướng dẫn như:

• CLAUDE.md cho Claude biết dự án là gì: stack, quy ước, mục tiêu và những gì nằm ngoài mục tiêu. Mỗi lượt review đều nạp file này, nên trong codebase lớn, chúng tôi giữ nó ngắn gọn và từ đó trỏ tới các tài liệu khác. Reviewer cũng chỉ ra code vi phạm quy ước trong file và những thay đổi khiến một dòng trong file không còn đúng.
• REVIEW.md, do những người phụ trách code viết, cho reviewer biết điều gì quan trọng trong phần code họ phụ trách. Chúng tôi kiểm tra riêng xem reviewer có thực sự làm theo file này không. Những file tốt đều ngắn gọn. Chúng mô tả thất bại trông như thế nào trong repo đó (với tài liệu là “nó nói sai”, với cấu hình là “nó định tuyến sai”), giới hạn số góp ý vụn vặt, liệt kê đường dẫn cần bỏ qua và yêu cầu dẫn chứng bằng file cùng số dòng thay vì đoán từ tên. Chúng cũng yêu cầu bản tóm tắt bắt đầu bằng số lượng vấn đề và nói rõ khi không có gì cần sửa.

2. AI review trên mọi pull request

Mọi pull request đều được Claude review trước khi con người xem. Nó đọc diff trong tương quan với toàn bộ repo và ý định được nêu trong PR, rồi đặt câu hỏi: thay đổi này có giải quyết được vấn đề của nó, có phù hợp với hệ thống hay có làm hỏng thứ gì khác không?

Với một bản sửa bug, nó tìm nguyên nhân gốc rễ. Phiên bản công khai, Code Review for Claude Code, hiện đã được phát hành chính thức trên các gói Team và Enterprise, còn /code-review chạy một phiên bản nhẹ hơn ở local.

Khi chúng tôi ra mắt bản xem trước nghiên cứu, tỷ lệ PR nội bộ nhận được bình luận review có nội dung thực chất tăng từ 16% lên 54%. Phần lớn PR trên 1,000 dòng đều có vấn đề được phát hiện, còn phần lớn PR nhỏ không bị phát hiện vấn đề nào. Quản trị viên đặt chế độ Quick, Standard hoặc Deep cho từng repo. Deep đáng dùng ở những nơi mà một bug bị bỏ sót gây thiệt hại lớn hơn thời gian review bổ sung.

Các vấn đề được phát hiện sẽ được những agent khác kiểm chứng trước khi con người xem xét. Nhiều agent cùng tìm bug một lúc. Sau đó, một nhóm riêng bỏ phiếu cho từng vấn đề, và vấn đề chỉ được đăng nếu có đủ agent đồng ý rằng nó có thật. Những phát hiện chỉ liên quan đến phong cách, thông tin chẩn đoán hay dọn dẹp code sẽ bị loại. Chúng tôi đã thử nghiệm A/B các bộ lọc đó trên PR của chính mình trước khi giữ chúng lại. Những gì còn lại xuất hiện dưới dạng bình luận ngay trên dòng code, được sắp xếp theo mức độ nghiêm trọng. Mỗi bình luận được gắn nhãn Important, Nit hoặc Pre-existing, để bug không do PR gây ra không bị hiểu thành lỗi của tác giả.

Mọi vấn đề được nêu ra đều phải được phản hồi. Bạn hoặc sửa nó, hoặc đánh dấu luồng thảo luận đã giải quyết kèm lý do. Thường thì một agent nhận sửa qua đêm, nên khi tác giả quay lại, PR đã trải qua thêm một vòng nữa.

3. Review bảo mật có thể chặn merge

Bảo mật cũng có lượt review tự động riêng. PR không thể merge khi còn bất kỳ vấn đề nào từ lượt review bug hoặc review bảo mật chưa được xử lý. Bạn hoặc sửa nó, hoặc đóng luồng thảo luận với một lý do ngắn gọn; đó cũng là cách loại bỏ một cảnh báo nhầm (false positive).

Nếu một commit sau đó sửa vấn đề, phát hiện tương ứng sẽ tự được xóa. Bạn có thể thiết lập điều tương tự với GitHub Action review bảo mật mã nguồn mở hoặc lệnh /security-review. Cách thiết lập được trình bày trong review bảo mật tự động trong Claude Code.

4. Các bước kiểm tra tự động có thể chặn merge

Những bước quen thuộc: lint, kiểm tra kiểu, test trên mọi nền tảng và build. (Chúng tôi đã viết về cách mở rộng CI để đáp ứng khối lượng này tại đây.) Một pull request CLI điển hình có thể chạy hàng chục bước kiểm tra trước khi có người xem. Mẫu PR yêu cầu nêu cách đã kiểm thử thay đổi và cách hoàn tác nó. Claude có thể điền nội dung đó, nhưng người yêu cầu thay đổi phải xác nhận.

5. Mức phê duyệt của con người tùy theo rủi ro

Sửa tài liệu và thay đổi trình tự động cập nhật có rủi ro khác nhau, nên chúng được review khác nhau.

Thay đổi quyết định mức rủi ro, không phải tác giả. Một bộ phân loại đọc thay đổi và chọn mức rủi ro cho nó. Bộ phân loại thứ hai xem thay đổi cụ thể này có cần thêm một người hay không, ngay cả khi mức rủi ro của nó nói rằng không cần. Một số đường dẫn luôn cần con người: bất kỳ phần nào người phụ trách đã liệt kê là nhạy cảm và mọi file workflow CI.

Chỉ tác giả đáng tin cậy mới được áp dụng quy trình nhẹ hơn. Chỉ tác giả trong danh sách đáng tin cậy của repo mới được áp dụng quy trình nhẹ hơn, chủ yếu là đội ngũ phụ trách repo đó. Tất cả những người khác đều cần người thứ hai phê duyệt. Lượt phê duyệt của agent cũng không bao giờ được tính là của con người. Review tự động có thể cho phép một thay đổi rủi ro thấp đi tiếp, nhưng không thể thay thế một vị trí bắt buộc phải có con người.

Ai prompt cho thay đổi thì chịu trách nhiệm về nó. Với PR do agent viết, người chỉ đạo agent được tính là một trong những reviewer bắt buộc, giống như khi họ tự gõ code.

Một lượt phê duyệt chỉ áp dụng cho một commit cụ thể. Nếu có commit mới mà hệ thống không thể bảo chứng, chẳng hạn một lần push của agent hoặc một bản merge được ai đó xử lý xung đột thủ công, thì phải phê duyệt lại.

6. Hàng đợi merge, flag và phát hành dần

Hàng đợi merge chạy lại mọi bước kiểm tra trên nhánh main với thay đổi đã được áp dụng, để hai PR đạt riêng rẽ không thể kết hợp thành một nhánh main bị hỏng. Hành vi mới thường được đặt sau flag và phát hành trước cho nhân viên Anthropic; mức sử dụng cao của chúng tôi thường làm lộ lỗi hồi quy (regression) trước khi người dùng gặp phải. Các bản phát hành công khai đến kênh latest trước. Kênh stable đi sau.

7. Phát hiện nhanh, rollback nhanh

Một số sai sót vẫn sẽ lọt qua, nên lớp cuối cùng tập trung vào việc phát hiện chúng thật nhanh. Có thể tắt flag mà không cần deploy. Claude Code luân phiên trực vận hành (on-call) hằng tuần, và khi xem xét sự cố, chúng tôi đặt câu hỏi lớp nào lẽ ra phải phát hiện vấn đề.

Việc nhận ra một bản merge có vấn đề vẫn phụ thuộc vào tác giả và người trực on-call, cũng như các dashboard theo dõi revert và sự cố. Chúng tôi chưa có cơ chế ngắt mạch (circuit breaker) tự siết chặt phê duyệt khi những số liệu đó thay đổi; các kỹ sư ở đây muốn có chúng trước khi mở rộng việc merge không cần con người sang nhiều code hơn.

Một đồng nghiệp nói rằng làm chậm lại đúng là giảm tỷ lệ lỗi, nhưng chủ yếu vì bạn đang làm ít đi mọi thứ. Chúng tôi muốn phát hiện và sửa vấn đề nhanh hơn thay vì vậy.

Cách chúng tôi cải thiện reviewer

Quy trình code review của chúng tôi liên tục được cải thiện theo một vòng lặp.

Giờ đây, mọi sự cố đều trở thành một eval. Đội ngũ đã tập hợp những PR từng gây sự cố, cùng các bản sửa tiếp và revert tương ứng, rồi nhờ những kỹ sư hiểu phần code đó xác nhận từng bug và vị trí của nó. Reviewer chạy trên bộ dữ liệu đó hằng ngày.

Hình: Một sự cố hoặc lần revert trở thành một trường hợp đã được chuyên gia kiểm tra và được thêm vào bộ eval. Một thay đổi của reviewer được đưa vào lượt chạy eval hằng ngày, chấm điểm trên mọi trường hợp; thay đổi được giữ lại nếu điểm tăng và bị loại nếu không, rồi vòng lặp bắt đầu lại với thay đổi tiếp theo.

Bộ eval lớn lên sau mỗi sự cố, và mọi thay đổi của reviewer đều được chấm điểm trên toàn bộ dữ liệu đó.

Chúng tôi đo độ nhiễu bằng cách quan sát mọi người làm gì với các bình luận. Bắt được nhiều bug hơn là chuyện dễ nếu bạn không ngại báo cả đống thứ không phải bug, nên chúng tôi cần một cách kiểm soát điều đó. Chúng tôi phân loại mọi bình luận reviewer để lại dựa trên phản hồi của người xử lý PR: họ đã sửa, nói nhận xét đó sai, nói hành vi đó là có chủ đích, hoặc quyết định rằng nó không quan trọng. Chúng tôi cũng chạy reviewer trên những PR đã biết là không có vấn đề và đếm số lần nó báo điều gì đó có thể khiến người ta thực hiện một thay đổi gây hại. Ưu tiên được viết rõ của chúng tôi là bắt bug thật trước, giảm số vòng review sau.

Độ nhiễu gây tốn kém hơn khi tác giả là agent. Một người có thể bỏ qua góp ý vụn vặt trong vài giây. Agent thì sửa nó, đồng nghĩa với thêm một commit và thêm một vòng review.

Review phải hội tụ. Một agent viết code và một agent review có thể khiến nhau bận rộn mãi không thôi. Một PR CLI đã trải qua hơn năm mươi vòng review và sửa lỗi trong một đêm trước khi tác giả dừng nó lại.

Khi chạy git blame trên những gì reviewer liên tục chỉ ra, khoảng 59% là code đã tồn tại từ lượt review đầu tiên. Reviewer hiếm khi tìm thấy bug mới; mỗi vòng nó lại tìm thêm một vài bug cũ.

Chính chúng tôi đã làm tình hình tệ hơn. Chúng tôi quen với việc mặc định chạy nhiều vòng, vì mỗi lượt đều phát hiện thêm điều mới. Điều này có thể đáng làm với thay đổi rủi ro cao, nhưng không phải với mọi PR. Đội ngũ giờ theo dõi số vòng cần để đạt cùng với độ bao phủ phát hiện bug (recall), và đã thay đổi cách review lại:

• Giới hạn số vòng. Sau ba vòng, reviewer yêu cầu tác giả lùi lại và xem xét lại hướng tiếp cận.
• Chỉ review lại phần diff sau vài lượt đầu.
• Chỉ ra cả loại bug, để tác giả sửa mọi trường hợp, không chỉ một dòng.
• Không lặp lại những vấn đề đã đăng.

Các agent review cũng chạy hằng đêm trên code hiện có, giúp chúng tôi bắt bug cũ trước khi chúng lộ ra ở nơi khác.

Hình: Trước và sau khi cải thiện khả năng hội tụ: tỷ lệ pull request đạt sau một vòng review và sửa tăng từ 65% lên 78%; tỷ lệ pull request cần từ năm vòng trở lên giảm từ 8.9% xuống 1.5%; số lượt review trung bình để đạt giảm từ 2.08 xuống 1.32.

Số vòng review trên mỗi pull request nội bộ giảm sau những thay đổi giúp review hội tụ

Những chỗ con người vẫn tham gia

Kéo một kỹ sư senior ra khỏi công việc cần tập trung sâu để bắt một sai sót thường gặp tốn kém hơn nhiều so với review tự động. Mọi người trong đội vẫn chịu trách nhiệm về:

• Quyết định có nên xây dựng nó hay không. Định hướng, gu đánh giá và phạm vi. Một đội từng tuyên bố đã giải quyết được nút thắt review vẫn giữ bước review của con người cho thay đổi từ bên ngoài đội, để có người hỏi “chúng ta có nên làm việc này không?”
• Review code rủi ro cao như thanh toán, trình tự động cập nhật và các workflow CI.
• Review kiến trúc đặt ra khuôn mẫu mà người khác sẽ làm theo.
• Đọc bằng chứng. Output của test, lệnh đã chạy và kết quả trả về, ảnh chụp màn hình, những vấn đề reviewer phát hiện. Nếu bạn không nói được các bước kiểm tra có thể bỏ sót điều gì, hãy yêu cầu một lượt review thực sự thay vì phê duyệt cho nhanh.
• Chịu trách nhiệm về kết quả. Mọi thay đổi được phát hành đều có một người chịu trách nhiệm, bất kể ai gõ code.

Chia sẻ context trong toàn đội

Công việc thứ hai của code review từ trước đến nay vẫn là lan tỏa hiểu biết về codebase. Đọc diff của đồng đội là cách bạn biết điều gì thay đổi và các phần ăn khớp với nhau thế nào. Nếu máy đọc phần lớn code, mọi người sẽ học code bằng cách nào?

Chúng tôi không có quy trình chính thức cho việc này. Không ai trong đội giữ trong đầu một mô hình tư duy hoàn chỉnh về Claude Code, và chúng tôi không nghĩ ai cần phải làm vậy. Khi muốn hiểu một phần codebase, mọi người nhờ Claude viết bài giải thích cho đúng phần đó. Việc này mất vài phút và phản ánh code đúng như trạng thái hiện tại.

Một số người trong chúng tôi còn đi xa hơn, nhờ Claude tạo một artifact nhỏ để trực quan hóa phần code đó và giải thích theo cách họ thích học.

Nếu mục tiêu là sử dụng tốt sự tập trung của con người, cách này tốt hơn đọc từng dòng của những diff vụn vặt. Một thay đổi câu chữ chỉ dài một dòng gần như không dạy bạn điều gì. Một bài giải thích về module bạn sắp thay đổi sẽ dạy bạn rất nhiều. Văn hóa mặc định làm việc trên các kênh Slack mở của chúng tôi cũng hữu ích, vì bạn thấy người khác đang xây dựng gì ngay trong lúc họ làm.

“Bạn merge thì bạn chịu trách nhiệm”

Nếu bạn merge một thay đổi nhỏ hoặc vừa mà vẫn có chuyện không ổn, thông lệ của đội là bạn thường sẽ sửa nó. Một vài điều giúp cách làm này không trở nên tệ hại:

• Thay đổi đều nhỏ, nên dễ review, debug và revert.
• Mọi thứ đều có thể hoàn tác. Flag, revert và phát hành theo từng giai đoạn giúp hoàn tác phần lớn sai sót trong vài phút.
• Phạm vi ảnh hưởng (blast radius) quyết định mức yêu cầu. Code mà lỗi của nó gây thiệt hại lớn cần nhiều người và nhiều bước kiểm tra hơn.
• Lỗi hồi quy lộ ra nhanh nhờ dữ liệu đo lường vận hành (telemetry) và việc sử dụng nội bộ.
• Đây không phải chuyện đổ lỗi. Bạn phụ trách sửa vì bạn có nhiều context nhất; việc xem xét sự cố tập trung vào hệ thống.

Trách nhiệm cũng được chia sẻ. Phần lớn đội ngũ làm việc trong các kênh mở, nơi bất kỳ ai cũng thấy người khác đang xây dựng gì, tiếp nối một luồng thảo luận hoặc giao cho Claude xử lý một chỗ còn thiếu; phản hồi cũng đến từ cả những người không phụ trách code đó. Sự cởi mở ấy đóng vai trò lớn trong việc giữ chất lượng cao mà không cần cửa kiểm soát ở từng dòng code.

Khi chúng tôi đổi hướng

Agent khiến việc bắt tay làm một thứ trở nên ít tốn kém, nên sẽ có những phần việc không nên được merge. Thường thì ai đó trong kênh sẽ hỏi lý do, chỉ ra một quyết định trước đây hoặc đề xuất cách đơn giản hơn, rồi tác giả đóng PR hoặc điều chỉnh lại nó.

Vì code được viết nhanh, đóng PR không tạo cảm giác mất mát. Mấu chốt là sớm nêu hướng đi khác trong luồng thảo luận, chứ không phải để lại một bình luận chặn merge trên PR đã hoàn thành.

Cách bạn có thể áp dụng quy trình này

Phần lớn các thành phần cần thiết để làm điều này cùng đội của bạn đã có sẵn hôm nay.

Trước pull request

• Cung cấp cho agent các bước kiểm tra nó có thể chạy, liệt kê trong một file CLAUDE.md ngắn gọn, cùng các hook chạy formatter và linter.
• Chạy /code-review và /security-review ở local, hoặc để một subagent với context mới hoàn toàn thực hiện review.
• Thêm REVIEW.md và chuyển những bình luận review lặp đi lặp lại vào đó.

Trên mọi pull request

• Bắt buộc chạy CI, và thêm “Kiểm thử”, “Rủi ro” cùng “Cách revert” vào mẫu PR.
• Thêm một AI reviewer (Code Review for Claude Code hoặc Claude Code GitHub Action) vào một repo, tinh chỉnh REVIEW.md trong vài tuần rồi mở rộng.
• Thêm review bảo mật tự động và yêu cầu mọi luồng thảo luận review được giải quyết trước khi merge.
• Điều chỉnh công sức review theo rủi ro: xem nhanh những thay đổi thường lệ, xem sâu ở nơi một bug bị bỏ sót gây thiệt hại lớn (Quick, Standard hoặc Deep trong Code Review).
• Giới hạn số vòng review; sau vài vòng đầu, chỉ review lại phần diff mới.

Phê duyệt

• Viết rõ các mức rủi ro, xác định dựa trên thay đổi chứ không phải tác giả; bắt đầu nghiêm ngặt rồi nới lỏng khi có bằng chứng.
• Chỉ dành quy trình phê duyệt nhẹ hơn cho những tác giả bạn tin tưởng.
• Dùng CODEOWNERS và bảo vệ nhánh để phần xác thực, thanh toán, các workflow CI và phát hành, cùng trình cài đặt luôn cần con người.
• Không bao giờ để lượt phê duyệt của bot thay thế lượt phê duyệt bắt buộc của con người; hủy hiệu lực phê duyệt khi có commit mới.

Merge và sau đó

• Dùng hàng đợi merge, feature flag, sử dụng nội bộ trước, phát hành theo từng giai đoạn và rollback chỉ bằng một bước.
• Biến sự cố và các lần revert thành bộ eval, rồi chấm điểm lại reviewer mỗi khi prompt, tool hoặc model của nó thay đổi.
• Đo thời gian của con người, dùng tỷ lệ revert và sự cố làm rào chắn.

Hướng đi tiếp theo

Bài công bố Code Review nói rằng phê duyệt pull request vẫn là quyết định của con người; sản phẩm đăng các vấn đề được phát hiện chứ không đăng phê duyệt. Các repo của chính chúng tôi đi xa hơn, cho phép người phụ trách quyết định những thay đổi rủi ro thấp nào được merge chỉ dựa trên kiểm tra tự động, và ranh giới đó vẫn tiếp tục dịch chuyển.

Khi một lượt review bỏ sót điều gì, chúng tôi hỏi model đã thiếu thông tin nào trước mắt và đưa cách khắc phục vào CLAUDE.md, một skill hoặc một bước kiểm tra mới. Mục tiêu không thay đổi: ít thời gian của con người hơn cho mỗi thay đổi, và số lần revert không nhiều hơn trước.

Nếu đội của bạn cho phép agent mở pull request, chúng tôi muốn nghe bạn chia sẻ những bước kiểm tra nào đã được tự động hóa, bước nào vẫn cần con người và bạn nghĩ chúng tôi đang sai ở đâu.

Cảm ơn Emma Webb, Michael Segner và Amie Rotherham đã review bài viết.