Papers
Topics
Authors
Recent
Search
2000 character limit reached

Why Does CLAUDE.md Keep Growing? Catastrophic Remembering in Agentic Coding

Published 11 Aug 2026 in cs.AI, cs.LG, and cs.SE | (2608.11095v1)

Abstract: Agentic coding READMEs like CLAUDE.md grow without bound in real repositories, stopping only when the repository retires or someone rewrites the file wholesale. We trace this to imperfect recall: appending an instruction is always cheap, but once an instruction's rationale is gone, deleting it without risking a correctness regression costs O(2|D|) in a prompt of |D| instructions. We name the resulting divergence catastrophic remembering, the inverse of catastrophic forgetting around which continual learning is organized. First, we characterize this phenomenon across 247,694 instruction lifetimes in 1,867 repositories: agentic prompts grow without bound, more than tripling over their lifetime (+226%), gaining +4.9 net instructions every commit; further, the older an instruction gets, the less likely it is to be deleted (log-hazard -0.032/commit). Then, we show that prompt comments can halt the growth: inverting IFEval yields verifiable worlds whose optimal prompts are known, and there comments encoding latent reasoning remove 99.3% of excess instructions (+211.3% to +1.4%). Finally, applying the same inversion to WildIFEval, we show that prompt comments can improve real-world agentic instruction-following by up to 23.1%. If English is the new code, why don't we have comments yet?

Authors (1)

Summary

  • The paper introduces catastrophic remembering, a theory and empirical account of agentic coding prompts accumulating instructions because maintainers lose access to the rationale needed for safe deletion.
  • Repository analysis of 1,801 context files found a median terminal size of 39 instructions, a mean growth of 226% over file lifetimes, and declining deletion hazard, especially in multi-author projects.
  • Controlled experiments show that outcome-grounded, executor-invisible comments reduced excess instructions by 99.3% and improved instruction following by up to 23.1% amid distracting context, though automated deletion still requires safeguards.

Catastrophic Remembering in Agentic Coding

Thesis and conceptual contribution

“Why Does CLAUDE.md Keep Growing? Catastrophic Remembering in Agentic Coding” (2608.11095) examines the persistent growth of agentic coding context files, including CLAUDE.md, AGENTS.md, and copilot-instructions.md. Its central claim is that this growth is not primarily caused by changing requirements, poor instruction quality, or simple maintainer preference. Instead, it results from the decay of the latent rationale behind individual instructions. Instructions remain visible after the reasons for introducing them have become unrecoverable. Addition therefore remains comparatively inexpensive, whereas safe deletion requires reconstructing counterfactual evidence about what would fail if an instruction were removed.

The paper names this dynamic catastrophic remembering, presenting it as an analogue—and inverse—of catastrophic forgetting in continual learning. In catastrophic forgetting, a learner overwrites information that should have been retained. In catastrophic remembering, maintainers retain instructions that should have been removed because the evidence authorizing deletion has disappeared. The resulting prompt becomes append-only in practice, even when the underlying task distribution is stationary.

The paper combines a theoretical model of prompt maintenance, a large-scale longitudinal analysis of public repositories, and controlled experiments based on inverted instruction-following benchmarks. Its strongest claim is causal: preserving latent reasoning in comments can arrest prompt growth while maintaining correctness, and can recover instruction-following performance lost to irrelevant context.

A model of prompt maintenance under censored feedback

The theoretical framework treats prompt maintenance as online estimation of an unobservable constraint set from noisy and censored feedback. A task has an objective and a hidden collection of constraints, while the maintained prompt contains a set of instructions intended to cover those constraints. The executor receives the instructions but not the comments or rationale. The maintainer observes only partial feedback: failures may indicate a violated dimension, but they do not identify the responsible instruction, the relevant parameter, or whether a passing instruction was necessary.

This formulation establishes five properties of the maintenance environment:

  • Instructability: some instructions improve satisfaction of hidden constraints.
  • Interference: adding an instruction can reduce performance on other constraints.
  • Redundancy: multiple instructions can cover the same constraint.
  • Censoring: feedback does not identify which instruction caused an outcome.
  • Stochasticity: even a correctly covered constraint may fail intermittently.

Under these assumptions, determining whether an instruction is excess requires evaluating counterfactual prompt subsets. Redundancy makes one-at-a-time deletion tests insufficient: two instructions may each appear dispensable individually while being jointly necessary. An exhaustive audit can therefore require O(2D)O(2^{|D|}) subset probes for a prompt containing D|D| instructions. By contrast, recording the rationale at write time costs approximately O(1)O(1) and can substantially reduce the cost of future maintenance.

The model introduces a recoverability function, ρ(d,a)\rho(d,a), representing the probability that the rationale for instruction dd remains available after age aa. As rationale recoverability declines, deletion hazard declines as well. If additions continue at a roughly stable rate while the aggregate deletion hazard approaches zero, the equilibrium prompt size diverges. This result does not require task drift: a stationary constraint set is sufficient for unbounded prompt growth if rationale decays independently of the instruction itself.

The proposed mechanism also yields a prediction that distinguishes imperfect recall from competing explanations. If instructions become stale, their deletion hazard should increase with age. If fragile instructions die young, population-level hazard may decline, but the decline should not depend systematically on the number of maintainers. Imperfect recall predicts both an age-related decline and a stronger decline in files edited by multiple authors.

Repository-scale evidence for the ratchet

The empirical analysis reconstructs instruction histories across 1,867 public GitHub repositories and 1,801 multi-version context files. The corpus contains 299,440 version transitions, 247,694 instruction lifetimes, and 28,426 tracked deletions after censoring wholesale rewrites and cross-file migrations.

