Catastrophic Remembering: Why Your CLAUDE.md Keeps Growing

Your CLAUDE.md, AGENTS.md, or copilot-instructions.md grows without bound. Instructions get added and almost never removed, until the file is a museum of stale rules that the model has to wade through. A new paper by Kushal Chakrabarti calls this catastrophic remembering — the inverse of catastrophic forgetting — and shows it's not an accident of developer habits. It's a structural consequence of how agentic prompts are maintained. And there's a fix: comments.

The Phenomenon

Researchers analyzed 247,694 instruction lifetimes across 1,867 repositories (1,801 multi-version files, 299,440 tracked version-to-version transitions) and found agentic prompts grow relentlessly:

• Prompt files more than triple over their lifetime (+226%); total size grows +140% too, so it's not just text migrating between instruction and payload classes
• They gain +4.9 net instructions per commit across 19,267 commits
• The older an instruction gets, the less likely it is to be deleted (log-hazard −0.032 per commit)
• The median file already carries 39 instructions; the 90th percentile sits at 131 — well past the range where instruction-following measurably degrades
• 64.3% of multi-version repositories grow their instruction count against only 26.6% that shrink it, with a median net gain of +7 instructions

This is the sawtooth pattern you've probably seen in your own repos: the file grows until someone rewrites it wholesale, then it grows again. The paper even quantifies the sawtooth: a mass rewrite drops the count to 59.5% of its pre-rewrite value, but it recovers to 91.5% within ten commits — and growth after a rewrite is faster (+4.9% instructions per commit vs +4.3% before).

Why It Happens: Imperfect Recall

The paper traces the root cause to the cost asymmetry of recall. When you add an instruction, you don't need to remember why — the reason is fresh. When you want to delete one safely, you have to reconstruct why it was added in the first place, and whether removing it risks a regression. With D instructions in a prompt, doing that safely costs O(2^|D|) — infeasible, because two instructions can each look free alone while both are needed together. Appending is always cheap; deleting is always expensive. So instructions accrete.

Two observations confirm the mechanism is imperfect recall, not instruction staleness or content fragility:

• The deletion hazard decays with age at −0.032 per commit — the opposite of what staleness would predict. Old instructions are the ones whose reasons have evaporated, and they're the least likely to be touched.
• More authors make it worse. Successive edits by multiple authors destroy the "why" behind each rule faster — the multi-author interaction term is significant (β −0.021) — because every undocumented handoff erases more surviving rationale.

Why It Hurts

Keeping everything isn't free. The median file carries 39 instructions, and instruction-following degrades as constraints accumulate — irrelevant context distracts the model. Files that are smaller let agents finish tasks faster and in fewer tokens. The cost is double: you're paying token and latency overhead on every run, and you're degrading the reliability of the rules that actually matter.

The Fix: Prompt Comments

The paper's headline result: comments encoding an instruction's latent reasoning halt the growth. Across 552 maintenance histories, maintainers who recorded why each instruction existed kept prompts at −5.8% excess size versus +60.4% for those who didn't — a 66-point swing at parity constraint satisfaction. In a longer-horizon simulation, comments removed 99.3% of excess instructions (+211.3% → +1.4% over 51 steps).

Because a smaller, cleaner prompt distracts the model less, real-world instruction-following improved by up to 23.1%.

The winning comment format isn't a description — it's the outcome-grounded latent reasoning: the failure behind the instruction, the hypothesis it encodes, and how that hypothesis has fared.

## Rule: Never auto-format on save
# Why: Introduced after formatter reformatted the whole codebase mid-agent-run
# and broke three tests that depended on line numbers. Hypothesis: diff noise
# confused the patch application. Still standing as of 2026-08.

Two ablations sharpen the finding:

• Comment-shaped noise is worthless. Comments with no reasoning landed within 2.7 points of no comments at all — the content drives the gain, not the annotation itself.
• An unvalidated premise is worse than no comment. A narrative of attempts without outcomes (+70.0%) was the worst arm of the entire study — worse than no comments. Handing the next maintainer a guess dressed as history is actively harmful.

One more thing worth internalizing: the comments are for the maintainer, not the model. They're stripped before the prompt reaches the model, so they cost nothing at inference time. Their entire job is to let a future you — or a future agent — decide whether a rule can safely go.

The Three-Part Comment

The paper's winning format is outcome-grounded, and it maps to three fields:

## Rule: <the instruction itself>
# Why: <the failure that motivated it>
# Hypothesis: <the causal belief the rule encodes>
# Status: <whether the hypothesis has held or failed since>

The Status field is the part almost everyone skips — and the paper shows it's the load-bearing one. A narrative of attempts without outcomes was the worst arm of the entire study (+70.0% size, worse than no comments at all). A rule whose hypothesis has since failed is exactly the instruction a maintenance audit should flag for removal — but only if the hypothesis was ever recorded in the first place.

Audit Your Prompt File

The delete mindset doesn't require waiting for a rewrite cycle. A fifteen-minute audit catches most of the damage:

1. Read your prompt file as a stranger. For each rule, ask: does it still serve the repository's current state? Rules written for a deleted module are safe removals.
2. Tag every rule. No comment → either recover the reasoning and add it, or treat the rule as a candidate for deletion. The cost asymmetry says you'll only ever delete the rules whose history you can reconstruct.
3. Check for contradiction. Two rules that conflict with each other is a symptom of unreconstructed history — each one was added for a reason, and the reasons now fight.
4. Treat agents as maintainers too. Instruction files also grow from agent feedback loops — an agent that "learns" it needs a rule after a failure appends one without recording the reasoning. The same comment discipline applies whether the editor is human or not.

What to Do Today

1. Comment every rule you add. One line for the failure that caused it, one for the hypothesis, and how it's fared since. Cost: near zero. It's the O(1) investment that prevents the O(2^|D|) problem.
2. Review your prompt file with a delete mindset. If a rule has no comment and no one remembers why it exists, that's exactly the risky-deletion case the paper describes — either recover the reasoning and comment it, or remove the rule.
3. Treat the sawtooth as a symptom. If you're rewriting your prompt file wholesale every few months, that's the ratchet catching up with you. The comment discipline stops the growth at the source instead of resetting it.
4. Keep files small. Repositories carrying a lean CLAUDE.md/AGENTS.md finish agent tasks faster and in fewer tokens. Irrelevant context isn't inert — it measurably degrades instruction-following.

Catastrophic remembering is the maintenance cost of agentic prompts that no one is tracking. The fix is cheap, verifiable, and — as this paper shows — measurable. Your prompt file is code; start treating the comments like the code comments you'd never ship without. This also pairs directly with the Harness-IF findings: rules that don't change behavior are just tokens, and tokens that carry no recorded reasoning are the ones nobody will ever dare remove.

Related: the Research Agent blueprint shows a deliberately lean agent context design.