Agent lập trình giải được bài toán, nhưng chúng đã lãng phí bao nhiêu công sức?

Các agent lập trình (coding agent) dựa trên mô hình ngôn ngữ lớn đang ngày càng phổ biến trong quy trình phát triển phần mềm. Nhưng khi một agent giải xong bài toán, câu hỏi đặt ra không chỉ là "đúng hay sai" mà còn là "nó đã tiêu tốn bao nhiêu nguồn lực để đi đến đích". Một nghiên cứu mới với 50.400 lượt chạy trên các kho mã thực tế đã mang lại câu trả lời khá bất ngờ.

Bài toán đặt ra: hiệu quả chứ không chỉ kết quả

Phần lớn các bộ đánh giá agent lập trình hiện nay chỉ tập trung vào tỷ lệ giải đúng bài toán — tức là liệu bản vá cuối cùng có vượt qua được bộ kiểm thử hay không. Cách đo lường này bỏ qua một khía cạnh quan trọng: chi phí thực tế để agent đạt được kết quả đó.

Nghiên cứu này tiếp cận theo hướng khác. Thay vì chỉ hỏi "agent có giải được không", nhóm tác giả đặt câu hỏi sâu hơn: agent đã lãng phí bao nhiêu lượt suy luận, tạo ra bao nhiêu thay đổi mã dư thừa, và liệu có những quy tắc nào trong harness (khung điều phối agent) giúp giảm lãng phí hay không.

Thiết kế nghiên cứu: kho mã thực, quyết định được gieo sẵn

Điểm đáng chú ý của nghiên cứu là cách tiếp cận "seeded agent decisions" — nghĩa là các quyết định của agent được gieo sẵn một cách có kiểm soát. Kết hợp với việc chạy trên các kho mã thực tế thay vì bài toán giả lập, nghiên cứu tạo ra bối cảnh gần với công việc lập trình hàng ngày.

Tổng cộng 50.400 lượt chạy được thực hiện, cho phép nhóm nghiên cứu rút ra những mẫu hình thống kê đáng tin cậy về hành vi của agent. Đây là quy mô đủ lớn để phân biệt giữa những sai sót ngẫu nhiên và những xu hướng mang tính hệ thống.

Ba phát hiện chính

1. Lượt suy luận bị lãng phí là phổ biến

Agent thường mất nhiều lượt suy luận để khám phá những hướng đi không dẫn đến đâu, thử đi thử lại các cách tiếp cận đã thất bại, hoặc đọc lại những phần mã không liên quan. Những lượt dư thừa này không giúp ích cho kết quả cuối cùng nhưng vẫn tiêu tốn thời gian và chi phí tính toán.

2. Patch churn — thay đổi mã rồi lại hoàn tác

Một hiện tượng đáng chú ý là patch churn: agent viết mã, sau đó hoàn tác hoặc sửa lại chính những thay đổi mình vừa tạo ra. Điều này cho thấy agent thiếu một kế hoạch rõ ràng từ đầu, hoặc không duy trì được ngữ cảnh nhất quán trong suốt quá trình làm việc. Hệ quả là bản vá cuối cùng có thể đúng, nhưng hành trình đến đó đầy rẫy những bước thừa thãi.

3. Quy tắc harness có tác động khác nhau

Nghiên cứu cũng xem xét các quy tắc harness — những chỉ dẫn và ràng buộc điều phối hành vi của agent. Không phải mọi quy tắc đều hữu ích như nhau. Một số quy tắc giúp giảm đáng kể số lượt lãng phí và patch churn, trong khi những quy tắc khác gần như không tạo ra khác biệt, thậm chí còn cản trở agent.

Kết quả cuối cùng đúng chưa chắc đã có nghĩa là quá trình làm việc hiệu quả. Hiệu quả vận hành cần được đo lường riêng.

Ý nghĩa với người làm phần mềm tại Việt Nam

Với các đội ngũ phát triển phần mềm ở Việt Nam đang bắt đầu tích hợp agent lập trình vào quy trình làm việc, những phát hiện này mang lại vài gợi ý thực tế:

• Đừng chỉ đo tỷ lệ giải đúng bài toán. Cần theo dõi cả chi phí token, số lượt suy luận và mức độ thay đổi mã không cần thiết.
• Thiết kế harness cẩn thận. Những quy tắc rõ ràng về phạm vi công việc, thứ tự thực hiện và tiêu chí hoàn thành có thể giúp agent làm việc gọn gàng hơn.
• Xem xét patch churn như một chỉ số chất lượng. Nếu agent liên tục sửa rồi hoàn tác, đó là dấu hiệu cần điều chỉnh cách giao việc hoặc cung cấp ngữ cảnh.

Kết luận

Các agent lập trình đang tiến bộ nhanh về khả năng giải bài toán, nhưng nghiên cứu với 50.400 lượt chạy này nhắc nhở rằng giải được và giải hiệu quả là hai chuyện khác nhau. Việc hiểu rõ agent lãng phí công sức ở đâu — và quy tắc harness nào thực sự giúp ích — sẽ là chìa khóa để biến những công cụ này từ món đồ chơi thú vị thành công cụ sản xuất đáng tin cậy.