The growth pattern is substantial. The median terminal file contains 39 instructions, while the 90th percentile contains 131. Across multi-version repositories, 64.3% increase their instruction count compared with 26.6% that decrease it. Excluding wholesale rewrites, the mean net change is +4.9 instructions per commit. Over normalized file lifetimes, the mean instruction count increases by +226%, while mean instruction length increases by only approximately +10%. The accompanying payload also grows, indicating that the result is not primarily an artifact of reclassifying existing prose as instructions.

The paper therefore identifies a ratchet rather than merely a positive trend: additions accumulate during ordinary maintenance, a wholesale rewrite occasionally reduces the file, and growth then resumes. This pattern is especially important because it shows that rewriting is not a durable maintenance solution.

Figure 1

Figure 1: Wholesale rewrites account for most instruction deaths, but prompt growth resumes rapidly after the rewrite.

A mass rewrite removes at least half of a file’s instructions. Such rewrites account for 76.8% of instruction deaths in the headline analysis, or 77.3% when the broader rewrite-and-migration censoring category is used. Following the first rewrite, the mean file falls to 59.5 instructions relative to its pre-rewrite level and returns to 91.5 within ten commits across the aligned sample.

The post-rewrite growth rate is not lower. Files gain approximately 4.1 instructions per commit before rewriting and 4.9 afterward.

Figure 2

Figure 2: A wholesale rewrite resets prompt size but does not remove the underlying growth process.

This result supports the paper’s interpretation of rewriting as a reset of state rather than a correction of mechanism. A maintainer can remove many instructions simultaneously without determining which individual instructions are unnecessary. The operation avoids the need for instruction-specific justification, but it also discards useful constraints indiscriminately. Once new failures occur, additions rebuild the prompt, often at an even higher rate.

Deletion hazard and identification of imperfect recall

The paper estimates deletion hazard as a function of instruction age using a repository-stratified Nelson–Aalen analysis. The estimated log-hazard slope is −0.032 per commit, with a 95% bootstrap interval of [−0.047, −0.019].

Figure 3

Figure 3: Instruction deletion hazard declines with age, consistent with decaying rationale recoverability.

The negative slope contradicts the prediction of instruction staleness, which would produce increasing deletion risk as requirements become obsolete. The authors also fit gamma frailty models to address content fragility and survival heterogeneity. Shared frailty associated with recurring instruction text absorbs part of the decline, but the negative age slope remains. In the strongest specification, the slope is −0.0355, with a 95% interval of [−0.0414, −0.0296].

The multi-author interaction provides additional evidence. The age-by-multi-author coefficient is −0.0211, with z=11.7z=-11.7. This indicates that deletion hazard decays more steeply in files edited by multiple human authors, consistent with the loss of rationale during handoffs and author turnover. The result is exploratory rather than fully preregistered, and the measure is only a proxy: counting authors does not establish whether the original author actually left or whether a particular instruction’s rationale was lost.

The identification strategy is technically thoughtful but bounded by measurement assumptions. Instructions are segmented using a fixed corpus-level grammar and matched across versions with exact, normalized, and fuzzy matching. Validation on 50 hand-annotated transitions produced precision of 1.000 and recall of 0.933. However, the annotation sample is small relative to the 299,440 transitions. The 50% rewrite threshold also censors a large share of deaths. These choices could affect the magnitude of the estimated hazard, although the authors argue that missed rewordings would bias the age slope toward zero, making the observed decline conservative.

Informative comments as a causal intervention

The proposed intervention is to separate executor-facing instructions from maintainer-facing comments. An instruction specifies what the executor should do. Its associated comment records why the instruction was added, including the observed failure, the hypothesized cause, recurrence information, falsified alternatives, and—in replacement cases—the exact text of the superseded instruction.

The executor receives the instruction with comments stripped. Future maintainers receive both. This separation is essential: rendering comments to the executor would increase context length without providing the intended maintenance benefit and could contaminate the execution prompt.

To test the mechanism under controlled conditions, the paper inverts IFEval (Zhou et al., 2023). The original instructions become a known minimum cover DD_\star, while the associated verifiers remain hidden constraints. A stronger model produces a general task objective, and a maintainer must reconstruct an effective prompt from censored feedback over repeated rounds. This design makes excess size observable: correctness can be measured against the hidden verifiers, while prompt size can be compared with the known optimal cover.

The controlled experiment includes three arms: no comments, comment-shaped placebo noise, and informative comments. At 15 maintenance steps, informative comments reduce excess size from +60.4% to −5.8%, while maintaining comparable constraint satisfaction. At 51 steps, the effect becomes more pronounced: excess size decreases from +211.3% to +1.4%, representing a 99.3% reduction in excess instructions relative to the no-comment condition.

Figure 4

Figure 4

Figure 4: Informative comments stabilize prompt size near the known optimum without reducing correctness, whereas absent or uninformative comments permit continued growth.

The placebo condition is critical. Comment-shaped noise produces excess sizes of +53.2% at 15 steps and +147.9% at 51 steps, close to the no-comment arm. The result therefore cannot be attributed to formatting, additional channel capacity, or the mere presence of auxiliary text. The comments must encode useful maintenance state.

The effect is not uniformly risk-free. The informative-comment protocol ends with an empty prompt in 12.1% of controlled worlds, compared with 2.4% in the no-comment arm. On these difficult worlds, the commented arm performs worse, demonstrating that rationale-supported pruning can still delete instructions that remain necessary. The paper consequently recommends human review and safety floors for deletion. Writing comments is low risk; automating deletion based on them is not.

The ablations further indicate that outcomes are the critical content. Narrative descriptions without observed outcomes perform poorly, while removing recurrence counts, falsification lineage, or restoration quotes weakens pruning to varying degrees. This supports a specific interpretation of comments as compact empirical records rather than generic explanations.

Effects on real-world instruction following

