TL;DR: After 30 or 40 turns, AI coding agents start forgetting decisions and undoing their own fixes. A short checkpoint prompt makes the model restate the goal, its changes, and what must not be undone, before it touches another file.
The problem: drift
If you’ve run a long agent session, you know the pattern. Early on the model is sharp. It reads the right files, follows your conventions, and makes small, clean edits. Then somewhere past turn 30 it contradicts a choice you made together, or quietly reverts a bug fix from an hour ago. Nothing dramatic happens. The session just slowly goes sideways.
Here’s a typical example. You agree early on that dates will be stored in UTC and converted only at the display layer. Forty turns later the agent adds a helper that converts to local time inside the database query, because that decision has scrolled far enough back that it no longer carries weight. The code looks reasonable on its own. It just breaks the rule you set, and you may not notice until a test fails two files away.
A Redditor on r/PromptEngineering shared a simple habit that helps: pause every so often and paste a checkpoint prompt. It’s small, and it works because it forces the model to show its state before it acts. Instead of trusting that the agent still remembers everything, you make it prove it.
How the checkpoint works
The prompt asks for four things and one restriction:
- The goal in 3 bullets. This is your drift detector. If the summary is wrong, the context has wandered and a fresh chat is the better move. Pay attention to what’s missing as well as what’s wrong. If a constraint you care about, like “don’t touch the public API,” never shows up, the model may have dropped it.
- Every changed file, one line each. You get a quick audit of what the agent actually did, not what it thinks it did. Compare the list against your git diff. A file you don’t recognize is worth a look before you go any further.
- Decisions the next step must not undo. This is the guard against the classic loop where the agent reintroduces a bug it already fixed. Writing the decisions out again also pushes them back to the front of the context, where the model weighs them more heavily.
- One next step, plus how it will be verified. One step with a check beats five changes at once. A good answer names something concrete, like a test to run or a command to execute, not just “make sure it works.”
- No file edits in this reply. The model has to think and report instead of coding its way out.
Why it earns its place
The best part is what happens when the checkpoint fails. A wrong goal summary tells you to start over, and you can paste the checkpoint in as the first message of the new chat. You carry the useful state forward and leave the clutter behind. Failed attempts, abandoned approaches, and long error logs all stay in the old session, so the new one starts clean.
It also costs almost nothing. The whole exchange takes under a minute, and it often saves you from reading a long diff to work out what went wrong. Compare that with the alternative, where you spend an hour untangling changes the agent made while working from a half-remembered plan.
The author also has a handy trigger: run it the second time the agent says “let me try a different approach.” That phrase is often the first sign the model has lost the thread. Once is normal, since good debugging involves changing course. Twice in a short stretch usually means the agent is guessing. If you’d rather work on a schedule, every 15 to 20 turns, or right before any big refactor step, also works well.
One commenter pointed out what this really is: a hand-run memory system. You’re doing manually, per session, what a lot of tools are now trying to automate. I think that’s a fair way to see it. Until your tools handle it for you, a pasted checkpoint is a cheap stand-in.
Use cases 🧭
- Multi-hour coding sessions in Claude Code, Cursor, or Codex
- Refactors that touch many files, where one undone fix breaks something else
- Handing work from one chat to a fresh one without losing decisions
- Reviewing what an agent changed before you commit
- Coming back to a session after lunch or overnight, when you’ve forgotten the details yourself
Prompt of the Day
Stop. Before writing any more code, give me a checkpoint:
- In 3 bullets, what is the goal of this session?
- List every file you’ve changed so far and why, one line each.
- List any decision we agreed on that the next step must NOT undo.
- What is the single next step, and what will you check to know it worked?
Don’t change any files in this reply.
Tweak it for your own workflow. If you keep a notes file for the project, add a fifth line asking the model to flag anything that conflicts with it. You can also save the prompt as a snippet or a custom slash command, so you can fire it off in a few keystrokes instead of retyping it. The easier it is to run, the more often you’ll actually use it.
Your move
Next time an agent says “let me try a different approach” for the second time, paste this before you reply. Then tell me what the goal summary looked like. If it was wrong, you just saved yourself an hour.
Frequently Asked Questions
Q: Can the checkpoint itself drift without me noticing?
Yes. A wrong goal summary is easy to catch, but a smooth, plausible checkpoint can quietly confirm a drifted version, and pasting it into a fresh chat locks that error in. Keep a decision log that you append to at the moment each decision is made, then compare each checkpoint against it. Any gap between the two is your drift signal.
Q: Where should the don’t-undo list live?
Keep it in a standing file that the agent can append to but not edit. A list rewritten at every checkpoint can drop a constraint while still looking complete, and nothing warns you. Checkpoints should read the file, not regenerate it.
Q: Is it worth adding a question about failed attempts?
Yes, it makes a useful fifth item: What did you try that failed, and what did it rule out? Failed approaches are the first thing a long session forgets and the first thing it retries. A short list of dead ends stops the third and fourth attempts at the same wall.
Q: How do I make the check in step 4 actually useful?
Pick a check you can run yourself, like a test result, a diff, or a number, instead of the agent’s own sense that it worked. Then the question becomes what you can verify, not what the agent says it will check. That keeps each next step tied to something outside the agent’s story.
A “checkpoint” prompt I drop into long AI coding sessions before things go sideways
by u/SiranqHQ in PromptEngineering