Một trong những cảm giác dễ nghiện nhất của vibe coding là nhìn agent chạy. Nó đọc file, sửa code, chạy build, fix lỗi, lại chạy build, lại sửa. Mọi thứ trông như tiến triển. Nhưng chạy lâu không đồng nghĩa với đi đúng hướng.

Chi phí của vibe coding không chỉ là tiền token hoặc subscription. Chi phí còn là thời gian chờ, context bị loãng, diff khó review, lỗi lặp, và niềm tin sai rằng “nó đang cố thì chắc sắp xong”. Agent có thể tự chạy lâu hơn con người, nhưng nó không tự động biết khi nào nên dừng.

Người dùng phải đặt giới hạn. Không phải để làm AI yếu đi, mà để giữ quyền kiểm soát.

Long run không tự động tốt hơn

Autonomous agent có lợi khi task có nhiều bước rõ: đọc repo, sửa file, chạy test, fix lỗi compile, viết summary. Nhưng nếu task mơ hồ, chạy lâu chỉ làm mơ hồ đắt hơn.

Ví dụ prompt:

Make the app production-ready.

Agent có thể hiểu là thêm validation, đổi UI, thêm auth, viết test, đổi folder, tối ưu build, thêm logging. Mỗi bước có thể hợp lý riêng, nhưng tổng thể không còn kiểm soát. Sau 40 phút, bạn nhận một diff lớn, không biết phần nào cần giữ.

Prompt tốt hơn:

Add client-side validation to the booking form only.
Do not change persistence, admin view, styling system, or routes.
Stop after tests/build and summarize the diff.

Agent chạy ngắn hơn, nhưng kết quả dễ review hơn. Vibe coding mạnh nhất khi task nhỏ, tiêu chí xong rõ, và scope bị khóa.

Cost tăng theo retry, test, context và blast radius

Nhiều người chỉ tính cost theo một lần prompt. Thực tế cost tăng theo vòng lặp.

Một task nhỏ có thể thành đắt khi:

  • Agent phải đọc nhiều file vì scope rộng.
  • Prompt chứa context dài không cần thiết.
  • Build/test chậm.
  • Agent fix lỗi compile nhiều vòng.
  • Nó chọn dependency mới rồi phải xử lý conflict.
  • Nó refactor nhiều file nên mỗi vòng diff lớn hơn.
  • Bạn tiếp tục prompt “fix it” mà không reset hướng.

Ngay cả khi platform không tính từng token rõ ràng, bạn vẫn trả bằng thời gian và review debt. Một diff 20 file có thể mất một giờ review dù agent viết trong 10 phút.

Cost thật nên hỏi:

Sau vòng này, tôi có hiểu rõ hơn không?
Diff có nhỏ hơn và gần mục tiêu hơn không?
Hay chỉ có thêm thay đổi để đọc?

Nếu diff lớn dần nhưng app không ổn hơn, bạn đang trả tiền cho loop sai.

Dấu hiệu agent đang kẹt

Agent bị kẹt không phải lúc nào cũng báo lỗi. Nhiều khi nó nói rất tự tin. Một vài dấu hiệu:

  • Cùng một lỗi xuất hiện sau nhiều lần “fixed”.
  • Mỗi lần fix lại chạm thêm file mới.
  • Nó đổi hướng mà không giải thích.
  • Nó thêm fallback thay vì xử lý root cause.
  • Nó xoá test hoặc bỏ qua test đang fail.
  • Nó nói “should work now” nhưng không có bằng chứng.
  • Nó thay đổi dependency để né lỗi nhỏ.
  • Nó sửa UI trong khi bug là data.
  • Nó claim build pass nhưng bạn chưa thấy output hoặc command.

Sau hai vòng fix không tiến triển, đừng để chạy tiếp theo quán tính. Dừng lại và yêu cầu báo cáo:

Stop editing.
Summarize the exact error still failing.
List what you tried and why it did not work.
List the smallest next options.
Do not modify code.

Đây là cách chuyển agent từ chế độ “cứ sửa” sang chế độ “giải thích trạng thái”.

Stop condition phải viết trước

Stop condition là điều kiện để agent dừng. Nếu không có, nó có thể tiếp tục tối ưu, refactor, hoặc fix vòng quanh.