The WildIFEval (Lior et al., 9 Mar 2025) experiment evaluates whether comments can recover correctness in prompts containing irrelevant instructions. The setup seeds prompts with true instructions and distractors sampled from other benchmark items. With one withheld true instruction and 16 distractors, irrelevant context reduces satisfaction of the true instructions by 24.1 percentage points, from 65.6% to 41.5%.

Informative comments raise satisfaction from 50.4% to 62.0% over three maintenance rounds, an absolute gain of 11.6 points and a relative gain of 23.1% compared with the uncommented condition. Comment-shaped placebo noise produces an effect close to zero. The result replicates under a second LLM judge, although the point estimate falls from 11.6 to 7.8 points and the confidence interval for the difference between judges includes zero.

The scope of this result is important. Comments do not constitute a general instruction-following improvement in clean prompts. Their benefit appears when prompts contain distractors that can be identified and pruned. The experiment measures recovery from seeded noise rather than the full longitudinal ratchet observed in repositories. It establishes that the maintenance intervention has execution-level consequences, but not that the controlled benchmark reproduces the scale or dynamics of production coding repositories.

Relationship to software engineering and continual learning

The paper’s practical proposal resembles established software-engineering practices: comments, commit messages, architecture decision records, and literate programming all preserve information intended for future maintainers. The contribution is to adapt this principle to agentic prompts, where instruction text is executable policy and comments are explicitly excluded from the executor’s context.

The connection to continual learning is conceptually productive. Conventional continual-learning systems must preserve parameters or representations that future tasks require, while context-file maintainers must preserve rationale that future deletion decisions require. In both cases, the update fails when the information licensing the update is absent. However, the mechanisms differ. Catastrophic forgetting concerns parameter interference under changing objectives; catastrophic remembering concerns textual accumulation under approximately stationary objectives and noisy feedback.

This distinction has implications for agent-memory design. Existing memory systems often use explicit staleness, contradiction, timestamps, or context pressure as eviction signals. The paper argues that authored instructions require a different criterion: the principal maintenance variable is not whether an instruction is old, but whether its rationale remains recoverable and whether its empirical contribution has been falsified.

Practical and theoretical implications

For coding-agent platforms, the most direct intervention is a first-class comment syntax with strict projection semantics. A context file should expose separate views for maintainers and executors. Comments should be attached to stable instruction identities rather than line positions, and should preserve outcome-grounded provenance through instruction replacement and deletion.

A robust production implementation would require additional safeguards:

  • comments should record observed failures and validated outcomes rather than unsupported narratives;
  • deletion should require confidence thresholds, regression tests, or human approval;
  • safety-critical instructions should be excluded from automatic pruning;
  • comments should be versioned independently when an instruction is rewritten;
  • prompt compilers should enforce that rationale does not leak into the executor context;
  • maintenance dashboards should track instruction age, provenance completeness, recurrence, and empirical support.

The theoretical contribution suggests a broader research program on continual learning over natural-language policies. Candidate methods include rehearsal of historical failures, rationale-aware regularization, Bayesian instruction utility estimation, counterfactual execution, and bounded prompt architectures. A future system could maintain a structured evidence graph in which instructions, failures, hypotheses, tests, and replacements are distinct objects. Such a representation would avoid the paper’s protocol limitation that rationale disappears when its associated instruction is deleted.

The empirical claims also motivate better benchmarks. Inverted IFEval provides a known optimum and mechanically verifiable constraints, but its covers are only two or three instructions—far smaller than the median real context file. Future evaluations should use larger, interacting constraint sets; real code-level verifiers; nonstationary objectives; multi-agent authorship; instruction rewriting; and long horizons. WildIFEval’s LLM-based judging should be supplemented with human annotations and executable tests where possible.

Limitations and interpretation

The evidence supports the proposed mechanism, but it does not establish that imperfect recall is the only cause of context-file growth. The observational corpus is restricted to public GitHub repositories and three filename classes. Language distribution, repository domain, organizational structure, and non-English instructions are not analyzed. The author-count interaction is correlational and does not directly measure rationale transfer or personnel turnover.

The controlled experiments also operate in a deliberately constrained regime. The maintenance horizon is short relative to repository lifetimes, both maintainer and executor are instantiated from a single model family in the main experiment, and the known minimum covers are much smaller than real prompts. The WildIFEval result is based on an LLM judge rather than ground-truth annotations. These limitations temper claims about deployment-scale magnitude, even though they do not undermine the central pattern: comments containing empirical rationale reduce unnecessary retention under censored maintenance feedback.

Conclusion

“Why Does CLAUDE.md Keep Growing? Catastrophic Remembering in Agentic Coding” (2608.11095) explains agentic prompt growth as a failure of rationale preservation. Across 247,694 instruction lifetimes, prompts exhibit persistent accumulation, wholesale rewrite cycles, and declining deletion hazard. The theoretical model shows how decaying rationale recoverability makes append-only maintenance rational under noisy feedback. Controlled experiments then demonstrate that outcome-grounded comments can reduce excess prompt size by 99.3% in a known-optimum setting and improve instruction-following by up to 23.1% under distractor-heavy conditions.

The paper’s principal implication is architectural: agentic coding systems should treat maintainer rationale as a first-class, executor-invisible artifact. Comments do not merely document prompts; they provide the information required to delete, revise, and prevent instructions safely. Future systems will need to combine this provenance channel with verification, human oversight, and explicit mechanisms for selective retention if agentic prompts are to remain compact, interpretable, and operationally reliable.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

1. What is this paper about?

This paper studies why files such as CLAUDE.md, AGENTS.md, and copilot-instructions.md often become longer and longer in software projects.

These files contain instructions for AI coding assistants. For example, they might say:

  • “Always run the tests before finishing.”
  • “Put database code in this folder.”
  • “Never edit this configuration file directly.”

