Một prompt có thể làm app tốt lên rất nhanh. Một prompt cũng có thể phá app rất nhanh. Vấn đề không nằm ở prompt dài hay ngắn. Vấn đề là trước khi bấm chạy, bạn có điểm quay lại chưa.

Người mới vibe coding thường học rollback sau khi đã đau. App đang chạy ổn, bạn yêu cầu “làm UI đẹp hơn và thêm admin dashboard”. Agent sửa 30 file. Dashboard chưa xong, form booking đang chạy tự nhiên lỗi, mobile layout vỡ, và bạn không biết đoạn nào cần giữ. Lúc đó mới hỏi “undo được không?” thì đã muộn một nửa.

Checkpoint và Git không làm bạn chậm đi. Nó làm bạn dám thử mà không mất kiểm soát.

Checkpoint là thói quen trước khi thử

Một số platform có checkpoint hoặc rollback built-in. Bạn có thể quay lại trạng thái trước khi agent sửa. Cách nghĩ này đúng, dù bạn dùng Replit, Lovable, Bolt, Cursor, Claude Code, Codex hay repo local: trước mỗi thay đổi rủi ro, tạo một trạng thái biết là tốt.

Known-good state đơn giản là: app mở được, flow chính chạy được, không có lỗi rõ trong console, và bạn biết thay đổi gần nhất là gì nên có thể quay lại nếu cần.

Đừng đợi app “hoàn hảo” mới checkpoint. Checkpoint tốt nhất nằm sau mỗi lát mỏng đã test được. Ví dụ:

  • Landing page hiển thị đúng.
  • Booking form submit được với validation cơ bản.
  • Confirmation screen hiện đúng data.
  • Admin list đọc được booking.
  • Export CSV tải file đúng cột.

Mỗi điểm này là một bậc thang. Nếu bậc sau hỏng, bạn quay về bậc trước, không rơi xuống tầng trệt.

Git commit là checkpoint có tên

Nếu code sống trong Git, commit là cách đặt tên cho trạng thái tốt. Không cần biến bài này thành Git tutorial. Bạn chỉ cần hiểu ba việc.

Thứ nhất, commit sau khi app đang ổn:

git status --short
git diff
git add <files>
git commit -m "feat: add booking form"

Thứ hai, commit không phải nơi trộn mọi thứ. Một commit nên tương ứng một lát đã test. Đừng gom “thiết kế lại homepage”, “đổi database schema”, “thêm export”, “sửa auth” vào cùng một commit chỉ vì agent làm trong một phiên.

Thứ ba, commit message không cần thơ. Nó cần giúp bạn nhận ra điểm quay lại:

add booking form validation
add admin booking list
add CSV export

Khi app hỏng, bạn có thể nói: “quay lại commit trước khi thêm CSV export”. Câu đó rõ hơn nhiều so với “quay lại lúc nó còn chạy”.

Branch trước khi làm thay đổi rủi ro

Branch là phòng thử riêng. Những thay đổi như thêm auth, đổi database schema, nối API thật, hoặc thay UI framework đều đủ rủi ro để cần branch, vì nếu agent sửa sai, bạn bỏ branch hoặc revert branch mà main app vẫn còn.

Không cần branch cho mọi typo. Nhưng cần branch trước những prompt kiểu:

Refactor the app structure.
Replace local storage with database.
Add admin role and permissions.
Integrate Stripe checkout.

Nếu agent sửa sai trên branch, bạn bỏ branch hoặc revert branch. Main app vẫn còn.

Một prompt tốt trước task rủi ro:

Before editing, summarize the files you expect to change.
Keep this change isolated.
Do not modify unrelated flows.
Do not run destructive database actions.

Branch không cứu bạn khỏi review. Nhưng nó giới hạn thiệt hại.

Rollback khác fix forward

Khi app hỏng, có hai hướng: rollback hoặc fix forward.

Rollback là quay về trạng thái tốt trước đó. Fix forward là giữ thay đổi hiện tại và sửa lỗi ngay trên nó. Cả hai đều đúng trong tình huống khác nhau.

Rollback hợp lý khi thay đổi vừa rồi làm hỏng flow chính, bạn chưa hiểu root cause, có checkpoint rõ để về, và không có migration irreversible đã chạy. Tức là app cần chạy lại nhanh hơn là cần đúng ngay.

