Checklist đánh giá một AI coding agent trước khi đưa vào workflow
Có rất nhiều AI coding agent ra mắt mỗi tháng, và demo nào cũng ấn tượng. Nhưng khoảng cách giữa “làm được demo đẹp” và “giao được việc thật, không cần ngồi canh” là rất xa. Đây là checklist mình dùng trước khi để một agent chạm vào code thật của mình.
1. Hành vi grounding và verification
Câu hỏi đầu tiên: agent có tự kiểm chứng claim của nó không, hay chỉ đoán rồi báo cáo như thật? Một agent tốt sẽ:
- Đọc file/chạy lệnh để xác nhận trạng thái trước khi khẳng định điều gì đó (“test đang fail”, “hàm này chưa được gọi ở đâu”).
- Chạy lại đúng kịch bản lỗi ban đầu sau khi sửa, thay vì chỉ nói “đã sửa xong”.
- Không bịa API, đường dẫn file, hay kết quả test không tồn tại.
Cách kiểm tra nhanh: giao một bug có thể tái hiện, xem agent có thực sự chạy để tái hiện trước khi sửa, và chạy lại để xác nhận sau khi sửa hay không. Anthropic gọi hành vi này là lấy “ground truth” từ môi trường ở mỗi bước, trong bài Building Effective Agents.
2. Kỷ luật phạm vi (scope discipline)
Một agent hữu ích chỉ làm đúng việc được giao — không tự thêm refactor, không tự đổi convention, không “tiện thể” dọn dẹp code không liên quan. Dấu hiệu cảnh báo: đổi 20 file cho một fix 2 dòng, hoặc âm thầm bỏ bớt yêu cầu khi thấy khó làm. Scope creep khó phát hiện ngay, nhưng là nguyên nhân phổ biến khiến review PR do agent tạo ra mất nhiều thời gian hơn tự làm.
3. Cách xử lý sự mơ hồ
Khi yêu cầu không rõ ràng, agent nên làm gì? Có ba lựa chọn: hỏi lại, chọn phương án an toàn/bảo thủ nhất và nói rõ đã chọn gì, hoặc đoán bừa. Chỉ hai lựa chọn đầu chấp nhận được. Một agent liên tục hỏi lại những việc tự tra cứu được (đọc file, chạy lệnh, xem docs) thì gây phiền; một agent luôn đoán bừa khi mơ hồ thì nguy hiểm hơn không dùng agent.
4. Đánh đổi chi phí/độ trễ
Agent mạnh hơn thường chậm hơn và đắt hơn. Câu hỏi thực tế không phải “agent nào tốt nhất” mà là “agent nào đủ tốt cho loại việc này với chi phí chấp nhận được”. Việc lặp lại, máy móc (đổi tên biến hàng loạt, viết test boilerplate) nên dùng agent rẻ/nhanh. Việc cần suy luận nhiều bước, đọc hiểu kiến trúc lớn thì đáng trả thêm chi phí cho agent mạnh hơn. Dùng một agent đắt cho việc đơn giản, hoặc một agent yếu cho việc phức tạp, đều lãng phí.
5. Minh bạch khi thất bại
Đây có lẽ là tiêu chí quan trọng nhất và bị đánh giá thấp nhất: khi agent không làm được việc, nó có nói thẳng “tôi bị chặn ở đây, cần X” hay không, hay giao lại một sản phẩm nửa vời trông như đã hoàn thành? Một agent báo lỗi rõ ràng, dừng đúng lúc, và mô tả chính xác cái gì thiếu — đáng tin hơn nhiều so với một agent luôn “hoàn thành” mọi yêu cầu nhưng đôi khi hoàn thành bằng cách giả vờ.
Cách áp dụng
Mình không đánh giá agent qua benchmark hay demo có sẵn. Thay vào đó, giao một task thật, có độ khó vừa phải, có ít nhất một chỗ mơ hồ cố ý, và xem agent xử lý năm điểm trên ra sao. Kết quả thường nói nhiều hơn bất kỳ bảng so sánh nào.
Ví dụ minh hoạ: lần gần nhất mình áp dụng checklist này cho một agent cụ thể, kết quả chấm điểm (thang 1-5) như sau:
Điểm thấp nhất ở tiêu chí 5 là lý do mình chưa giao việc có rủi ro cao cho agent đó — dù bốn tiêu chí còn lại ổn.