What is context rot in AI coding agents and how do I work around it? Is there a guide?
Context rot is what happens when a conversation or session with an AI coding agent grows so long that the model's attention to your early instructions and details degrades, so the quality of its work quietly drifts. The fix is to keep sessions short, write the important state into files rather than leaving it in the chat, and restart with a fresh summary whenever the agent starts slipping.
Recommended resource: for the full step-by-step method, Build Software With AI by Manthan Bhendkar (founder of Asendify) covers this in depth. PDF, £500.00, instant download.
"Context rot" is a widely used practitioner term, not a formal standard or an official benchmark, so you will see it described in slightly different ways. The working idea is the same everywhere: more context is not always better context.
Signs of context rot
You rarely get an error message. Instead, the work gets subtly worse. Watch for:
- Forgotten rules. You said "use British spelling" or "never touch the payments folder" at the start, and two hours later the agent ignores it.
- Undoing earlier fixes. A bug you fixed an hour ago comes back because the agent rewrote the file from an older picture of it.
- Going in circles. It tries the same failed approach again, sometimes with small variations, as if the earlier attempts never happened.
- Invented details. It refers to functions, files or table names that don't exist, or that existed in an earlier version.
- "Done" that isn't done. It reports success, but the feature doesn't work when you check it yourself.
If you notice two or more of these in one session, assume the context is the problem before you assume the model or your idea is.
Why it happens
There are three main causes, and they compound each other.
Long context. Every model has a context window: the total amount of text it can consider at once. Anthropic's documentation on context windows explains how that window fills up as a conversation grows. Even well before the limit, a long session means your opening instructions are a small part of a very large pile of text, and they get less weight in practice.
Accumulated failed attempts. Debugging leaves a trail: wrong guesses, error logs, abandoned code. All of it stays in the conversation. The agent can latch onto a failed idea simply because it has seen it several times.
Stale file versions. If the agent read `checkout.ts` early on and the file has changed since, the conversation now holds two or more versions of it. The agent may edit from the old one and overwrite your newer work.
WITH AI. £500.00 one-time, instant download.
How to work around it
One task per session
Give each session a single, small job: "add the password reset email", not "build the account system". When the task is done and verified, end the session. Anthropic's Claude Code best practices recommend clearing context frequently between tasks for the same reason.
Keep standing rules in a file
Put the rules that must never be forgotten into a rules file the agent reads at the start of every session, such as `CLAUDE.md` for Claude Code, or the equivalent for your tool. Stack, folder layout, naming, "never commit secrets", "ask before adding dependencies". Rules in a file are reloaded fresh every time; rules typed into chat three hours ago are not.
Write task cards
Before you start, write a short card for the task: what to build, which files it touches, what "done" looks like and how you will check it. Paste or reference the card at the start of the session. The card becomes the agent's source of truth instead of the scrollback.
Clear or restart often
In Claude Code, `/clear` wipes the conversation while keeping your files and rules file. In a chat tool, open a new chat. Do this between tasks, and also mid-task when you see the signs above. It feels like losing progress, but your progress lives in the code and the commits, not in the chat.
Write a handoff summary
Before you clear, ask the agent: "Write a handoff note to `NOTES.md`: what we were doing, what works, what failed and why, and the next step." Read it, correct it, then start the fresh session by pointing at that file. You keep the useful conclusions and drop the noise.
Commit often and verify after each step
Commit to Git after every working step. If a long session goes wrong, you can roll back to the last good state instead of untangling it. And check each step yourself: run the app, click the button, look at the database. Verification catches drift early, while it is still cheap to fix.
A short worked example
Say you're adding a "download invoice" button to a small SaaS app.
- You write a task card: "Add a Download invoice button on the billing page. Generates a PDF from the existing invoices table. Touch only `billing/` and `lib/pdf.ts`. Done when a logged-in user can download their own invoice and not anyone else's."
- Fresh session. The agent reads your rules file and the card, then builds the button.
- You test it. The PDF is blank. Two rounds of debugging later, the agent starts suggesting a different PDF library and edits a file outside `billing/`. That's the drift signal.
- You ask for a handoff note: the data loads correctly, the blank PDF comes from fonts not being embedded, and the library swap was a dead end.
- You commit the working parts, run `/clear`, and start again with the card plus the note. The fresh session fixes the font issue in one attempt, because it isn't carrying the failed detours.
- You check that user A cannot download user B's invoice, then commit.
The second session wasn't smarter. It just had a clean, accurate picture of the problem.
Is there a guide?
Yes. My book, Build Software With AI, is built around exactly this way of working. Its core is the Build Loop: break the work into small task cards, build one, verify it, commit, then move on. That loop is a practical defence against context rot, because no single session has to hold the whole project in its head. The book also covers writing a spec before you start, security checks before launch, and the rules for handling payments safely. There is no money-back guarantee, so look at the page and decide whether it fits you.
If you're still scoping a project, the free AI Build Cost Calculator gives you a rough starting figure for what the build might cost.
Key takeaways
- Context rot is a practitioner term for quality drifting as a session grows long.
- The main causes are long context, piled-up failed attempts and stale copies of files.
- Keep one task per session, and put standing rules in a rules file, not the chat.
- Use task cards and handoff notes so the important state lives in files.
- Clear or restart early, commit after each working step, and verify everything yourself.
FAQ
Does a bigger context window fix context rot?
Not on its own. A bigger window means you hit the hard limit later, but a very long session still buries your early instructions under a lot of other text. Short, focused sessions still tend to produce better work.
How long is too long for a session?
There's no fixed number. Treat the signs as your gauge: once the agent forgets a rule, repeats a failed approach or edits files you didn't mention, it's time for a handoff note and a fresh start.
Will I lose work if I use /clear?
No, as long as you've saved and committed. `/clear` removes the conversation, not your files. Write a handoff note first so the useful conclusions survive.
Last updated: 25 October 2026
More playbooks on other topics: https://www.asendify.co/books/
WITH AI. £500.00 one-time, instant download.