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, không phải nút cứu hộ cuối cùng

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 nghĩa là:

  • App mở được.
  • Flow chính chạy được.
  • Không có lỗi rõ trong console/log.
  • Bạn biết thay đổi gần nhất là gì.
  • Bạn có thể quay lại trạng thái đó.

Đừ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. Bạn dùng branch khi thay đổi có thể làm hỏng flow chính:

  • Thêm auth.
  • Đổi database schema.
  • Thêm payment.
  • Đổi routing.
  • Refactor folder structure.
  • Thay UI framework.
  • Nối API thật.
  • Thêm upload.

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/commit rõ.
  • Không có migration irreversible.
  • App cần chạy lại nhanh.

Fix forward hợp lý khi:

  • Lỗi rất nhỏ và hiểu rõ.
  • Rollback sẽ mất nhiều thay đổi tốt khác.
  • Database đã migrate và code cũ không compatible.
  • Hotfix nhỏ hơn rollback.

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, không phải lý do lái xe nhắm mắt.

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á.

Chốt lại

Vibe coding vui nhất khi bạn thử nhanh mà không sợ mất app. Muốn vậy, phải có checkpoint trước khi rủi ro xuất hiện, không phải sau khi đã hỏng.

Hãy giữ nhịp:

Build small slice.
Test main flow.
Create checkpoint or commit.
Then ask next prompt.

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. 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 là một canh bạc.