Review PR do agent viết — playbook 10 phút cho reviewer

Agent tạo PR nhanh hơn bạn đọc PR. Đây là quy trình 10 phút để bắt đúng chỗ yếu mà CI không thấy.

Tuần trước team bạn merge bao nhiêu PR? Trong số đó, bao nhiêu cái thật sự do con người viết từ đầu đến cuối?

Con số từ GitHub: hơn 1 trong 5 code review trên platform hiện tại có agent tham gia. Tổng lượng review đã vượt 60 triệu, tăng 10 lần trong chưa đầy một năm. PR do agent tạo trông sạch, CI xanh, diff gọn — và chính vì vậy mà reviewer dễ approve mà không nhìn thấy nợ kỹ thuật đang tích tụ bên dưới.

Bài này là một playbook ngắn: 10 phút review có hệ thống, đủ để bắt những lỗ hổng mà pipeline tự động bỏ sót.

Mục tiêu của playbook

Không phải chậm lại. Mà là review đúng lớp.

Agent code giống tấm vải nhìn phẳng phiu mặt ngoài — nhưng nếu sợi dọc (guardrail, CI, permission) bị lỏng thì cả mảng sẽ tuột khi chịu lực production. Reviewer chính là người kiểm tra sức căng của những sợi dọc đó, thay vì ngồi vuốt từng cm bề mặt.

Sau playbook này bạn sẽ có:

• Một checklist 6 điểm dùng lại được cho mọi agent PR
• Quy trình 10 phút chia rõ bước, không phụ thuộc cảm tính
• Danh sách red flag cụ thể để block hoặc request changes ngay

Checklist nhanh — in ra dán cạnh màn hình

| # | Kiểm tra | Block nếu... |
|---|----------|---------------|
| 1 | CI có bị yếu đi không? | Test bị xóa, skip, hoặc threshold giảm |
| 2 | Có utility/helper mới nào trùng code cũ? | Duplicate mà không justify |
| 3 | Critical path đã trace end-to-end chưa? | Logic boundary chưa có test |
| 4 | Workflow có đọc untrusted input? | Input chưa sanitize trước khi vào prompt |
| 5 | GITHUB_TOKEN scope có thừa không? | Write permission khi chỉ cần read |
| 6 | PR có plan rõ ràng không? | Body trống hoặc diff >5 file không liên quan |

Từng bước — phân bổ 10 phút

Phút 1–2: Phân loại trước khi đọc code

Mở file list, nhìn diff size. PR này thuộc nhóm nào: thay đổi nhỏ gọn (docs, config, CI tweak) hay phức tạp (multi-file logic, performance, test refactor)? Nhóm đầu review nhanh, nhóm sau cần trace sâu — quyết định này tiết kiệm cho bạn cả tiếng nếu làm đúng từ đầu.

Phút 2–4: Soi CI trước tiên

Trước khi đọc một dòng app code nào, mở .github/workflows, test config, coverage setting. Agent khi gặp CI đỏ có xu hướng "sửa" bằng cách tắt test hoặc thêm || true. Bất kỳ thay đổi nào làm yếu CI là hard stop — yêu cầu giải thích trước khi tiếp tục.

Ví dụ thực tế: Giả sử team bạn 4 người, một dev dùng Copilot agent tạo 3 PR trong buổi sáng. PR thứ hai rename một file test và coverage threshold tự giảm từ 80% xuống 72%. Nếu bạn không kiểm bước này, PR thứ ba sẽ kế thừa ngưỡng thấp hơn — và agent tiếp theo sẽ coi đó là "prior art".

Phút 4–6: Tìm code trùng lặp

Agent không có cái nhìn toàn cục về repo. Nó thấy pattern ở file A, tái tạo lại ở file B mà không biết file C đã có utility làm đúng việc đó. Với mỗi helper/function mới trong diff, grep nhanh repo. Tìm thấy duplicate? Không comment — yêu cầu consolidate trước merge.

Đây là điểm mà nợ kỹ thuật sinh sôi nhanh nhất: agent sau sẽ lại tìm thấy đoạn trùng và nhân bản tiếp. Như sợi chỉ lỗi trong khung dệt — để lâu thì cả tấm vải bung.

Phút 6–8: Trace critical path

Chọn đường logic quan trọng nhất trong diff. Đi từ input qua mọi transform đến output. Kiểm tra: boundary condition (zero, max, empty), permission check trên mọi branch, race condition tiềm ẩn.

Agent viết code compile được, pass test, nhưng sai — đó mới là dạng hallucination (bịa kết quả trông hợp lý) nguy hiểm nhất. Off-by-one trong pagination, thiếu auth check ở branch hiếm khi chạy trong test — những thứ này CI không bắt được.

Phút 8–9: Security boundary

Nếu PR chạm workflow gọi LLM hoặc xử lý input từ bên ngoài: kiểm tra prompt injection vector. PR body, issue body, commit message — bất kỳ thứ gì untrusted mà bị interpolate vào prompt rồi output chạy shell command là lỗ hổng thật.

Yêu cầu: least-privilege permission trong workflow YAML, tách bước "phân tích" khỏi bước "thực thi", không bao giờ eval output của model.

Phút 9–10: Yêu cầu bằng chứng

Với mọi logic change không trivial, yêu cầu test fail trên behavior cũ. Nếu agent không viết được test chứng minh bug nó claim đã fix — thì fix đó chưa đủ tin cậy.

Ba cái bẫy reviewer hay rơi

Bẫy 1: "CI xanh = an toàn"

CI xanh chỉ có nghĩa là test hiện tại pass. Nếu agent đã sửa test để pass, CI xanh không còn là tín hiệu đáng tin. Luôn kiểm tra CI có bị thay đổi không trước khi tin kết quả CI.

Bẫy 2: "PR nhỏ = ít rủi ro"

Một PR 12 dòng xóa permission check ở middleware nguy hiểm hơn PR 200 dòng thêm feature mới. Size không tương quan với risk — logic path mới tương quan.

Bẫy 3: "Agent sẽ sửa theo comment"

Bạn để review chi tiết, giải thích context, gợi ý hướng đi. Agent im lặng. Hoặc trả lời nhưng miss point hoàn toàn. Với PR lớn không có implementation plan — đừng đầu tư review sâu ngay. Yêu cầu breakdown trước:

"PR này quá lớn để review mà không có plan rõ ràng. Có thể tách thành unit nhỏ hơn, hoặc thêm summary mỗi phần làm gì và tại sao cấu trúc vậy không?"

Ngắn, rõ, không cá nhân hóa. Tiết kiệm cho bạn cả tiếng.

Next action — bắt đầu từ PR tiếp theo

Lấy checklist 6 điểm ở trên, paste vào template review của team. Cho Copilot code review chạy trước để bắt lỗi cơ học (style, type mismatch, missing error handling) — bạn chỉ cần focus vào phần judgment: context mà chỉ người trong team mới có.

Nếu muốn nâng thêm một bậc: viết custom instruction cho Copilot review, yêu cầu nó flag bất kỳ thay đổi nào chạm CI threshold hoặc thêm utility mới. Biến checklist thành automation — để bạn dành 10 phút cho trace logic thay vì scan boilerplate.

Bản chất: volume PR sẽ chỉ tăng. Thời gian review của bạn thì không. Playbook này giúp bạn đặt đúng 10 phút vào đúng lớp — thay vì dàn đều rồi bỏ sót chỗ quan trọng nhất.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng