Review code agent viết: xếp hàng rủi ro, bắt giải trình

Agent sửa mười hai file, bạn gõ git diff, và diff trôi qua theo thứ tự nó đụng vào file, không theo thứ tự quan trọng. Bạn đọc hết, gật đầu, rồi phát hiện một tuần sau rằng có một exception bị nuốt ở đoạn thanh toán. Bài này đi qua ba cách đọc output của agent cho đỡ sót, cộng một lớp chặn drift từ đầu nguồn.

Vì sao review code agent viết mệt hơn review đồng nghiệp

Lý do nằm ở bối cảnh, không nằm ở chất lượng code. Pull request của đồng nghiệp đi kèm mô tả, lịch sử và một con người để bạn hỏi. Thay đổi của agent đi kèm một transcript chat mà bạn gần như chắc chắn chỉ liếc qua.

Tác giả bài viết trên Dev.to dẫn khảo sát Sonar 2026 State of Code trên hơn 1.100 developer: 96% không hoàn toàn tin code do AI sinh ra, chỉ 48% nói luôn kiểm tra trước khi commit, và 38% cho rằng review code AI tốn sức hơn review code đồng nghiệp. Chính anh cũng rào trước rằng Sonar bán sản phẩm kiểm định code và số liệu là tự khai, nên đọc nó như một tín hiệu chứ không phải một phép đo. Kết luận anh rút ra vẫn đứng vững: nút thắt đã dịch từ viết code sang đọc code.

Cách 1: đọc theo function, đừng đọc theo hunk

Agent thường viết lại cả một function từ đầu đến cuối. Line diff hiển thị việc đó thành một bức tường đỏ và xanh, trong khi thứ bạn cần là so sánh bản cũ và bản mới của toàn bộ function nằm cạnh nhau. Đây là thay đổi rẻ nhất: cấu hình diff tool đọc theo đơn vị function trước khi bàn tới chuyện thêm công cụ.

Cách 2: để một thang điểm tĩnh quyết định đọc gì trước

Tác giả xây một tool mã nguồn mở tên Klaub để làm phần này. Nó parse repo (Python, JavaScript, TypeScript, Rust, Go và Java được phân tích đầy đủ), khớp symbol giữa hai phiên bản, rồi xếp mọi function, class và file đã đổi vào một hàng đợi từ P0 tới P3.

Phần đáng học không phải cái tool, mà là cách chấm điểm có thể bóc tách ra được. Trong repo mẫu của bài, một function thanh toán vào P0 với điểm 83, chia ra như sau:

• +25: khai báo của một public symbol đã thay đổi
• +20: một entrypoint bên ngoài (một route) chạm tới được nó
• +15: nó động vào vùng nhạy cảm (payments)
• +15: một error bị bỏ qua, và finding này được đánh dấu là do chính thay đổi lần này tạo ra
• +8: không tìm thấy test nào đi kèm

Không có model nào trong thang điểm đó. Cùng một thay đổi luôn cho ra cùng một hàng đợi, và từng con số đều mổ xẻ được — thứ bạn không có khi nhờ chính LLM xếp hạng rủi ro. Tác giả cũng nói rõ giới hạn: thứ tự ưu tiên chỉ quyết định bạn đọc gì trước, nó không phát biểu mức độ nghiêm trọng, và một mục P3 vẫn có thể quan trọng. Tool còn hiển thị "contract" của từng đơn vị code: tham số trước và sau, route nó phục vụ, exception nó ném ra, caller trực tiếp và entrypoint chạm tới nó. Mỗi bước nhảy được đánh dấu resolved, heuristic hay unresolved, vì một đường dẫn không tìm thấy không chứng minh được rằng không có gì phụ thuộc vào đoạn code đó.

Cách 3: bắt agent khai ra quyết định kỹ thuật của nó

Diff cho bạn thấy cái gì đã đổi. Những lựa chọn đứng sau nó — một format lưu trữ mới, một exception bị nuốt — gần như không được viết xuống ở đâu cả. Cơ chế trong bài là yêu cầu agent xuất ra danh sách quyết định kỹ thuật dưới dạng JSON, mỗi quyết định viết cho người không biết gì về đoạn code đó: bối cảnh, quyết định là gì, vì sao, các phương án thay thế kèm đánh đổi, nó làm thay đổi điều gì, và câu hỏi dành cho bạn.