The paper argues that these files grow because developers remember what an instruction says but gradually forget why it was added. Without knowing the reason, deleting an old instruction feels dangerous. So people keep adding new instructions but rarely remove old ones.

The author calls this problem catastrophic remembering. It is the opposite of “catastrophic forgetting”: instead of forgetting useful information, people keep too much information because they have forgotten which parts are still useful.

2. What questions does the research ask?

The paper mainly asks four questions:

  1. Do AI coding instruction files really grow over time?
  2. Why are old instructions rarely deleted?
  3. Does forgetting the reason behind an instruction cause this growth?
  4. Can comments explaining the reason for an instruction stop the files from becoming too large?

The central idea is that an instruction should have two parts:

  • The instruction itself: what the AI should do
  • A comment: why the instruction exists

For example:

1
2
3
Always write dates in ISO format.
# Reason: A previous bug happened because different parts of the program
# used different date formats.

The AI coding assistant follows the first line. Future developers use the comment to decide whether the instruction is still needed.

3. How did the researchers study this?

The study used two main approaches.

Studying real software repositories

The researchers examined the history of instruction files in 1,867 public GitHub repositories. They tracked nearly 248,000 individual instructions over time.

They looked at:

  • How many instructions were added
  • How many were removed
  • How old instructions were before disappearing
  • How many different people edited the file
  • What happened after a large rewrite of the file

This is similar to watching a collection of notebooks over many years and recording which rules are added, crossed out, or rewritten.

The researchers also used a measurement called deletion hazard. In everyday language, this means the chance that an instruction will be deleted at a particular age. If the chance becomes smaller as the instruction gets older, that suggests people are becoming less willing to remove it.

Running controlled experiments

The researchers also created artificial testing situations based on instruction-following tests called IFEval and WildIFEval.

They hid the original instructions from an AI “maintainer” and gave it only a general description of the task. The AI then had to build an instruction file by learning from whether its answers passed or failed different checks.

There were three groups:

  • No comments: Instructions were passed on without explanations.
  • Noise comments: Comments existed but contained no useful information.
  • Informative comments: Comments explained what had gone wrong, what was tried, and whether it worked.

The researchers then compared two things:

  • Correctness: Did the AI follow the necessary rules?
  • Excess size: How many unnecessary instructions did the file contain?

The researchers knew the smallest correct instruction set in these artificial tests. This gave them a way to tell whether an instruction file was larger than necessary.

4. What did the researchers find?

Instruction files grow very quickly

The real-world study found that instruction files usually gain more rules than they lose.

Across the repositories:

  • The typical file eventually contained 39 instructions.
  • Files grew by about 4.9 instructions per commit, on average, when large rewrites were excluded.
  • Over their lifetimes, files became more than three times larger, with an average increase of 226%.
  • About 77% of instruction disappearances happened during a large rewrite, rather than through careful deletion of individual rules.

A large rewrite is like throwing away most of a messy notebook and starting a new one. However, the same kinds of rules soon begin piling up again.

Growth starts again after rewrites

When a file was rewritten, its size dropped. But the growth quickly returned. In fact, files grew slightly faster after a rewrite than before one.

This suggests that rewriting the file does not solve the real problem. It only temporarily clears away the symptoms.

Older instructions are less likely to be deleted

The chance of deleting an instruction became smaller as the instruction got older. Instructions were also less likely to be removed when more people had edited the file.

This supports the idea that the reason for an instruction becomes harder to recover over time. When several people edit a file, each person may understand only part of its history.

The findings do not fit as well with other possible explanations. For example, if old instructions simply became outdated, they should become more likely to be deleted, not less likely.

Useful comments almost stopped unnecessary growth

In the controlled experiments, informative comments made a very large difference.

After 51 rounds of maintenance:

Type of prompt Unnecessary size
No comments About 211% larger than necessary
Meaningless comments About 148% larger
Useful reasoning comments About 1% larger

In another experiment with real-world-style instructions, useful comments improved instruction-following by up to 23.1% compared with having no comments.

Comments worked only when they contained meaningful information. Simply adding a comment symbol or writing a vague sentence did not help.

The most useful comments explained:

  • What failure had occurred
  • What solution was tried
  • Whether the solution actually worked

5. Why are these findings important?

Long instruction files can confuse AI systems. Every extra rule gives the AI more information to consider, and some rules may conflict with one another. As the number of instructions increases, the AI may follow the important rules less reliably.

The paper suggests that comments can act like a memory aid for future maintainers. They preserve the missing background information needed to decide whether an instruction is still useful.

This is similar to labeling things in a school science cabinet. If a bottle only says “keep refrigerated,” someone may keep following that rule forever. But if it also says “because the chemical becomes dangerous when warm,” a future student can make a better decision.

6. Implications and possible impact

The paper recommends that AI coding tools support comments specifically for explaining the reason behind instructions. These comments should be visible to developers and future AI maintainers but hidden from the coding assistant when it performs the task.

This could lead to:

  • Smaller and clearer instruction files
  • Fewer contradictory rules
  • Better AI instruction-following
  • Safer removal of outdated or unnecessary instructions
  • Less need for disruptive, complete rewrites

However, the authors warn that comments should not cause automatic deletion. A comment can help someone make a decision, but it does not prove that removing the instruction is safe. A person should still review important changes, especially rules related to security or safety.

The experiments were also limited. Some tests used small instruction sets and artificial tasks, while real-world instruction files can contain many more rules. The study focused on public GitHub repositories and did not test every kind of AI prompt or every language.

Simple conclusion

AI coding instruction files grow because people remember the rule but forget the reason for the rule. Without that reason, deleting an instruction feels risky, so new rules are added on top of old ones.