Fix forward hợp lý hơn khi lỗi nhỏ và bạn hiểu rõ nguyên nhân, hoặc rollback sẽ mất nhiều thay đổi tốt khác, hoặc database đã migrate và code cũ không compatible nữa.

Với vibe coding, người mới thường fix forward quá sớm. Agent sửa sai, rồi bạn lại prompt “fix it”, agent sửa thêm, lỗi mới xuất hiện, rồi prompt tiếp. Sau 5 vòng, diff thành đống rối. Nếu hai lần fix vẫn không ổn, hãy cân nhắc rollback về known-good state và chia lại task nhỏ hơn.

Prompt revert phải nói rõ giữ gì, bỏ gì

“Undo that” là prompt yếu. Agent có thể hiểu sai “that”. Nó có thể revert cả phần bạn muốn giữ, hoặc chỉ sửa bề mặt.

Prompt tốt hơn:

Revert only the changes related to CSV export.
Preserve the booking form validation and confirmation page.
Do not change database schema.
After reverting, list files changed.

Hoặc:

The admin dashboard broke the public booking flow.
Restore the public booking flow to the previous working behavior.
Keep the visual styling changes on the landing page.
Do not touch auth or database files.

Ba động từ cần nhớ:

  • Preserve X: giữ phần này.
  • Revert Y: bỏ phần này.
  • Keep Z unchanged: không chạm phần này.

Prompt revert tốt phải cụ thể theo file, flow, hoặc feature. Nếu không biết file, nói theo flow người dùng. Ví dụ “public booking form”, “admin list”, “CSV export”, “confirmation email”.

Đừng rollback mù

Rollback cũng là thay đổi. Sau rollback, phải test lại.

Checklist tối thiểu:

  • App build/run được.
  • Flow chính trước đó chạy lại.
  • Lỗi vừa thấy đã biến mất.
  • Không mất dữ liệu quan trọng.
  • Không còn diff lạ ngoài ý muốn.

Nếu rollback bằng platform checkpoint, mở app và click lại flow chính. Nếu rollback bằng Git, chạy test hoặc build nếu project có. Nếu rollback liên quan database, kiểm tra dữ liệu mẫu còn đọc được.

Một lỗi hay gặp: rollback UI nhưng database schema đã đổi. App cũ không chạy với database mới. Đây là lý do migration cần review riêng trước khi chạy.

Khi agent bị kẹt, quay lại prompt nhỏ hơn

Rollback không chỉ để chữa cháy. Nó còn là cách học rằng task vừa rồi quá rộng.

Ví dụ prompt ban đầu:

Make this booking app production-ready with admin dashboard, auth, email, and export.

Đây là một prompt quá lớn. Nếu hỏng, rất khó biết phần nào gây hỏng. Sau rollback, chia lại:

Slice 1: Add booking form validation only.
Do not change persistence, admin, auth, or styling.

Sau khi test:

Slice 2: Add confirmation screen after successful booking.
Keep existing validation unchanged.

Rồi:

Slice 3: Add read-only admin booking list.
No edit/delete actions.
No auth changes yet.

Mỗi slice có checkpoint. Mỗi checkpoint giảm áp lực cho lần sau.

Không dùng checkpoint để né trách nhiệm review

Một số người nghĩ có rollback rồi thì cứ để agent chạy. Sai. Rollback là dây an toàn. Nó không thay thế review.

Nếu prompt có thể xoá data, gửi email thật, gọi payment thật, hoặc deploy production, checkpoint không đủ. Bạn cần approval rõ, sandbox, test environment, và người hiểu hệ thống.

Đặc biệt cẩn thận với câu:

Clean up unused resources.

Với agent, “unused” có thể là file, table, bucket, branch, config. Nếu nó hiểu sai, rollback code chưa chắc cứu được resource đã bị xoá.

Vibe coding vui nhất khi bạn thử nhanh mà không sợ mất app. Muốn vậy, checkpoint phải có trước khi rủi ro xuất hiện, không phải sau khi đã hỏng. Khi hỏng, đừng lập tức prompt tiếp trong hoảng. Xem bạn đang có known-good state nào, quyết định rollback hay fix forward, rồi dùng prompt revert cụ thể: preserve X, revert Y, keep Z unchanged. Một app vibe-coded có thể chưa hoàn hảo, nhưng nó phải có đường quay lại. Không có rollback point thì mỗi prompt tiếp theo đều tăng rủi ro, kể cả những prompt trông vô hại.