How do you undo in vibe coding? Rollback, revert and version history

What it actually is

Rollback, revert, and version history are three names for the same basic move: getting your project back to a state that used to work. Think of Google Docs: it saves versions as you go, and “Version history” lets you open a list of past saves and restore an older one without losing the ability to jump forward again. Git, the version control system underneath most vibe coding tools, works the same way, just for code instead of paragraphs.

The words aren’t perfectly interchangeable, though. “Rollback” is the casual, general term for going back to an earlier state. “Revert” is more specific in git: git revert <commit> doesn’t erase history, it adds a new commit that undoes the changes from an old one, like crossing something out instead of tearing the page. “Version history” usually means the visual list of saved states, whether that’s git log in a terminal or the history panel in a tool like Lovable or Cursor.

Why your AI just did this

Every vibe coding tool snapshots your work in some way, so there’s a safe point to return to if the next change breaks things. Claude Code keeps checkpoints as it goes. Tap Esc twice, or run /rewind, to jump the code and conversation back to an earlier point, no git required. Cursor saves checkpoints in its agent history that you can click back to. Lovable snapshots your project after each generated change, with a history panel to see and restore earlier versions.

When something breaks (a blank screen, a 500 error, a feature that used to work now doesn’t), the agent’s first move is often to look at what changed, and its fix is sometimes “revert this file to the last working version” rather than trying to patch the new bug forward.

When you’ll run into it

• You ask your AI to add something, it breaks the app, and you say “undo that.” The agent runs git revert or points you to a “Restore checkpoint” button.
• Terminal output like fatal: not a git repository. A sign your project was never set up with version tracking, so there’s no history to roll back to.
• git log --oneline listing past commits with short messages like add login page or fix stripe webhook, so you can find the one before things broke.
• A “Revert to this version” link next to a timestamped entry in your tool’s history panel.
• Your agent saying something like “I’ve saved a checkpoint before this change” right before it starts editing.

What to check

• Confirm your project actually has version history turned on: a .git folder locally, or an active history panel in your tool. No history means no safety net.
• Before a risky change, make sure the current working state is actually saved (committed or checkpointed). Uncommitted changes can be lost in a rollback.
• Know whether your revert creates a new commit (safe, keeps the full story) or rewrites history (like a hard reset). The second kind can permanently delete work if you pick the wrong point.
• After rolling back code, check .env files, API keys, and database changes separately. Code reverts, but environment variables and database migrations often don’t. And if the rollback removes a commit where a secret was exposed, that’s not fixed: the key is still in your git history, so rotate it instead of relying on revert to hide it.
• If your tool’s history is tied to a live deployment, confirm whether restoring an old version in the editor also restores what’s live for users, or just the code you’re looking at.

Say it like a dev

Instead of: “undo that last thing” Say: “revert the last commit”

Instead of: “just put it back to how it was before” Say: “roll back to the commit before we added the login page”

Instead of: “it’s broken now, just fix the undo button” Say: “check git log, find the last working commit, and revert to it”