The paper’s proposed solution is simple: write down why each instruction exists. Useful comments preserve the history and evidence behind a rule. According to the experiments, this can keep instruction files close to their ideal size while helping AI assistants follow instructions more accurately.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

  • Causal attribution in real repositories remains unresolved: the observational decline in deletion hazard is consistent with imperfect recall, but cannot definitively distinguish it from unmeasured factors such as repository maturity, organizational norms, instruction importance, project complexity, or selective survival of particular files.
  • The proposed mechanism is not directly measured: the study infers latent-reasoning loss from deletion behavior but does not observe whether maintainers actually forgot an instruction’s rationale, could not reconstruct it, or deliberately retained it for other reasons.
  • The recoverability function ρ(d,a)\rho(d,a) is not empirically estimated: its assumed decay toward zero is central to the theoretical divergence result, yet the paper does not measure how rationale recoverability varies with instruction age, instruction type, author identity, or repository context.
  • The theoretical O(2D)O(2^{|D|}) deletion cost is not validated in realistic maintenance settings: the analysis assumes exhaustive subset probing is required, but practical maintainers may use testing, documentation, code search, ownership knowledge, or statistical heuristics to reduce this cost.
  • The model assumes approximately stationary constraints: it does not establish how catastrophic remembering interacts with changing requirements, obsolete instructions, evolving coding conventions, dependency updates, or repository migrations.
  • The boundary between imperfect recall and instruction staleness is not fully identified: old instructions may be retained because they remain important, while deletion may occur only during deliberate redesign; richer metadata about applicability and usage would be needed to separate these processes.
  • The corpus may not represent agentic coding broadly: it includes public GitHub repositories containing CLAUDE.md, AGENTS.md, or copilot-instructions.md, but excludes private repositories, undocumented prompts, system prompts, tool configurations, agent skill files, issue-level instructions, and other maintenance practices.
  • Language and cultural generalizability are unknown: the repository corpus and experiments do not assess non-English instructions, multilingual teams, or culturally different documentation and code-review practices.
  • The corpus-selection process may introduce survivorship and visibility bias: repositories with files that were deleted, renamed, kept private, or never committed may be absent, potentially inflating estimates of long-term growth and obscuring alternative maintenance trajectories.
  • Instruction extraction and matching remain insufficiently validated: the matcher was validated on only 50 hand-annotated transitions, and the segmentation grammar was not systematically compared with alternative definitions of an “instruction.”
  • The censoring strategy may alter the estimated deletion process: wholesale rewrites and migrations account for most instruction deaths but are excluded or treated as competing risks, even though these events may themselves reflect lost rationale or successful forms of maintenance.
  • The fixed 50% rewrite threshold is untested: different thresholds, file-level migrations, renamings, and gradual rewrites could substantially change the estimated lifetimes, hazard curve, and rate of prompt growth.
  • The analysis does not explain why some repositories avoid the ratchet: approximately one-quarter of repositories shrink, and the characteristics of these files, teams, workflows, review practices, or tool integrations are not analyzed.
  • Author count is an incomplete measure of knowledge fragmentation: the multi-author interaction uses the number of editors, but does not capture whether the original author left, whether authors reviewed one another’s changes, team ownership, organizational turnover, or the distribution of edits across instructions.
  • The proposed comments may become stale themselves: the paper does not measure comment–instruction divergence, whether comments are updated after failures or code changes, or whether outdated rationales create more harmful deletions than missing rationales.
  • The optimal structure and content of a rationale are unclear: the experiments suggest that outcome information matters, but do not determine how much detail, which fields, uncertainty statements, provenance, timestamps, or links are necessary for reliable future maintenance.
  • The safety of rationale-guided deletion is not established: the paper acknowledges that the protocol can remove genuinely necessary instructions, but does not quantify false-positive deletion rates across instruction categories or define reliable safeguards for safety-critical, security, compliance, and deployment rules.
  • The experiments use an unusually small and simple prompt regime: the controlled IFEval worlds involve covers of roughly two or three instructions, far below the median real file size of 39 instructions, so it is unknown whether comments remain effective under realistic redundancy, hierarchy, conflicts, and long contexts.
  • The controlled experiments do not reproduce real repository maintenance: they use short horizons, artificial task worlds, one model serving as maintainer and executor, and simulated handoffs rather than human–agent teams working on actual codebases over months or years.
  • Long-term persistence of the intervention is unknown: the 15- and 51-step experiments do not establish whether comments prevent growth indefinitely, merely delay it, or eventually accumulate their own redundant and conflicting content.
  • The intervention has not been compared with competing maintenance strategies: no evaluation contrasts informative comments with automated pruning, versioned decision records, ownership metadata, retrieval-based memory, periodic audits, regression testing, rehearsal, regularization, or human review.
  • The effect may depend on the model and prompting interface: the study does not test multiple model families, context-window sizes, agent architectures, tool-use policies, temperature settings, or models with different instruction-following and summarization capabilities.
  • The role of comment visibility and placement is unexplored: it remains unknown whether comments work because they preserve rationale, increase attention to particular instructions, change formatting or hierarchy, or provide a form of retrieval cue; alternative locations and syntaxes are not evaluated.
  • The WildIFEval results rely on imperfect LLM judges: the second judge provides partial replication but neither judge is ground truth, and the paper does not report human validation, judge calibration by constraint type, or sensitivity to judge selection.
  • The distractor-generation procedure may not reflect real prompt noise: noisy instructions are sampled uniformly from other benchmark items, whereas real repositories likely contain correlated, partially relevant, contradictory, duplicated, or project-specific distractors.
  • The real-world experiment does not test ratchet dynamics at realistic scale: it measures the immediate effect of seeded excess instructions over three rounds rather than whether comments reduce additions and deletions during genuine ongoing prompt evolution.
  • The minimum-cover formulation may be too restrictive for software tasks: real instructions can be conditional, hierarchical, probabilistic, overlapping, or valuable for interpretability and coordination even when they do not increase measured constraint satisfaction.
  • The evaluation does not measure downstream engineering outcomes: reductions in prompt size and benchmark satisfaction are not linked to code correctness, test-passing rate, security defects, maintainability, development time, token cost, or developer workload in actual repositories.
  • The relationship between prompt size and agent performance is not characterized across scales: the study assumes excess instructions harm following, but does not identify performance thresholds, nonlinear effects, interactions with context length, or cases where additional instructions improve robustness.
  • The recommendation to preserve rationale may increase maintenance burden: the paper does not quantify the writing time, token overhead, review cost, cognitive load, or potential privacy and security risks introduced by storing detailed failure histories in repository files.
  • Open-source repository histories may omit non-commit maintenance activity: edits performed through generated configuration, deployment systems, local uncommitted files, or external orchestration layers are not observed, limiting conclusions about the full lifecycle of agent instructions.

