Từ khi agent bắt đầu tự mở pull request, phần lớn các đội đều than phiền cùng một chuyện: hàng đợi đầy ứ và chẳng ai tin vào kết quả review.
Review sản phẩm của agent là một công việc khác với review của đồng nghiệp, vì kiểu lỗi khác nhau. Đây là quy trình được nắn theo điều đó.
Bắt đầu từ danh sách thư viện, không phải từ diff
Một người đóng góp hiếm khi thêm gói mà không nói gì. Agent thêm ba gói và im lặng.
GitHub siết hai mặc định bảo mật chuỗi cung ứng ngày 28/07 chính vì lý do này — Dependabot cảnh báo gói độc hại trên nhiều hệ sinh thái hơn, còn Actions giữ workflow khả nghi chờ phê duyệt. Những mặc định đó là lưới an toàn, không phải bước review. Hãy đọc diff của lockfile trước, mọi lần.
Đối chiếu thay đổi với yêu cầu, đừng đối chiếu nó với chính nó
Code của agent gần như luôn nhất quán nội tại theo đúng cách nó được tạo ra. Nó biên dịch được, văn phong đồng nhất, và đọc trôi. Đó là lý do review từng dòng cảm giác rất năng suất mà bắt được rất ít.
Lỗi phổ biến không phải một dòng hỏng. Đó là một thay đổi giải quyết bài toán hơi khác với bài toán được đặt ra. Hãy đọc lại issue gốc trước khi đọc diff.
Đọc test trước phần hiện thực
Test viết cùng lúc với phần hiện thực thường mã hoá lại những gì phần hiện thực đang làm, chứ không phải những gì nó nên làm. Hãy đọc test trước, khi bạn còn giữ ý niệm riêng về hành vi đúng, và tự hỏi liệu những test này có fail không nếu code sai.
Chẻ thay đổi đủ nhỏ để review được
GitHub đưa stacked pull request lên bản xem trước công khai ngày 30/07. Đây chính là lý do.
Một lượt chạy của agent cho ra migration, model, handler và test cùng lúc. Chẻ nó thành một stack thì mỗi bước mới nhận được một lần review thật sự thay vì một cái bấm duyệt.
Dùng bộ review tự động như lượt một, không phải phán quyết
Copilot code review lên GA cùng agent skills và MCP ngày 29/07, cho phép nó đối chiếu diff với hệ thống và quy ước của chính bạn. Đó là loại vấn đề không người review nào bắt được ổn định.
Nhưng nó không bắt được thay đổi giải sai bài toán. Việc đó phải để con người làm.