Cổng CI cho code agent: reviewer sạch context và 3 chốt remote

PR đang mở, CI xanh, diff 400 dòng do agent viết và cũng do chính phiên đó tự review. Bạn kéo qua một lượt, thấy hợp lý, bấm merge — lần thứ mười trong tuần.

Bài này dựng cái cổng đứng giữa hai thao tác đó: ai (hoặc cái gì) được quyền nói "merged", và tại đúng khoảnh khắc bấm thì phải kiểm lại những gì. Bốn quy tắc dưới đây lấy từ hai repo thật đang chạy workflow agent hàng ngày.

"Nhìn hợp lý" không phải là kiểm chứng

Tác giả Network Doctor — một CLI viết bằng Go — mô tả vấn đề gọn hơn mọi định nghĩa: "AI can produce code that looks extremely convincing while being completely unnecessary, subtly wrong, overengineered, or based on a bug that never existed in the first place. That is what is known as AI slop." Điểm chết nằm ở chữ convincing: loại code này không gãy ở compile, không đỏ ở test có sẵn.

Cái giá của việc bỏ bước kiểm chứng đã đo được ở quy mô ngành. TechCrunch đưa tin ngày 25/9: hãng an ninh mạng UpGuard "found around 16,000 databases on which some degree of personal data was exposed while they were hosted by Supabase". Bài báo diễn giải nguyên nhân: "the generated code can often contain security flaws, or apps might require specific configuration that the developer may be ignorant of." CISO của Supabase, Bil Harmer, trả lời rằng nền tảng "secure by default" và bảo mật là trách nhiệm chia sẻ: "We provide secure defaults and tooling, and customers control how their own projects are configured."

Dịch sang ngôn ngữ vận hành: phần "customers control how their own projects are configured" chính là phần agent đang viết hộ bạn, và cũng là phần không ai đọc lại.

Quy tắc 1: người review không được là người viết

Lawrence Liu, tác giả công cụ Orbi, đặt đây là quy tắc đầu tiên: "the reviewer is not the author. Not a second pass in the same session with a different prompt: a separate process, a fresh context, started after the pull request exists, reading the frozen diff."

Ba chữ quan trọng là fresh context. Một prompt "giờ review lại code trên" trong cùng phiên không phải review — nó thừa hưởng toàn bộ lý do mà phiên đó đã tự thuyết phục mình khi viết. Reviewer sạch context không biết ý định người viết, và theo Liu đó mới là điểm mạnh: "If the code needs the author's intentions to make sense, the code is not finished."

Vòng lặp cũng cần trần cứng. Liu đặt trần 5 lượt: "A round that ends with findings is not a merge; it is another round... exhausting them is a stop, not a merge." Hết lượt là dừng và gọi người, không phải hạ chuẩn cho qua.

Biến thể rẻ hơn: dùng model khác cho khâu review. Tác giả Network Doctor nói rõ lý do không phải vì model nào đáng tin hơn — "It is because disagreement is useful."

Quy tắc 2: kiểm lại ba điều kiện ngay tại thời điểm merge

Verdict "đạt" có hạn sử dụng. Giữa lúc review xong và lúc bấm merge, nhánh có thể đã dịch chuyển. Liu kiểm lại ba thứ với remote ngay tại bước merge:

• CI xanh trên đúng commit head đã được review.
• Head chưa dịch chuyển kể từ lúc có verdict — "A push after the review invalidates it."
• Base đã cập nhật: PR phải chứa main mới nhất, hợp bằng merge thường chứ không phải rebase viết lại thứ đã review.

Điều kiện thứ hai gần như miễn phí, và hầu hết team không bật. Ví dụ minh hoạ từ bài viết:

gh pr merge "$PR" --squash --match-head-commit "$REVIEWED_HEAD"

Liu mô tả hành vi: "If the remote head moved after the review, that call fails instead of merging something nobody reviewed." Đây là chốt rẻ nhất trong cả bài — một flag, không hạ tầng, không service mới.

Lý do phải viết thành code thay vì thành thói quen cũng đáng chép lại: "they are three lines in a state machine rather than three habits in a person's head, so they hold at 3 a.m. on the ninetieth pull request."

Quy tắc 3: lỗi lặp lại thì biến thành invariant của repo

Chiến lược của Network Doctor là "make the repository hostile to unverified work". Hai luật cụ thể đáng bê nguyên.

Chứng minh bug tồn tại trước khi sửa. Guideline repo ghi: "Before changing behavior, verify the reported issue against the current HEAD." Với agent, luật này lọc rác từ đầu nguồn — đưa một bug report nghe thuyết phục thì agent sẽ lao vào sửa, kể cả khi bug đã được vá từ tháng trước.

Không để AI tự tuyên bố mình đúng. Tác giả gọi thẳng vòng lặp hỏng: "AI writes the code. AI reads the code. AI says the code looks correct. Done. That is not verification." Thay thế là một lệnh check chạy được: format, vet, build đúng ràng buộc như bản release, cross-compile, chạy test.

Luật meta quan trọng nhất: "If you keep correcting the same AI mistake manually, consider turning the correction into an invariant. The repository starts remembering the lesson for you." Ví dụ nhỏ đến mức buồn cười — repo này có hẳn một test từ chối dấu gạch ngang dài trong file text, vì tác giả chán nhắc model mỗi lần.

Chỗ cần đặt invariant là các hợp đồng nhàm chán: shape tham số, exit code, tên field JSON, hành vi timeout. Agent rất giỏi làm cho thay đổi trông nhất quán — theo tác giả, chúng "can update the implementation, update the nearby test, update the comment, and produce a beautifully self-consistent change that still breaks the public contract." Test nằm ngoài vùng implementation là thứ duy nhất bắt được lớp lỗi đó.

Quy tắc 4: ticket mơ hồ thì không cổng nào cứu được

Liu cảnh báo giới hạn của mọi gate phía sau: "A vague ticket produces a confident wrong delivery, and no gate downstream catches that, because the gate checks whether the code does what the ticket said." Gate kiểm tính nhất quán giữa code và mô tả; nó không biết mô tả có đúng ý bạn hay không. Điều kiện nghiệm thu phải viết sao cho một thứ không hỏi lại được vẫn kiểm được là "xong".

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

1. Thêm --match-head-commit vào bước merge. Một dòng, chặn nhóm lỗi "merge thứ chưa ai review".
2. Tách review sang phiên riêng, chạy sau khi PR tồn tại, đọc diff đã đóng băng — và đặt trần số vòng lặp.
3. Chọn ba lỗi bạn đã sửa tay từ hai lần trở lên, viết thành test. Đó là ba invariant đầu tiên.
4. Viết lại một Issue gần nhất theo chuẩn "điều kiện nghiệm thu kiểm được bằng máy", rồi so với thứ agent giao ra.

Liu tự mô tả kết quả trên repo của mình sau một tháng: 431 pull request đã merge, 416 Issue đi hết vòng, 40 bản release — và theo lời anh, "I have not read the diffs." Đó là con số của người đã dựng xong cả bốn lớp trên, không phải điểm khởi đầu của bất kỳ ai. Thứ đáng sao chép là bốn điều kiện, không phải con số.