Practical Applications

Immediate Applications

The paper’s findings support the following practices and tools that can be deployed now, especially in software engineering and AI-agent workflows:

  • Add rationale comments to agentic context files.
    • Observed failure: what went wrong;
    • Hypothesis: why the instruction should prevent recurrence;
    • Outcome: whether subsequent evaluations confirmed the hypothesis;
    • Recurrence: how often the failure appeared.
    • This is the paper’s most directly supported intervention: informative comments reduced excess prompt size from approximately +60.4 to −5.8 in the 15-step experiment and from +211.3 to +1.4 over 51 steps, while preserving constraint satisfaction.
    • Sector: software engineering, DevOps, AI coding assistants.
    • Dependencies: the comments must contain outcome-grounded rationale rather than generic prose or comment-shaped noise; comments must be visible to maintainers but stripped before the executor receives the prompt.
  • Introduce a “prompt rationale” section in pull requests and code review. Teams can require every new agent instruction to include a short explanation of the problem it addresses and the evidence supporting it. Reviewers can assess whether the instruction is:

    1. tied to a reproducible failure,
    2. non-redundant with existing instructions,
    3. still applicable to the current repository, and
    4. accompanied by a verification procedure. Sector: software development, engineering management, research software. Dependencies: developer adherence and review-time incentives; rationale quality may decline if documentation becomes a bureaucratic checkbox.
  • Build linting and CI checks for prompt maintenance.

    • executable instructions without rationale comments;
    • duplicate or semantically overlapping instructions;
    • large increases in instruction count;
    • instructions added without linked failing tests, issues, or examples;
    • comments that contradict current code or tests;
    • mass rewrites that remove many instructions without an audit record.
    • The tool should initially warn rather than automatically delete content.
    • Potential product: a prompt-lint command or GitHub Action integrated with pull requests.
    • Dependencies: reliable instruction segmentation and semantic matching; the paper reports that large-scale matching and segmentation remain measurement limitations.
  • Add prompt-size and instruction-following metrics to agent observability. Agent platforms can track prompt instruction count, token cost, repeated failures, constraint satisfaction, and performance before and after prompt changes. Dashboards could display a “prompt health” trend and identify ratchet behavior, such as persistent positive instruction growth after each commit or rewrite. Sector: AI infrastructure, developer tools, enterprise software. Dependencies: access to task outcomes and suitable verifiers; for subjective tasks, evaluation may rely on imperfect LLM judges.
  • Use human-reviewed pruning rather than automated deletion. Teams can periodically audit old instructions, prioritizing those whose rationale is recoverable and whose removal can be tested in a staging environment. The paper’s ethics statement explicitly warns that automated deletion may remove safety-relevant instructions or instructions whose rationale was incorrectly reconstructed. Workflow: branch the prompt, remove one or more candidate instructions, run a regression suite, compare agent success and failure modes, and merge only after human approval. Sector: safety-critical software, cybersecurity, regulated engineering. Dependencies: representative regression tests and a clearly defined rollback process.
  • Preserve prompt history as an engineering artifact. Instead of treating context files as ordinary prose, organizations can link each instruction to an issue, commit, test failure, incident report, or architectural decision record. This makes the latent reason recoverable even when the original author leaves and multiple maintainers edit the file. Potential tools: links from prompt lines to tickets, ADRs, test cases, and incident-management systems. Dependencies: persistent project-management records and stable identifiers; linked artifacts can themselves become outdated.
  • Use the paper’s inverted-benchmark methodology to evaluate agent prompts.
    • correctness or constraint satisfaction;
    • excess prompt size relative to a known minimum cover;
    • robustness to distractor instructions;
    • the effect of rationale comments.
    • This enables controlled comparisons of prompt-maintenance strategies rather than evaluating only final task success.
    • Sector: AI evaluation, model development, software testing.
    • Dependencies: mechanically verifiable constraints or trustworthy evaluators; the paper’s WildIFEval results use LLM judges rather than ground-truth labels.
  • Establish documentation standards for AI-generated code and workflows.
    • text the agent must execute;
    • rationale intended for future maintainers;
    • evidence and test outcomes;
    • safety restrictions that require explicit human ownership.
    • Sector: enterprise governance, education, open-source software.
    • Dependencies: agreement on a common syntax and support from the coding-agent platform.
  • Apply the principle to non-coding prompt libraries. Teams maintaining prompts for customer support, data analysis, content generation, or internal automation can record why each instruction exists and what failure it addresses. This may reduce prompt bloat and interference from irrelevant constraints. Sector: customer service, finance operations, marketing, business-process automation. Dependencies: the paper directly studies coding-oriented context files; transfer to other domains requires domain-specific validation and stronger safeguards for high-impact decisions.

Long-Term Applications

