Trước khi merge code do AI agent sửa, kiểm ba thứ: diff, test và quyền

Một coding agent có thể trả lời rất thuyết phục: đã sửa xong, test đều pass. Nhưng câu đó chưa phải bằng chứng để merge. Với một thay đổi thật, bạn cần biết agent đã sửa đúng file, test nào thực sự chạy được và nó đã dùng hoặc đòi quyền gì.

GitHub Security Lab gần đây mô tả một taskflow dùng agent cho fuzzing. Điểm đáng học ở đây không phải là coi agent như người duyệt cuối, mà là thiết kế công việc thành các bước có đầu ra kỹ thuật để kiểm tra. Khi áp dụng coding agent vào repository của mình, bạn nên giữ cùng nguyên tắc: lời giải thích của agent chỉ là chỉ dẫn để bắt đầu review; diff và kết quả chạy lại mới là bằng chứng.

Ví dụ dưới đây là tình huống giả lập, không phải kết quả benchmark của GitHub hay của một model cụ thể.

Bắt đầu từ diff, không bắt đầu từ phần agent tự tóm tắt

Giả sử bạn giao nhiệm vụ: thêm kiểm tra null cho hàm parseInvoice và bổ sung test. Agent tạo pull request với ba thay đổi:

• src/parseInvoice.ts: thêm nhánh xử lý null;
• tests/parseInvoice.test.ts: thêm hai test;
• .github/workflows/deploy.yml: đổi quyền của workflow từ đọc sang ghi.

Hai file đầu nằm trong phạm vi dễ hiểu. File thứ ba cần dừng lại ngay: nhiệm vụ xử lý null không tự nhiên đòi thay quyền deploy. Đừng cố đoán agent ‘có lý do’. Hãy đánh dấu FIX và yêu cầu bỏ thay đổi ngoài phạm vi hoặc giải thích bằng một yêu cầu kỹ thuật đã được con người chấp thuận.

Một cách rà nhanh là đọc danh sách file trước, rồi mới đọc từng hunk. Với mỗi file, hỏi ba câu: file này có cần thiết cho yêu cầu không; thay đổi có nhỏ hơn hoặc bằng phạm vi đã giao không; có đụng credential, workflow, dependency hay cấu hình phát hành không. Nếu câu cuối là có, mức kiểm tra phải cao hơn.

Tests passed chỉ có giá trị khi bạn chạy lại được

Agent có thể đã chạy test trong môi trường khác, chạy thiếu test hoặc chỉ diễn giải log. Vì vậy hãy lấy chính lệnh test liên quan từ repository và chạy lại trong môi trường kiểm soát. Với ví dụ trên, bạn cần ít nhất test của parseInvoice và một test cho hành vi cũ để chắc rằng sửa null không làm hỏng trường hợp bình thường.

Nếu agent thêm test nhưng test chỉ khẳng định implementation hiện tại thay vì yêu cầu nghiệp vụ, đừng tính đó là bằng chứng đủ. Hãy đọc input và expected result. Một test tốt cho lỗi null phải chứng minh hệ thống xử lý input thiếu theo hành vi bạn muốn, không chỉ chứng minh code không crash trong một ví dụ duy nhất.

Không chạy mã lạ trên máy chứa token sản xuất. Nếu pull request đến từ nhánh hoặc dependency chưa tin cậy, dùng môi trường cô lập và cơ chế CI phù hợp với chính sách repository.

Quyền phải nhỏ tương ứng với nhiệm vụ

Coding agent thường cần đọc repository và có thể cần ghi vào nhánh làm việc. Điều đó không có nghĩa nó cần quyền deploy production, đổi secret hay sửa cấu hình tổ chức. Hãy viết ra thao tác tối thiểu của nhiệm vụ: đọc file, sửa hai file, chạy test, tạo commit. Sau đó so danh sách đó với token, app permission và workflow mà agent dùng.

Nếu một tác vụ sửa hàm thuần túy chỉ chạy được sau khi cấp quyền rộng hơn, coi đó là một tín hiệu cần điều tra, không phải một bước setup mặc định. GitHub Security Lab mô tả agent trong một taskflow bảo mật cụ thể; bài viết đó không chứng minh rằng mọi agent hay mọi repository nên dùng cùng một cấu hình quyền.

Dùng ba quyết định thay vì câu hỏi ‘agent có tốt không?’

Sau review, chọn một trong ba trạng thái:

MERGE — mọi file đều thuộc phạm vi; test liên quan chạy lại được và đạt; không có quyền hoặc thay đổi nhạy cảm ngoài nhu cầu.

FIX — ý tưởng chính hợp lý nhưng có file ngoài phạm vi, test thiếu hoặc thay đổi cần thu hẹp. Gửi lại yêu cầu cụ thể, ví dụ: giữ thay đổi ở parseInvoice và test; hoàn nguyên deploy.yml.

REJECT — thay đổi không truy được về yêu cầu, test không thể tái hiện trong điều kiện an toàn, hoặc agent cần quyền rộng mà không có lý do được phê duyệt. Khi đó bắt đầu lại từ task nhỏ hơn thường an toàn hơn việc vá tiếp một PR khó hiểu.

Bạn có thể lưu một review note rất ngắn:

Scope: PASS / FAIL — file nào ngoài phạm vi?
Tests: PASS / FAIL — lệnh nào đã chạy lại?
Permissions: PASS / FAIL — quyền nào vượt nhu cầu?
Decision: MERGE / FIX / REJECT
Evidence: link diff + CI run + ghi chú quyền

Mục tiêu không phải biến review thành thủ tục dài. Mục tiêu là khiến một thay đổi do agent tạo có cùng loại bằng chứng mà bạn đòi hỏi ở thay đổi quan trọng do con người tạo. Khi ba dòng scope, tests, permissions chưa trả lời được, câu agent nói đã xong chưa đủ để merge.

Nguồn tham khảo

1. github.blog

Tiếp trên bàn Việc hôm nay: Ba ngoại lệ cũ quyết định email nào được gửi tự động