Chi tiết quan trọng nhất: mỗi quyết định phải ghi rõ nó được nêu ra trong thay đổi (commit message, comment, test) hay được suy ra từ diff. Nhóm suy ra chính là nhóm đáng chất vấn, vì không ai viết nó xuống cả.

Trong repo mẫu, agent liệt kê năm quyết định và hai trong số đó đáng dừng lại: một lệnh gọi tới payment provider thất bại bị bắt rồi bỏ qua, nên đơn hàng vẫn được lưu như thể đã thanh toán; và một endpoint mới liệt kê đơn hàng của bất kỳ user nào, có kiểm tra caller đã đăng nhập nhưng không kiểm tra caller có đúng là user đó không. Cả hai đều dễ lọt qua line diff, vì mỗi cái là một thứ mà code không kiểm tra. Kèm theo là cảnh báo đi chung với mọi cơ chế kiểu này: đó là lời tự thuật của agent về việc của chính nó, công cụ chỉ kiểm định format và tham chiếu chứ không kiểm định tính đúng, nên hãy coi nó là bản đồ đọc, không phải bằng chứng.

Chặn một lớp drift trước khi nó tới bàn review: DESIGN.md

Có những lỗi không đáng để review bắt, vì lẽ ra chúng không nên sinh ra. Ví dụ điển hình trong một bài Dev.to khác: bạn nhờ agent dựng trang settings, nó chạy được và trông gần đúng — màu xanh lệch một nấc, font na ná font của bạn, card bo góc theo kiểu brand bạn không dùng. Agent không ẩu; nó không có chỗ đáng tin cậy nào để đọc design system của bạn nên lấp bằng thứ phổ biến nhất.

DESIGN.md là một format mở của Google Labs, công bố trên GitHub dưới giấy phép Apache 2.0, mô tả là "for describing a visual identity to coding agents". File có hai lớp: design token viết bằng YAML (front matter ở đầu file hoặc block yaml trong từng mục) và phần văn xuôi Markdown trong các mục ## giải thích cách dùng những giá trị đó. Spec gọi token là "the normative values" và nói phần văn xuôi "provides context for how to apply them"; trang philosophy của dự án đi xa hơn, gọi văn xuôi là "the most vital part of the specification".

Lý do của cách chia đó rất thực tế: một mã hex nói cho agent biết màu nhấn của bạn là gì, nhưng chỉ một câu văn mới nói được rằng màu nhấn chỉ dành cho nút hành động chính và không dùng cho bất kỳ thứ gì khác. Các mục là tuỳ chọn, nhưng nếu dùng thì nên theo đúng thứ tự: Overview, Colors, Typography, Layout, Elevation & Depth, Shapes, Components, Do's and Don'ts. Lưu ý trước khi bạn đưa vào repo production: tác giả nhấn mạnh format đang ở version alpha, README ghi rằng spec, token schema và CLI "are under active development" — tức là hãy chuẩn bị tinh thần nó sẽ đổi.

Làm gì trong tuần này

Chọn một PR do agent viết gần nhất và thử đúng ba việc. Một, đọc lại nó theo đơn vị function thay vì theo hunk, xem bạn có thấy thứ gì đã bỏ sót không. Hai, tự viết ra thang điểm rủi ro của team bạn — public symbol đổi, route chạm tới được, vùng nhạy cảm, error bị nuốt, thiếu test — rồi xếp hàng đợi review theo nó, kể cả khi mới chỉ làm thủ công trên giấy. Ba, yêu cầu agent liệt kê các quyết định kỹ thuật của PR đó và đánh dấu cái nào là suy ra chứ không phải nêu ra. Nếu đội bạn có frontend, một file DESIGN.md nhỏ đặt ở gốc repo sẽ cắt bớt một lớp lỗi mà lẽ ra review không cần phải bắt.