The results also suggest broader systems and research directions that require further validation, scaling, or product development:

  • Version-controlled prompt-management platforms.
    • executable instructions and non-executable rationale comments as separate layers;
    • instruction-level lineage and authorship;
    • semantic diffs;
    • dependency graphs among instructions;
    • rollback and branching;
    • automated regression evaluation;
    • approval workflows for deletions.
    • Such a system could become the equivalent of source control plus architecture-decision tooling for agent behavior.
    • Sectors: software, robotics, enterprise AI, industrial automation.
    • Dependencies: reliable instruction identity across rewrites, standardized prompt formats, and benchmark suites that reflect real tasks.
  • Automated rationale extraction from development traces. Future agents could infer candidate comments from failed tests, tool outputs, issue discussions, commit messages, and execution traces. For example, after an agent violates a formatting rule, the system could propose a comment describing the failure, hypothesized cause, and observed recurrence. A human would approve the rationale before it becomes part of the prompt-maintenance record. Potential product: an AI “prompt historian” or rationale-generation assistant. Dependencies: inferred rationales must be factually accurate and traceable to evidence; hallucinated explanations could make future pruning less safe.
  • Rationale-aware prompt optimizers. Instead of appending instructions whenever a failure occurs, an optimizer could search for a minimal, non-conflicting instruction set while retaining comments as maintenance metadata. Candidate changes could be evaluated against historical tasks, adversarial tests, and safety constraints. Sectors: LLM serving, coding agents, robotics control, autonomous operations. Dependencies: the general minimum-cover problem is computationally difficult; optimization quality depends on representative task distributions and sufficiently strong verifiers.
  • Selective forgetting and rehearsal for agent prompts.
    • retaining a compact core prompt;
    • storing rarely used rationales in external memory;
    • retrieving instructions only for relevant tasks;
    • periodically rehearsing safety-critical constraints;
    • assigning confidence and evidence scores to each instruction.
    • Sectors: long-running agents, robotics, personal assistants, enterprise automation.
    • Dependencies: retrieval must not omit constraints that are globally applicable; eviction policies require rigorous safety and coverage guarantees.
  • Prompt-memory systems for long-lived robots and autonomous agents. Robots operating over months or years could maintain task rules together with rationale, failure history, and environmental conditions. This could prevent the accumulation of contradictory behavioral rules in household robots, warehouse systems, or field robots. Potential workflow: the robot records an intervention, links it to a validated policy change, and presents the rationale to a human supervisor before deployment. Dependencies: physical-world failures are costly and sometimes irreversible; simulation alone may not reveal interaction effects, and human authorization would remain necessary for safety-critical updates.
  • Regulatory standards for auditable AI instructions. Regulators and standards bodies could require organizations deploying persistent agents to maintain instruction provenance, rationale, test evidence, change history, and human approval for safety-relevant deletions. This would extend existing requirements for model documentation and software change control to natural-language agent policies. Sectors: healthcare, finance, public administration, critical infrastructure. Dependencies: standards must distinguish harmless prompt optimization from changes to operational policy and must address privacy, trade secrets, and cross-provider interoperability.
  • Healthcare and clinical decision-support safeguards. In clinical systems, rationale-preserving prompt maintenance could document why an instruction requires citation of guidelines, escalation to a clinician, or abstention under uncertainty. A controlled prompt registry could prevent silent accumulation or deletion of medical constraints. Potential tools: regulated prompt versioning, evidence-linked instructions, clinical regression suites, and approval gates for prompt changes. Dependencies: clinical validation, regulatory approval, current medical evidence, patient privacy, and strict separation between documentation assistance and autonomous medical decision-making.
  • Financial and compliance-agent governance. Compliance agents could associate each instruction with the regulation, policy clause, historical incident, or audit finding that motivated it. This would make it easier to determine whether a rule is obsolete, duplicated, or still required. Potential workflow: proposed deletions trigger impact analysis across policies, historical cases, and compliance tests. Dependencies: regulations change over time, and the paper’s stationary-task setting does not establish how rationale comments perform under rapidly changing objectives; legal review remains essential.
  • Educational tools for teaching maintainable AI workflows. Software engineering and AI courses could use the paper’s ratchet phenomenon to teach students that prompt instructions require the same rationale, testing, and lifecycle management as code. Assignments could compare append-only prompts with rationale-aware prompts using controlled instruction-following evaluations. Sector: academia and professional training. Dependencies: educational benchmarks should not imply that short prompts are always better; some domains legitimately require extensive instructions.
  • Large-scale empirical studies of catastrophic remembering. Researchers can test whether the effect generalizes to system prompts, agent skills, non-English repositories, multimodal agents, enterprise repositories, and tasks with changing objectives. Studies should also compare human maintainers with model-based maintainers and examine whether comments remain synchronized with instructions over time. Dependencies: access to representative repositories, privacy-preserving data collection, independent annotation, and evaluation beyond LLM-judge agreement.
  • Formal safety analysis of comment-guided deletion. A mature system could model instruction dependencies and estimate the risk of deleting an instruction, but this requires research into redundancy, interaction effects, hidden constraints, and counterfactual evaluation. The paper’s experiments show that comments improve maintenance in controlled settings; they do not establish that automated deletion is safe. Sectors: autonomous systems, cybersecurity, healthcare, critical infrastructure. Dependencies: formal or high-coverage verifiers, conservative human-in-the-loop policies, and explicit exclusion of safety-critical instructions until validated.

