---
title: 'In the News: August 15, 2026'
description: 'A study of 247,694 instruction lifetimes explains why CLAUDE.md only grows, and shows that writing down why each rule exists stops it.'
canonical_url: 'https://darkfactory.dev/news/2026-08-15-morning'
markdown_url: 'https://darkfactory.dev/news/2026-08-15-morning.md'
collection: news
date_published: '2026-08-15T09:45:00-04:00'
date_modified: '2026-08-15T09:45:00-04:00'
---

# In the News: August 15, 2026


The instructions file in your repository never gets smaller, and a study of 247,694
individual instructions now says why: the reason each rule was added decays faster than
the rule does, so deleting one safely becomes unaffordable. The same week brought a
controlled experiment that holds an agent's capabilities fixed and varies only how they
are exposed, and finds the packaging changes what the agent does.

## 1. Your CLAUDE.md grows because nobody wrote down why each rule is there

**[Why Does CLAUDE.md Keep Growing? Catastrophic Remembering in Agentic Coding](https://arxiv.org/abs/2608.11095)** · Kushal Chakrabarti, South Park Commons · arXiv, August 11, 2026

Chakrabarti tracked individual instructions, not file sizes, across 1,867 GitHub
repositories and 247,694 instruction lifetimes. At its last tracked version the median
agentic context file carries 39 instructions, with a 90th percentile of 131. Instruction
count more than triples over a file's own lifetime, +226%, and grows by a net +4.9
instructions per commit across 19,267 commits once mass rewrites are excluded.

Deletions do happen, but almost never one at a time: 77.3% of instruction deaths arrive
in a wholesale rewrite or a migration to a sibling file. Aligning files on their first
such rewrite, the mean instruction count drops to 59.5% of its pre-rewrite value and is
back to 91.5% within ten commits, growing faster afterwards than before, 4.9% per commit
against 4.1%.

The mechanism claim rests on the shape of the deletion hazard. If instructions were
being removed because they had gone stale, removal would get more likely with age. It
gets less likely: a log-hazard slope of -0.032 per commit, 95% CI [-0.047, -0.019],
over 28,426 tracked deletions, and the hazard falls further the more authors have
touched the file. The paper's framing of the asymmetry is direct: "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."

The proposed fix is a comment channel. Each instruction carries a note recording the
failure that prompted it, the hypothesis, and how the hypothesis has fared. The harness
strips the comments before the prompt reaches the executor, so they are addressed to
the next maintainer only. In constructed test worlds whose optimal prompt is known by
design, excess prompt size falls from +211.3% to +1.4% over 51 maintenance rounds at
parity constraint satisfaction. On prompts drawn from WildIFEval, comments lift
constraint satisfaction from 50.4% to 62.0% over three rounds, 11.6 points. A placebo
arm of comment-shaped text with no real reasoning in it lands within noise of the
control, which is the ablation that makes the result about the content of the comment
rather than its presence.

The satisfaction gain is a rate under an LLM judge; re-scoring all 6,336 verdicts under a
second judge put the effect at
7.8 points instead of 11.6, with a confidence interval that includes zero. The size
result comes from worlds whose optimal prompts hold two or three instructions, against a
median real file's 39.

**Why it matters:** every practitioner running agents at scale maintains one of these
files, and most of them have been told to prune it without being told how to decide what
to cut. The difficulty comes from missing information, not laziness, and that information is
cheap to record
at the moment you add the rule. If the finding holds, the next feature to want from a
harness is a comment syntax that the executor never sees.

## 2. The same capabilities, packaged differently, change what an agent does

**[The Devil Is in the Interface: Evaluating How Tool Architecture Shapes Coding Agent Behavior](https://arxiv.org/abs/2608.11386)** · Xiangzhe Xu and seven co-authors · arXiv, August 11, 2026

The experiment holds what an agent can do roughly fixed and varies only how those
capabilities are organized and exposed. Six tool setups, three actor models
(Qwen3Coder-30B, Kimi K2.5 and Claude Sonnet 4.5), 65 issue-resolution instances sampled
from SWE-bench Live, ten independent rollouts each, 11,700 trajectories in total.

Against a bash-only baseline, a set of structured low-level primitives improves
consistency across repeated attempts by up to 4.7x, and is the only setup with uniformly
positive consistency deltas across all three models. The gain is largest for the weakest
model, which the authors attribute to fewer malformed commands and broken edits rather
than better reasoning. A natural-language search interface increases access to plausibly
relevant files by more than 11%. Python CodeAct-style interfaces reach similar task
performance with 41.6% fewer steps and 56.3% lower token cost.

Two lightweight text aids, a scratchpad and a hypothesis tracker, gave the agent
an explicit place to record intermediate
reasoning and changed its behaviour very little. The authors are careful that this is a
finding about the two aids they built, not a claim about every way of structuring an
agent's reasoning.

**Why it matters:** harness authors spend most of their effort on what tools to add.
This is evidence that the packaging is a live variable in its own right, and that the
cheapest wins are at opposite ends: structured primitives for reliability, a
code-execution interface for cost. It also suggests that a tool whose only function is to let
the agent think out loud is buying less than it looks like it is.