DEV Community

Breach Protocol
Breach Protocol

Posted on • Originally published at groundtruth.day

Agent instruction files triple in size because nobody remembers why a rule exists

Agentic coding instruction files grow more than 226 percent over their lifetime and stop growing only when the repository dies or someone rewrites the file from scratch. That is the finding of a study by Kushal Chakrabarti covering 247,694 instruction lifetimes across 1,867 public GitHub repositories, published August 12, 2026. The cause is not laziness. It is that deleting a rule whose rationale has been forgotten is genuinely risky, while adding one is free.

Key facts

  • 247,694 instruction lifetimes tracked across 1,867 repositories, per the paper.
  • Instruction files more than triple over their lifetime, gaining 4.9 net instructions per commit on average.
  • The older an instruction gets, the less likely anyone is to delete it, at a measured log-hazard of -0.032 per commit.
  • Adding comments that record the reasoning behind an instruction removed 99.3 percent of excess instructions in a controlled benchmark.

The asymmetry that drives it

Anyone who has maintained an agent instruction file recognizes the pattern immediately. The agent does something wrong, you add a line telling it not to, and the line stays there forever. Six months later the file is 400 lines and nobody on the team can tell you which of them are still load-bearing.

Chakrabarti's contribution is showing that this is structural rather than sloppy, and naming the cost. Appending an instruction is a one-line commit with essentially no risk. Deleting one is a gamble: if you do not know why a rule was added, you cannot know what breaks without it. The paper formalizes this, arguing that once an instruction's rationale is gone, safely removing it costs on the order of two to the power of the number of instructions in the prompt, because the rule may be interacting with any subset of the others.

He calls the result catastrophic remembering, framing it as the inverse of catastrophic forgetting, the failure mode that continual learning research has organized itself around for thirty years. Catastrophic forgetting is a model losing knowledge you wanted it to keep. Catastrophic remembering is a prompt keeping instructions you would remove if you could establish it was safe.

What the numbers show

The measurements are the persuasive part. Instruction files gain 4.9 net instructions per commit and grow 226 percent over their tracked lifetime, with no equilibrium in sight. And the deletion hazard drops with age at a log-hazard of -0.032 per commit, meaning an instruction that has survived a while is measurably safer from deletion than a fresh one, which is precisely backwards from what you would want. New instructions are the ones most likely to be redundant with something already there. Old ones are the ones whose reasons have evaporated.

The only observed reset is wholesale rewriting. Someone gets fed up, deletes the file, and starts over, after which growth resumes on the same trajectory. That is not maintenance. That is bankruptcy.

The fix is a comment

The proposed remedy is almost aggressively unglamorous, and the paper's closing line makes the case better than any summary: "If English is the new code, why don't we have comments yet?"

To test it, Chakrabarti inverts IFEval, a standard instruction-following benchmark, to construct worlds where the optimal prompt is known in advance. That makes excess instructions measurable rather than a matter of taste. In that setting, comments encoding the latent reasoning behind each instruction removed 99.3 percent of the excess, dropping bloat from 211.3 percent above optimal to 1.4 percent. Applying the same inversion to WildIFEval, a harder real-world set, comments improved instruction-following by up to 23.1 percent.

The nuance matters as much as the headline. The comments are for the person or agent pruning the file, not for the model executing it. Showing the rationale to the executor adds prompt length without buying correctness, which makes sense: the model does not need to know why a rule exists in order to follow it. It needs to know that only when deciding whether the rule can go.

Why this lands now

The result arrives alongside a related paper, SkillZip, attacking the same bloat from the compression side, and it fits a broader pattern this site has been tracking: agent systems fail on memory management long before they fail on capability. We covered the argument that an agent's memory should record what you did, not what you said, and the same principle applies here. An instruction without its rationale is a record of a conclusion with the evidence stripped out.

There is a practical footnote worth knowing. Claude Code stores session transcripts locally as plaintext JSONL files under the project directory, and per Anthropic's own documentation those files contain every message, tool call, and tool result, unencrypted at rest. So the rationale for many instructions technically still exists on disk. It is just in a 40-megabyte log nobody will ever read, which for practical purposes is the same as gone.

The caveat

This is an observational study of public repositories, which means it measures what open-source maintainers do rather than what a disciplined team could do. Growth may partly reflect projects genuinely getting more complex rather than pure accretion, and the paper's exponential deletion-cost argument is a model of the problem rather than a measurement of it. The comment intervention is validated on benchmarks, not on a real repository over a year. What is solid is the descriptive finding, and it is uncomfortable: across nearly two thousand repositories, essentially nobody successfully prunes. Our note on agent memory covers why the same asymmetry shows up wherever agents accumulate state, and context windows explains what the growth eventually costs you.


Originally published on Ground Truth, where every claim is checked against the primary source.

Top comments (0)