Glossary

  • Ablation: An experiment that removes or changes one component to measure its contribution. “We ablate the effect across comment payloads to show outcome-grounded latent reasoning drives the gain.”
  • Agentic coding: Software development in which an AI agent autonomously performs coding-related tasks. “Why Does CLAUDE.md Keep Growing?\ Catastrophic Remembering in Agentic Coding”
  • Arm-blind judge: An evaluator that does not know which experimental condition produced an output. “we score them with an arm-blind LLM judge that sees one constraint and one response and nothing else”
  • Bootstrap confidence interval: An uncertainty interval estimated by repeatedly resampling observed data. “bands are 95\% bootstrap over 184 worlds.”
  • Catastrophic forgetting: The loss of previously learned information when a model learns new information. “Under catastrophic forgetting, a gradient learner overwrites what it should have kept”
  • Catastrophic remembering: The accumulation of obsolete instructions caused by losing the rationale for deleting them. “We name the resulting divergence catastrophic remembering”
  • Censored feedback: Feedback that does not reveal all information needed to identify the causes of an outcome. “We model prompt maintenance as the \emph{online estimation of an unobservable constraint set from censored, noisy feedback}”
  • Censoring: A statistical treatment in which an event’s exact occurrence or cause is only partially observed. “We censor both as competing risks”
  • Compositional effects: Apparent aggregate patterns caused by changes in the composition of the observed population. “but composition alone cannot account for the slope.”
  • Competing risks: Multiple possible event types that can terminate an observation process. “We censor both as competing risks”
  • Constraint satisfaction: The degree to which a response fulfills specified requirements. “Every experiment in this paper scores DtD_t against DD_\star on two axes: correctness, the expected satisfaction E[qc]\mathrm{E}[q_c], and excess size”
  • Counterfactual: A hypothetical alternative outcome used to assess what would have happened under a different action. “Deleting agentic instructions risks a regression, and doing so safely requires counterfactuals that maintainers cannot feasibly run.”
  • Covariate: An observed variable included in a statistical model to explain variation in an outcome. “the covariate in \autoref{sec:hazard}”
  • Executor: The component that carries out tasks under a prompt’s instructions. “The harness draws tasks jj, runs them using the executor under prompt DtD_t
  • Excess size: The relative amount by which a prompt exceeds the size of its optimal instruction set. “Excess size is DtD1\frac{|D_t|}{|D_\star|} - 1.”
  • Event-history analysis: Statistical analysis of the timing and occurrence of events over time. “the event-history form used for written organizational rules”
  • Frailty model: A survival-analysis model that represents unobserved heterogeneity among entities. “We refit it with a gamma frailty model”
  • Gradient learner: A machine-learning model updated using gradients of an objective function. “Under catastrophic forgetting, a gradient learner overwrites what it should have kept”
  • Hazard: The instantaneous or conditional rate at which an event occurs, given that it has not yet occurred. “The deletion hazard h(a)h(a) and its interaction with author count identify imperfect recall as the mechanism driving instruction growth.”
  • Instructability: The property that adding an instruction can increase the probability of satisfying a constraint. “Properties A1–A3 (instructability, interference, and redundancy) set the overall regime”
  • Instruction staleness: The condition in which an instruction no longer applies because requirements or circumstances have changed. “If requirements stop applying (instruction staleness), deletion hazard rises with an instruction's age.”
  • Interference: The phenomenon in which adding one instruction reduces performance on another constraint. “A2 & interference & adding dd lowers other qcq_{c'}
  • Latent reasoning: Unobserved justification or rationale underlying an instruction or decision. “Prompt comments encoding latent reasoning can halt unbounded prompt growth”
  • Log-hazard: The logarithm of an event hazard, often modeled as a function of covariates. “The log-hazard slope from a repository-stratified bootstrap is 0.032-0.032 per commit”
  • Minimum cover: The smallest instruction set that achieves maximal expected constraint satisfaction. “A maintainer's target is the minimum cover DD_\star, the smallest instruction set that maximizes expected constraint satisfaction.”
  • Online estimation: Sequential estimation in which observations are incorporated as they arrive. “We model prompt maintenance as the \emph{online estimation of an unobservable constraint set from censored, noisy feedback}”
  • Pareto gain: An improvement in one or more objectives without worsening any other objective. “prompt comments enable strictly Pareto gains in both constraint satisfaction and excess size relative to control”
  • Placebo condition: An experimental condition designed to resemble treatment without containing its active mechanism. “placebo & comment-shaped noise”
  • Prompt maintenance: The process of adding, deleting, and revising instructions in an AI prompt. “To evaluate prompt effectiveness, we first propose a new evaluation for agentic prompts in task-stationary settings”
  • Provenance: Information about the origin, history, or justification of an artifact. “Without that provenance, the optimal estimator becomes append-only.”
  • Recoverability: The probability that previously recorded reasoning can still be reconstructed. “Recoverability thus sets equilibrium size.”
  • Redundancy: The condition in which an additional instruction contributes no further constraint satisfaction. “A3 & redundancy & a second dd' adds no qcq_c
  • Regression: A loss of previously functioning behavior after a change. “Deleting agentic instructions risks a regression”
  • Repository-stratified bootstrap: A bootstrap procedure that resamples while preserving repository-level group structure. “The log-hazard slope from a repository-stratified bootstrap is 0.032-0.032 per commit”
  • Stochasticity: Random variation in outcomes, even when the relevant constraints are covered. “Properties A4 (censoring) and A5 (stochasticity) respectively block deletions and drive additions.”
  • Survival analysis: Statistical analysis of the time until an event occurs, including when observations are censored. “We refit it with a gamma frailty model”
  • Task-stationary: Describing an environment in which the underlying task or constraints remain essentially unchanged over time. “To evaluate prompt effectiveness, we first propose a new evaluation for agentic prompts in task-stationary settings”
  • Verifiable constraint: A requirement whose satisfaction can be checked by an explicit evaluator or procedure. “Inverting IFEval yields verifiable worlds whose optimal prompts are known”
  • Wholesale rewrite: A replacement of most or all of a file rather than selective editing. “Most disappearances are not deletions”
  • WildIFEval: A benchmark for evaluating instruction following on real-world requests containing multiple constraints. “Inverting WildIFEval the same way carries the test to real prompts”

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Tweets

Sign up for free to view the 9 tweets with 258 likes about this paper.