Why AI instruction files never shrink

Open the instruction file you keep for an AI system. It might be a Gemini Gem, a custom GPT, the custom instructions on a ChatGPT project, your agency’s AI content style guide, or the system prompt buried inside a product-description pipeline. Whichever one it is, it has more lines in it than when you last looked, and close to nothing has ever come out. That is not carelessness. Appending an instruction takes ten seconds and carries no risk, while deleting one whose original reason nobody remembers means gambling that the thing it prevented will not come back. A paper published on 11 August 2026 measured this across 247,694 instruction lifetimes in 1,867 repositories, gave it a name, and modeled why it ends.¹ I then measured my own configuration against it and found the paper right about the growth, right about the ending, and silent on the part that matters most to anyone maintaining one of these files.

Agentic instruction files more than tripled over their lifetime, at plus 4.9 net instructions per commit, and the older an instruction became the less likely it was ever deleted.

Why does an AI instruction file only ever get longer?

An AI instruction file grows because its two operations have wildly different prices. Adding a rule is free and instant. Removing one requires proving the rule is no longer load-bearing, and if its rationale was never written down, that proof means re-testing the behavior it was there to prevent.

Think of a fuse box where adding a fuse takes a second and pulling one means finding out later which room went dark. The analogy breaks at one point worth keeping, since a fuse box has a physical limit on slots while a prompt has only a budget you can keep raising.

Kushal Chakrabarti prices the deletion problem at O(2^|D|) in a prompt of |D| instructions, which in plain terms means that proving a deletion is safe would mean re-testing every combination of the rules you kept.¹

The paper calls the result catastrophic remembering, and names it the mirror of catastrophic forgetting, or the failure that most continual-learning research is organized around.¹ One is a system that loses what it knew. The other is a system that cannot let anything go.

I would add one additional piece of framing to the paper; underneath the token arithmetic, the asymmetry runs on accountability. A rule you added and never needed costs you nothing visible, whereas a rule you deleted, followed by a bad output three weeks later, is a mistake with your name on it.

What did the study actually measure across 1,867 repositories?

Across 1,867 public repositories, Chakrabarti traced 247,694 individual instruction lifetimes, following each one from the commit that introduced it to the commit that removed it, or to the present day. The files more than tripled over their lifetime, a plus 226 percent change. They gained plus 4.9 net instructions per commit. And the deletion log-hazard ran at minus 0.032 per commit, so an instruction’s chance of removal fell as it aged.¹

Of the three, the log-hazard is the most noteworthy. Most things in a codebase get less likely to survive as they age, because they drift out of step with everything around them.

Instructions run the other way, where the longer a rule sits in the file, the more it looks like load-bearing structure, and the less anyone is willing to touch it. This leaves your oldest instruction as your safest instruction, which is another way of saying your pipeline is partly governed by rules nobody on the team can still justify.

Having named the problem, the paper proposes a fix and tests it twice. Inverting IFEval produces synthetic worlds where the optimal prompt is known in advance, and in those worlds, comments encoding the latent reasoning behind each instruction removed 99.3 percent of the excess, taking a plus 211.3 percent bloat down to plus 1.4 percent.

Applying the same inversion to WildIFEval, comments improved real-world agentic instruction-following by up to 23.1 percent.¹ The paper closes on an obvious question, positing if English is the new code, why don’t we have comments yet?

How fast did my own configuration grow?

Against that average, my own configuration grew far faster. Measured on 18 August 2026 by walking every commit that touched the main instruction file or anything in its rules directory, and summing all of them together, the total went from 51 lines on 13 May 2026 to 784 lines on 31 July, across nine files.

By my count, that growth is plus 1,437 percent in eleven weeks, at 9.3 lines a day. The main file on its own went from 51 to 294 lines, a plus 476 percent change.

One caveat I want to make regarding my own configuration: the paper counts instructions, while I’m counting lines, which are correlated, but not the same unit. My 27.1 lines per commit is therefore not directly comparable to the paper’s plus 4.9 instructions per commit. Having said that, what the two do share is direction and rough magnitude.

None of that growth was slop and nearly every commit in that history was a real correction; a gotcha that had cost me an hour, a model default that changed, a rule added after a client deliverable went out with the wrong number in it, each individual addition was justified at the moment it was made.

Does splitting the file into modules fix it?

If splitting a file into modules were a brake, my own history would show it, and in the one case I can measure precisely it shows the opposite. On 6 August 2026 I moved my prose rules out of the main file into a dedicated rules file of 87 lines. In that same commit the parent file went from 162 lines to 166. It gained four lines. The total across all files gained ninety-one.

Nothing moved out. Something new moved in, and the split was the occasion for writing it. The new file states the reason, without being asked, where it was split out “so it could hold the full standard instead of a compressed summary”. The extraction was permission to be longer, and I granted it to myself in writing.

Brandon’s own claude-config git history, commits ac7240c then 7f2b474, re-derived 2026-08-18.

Defining the pattern, the extraction premium is the net volume a configuration gains at the moment it is modularized, because a rule with its own file has room to argue its case. Mine ran to plus ninety-one lines against nothing removed. That is one observation from one configuration, so treat it as a label for a thing to watch rather than as a rate.

What happens after you finally rewrite an instruction file?

Eventually, the paper says, growth stops only when a repository retires or someone rewrites the file wholesale.¹ I did the second one, and it worked. On 3 August 2026 a single commit removed 281 lines from the main file, added 132, deleted seven whole sections, and deleted two rules files outright. Total instruction volume went from 784 lines to 381 in one commit, a 51 percent cut.

Then it came back. Within five days the total was 496 lines, so 115 lines returned at 23 a day, against the 9.3 a day that preceded the cut. It has since held at 496 for the ten days to 18 August.

Ninety-one of those 115 returned lines sit in a single commit, and five days is a tiny window, but what the sequence does establish is narrower and still useful. In practice the paper’s terminal state resets the clock rather than stopping it, and this configuration started the count again within the week.

How bad is the level, as opposed to the rate? Less bad than I first wrote. The total today is 496 lines against a 784-line peak, so it is down 37 percent from its high instead of roughly double. An earlier version of this analysis compared today’s total against the peak of the main file alone, which made the redistribution look far worse than it is. The takeaway here is the rate of return rather than the level.

How do you audit an instruction file whose reasoning you have already lost?

Sort your instruction file by the question “when was this last justified”, and for each rule either write the one line of reasoning that would let a future reader delete it safely, or delete it now. Growth is not the problem. Unjustifiable growth is the problem, and the two look identical from the outside until you try to remove something.

Three habits make this cheaper than it sounds:

Write the reason at the moment you add the rule, when it costs one sentence rather than an afternoon of archaeology. Date the rule, so a reader in six months can check whether the model behavior it guards against still exists.

When you extract a section into its own file, measure the total before and after, because on my own evidence that is the moment volume is most likely to rise while the file you are looking at gets shorter.

In my opinion, the reason the paper’s comment intervention works so well in its verifiable worlds is that a comment converts an expensive deletion into a cheap one. It does not make the file shorter. It makes the file prunable, which is the property that was actually missing.

If you maintain a Gem, a custom GPT, or a prompt inside a pipeline, and you have ever hesitated over a line because you could not remember why it was there, you already know which of those two problems you have. The pattern this paper measures in code repositories is the same pattern, and it is running in your file too, under a different name and with fewer people watching it.

For the argument that these five vendor products are one pattern rather than five, see Skills, Gems and working loops. This piece is that pattern’s maintenance bill.