“Thuốc giải” tốt nhất là review kiểu phản biện
Review output của AI như review một junior rất nhanh, rất tự tin, nhưng có thể sai ở những chỗ khó thấy.
1) “Could I explain this?” — Mình có tự giải thích lại được không?
Đây là câu hỏi đầu tiên và cũng là câu mạnh nhất. Nếu bạn không thể giải thích bằng lời của mình đoạn code AI vừa viết, khả năng cao là bạn chưa thật sự hiểu nó. Lúc đó, việc merge code chẳng khác nào duyệt một thứ mình không nắm chắc.
Nghiên cứu của Anthropic cũng củng cố điểm này: dùng AI để “sinh code hộ” có liên hệ với mức mastery thấp hơn; còn những người dùng AI để hỏi lại khái niệm, xin giải thích và tự xây hiểu biết thì giữ bài tốt hơn. Tức là chỉ riêng thói quen buộc bản thân “giải thích lại” đã là một cơ chế chống lệ thuộc rất mạnh.
Ví dụ: AI sinh ra một query SQL có window function hoặc CTE khá phức tạp. Nếu bạn không thể nói lại vì sao query đó đúng, hoặc không biết nó tệ ở trường hợp nào, thì chưa nên tin nó chỉ vì test hiện tại đang pass.
2) “What failure modes am I missing?” — Mình đang bỏ sót kiểu lỗi nào?
Đây là câu hỏi giúp kéo bạn ra khỏi happy path. OWASP nói rất rõ rằng output của LLM phải được xem như thứ cần được kiểm tra, làm sạch và xử lý an toàn trước khi đi tiếp xuống các thành phần khác. Nói theo ngôn ngữ kỹ sư: đừng chỉ xem “chạy được chưa”, mà phải hỏi “nó có thể hỏng theo những cách nào”.
NIST cũng khuyến nghị dùng hồ sơ quản trị rủi ro GenAI để giúp tổ chức nhận diện, đo lường và quản lý các rủi ro mới hoặc bị khuếch đại bởi GenAI trong suốt vòng đời hệ thống. Điều này rất phù hợp với việc review code AI theo failure mode thay vì theo cảm giác.
Ví dụ: AI viết một endpoint upload file. Bạn không chỉ hỏi “upload được chưa”, mà còn phải hỏi: file quá lớn thì sao, loại file giả mạo thì sao, đường dẫn nguy hiểm thì sao, log có lộ dữ liệu nhạy cảm không, và đầu ra sau đó có đi vào hệ thống nào khác không?
3) “Is this the right approach?” — Đây có phải đúng cách làm không?
Nhiều đoạn code AI viết ra có thể đúng ở mức cục bộ, nhưng chưa chắc đúng ở mức thiết kế. Prompt engineering của OpenAI nhấn mạnh rằng mô hình phản hồi tốt hơn khi bạn đặt rõ mục tiêu, ràng buộc và ngữ cảnh. Điều đó cũng có nghĩa là nếu bài toán được đóng khung sai, AI có thể giúp bạn đi rất nhanh… theo sai hướng.
Ví dụ: AI viết cache layer để tăng tốc một endpoint chậm. Nhưng bottleneck thật lại nằm ở query thiết kế chưa đúng hoặc workflow gọi dịch vụ thừa bước. Nếu chỉ vá ở tầng code, bạn có thể đang thêm complexity mà không chạm đúng nguyên nhân gốc.
4) “Does this fit our context?” — Nó có hợp với hệ thống và công cụ của mình không?
Đây là câu hỏi mà rất nhiều người bỏ qua khi dùng AI. GitHub Copilot nói rõ repository có thể được tự động index để hỗ trợ câu trả lời có context. ChatGPT Projects có built-in memory cho các chat và file trong project. Claude Code có hai hệ thống memory được nạp vào đầu mỗi cuộc hội thoại. Aider gửi repo map vào ngữ cảnh khi xử lý yêu cầu. Tất cả những điều đó cho thấy “AI hiểu codebase của mình tới đâu” là chuyện phụ thuộc công cụ và cấu hình, không phải mặc định giống nhau ở mọi nơi.
Ví dụ: bạn nghĩ AI đã “biết repo” nên chỉ hỏi “sửa bug này giúp tôi”. Nhưng thực ra tool chỉ đang thấy vài file, hoặc index chưa cập nhật, hoặc memory không bật theo cách bạn tưởng. Kết quả là câu trả lời nghe rất tự tin nhưng lại dựa trên bối cảnh thiếu.
5) Ý chính của phần này
Review kiểu phản biện không làm bạn chậm đi vô ích. Nó là phần bù bắt buộc cho tốc độ mà AI mang lại. AI giúp bạn tạo bản nháp rất nhanh; còn các câu hỏi phản biện giúp bạn không đem một bản nháp nghe hợp lý đi nhầm thẳng vào production.
Nguồn tham khảo:
