Claude tự viết 90% mã nguồn của chính nó: Bên trong quy trình review code tại Anthropic

Làm thế nào để review code khi các AI agent tạo ra khối lượng thay đổi khổng lồ mỗi ngày? Đội ngũ phát triển Claude Code tại Anthropic vừa chia sẻ chi tiết về quy trình làm việc của họ, tiết lộ rằng Claude viết khoảng 90% mã nguồn của chính Claude Code. Câu hỏi đặt ra không còn là "con người có đọc code không?" mà là "điều gì có thể sai với thay đổi này, và công cụ kiểm tra nào — tự động hay con người — là phù hợp để phát hiện nó?"

Minh họa quy trình review code tự động với AI

Khối lượng thay đổi tăng vọt khi agent viết code

Khi các 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 lượt trong tháng 5 lên hơn 30.000 lượt trong tháng 9 cùng năm. Claude Code nằm trong một repository riêng biệt, nhưng cũng chịu áp lực tương tự.

Khi tốc độ ship code nhanh đến vậy, việc review thủ công từng dòng một là điều gần như bất khả thi. Đây chính là lý do đội ngũ buộc phải thay đổi cách tiếp cận.

Từ tháng 6 đến tháng 9, số pull request được merge vào codebase Claude Code đã tăng hơn gấp đôi, trong khi tỷ lệ phải revert (hoàn tác) giảm hơn 40%. Điều đáng chú ý là họ không hề loại bỏ việc review — họ chỉ chuyển phần lớn việc đọc code sang máy móc, tối ưu cho thời gian và sự tập trung của con người, đồng thời đầu tư mạnh vào việc giúp quá trình sửa lỗi trở nên nhanh chóng và dễ dàng.

Chúng tôi cho rằng câu hỏi "liệu có con người đọc code này không?" là một cách đánh giá không chính xác cho câu hỏi thực sự: "điều gì có thể sai với thay đổi này, và công cụ kiểm tra nào là phù hợp để phát hiện nó?"

Review diễn ra liên tục, không còn là chốt chặn cuối cùng

Cách đặt vấn đề mới đã thay đổi cả thời điểm diễn ra review. Trước đây, review là một cổng chặn ở cuối con đường: viết code, mở PR, chờ đồng nghiệp xem xét. Giờ đây, review diễn ra liên tục, giống như tính năng kiểm tra chính tả khi bạn đang viết vậy.

Phần lớn các thay đổi đã được Claude review và sửa ít nhất một lần trước khi một con người được yêu cầu xem xét. Điều này giúp bắt được hầu hết các lỗi thông thường và dành sự tập trung của đội ngũ cho những câu hỏi ở tầng cao hơn.

Mục tiêu của đội ngũ là hầu hết các pull request trong các repo Claude Code (CLI, ứng dụng desktop, web và mobile) đều được merge với tối đa một người trong vòng lặp — người đó có thể chính là tác giả — mà không làm tăng tỷ lệ revert hay sự cố. Họ đo lường thời gian của con người qua số lượt phê duyệt, số bình luận và thời gian PR phải chờ đợi. Tỷ lệ revert và sự cố chính là rào chắn: nếu chúng tăng lên, nghĩa là thời gian của con người không hề được tiết kiệm, chỉ là chuyển từ chỗ này sang chỗ khác.

Các tầng kiểm tra trước khi PR được tạo

Điểm thú vị là phần lớn việc review giờ đây diễn ra trước khi một PR tồn tại. Đội ngũ đưa cho Claude một thứ nó có thể chạy — như test, build hoặc ảnh chụp màn hình để so sánh với thiết kế — và yêu cầu nó trình bày kết quả thay vì chỉ nói "xong rồi". Sau đó, một subagent sẽ review diff với ngữ cảnh mới.

Trước khi mở PR, nhiều kỹ sư còn chạy thêm một số công cụ nội bộ: một cái để truy tìm bug, một cái để đơn giản hóa diff, và một cái để kiểm tra hành vi từ đầu đến cuối. Các thay đổi về giao diện cũng được đối chiếu với hướng dẫn thiết kế của công ty.

Boris Cherny, người tạo ra Claude Code, từng gọi việc trao cho Claude một cách để tự kiểm chứng công việc của nó là điều quan trọng nhất để có kết quả tốt. Ông ước tính nó giúp kết quả cuối cùng tốt hơn hai đến ba lần.

Claude review mọi PR trước khi con người xem

Mỗi pull request đều được Claude review trước khi một người xem xét. Nó đọc diff đối chiếu với toàn bộ repo và ý định đã nêu của PR, rồi tự hỏi: thay đổi này có giải quyết đúng vấn đề không, có khớp với hệ thống không, có phá vỡ thứ gì khác không?

Khi 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 thực chất đã tăng từ 16% lên 54%. Hầu hết các PR trên 1.000 dòng đều có phát hiện, còn các PR nhỏ thường trở về với trạng thái sạch sẽ.

Một chi tiết quan trọng: các phát hiện phải được xác minh bởi các agent khác trước khi con người xem xét. Nhiều agent cùng tìm bug, sau đó một nhóm riêng biệt bỏ phiếu cho từng phát hiện — chỉ những cái được đủ số phiếu đồng ý mới được đăng tải. Những phát hiện chỉ liên quan đến style, chẩn đoán hay dọn dẹp sẽ bị loại bỏ.