Stop condition có thể là:

  • Dừng sau khi form validation hoạt động.
  • Dừng sau khi build pass.
  • Dừng sau khi tạo patch và summary.
  • Dừng nếu cần schema migration.
  • Dừng nếu cần secret hoặc production access.
  • Dừng nếu phải thêm dependency.
  • Dừng nếu test fail quá hai vòng.

Prompt ví dụ:

Implement this in one small slice.
Stop if you need to change database schema, auth, or deployment config.
Stop after two failed test-fix attempts and report the blocker.

Stop condition không làm agent yếu. Nó giúp bạn nhận biết lúc nào task vượt quyền tự động.

Budget cap không chỉ là tiền

Budget cap có thể là:

  • Tối đa 15 phút.
  • Tối đa 5 files changed.
  • Không thêm dependency.
  • Không đổi schema.
  • Không vượt 2 retry.
  • Không sửa ngoài src/features/booking.
  • Không động lockfile.

Với non-tech user, giới hạn theo file/flow dễ dùng hơn giới hạn token.

Ví dụ:

Limit this change to the booking form and validation helper.
If more files are required, stop and explain why.

Hoặc:

Do not modify more than 3 source files without asking.

Không phải lúc nào cũng giữ đúng số file. Nhưng nếu agent cần vượt giới hạn, nó phải giải thích trước. Đó là điểm kiểm soát.

Chia task nhỏ hơn thay vì cho một run kéo dài

Khi agent chạy sai hướng, bản năng thường là prompt dài hơn để sửa. Nhưng prompt dài hơn trong context đang rối có thể làm nó rối thêm.

Cách tốt hơn là chia lại:

Task A: Make the form reject empty name/email/date.
Task B: Show confirmation screen after valid submit.
Task C: Persist booking to existing storage.
Task D: Add read-only admin list.
Task E: Add CSV export.

Mỗi task có expected result và test riêng. Nếu Task C hỏng, bạn không phải nghi cả app.

Một mẹo thực tế: sau mỗi task, yêu cầu agent viết summary rất ngắn:

Changed files:
Behavior changed:
How verified:
Known risks:

Summary này giúp task tiếp theo có context sạch hơn. Nó cũng giúp người review biết agent nghĩ mình đã làm gì.

Context dài có thể làm agent tệ hơn

Nhiều người nghĩ càng paste nhiều càng tốt. Không hẳn. Context tốt là context liên quan. Context dài nhưng lộn xộn khiến agent khó phân biệt rule hiện tại, quyết định cũ, ý tưởng đã bỏ, và bug thật.

Trước task mới, lọc context:

  • Goal hiện tại.
  • Files liên quan.
  • Constraints không được vi phạm.
  • Behavior cần giữ.
  • Error/output mới nhất.
  • Definition of done.

Đừng paste cả chat 200 tin rồi hỏi “fix tiếp”. Nếu cần tiếp tục, viết một context pack ngắn. Agent không cần biết mọi ý tưởng bạn từng cân nhắc. Nó cần biết trạng thái thật và mục tiêu tiếp theo.

Đừng để “it says fixed” thay bằng evidence

Agent nói đã fix không phải bằng chứng. Evidence là:

  • Build output pass.
  • Test cụ thể pass.
  • Screenshot đúng.
  • Manual flow bạn click qua.
  • Diff nhỏ và đúng scope.
  • Log không còn error cũ.

Trong vibe coding, bạn phải học câu này:

Show evidence, not confidence.

Prompt:

Do not say "fixed" unless you include the exact command/test/manual steps used to verify it.

Nếu tool không thể chạy test, nó phải nói không thể chạy, không được giả vờ.

Chốt lại

Agent chạy lâu có thể hữu ích, nhưng chỉ khi task rõ và có giới hạn. Nếu không, long run biến thành máy tạo diff. Bạn trả bằng tiền, thời gian chờ, context loãng, và review debt.

Trước mỗi run, đặt scope, stop condition, budget cap. Sau mỗi run, đòi evidence. Nếu agent fix hai vòng vẫn sai, dừng sửa và yêu cầu báo cáo blocker. Cách kiểm soát vibe coding không phải viết prompt dài hơn. Cách kiểm soát là chia nhỏ hơn, giới hạn rõ hơn, và chỉ cho chạy tiếp khi kết quả trước đó đã được chứng minh.