Đừng để Claude Code biến task nhỏ thành chi phí 1000x

Một post hài đang lên hot trong r/ClaudeCode có câu rất ngắn: “cách này chỉ tốn hơn 1000 lần thôi”. Nghe như meme, nhưng nó chạm đúng một vấn đề ngày càng rõ khi dùng AI coding agent: nhiều khi agent không sai về kỹ thuật, nhưng sai về kinh tế.

Với coding agent, “làm được” không còn là tiêu chuẩn đủ. Câu hỏi thực tế hơn là: làm được với chi phí bao nhiêu, mất bao lâu, tạo thêm bao nhiêu vòng sửa, và có đáng hơn việc tự làm hoặc chia nhỏ task không.

Vì sao meme này đáng chú ý

Claude Code, Codex, Cursor, Opencode hay các agent tương tự đang khiến việc thử nghiệm trở nên rất dễ. Anh em có thể giao một task, để agent đọc repo, sửa file, chạy test, rồi tiếp tục refine. Nhưng chính vì quá dễ, mình cũng dễ rơi vào bẫy “thêm một vòng nữa chắc sẽ xong”.

Vấn đề là mỗi vòng như vậy đều có chi phí:

• token và quota model,
• thời gian chờ agent suy nghĩ,
• thời gian review patch,
• rủi ro agent sửa lan sang chỗ khác,
• chi phí dọn lại context nếu hướng đi ban đầu sai,
• và quan trọng nhất là chi phí cơ hội của người đang ngồi canh.

Một task đáng lẽ tự làm 20 phút có thể biến thành 2 giờ “vibe debug” nếu mình không đặt giới hạn từ đầu.

Chi phí thật không chỉ là tiền model

Nhiều người chỉ nhìn vào bill API hoặc giới hạn 5 giờ, nhưng chi phí vận hành của agent rộng hơn nhiều.

Ví dụ một task frontend nhỏ:

• Agent đọc sai component liên quan.
• Nó sửa thêm CSS ngoài phạm vi.
• Test fail vì snapshot thay đổi.
• Mình yêu cầu sửa lại.
• Agent thêm abstraction không cần thiết.
• Cuối cùng vẫn phải tự đọc lại diff và gỡ bớt.

Tiền model có thể không lớn, nhưng tổng thời gian và rủi ro đã vượt quá lợi ích ban đầu. Đây là lúc “AI giúp code nhanh hơn” chuyển thành “AI tạo thêm công việc quản lý”.

Một nguyên tắc đơn giản: đặt ngân sách trước khi giao task

Mình nghĩ anh em nên giao việc cho coding agent giống như giao việc cho một developer junior hoặc contractor: có scope, có tiêu chí xong, có ngân sách, và có điểm dừng.

Trước khi bắt đầu, thử ghi rõ:

Ngân sách cho task này:
- Tối đa 20 phút agent time.
- Tối đa 2 vòng sửa.
- Không refactor ngoài các file liên quan.
- Nếu chưa chắc nguyên nhân, dừng lại và báo giả thuyết thay vì sửa tiếp.

Nghe hơi máy móc, nhưng nó giúp agent bớt lang thang và giúp mình biết lúc nào nên tự làm.

Khi nào nên dùng agent, khi nào nên tự code

Không phải task nào cũng đáng giao cho AI. Một checklist nhanh:

Nên dùng agent khi:

• task cần đọc nhiều file để hiểu ngữ cảnh,
• có pattern lặp lại trong codebase,
• cần viết test hoặc migration boilerplate,
• cần refactor có phạm vi rõ,
• mình có thể kiểm chứng output bằng test/lint/build.

Nên tự làm hoặc chỉ dùng agent để hỏi ý tưởng khi:

• task rất nhỏ và mình biết chính xác cần sửa dòng nào,
• bug phụ thuộc vào domain knowledge nằm ngoài repo,
• môi trường local khó tái hiện,
• thay đổi chạm vào dữ liệu, billing, auth, deploy hoặc hạ tầng,
• không có test để kiểm chứng.

Điểm mấu chốt: agent mạnh nhất khi đường kiểm chứng rõ. Nếu không có cách chấm đúng sai, agent rất dễ tiêu tiền để tạo cảm giác đang tiến triển.

Cách giảm “chi phí 1000x” trong workflow hằng ngày

Mình thường dùng vài rule nhỏ:

1. Bắt agent phân tích trước khi sửa

Prompt nên tách rõ hai pha:

Đừng sửa code ngay.
Đầu tiên hãy chỉ ra file liên quan, giả thuyết nguyên nhân, và cách kiểm chứng rẻ nhất.
Chỉ sau khi mình đồng ý mới tạo patch.

Cách này giảm khả năng agent lao vào sửa theo cảm tính.

2. Giới hạn diff

Yêu cầu agent chỉ sửa những file cần thiết. Nếu nó muốn đổi kiến trúc, phải giải thích vì sao.

Giữ patch nhỏ nhất có thể.
Không refactor ngoài phạm vi bug.
Nếu cần sửa quá 3 file, dừng lại và giải thích kế hoạch trước.

3. Dùng test làm hàng rào

Nếu task có thể kiểm chứng, bắt agent chạy test mục tiêu trước và sau khi sửa. Nếu không có test, yêu cầu nó thêm test nhỏ hoặc mô tả manual check cụ thể.

4. Đặt điểm dừng

Sau 2 vòng agent vẫn chưa xong, đổi chiến thuật:

• tự đọc code,
• hỏi agent tóm tắt những gì đã thử,
• rollback patch lan man,
• hoặc chia task nhỏ hơn.

Đừng để sunk cost kéo mình vào vòng “thêm một prompt nữa”.

Bài học cho team dùng AI coding agent

Nếu team dùng agent nghiêm túc, nên đo một vài chỉ số rất thực dụng:

• Task nào agent hoàn thành đúng ngay từ vòng đầu?
• Task nào cần con người sửa lại nhiều nhất?
• Loại bug nào agent hay đoán sai?
• Model nào rẻ nhưng đủ tốt cho boilerplate?
• Model nào đắt nhưng đáng dùng cho debug khó?
• Trung bình một task agent tạo bao nhiêu dòng diff bị bỏ đi?

Không cần dashboard phức tạp. Chỉ cần ghi lại 10-20 task là đã thấy pattern: việc nào nên giao, việc nào không.

Kết luận

Meme “cách này tốn hơn 1000 lần” buồn cười vì nó đúng. AI coding agent có thể tạo đòn bẩy lớn, nhưng cũng có thể biến một việc nhỏ thành một vòng tiêu hao quota, thời gian và sự tập trung.

Cách dùng bền vững không phải là giao mọi thứ cho agent. Cách dùng bền vững là đặt ngân sách, giới hạn scope, bắt kiểm chứng, và biết dừng đúng lúc.

Nếu một task nhỏ bắt đầu tốn hơn tự làm, đó không phải thất bại của AI. Đó là tín hiệu mình cần đổi chế độ: từ “agent làm thay” sang “agent hỗ trợ suy nghĩ”, hoặc đơn giản là tự mở file và sửa cho xong.