Review code bằng LLM: 3 lượt quét thay vì một prompt

Bạn dán 200 dòng code vào Claude, gõ "review giúp", rồi nhận về mười gạch đầu dòng nghe rất hợp lý. Ba ngày sau production sập vì đúng cái nhánh mà model bảo là "đơn giản hoá được". Bài này mô tả quy trình ba lượt quét giúp bạn giữ tốc độ của LLM mà không đánh đổi bằng một sự cố.

Vì sao review một lượt gần như luôn trượt

Tác giả bài AI Code Review: How to Actually Use LLMs Without Shipping Garbage trên dev.to đặt vấn đề bằng một câu đáng dán lên tường: "LLMs are pattern matchers, not safety engineers" — mô hình khớp mẫu, không phải kỹ sư an toàn.

Anh liệt kê chỗ LLM mạnh: phát hiện lỗi đặt tên hiển nhiên, bắt các antipattern hiệu năng phổ biến, đề xuất refactor theo pattern đã có. Và chỗ nó yếu: hiểu kiến trúc cụ thể của bạn, biết cái gì là critical còn cái gì thì không, và toàn bộ phần context bạn chưa nói ra.

Bài học của anh đến từ một lần review hàm xử lý thanh toán. Model đề xuất "simplifying" phần error handling. Theo mô tả của tác giả, đó là "technically valid code—would've been a production disaster": code hợp lệ về mặt kỹ thuật, nhưng đưa lên production là thảm hoạ.

Điểm chung của các ca hỏng kiểu này: bạn hỏi model một câu duy nhất, mơ hồ, rồi coi output là kết luận thay vì là đầu vào cần thẩm định.

Lượt 0 — nạp context trước khi dán code

Tác giả gọi bước nạp context là "80% of the battle" — con số này là ước lượng của anh, không phải đo đạc, nhưng thứ tự ưu tiên thì đúng. Thay vì "review this code", anh dựng prompt nêu rõ hệ thống là gì và ưu tiên theo thứ tự nào: backend high-frequency trading, ưu tiên latency dưới một phần nghìn giây, correctness hơn clever, và audit trail cho compliance. Phần cuối chỉ đích danh thứ cần soi: race condition, thiếu audit log, nút thắt hiệu năng.

Một bài dev.to khác, Why Your Prompts Keep Failing, đưa ra khung tư duy khớp với việc này: viết prompt như viết một function signature — "define inputs, define outputs, define constraints" trước khi điền logic. Tác giả bài đó nói thẳng rằng "works sometimes" không phải là spec bạn chấp nhận từ một API, nên đừng chấp nhận nó từ một prompt đang chạy thật trong sản phẩm.

Tác giả cũng nhấn mạnh vai trò role framing: "'You are a senior backend engineer reviewing this PR' produces different output than 'review this code,'" ngay cả khi phần chỉ dẫn phía sau y hệt nhau. Role thu hẹp giả định của model về đối tượng đọc và độ sâu cần có.

Ba lượt quét, ba nhiệm vụ tách rời

Đây là phần đáng chép lại nhất. Thay vì một prompt gánh hết, tác giả chạy ba lượt với ba câu hỏi khác nhau:

Lượt	Câu hỏi gửi model	Thứ bạn đang tìm
1	"Are there obvious bugs or security holes?"	Lỗi logic lộ liễu, lỗ hổng bảo mật
2	"Is this maintainable? Will someone hate this in six months?"	Nợ kỹ thuật, khả năng đọc lại
3	"Performance—anything that'll choke under load?"	Nghẽn khi tải cao

Nhận xét của anh về cách làm một lượt rất gọn: "Single-pass AI review is lazy."

Một người đọc tên Brian bình luận dưới bài và diễn đạt lại lý do kỹ thuật chuẩn hơn cả bài gốc: tách thành pass bảo mật, pass maintainability và pass hiệu năng là "give the model different jobs instead of asking one review prompt to notice everything" — giao cho model ba việc khác nhau, thay vì bắt một prompt để ý mọi thứ cùng lúc.

Về mặt thực hành, cách này còn một lợi ích phụ: mỗi lượt cho ra một danh sách ngắn, và danh sách ngắn thì bạn thực sự đọc hết.

Hai ca thật: một lần cứu, một lần suýt phá

Ca cứu: một hàm dựng câu truy vấn database động. Model đánh dấu một nhánh thiếu parameterized query. Tác giả thừa nhận anh đã biết đó là rủi ro nhưng bỏ qua vì "we only use that path internally". Model trả lời: "Internal or not, this is SQL injection territory." Nhận xét của anh: LLM không có lợi ích gì trong quyết định đó, nên nó không tự thuyết phục mình bỏ qua.

Ca suýt phá: cũng team đó, hàm khác. Model đề xuất thay lớp cache tự viết bằng Redis — lời khuyên hợp lý trong đa số trường hợp. Nhưng theo tác giả, hệ thống của họ có yêu cầu invalidation dưới một phần nghìn giây và Redis không đáp ứng được. Anh mất khoảng 20 phút đọc lại kiến trúc mới đủ cơ sở phản bác.

Hai ca này nói cùng một điều: giá trị của model nằm ở chỗ nó không có thành kiến, và rủi ro của nó nằm ở chỗ nó không có bối cảnh.

Checklist trước khi merge

Tác giả chốt bằng một danh sách năm mục cần tick trước khi ship code đã qua LLM review:

• Bạn đã tự đọc code, không chỉ đọc bản tóm tắt của AI.
• Bạn hiểu lập luận của AI — đủ để giải thích lại.
• Thay đổi không mâu thuẫn với ràng buộc kiến trúc hiện có.
• Nếu là thay đổi bảo mật hoặc hiệu năng, bạn đã lần theo các failure mode có thể xảy ra.
• Một người quen codebase sẽ ra cùng quyết định.

Bộ lọc nhanh của anh cho từng đề xuất: "Would I explain this to a junior the same way the AI did?" Nếu câu trả lời là không, đào sâu thêm trước khi chấp nhận.

Prompt review là code — hãy version và test nó

Nếu bạn dùng cùng một prompt review cho cả team, bài Why Your Prompts Keep Failing có hai lời khuyên đáng ghép vào quy trình. Thứ nhất, tách phần cố định khỏi phần thay đổi — "the same way you'd separate a SQL query from its parameters" — để prompt có thể version, diff và test được thay vì thành một đống nối chuỗi.

Thứ hai, coi prompt đang chạy production nghiêm túc như một database migration: giữ một bộ input đại diện cùng output shape mong đợi, chạy lại mỗi khi sửa prompt hoặc đổi model. Tác giả nói phần lớn regression anh gặp không đến từ model kém đi, mà từ việc ai đó chỉnh prompt cho một edge case rồi âm thầm làm hỏng ba case khác không ai theo dõi.

Bắt đầu từ đâu trong tuần này

Chọn một repo, viết sẵn ba prompt cho ba lượt quét, kèm một khối context mô tả hệ thống và thứ tự ưu tiên. Lưu chúng vào repo như file thường, không để trong lịch sử chat. Sau vài PR, xem lượt nào thực sự bắt được lỗi ở codebase của bạn — rất có thể chỉ hai trong ba lượt đáng giữ, và đó là thông tin bạn chỉ có được sau khi tách chúng ra.