Mỗi phát hiện còn được gắn nhãn Important (Quan trọng), Nit (Nhỏ nhặt) hoặc Pre-existing (Đã tồn tại từ trước), để một bug mà PR không hề gây ra sẽ không bị quy kết cho tác giả.

Bảo mật và kiểm tra tự động

Bảo mật cũng có quy trình review tự động riêng. Một PR không thể merge khi bất kỳ phát hiện nào từ review bug hoặc review bảo mật vẫn còn đang mở. Bạn phải sửa nó hoặc đóng luồng thảo luận kèm lý do ngắn gọn — đó cũng là cách để xác nhận một cảnh báo sai.

Bên cạnh đó là các kiểm tra thông thường: lint, kiểm tra kiểu dữ liệu, test trên mọi nền tảng và build. Một pull request CLI điển hình có thể chạy hàng chục kiểm tra trước khi bất kỳ ai xem xét.

Phân loại rủi ro quyết định mức độ review

Không phải thay đổi nào cũng cần mức độ review như nhau. Một bản sửa tài liệu và một thay đổi trong trình tự động cập nhật mang mức rủi ro khác nhau, nên chúng được review khác nhau.

Điểm đáng chú ý là thay đổi quyết định tầng rủi ro, không phải tác giả. Một bộ phân loại sẽ đọc thay đổi và chọn tầng rủi ro tương ứng. Một bộ phân loại thứ hai sẽ hỏi liệu thay đổi cụ thể này có cần thêm người không, ngay cả khi tầng của nó nói là không.

Chỉ những tác giả nằm trong danh sách tin cậy của repo mới được đi theo đường nhẹ nhàng hơn — thường là chính đội ngũ sở hữu repo. Tất cả những người khác cần một người thứ hai phê duyệt. Và quan trọng hơn: phê duyệt của một agent không bao giờ được tính thay cho con người.

Người đưa ra yêu cầu thay đổi phải chịu trách nhiệm cho nó. Với một PR do agent viết, người điều khiển agent được tính là một trong những người review bắt buộc — hệt như khi họ tự tay gõ code.

Học hỏi từ sự cố và đo lường nhiễu

Mọi sự cố đều trở thành một bài kiểm tra (eval). Đội ngũ đã thu thập các PR trong quá khứ từng gây ra sự cố, cùng với các bản sửa và revert của chúng, rồi mời các kỹ sư am hiểu đoạn code đó xác nhận từng bug và vị trí của nó. Công cụ review sẽ chạy đối chiếu với tập dữ liệu này hằng ngày.

Để đo lường độ nhiễu, họ quan sát cách mọi người phản ứng với các bình luận. Rất dễ để bắt được nhiều bug hơn nếu bạn không ngại gắn cờ cho nhiều thứ không phải bug — nên cần có một phép kiểm tra cho điều đó. Mọi bình luận mà công cụ review để lại đều được phân loại theo cách người dùng PR phản hồi: họ sửa nó, nói nó sai, nói hành vi đó là cố ý, hay quyết định nó không quan trọng.

Ưu tiên của chúng tôi, được viết ra rõ ràng, là bắt được bug thật trước tiên và giảm số vòng review sau đó.

Khi agent review làm việc với agent viết code

Nhiễu còn tốn kém hơn khi tác giả là một agent. Một con người có thể gạt bỏ một lời nhắc nhỏ nhặt trong vài giây. Nhưng một agent sẽ đi sửa nó — nghĩa là thêm một commit và thêm một vòng review nữa.

Vấn đề quan trọng nhất là review phải hội tụ. Một agent tác giả và một agent review có thể khiến nhau bận rộn vô thời hạn. Đội ngũ từng ghi nhận một PR CLI trải qua hơn 50 vòng review và sửa chữa 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ì công cụ review liên tục gắn cờ, khoảng 59% là code đã tồn tại từ lượt review đầu tiên. Công cụ này hiếm khi tìm ra bug mới — nó chỉ tìm thêm vài bug cũ mỗi vòng.

Tương lai của review code trong thời đại AI

Bài học lớn nhất là kéo một kỹ sư cấp cao ra khỏi công việc tập trung sâu để bắt một lỗi thông thường tốn kém hơn nhiều so với một lượt review tự động. Tại Anthropic, công việc của các kỹ sư đã chuyển từ đọc từng diff sang đưa ra những quyết định mà máy móc còn yếu.

Chức năng thứ hai của review code vốn luôn là lan tỏa hiểu biết về codebase. Đọc diff của đồng nghiệp là cách bạn học được điều gì đã thay đổi và các mảnh ghép khớp với nhau ra sao. Nếu máy móc làm phần lớn việc đọc, làm sao mọi người học được code?

Đội ngũ thừa nhận họ không có quy trình chính thức cho việc này. Không ai giữ một mô hình tinh thần hoàn chỉnh về Claude Code trong đầu, và họ cho rằng không ai cần phải làm vậy. Khi muốn hiểu một phần của codebase, họ chỉ cần yêu cầu Claude viết một bản giải thích cho đúng phần đó — mất vài phút và phản ánh code như nó đang tồn tại ngày hôm nay.

Đối với các đội ngũ Việt Nam đang bắt đầu áp dụng AI agent vào quy trình phát triển phần mềm, kinh nghiệm này đáng để tham khảo. Điểm mấu chốt không phải là bỏ review, mà là dịch chuyển thời gian của con người đến đúng nơi cần thiết, đồng thời xây dựng các rào chắn đo lường được — tỷ lệ revert, tỷ lệ sự cố — để đảm bảo chất lượng không bị đánh đổi lấy tốc độ.