Gần như ai cũng rơi vào một khuôn mẫu khi làm việc với các agent viết code, và nó âm thầm phá hỏng toàn bộ mục đích của việc sử dụng một agent. Agent tạo ra một thay đổi, và bạn đặt câu hỏi hiển nhiên: "Cái này có chạy không?" Agent trả lời có. Bạn tin nó, vì nó nghe có vẻ tự tin và thường thì nó đúng. Và thỉnh thoảng, nó tự tin sai hoàn toàn — và bạn chỉ phát hiện ra khi đã lên production.
Vấn đề không phải là agent nói dối. Vấn đề nằm ở câu hỏi.
Vì sao "cái này có chạy không?" là câu hỏi sai
Khi bạn hỏi một agent liệu chính thay đổi của nó có hoạt động hay không, bạn đang yêu cầu nó đánh giá đầu ra của mình bằng chính lối lập luận đã tạo ra đầu ra đó. Nó đang tự chấm bài của mình bằng cùng một cây bút. Nếu nó bỏ sót một trường hợp biên khi viết code, nó cũng sẽ bỏ sót đúng trường hợp biên đó khi đánh giá code, bởi vì không có gì mới xuất hiện cả — vẫn là mô hình đó, ngữ cảnh đó, những điểm mù đó.
Tệ hơn nữa, các mô hình ngôn ngữ có xu hướng thiên về đồng tình. Đặt câu hỏi theo kiểu "cái này xử lý email null đúng chứ, phải không?" thì bạn không hề yêu cầu một đánh giá — bạn đã đưa ra một kết luận và mời agent xác nhận nó. Nó thường sẽ làm vậy. Điều bạn nhận lại không phải là sự xác minh. Đó là một tiếng vọng rất trôi chảy của chính hy vọng của bạn.
Hãy yêu cầu bằng chứng thay vào đó
Cách sửa rất nhỏ nhưng thay đổi mọi thứ: đừng yêu cầu agent khẳng định rằng thay đổi hoạt động nữa, mà hãy yêu cầu nó chứng minh cho bạn thấy. Bằng chứng là một sản phẩm bạn có thể tự kiểm tra, do hệ thống tạo ra chứ không phải do ý kiến của agent về hệ thống. Không phải bằng chứng nào cũng ngang giá trị — có một thứ bậc tương đối:
- Bằng chứng thực thi là mạnh nhất: agent thực sự đã chạy code và cho bạn xem đầu ra thật — bài kiểm thử đã vượt qua, lệnh đã trả về đúng như mong đợi.
- Bằng chứng trước-và-sau gần như tốt tương đương: một thay đổi cụ thể trong trạng thái có thể quan sát được. Số lượng truy vấn giảm từ 47 xuống còn 2; yêu cầu từng thất bại giờ trả về 200.
- Một bài kiểm thử do agent viết yếu hơn, vì điểm mù đã bỏ sót lỗi cũng có thể bỏ sót nó trong bài kiểm thử — nhưng một bài kiểm thử mà bạn có thể đọc và chạy vẫn tốt hơn nhiều so với một lời khẳng định suông.
- Một lời giải thích bằng miệng là yếu nhất. Đôi khi đó là tất cả những gì bạn có thể có được, nhưng "đây là lập luận của tôi" không phải là bằng chứng; đó chính là thứ mà bằng chứng phải kiểm chứng.
Cách xử lý trong mọi trường hợp đều giống nhau: biến câu hỏi có/không thành một yêu cầu về điều gì đó có thể quan sát được.
Trong thực tế trông như thế nào
Thay vì hỏi "liệu migration này có xử lý được email null không?", hãy yêu cầu agent tạo một dòng dữ liệu có email null, chạy migration, và cho bạn xem đầu ra. Thay vì hỏi "cái này đã sửa được truy vấn N+1 chưa?", hãy yêu cầu nó thêm ghi log truy vấn, gọi đến endpoint, và cho bạn xem số lượng truy vấn trước và sau. Thay vì hỏi "rate limiter có reset không?", hãy yêu cầu nó chạm ngưỡng giới hạn, chờ, thử lại, và cho bạn xem yêu cầu thành công. Trong mỗi trường hợp, bạn đã thay một lời khẳng định phải tin bằng một kết quả có thể đọc được.
Đây là lý do agent của chúng tôi hoạt động trong sandbox
Bằng chứng chỉ có tác dụng khi agent thực sự có thể chạy được mọi thứ, và đó là một quyết định thiết kế chứ không phải một ý nghĩ thêm vào sau. Mọi lần chạy của TaskGoblin đều diễn ra trong một sandbox với repository đã được clone và toolchain sẵn sàng, vì vậy agent không chỉ suy luận về việc code sẽ làm gì — nó có thể chạy các bài kiểm thử, thực thi các lệnh, và quan sát kết quả thực tế. Khi nó review một merge request, những phát hiện của nó chỉ ra hành vi cụ thể, và khi bạn trả lời @taskgoblin fix, thay đổi đó là thứ nó có thể kiểm chứng chứ không chỉ đơn thuần biện luận cho nó.
Đây cũng là lý do vì sao một môi trường phát triển tốt lại đem lại giá trị hơn bao giờ hết. Một agent có thể khởi động các dịch vụ của bạn, nạp dữ liệu mẫu, và chạy bộ kiểm thử của bạn thì có thể tạo ra bằng chứng thực sự; một agent chỉ có thể đọc code thì chỉ có thể đưa ra ý kiến. Dự án của bạn càng có thể chạy được, bạn càng có thể kiểm chứng nhiều hơn phần đầu ra của agent thay vì phải tin tưởng suông.
Phiên bản một câu
Đừng hỏi một agent liệu công việc của nó có đúng hay không. Hãy yêu cầu nó chứng minh cho bạn thấy điều đó — và ưu tiên những cách chứng minh mà bạn có thể tự kiểm tra được. Agent chạy code và trao cho bạn kết quả đầu ra đang làm điều duy nhất mà agent chỉ đảm bảo suông cho code không bao giờ làm được: cho bạn một thứ gì đó để tin tưởng ngoài chính sự tự tin của nó.
