DEV Community

Cover image for I Built Checkpoints for AI Agents So You Don't Ruin Your Repo
Arga Fairuz
Arga Fairuz

Posted on

I Built Checkpoints for AI Agents So You Don't Ruin Your Repo

There's a specific moment every vibe coder eventually has.

You give the agent a broad instruction, something like "refactor the data layer to use the new API client," and it goes further than you expected.

It touches twelve files. Some of the changes are exactly what you wanted. A few are questionable. And at least one file that had nothing to do with the task got modified in a way you don't fully understand yet.

Your first instinct is git. You open the diff. It's a wall of changes across files you weren't watching closely, mixed in with good parts from three prompts ago you don't want to lose.

Reverting the whole commit throws out work you actually want. Cherry-picking individual hunks by hand is slow and error-prone.

You're doing surgery on your own repo at 11pm hoping you don't make it worse.

This is the actual risk of giving an AI agent real autonomy: it's fast, and fast things break fast. The tool that makes you 10x more productive is also the tool most capable of quietly wrecking a working codebase in a single aggressive prompt.

Why plain git isn't built for this

Git is designed around commits you choose to make, at moments you choose.

An AI agent doesn't work in commit-sized units, it works in conversational turns, and a single chat message might span dozens of file edits, several of which you'd want to keep and several you wouldn't.

Bolting your safety net onto the same history you use for actual project commits also means every experimental AI detour risks polluting your real git log.

Worse, it tempts you into skipping careful commits altogether because "the AI will just fix it in the next message."

You need a rollback mechanism built around how agents actually operate, not around how humans commit.

The checkpoint model Clopen runs on

Clopen automatically saves a checkpoint after every chat turn in a session, without you doing anything to trigger it.

Every message that results in file changes gets its own snapshot: full project state, not a diff you have to interpret.

When something breaks, you don't dig through a diff trying to reconstruct what things looked like before.

You open the checkpoint list, find the point right before things went sideways, and restore. Every file goes back to exactly that state, in seconds.

Crucially, this checkpoint history is completely separate from your actual .git history. Your real commit log stays exactly as clean as you left it, because Clopen's checkpoints live in their own tracked layer, isolated from the repository you'll eventually push.

It's not just undo. It's branching

Here's the part that goes beyond a simple rollback button.

Clopen restore checkpoint interface

Say you're at Checkpoint B, and the next attempt (call it C) breaks something. You restore to B and try a different approach instead, call it B2.

Clopen doesn't discard the C path when you do this, it creates a new branch from B. You now have two histories: A → B → C (broken) and A → B → B2 (working).

If you're curious enough to go fix the original approach instead of abandoning it, you can switch back to the C branch and keep going from there.

Nothing is ever silently deleted just because you tried something else. Every path stays intact and restorable.

Comparing two different implementations of the same feature becomes a matter of switching branches, not maintaining two separate working directories or stashing constantly.

Why this changes how aggressively you prompt

Once restoring to any previous point is a guaranteed, precise, few-second operation, your behavior with the agent changes.

You stop giving small, defensive instructions designed to limit blast radius. You stop reviewing every single file change before letting the agent continue to the next step.

You start handing it the big, ambiguous refactor, because the worst case scenario is a checkpoint restore away, not a manual git archaeology session.

That shift, being willing to let the agent run further before checking in, is where a meaningful chunk of the speed advantage in AI coding actually comes from. Caution has a cost, and checkpoints are what let you stop paying it constantly.

Chat panel

Nothing to configure, nothing to remember

Checkpoints in Clopen aren't an opt-in feature you have to enable and maintain.

They happen automatically as part of every session, which means the safety net is there from your very first prompt, not something you set up after the first time an agent breaks something.

Give the agent the harder task

bun add -g @myrialabs/clopen
Enter fullscreen mode Exit fullscreen mode

Install it, open a real project, and let the agent attempt something bigger than you normally would. If it goes wrong, restore and try again.

Workspace clopen

Check out the GitHub repository and the landing page to see the checkpoint model in more detail.

Top comments (0)