You’ve probably felt it without having a name for it.
You start a Claude Code session fresh. The first few responses are sharp, focused, exactly what you asked for. Then an hour in, things start to drift. The code gets sloppier. Claude starts hedging more. It makes decisions you didn’t ask for. It “summarises” instead of doing. By the time you’re deep into a complex feature, it feels like you’re working with a different, more tired version of the same model.
You’re not imagining it. There’s a name for what’s happening.
It’s called ” Context Rot” — and honestly, I think it’s one of the most under-discussed problems in AI-assisted development right now.
What context rot actually is
Claude, like all large language models, doesn’t have persistent memory. What it has is a context window — a fixed amount of space that holds everything it can “see” at any given moment: your instructions, the conversation history, the code it wrote, the errors it encountered, your follow-up questions, its own previous responses.
When that window is empty, Claude is at its best. Full attention, full token budget, clear instructions.
As the session goes on, the context window fills up. Your conversation history grows. Earlier code and decisions accumulate. There’s less room for fresh, high-quality reasoning. Claude starts working around its own previous output instead of reasoning cleanly from scratch.
No degradation, no ‘ I’ll be more concise now.’” — GSD README
That phrase — “I’ll be more concise now” — if you’ve ever seen Claude say it mid-session, you’ve witnessed context rot in real time. The model is essentially telling you it’s running out of clean thinking space.
The result is inconsistent output, poorer reasoning, more hallucinations, and code that requires more manual review the longer a session runs. This is why so many developers have learned to start fresh sessions for each new task. It works, but it’s a workaround, not a solution.
Why this is a production-level problem
For simple tasks — write a function, fix a bug, generate a test — context rot is annoying but manageable. You restart, you move on.
For anything real — building a feature across multiple files, refactoring a legacy module, implementing a multi-step flow — context rot is a serious quality problem.
Think about what a typical complex task actually involves:
- Reading and understanding existing code across multiple files
- Holding architectural decisions made earlier in the session
- Tracking what’s been done vs. what still needs doing
- Maintaining consistency across functions, types, and API contracts
- Reasoning about dependencies and side effects
Every single one of those things gets harder as the context window fills. The model is doing more with less clean thinking space. And the longer the task, the worse the compounding effect.
This is the gap between impressive demos and reliable production systems. Demos are short sessions. Production is long, complex, and accumulative.
I explored this same idea in more detail in an earlier newsletter:
Enter GSD: Get Shit Done
GSD is an open-source meta-prompting, context engineering, and spec-driven development system built to solve exactly this problem. It was created by TÂCHES, a solo developer who, by his own description, doesn’t write code — Claude Code does.
The core philosophy is simple and honest:
The complexity is in the system, not in your workflow. Behind the scenes: context engineering, XML prompt formatting, subagent orchestration, state management. What you see: a few commands that just work.
You install it in one command:
npx get-shit-done-cc@latest
It works with Claude Code, OpenCode, Gemini CLI, Codex, Copilot, and Antigravity. One install, your choice of runtime.
At the time of writing, GSD has over 33,000 GitHub stars and nearly 3,000 forks. Those are not tutorial numbers. That is usually a sign that a repo has moved beyond curiosity and into real use.
How GSD actually solves context rot
GSD’s approach to context rot is architectural. Rather than trying to manage one long session better, it breaks development into structured phases and executes each plan in a completely fresh context window.
The workflow has five stages. Each one matters for a different reason:
1. Initialize (/gsd:new-project)
One command kicks off a structured questionnaire. GSD asks until it fully understands your idea — goals, constraints, tech preferences, edge cases. It then spawns parallel research agents to investigate the domain, extracts requirements scoped to v1 vs v2, and creates a phased roadmap. You approve it. Now the system knows what it’s building.
This creates: PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md. These files become the persistent memory that replaces relying on context window history.
2. Discuss (/gsd:discuss-phase)
Before any planning or coding, GSD captures your implementation preferences for each phase. Layout choices, API response formats, error handling, edge case decisions — whatever is relevant to what’s being built. The output is a CONTEXT.md file that feeds directly into the next two steps.
This is where you shape the implementation before it starts, rather than correcting it afterwards.
3. Plan (/gsd:plan-phase)
The system researches how to implement the phase, guided by your CONTEXT.md decisions. It then creates 2-3 atomic task plans using a structured XML format. Each plan is small enough to execute in a fresh context window. A plan-checker agent verifies each plan against your requirements before any code gets written.
4. Execute (/gsd:execute-phase)
This is where the context engineering magic happens. GSD groups plans into “waves” based on dependencies. Independent plans run in parallel. Dependent plans wait for their prerequisites. Each plan gets its own fresh 200,000-token context window — completely clean, no accumulated history.
The result: every piece of implementation gets Claude’s full attention. Context rot cannot accumulate because each subagent starts fresh. Your main session stays at 30-40% context usage while the actual work happens in clean subagent contexts.
Every task gets its own atomic git commit. Clean history. Easy bisecting. Clear traceability.
5. Verify (/gsd:verify-work)
Automated verification plus a human walkthrough. GSD presents each testable deliverable one at a time — “can you log in with email?” — and you confirm it works. If something’s broken, debug agents diagnose the root cause and write fix plans. You don’t manually debug. You just re-run.
The engineering insight worth understanding
Most people treat AI coding tools as smart autocomplete. You write, it suggests. You prompt, it responds. The context window is just “the conversation so far.”
GSD treats the context window as a constrained resource that must be engineered deliberately. Every file that gets loaded, every decision that gets documented, every plan that gets structured — these are choices about what to give Claude vs. what to let it derive. The quality of the output is a direct function of the quality of the context you provide.
That’s what “context engineering” actually means. Not longer prompts. Not more detailed instructions. Deliberate, structured management of what’s in the context window at every stage of the work.
The GSD README puts it plainly: “Claude Code is incredibly powerful if you give it the context it needs. Most people don’t. GSD handles it for you.
Who this is actually for
GSD is honest about its audience: people who want to describe what they want and have it built correctly — without pretending they’re running a 50-person engineering org.
Best fit for:
- A solo developer who relies on Claude Code for most implementation work and wants consistent output across long, complex builds.
- A small team where everyone needs to be able to pick up where someone left off without losing context.
- Building anything multi-phase — where requirements need to persist across multiple sessions and the risk of context drift is real.
- Frustrated with vibe coding — where you get something impressive in the first session and something inconsistent in the fifth.
It is probably overkill for simple, short tasks. GSD has a /gsd:quick command for those — same guarantees, faster path, no full planning cycle.
How to get started in under 5 minutes
Install it:
npx get-shit-done-cc@latest
The installer asks you two things: which runtime (Claude Code, Gemini, Copilot, Antigravity, etc.) and whether to install globally or for the current project. That’s it.
Verify it worked:
/gsd:help
Then, for a new project:
/gsd:new-project
For an existing codebase, run /gsd:map-codebase first. It spawns parallel agents to analyse your stack, architecture, and conventions — so the planning step already understands what you’re working with.
The full docs and user guide are at: https://github.com/gsd-build/get-shit-done
The takeaway
Context rot is not a Claude problem. It’s a systems problem. The model is working exactly as designed — it’s just that long sessions with accumulated history are not a good fit for how transformers actually process context.
GSD is one of the first tools I’ve come across that treats this as an engineering challenge to be solved architecturally rather than a limitation to be worked around manually. Fresh subagent contexts per plan, structured persistent files as memory, XML-formatted instructions for precision — these are real engineering decisions, not clever prompting tricks.
Whether you adopt GSD wholesale or just take its core ideas and apply them to your own workflow, the underlying principle is worth carrying: if you want consistent AI output on complex work, engineer the context deliberately. Don’t just let it accumulate.
Have you tried GSD, or do you have your own approach to managing context rot? I’d genuinely like to know what’s working for you — drop a comment.
