We deleted 275,000 lines of agent scaffolding, and the work got better
Earlier this year I wrote about organising your Claude Code rules in layers, and then about enforcing them in code instead of trusting the AI to read them. This post is the third one, and it is the awkward one, because it is largely about deleting the thing the first post told you to build.
In August we removed our agent development framework. All of it.
An AI is only as good as the information architecture around it. What it can find, in what order, described how, and what it is allowed to ignore. For most people that idea is still new. For developers it is not. Spec-driven development has been the default way of working with coding agents for a while, and it is a decent example of information architecture done well.
The interesting part is what happened next. Coding models kept evolving, and the current generation arrives with its own information architecture for software already installed. Through training it carries a well-organised map of how software gets built: how a Python service is laid out, what a FastAPI route looks like, where tests live, what a sensible migration is. That internal map is a big part of why these models got so much better at programming.
Which is awkward if, like us, you spent 2025 building an elaborate scaffold to supply that map on the model’s behalf.
The teardown: 275,000 lines of agent scaffolding, gone
Three commits on a single day. 754 files and 149,252 lines in the first. 332 files and 124,531 lines in the second. A cleanup pass for the remnants. Roughly 275,000 lines of agent scaffolding out of our monorepo, with two smaller repositories stripped the same week.
Our main instruction file went from 606 lines to exactly one: an import pointing at a single canonical AGENTS.md.
Nothing broke. Throughput went up. So what changed between 2025 and now?
Why agent frameworks were right in 2025 and wrong now
Frameworks compensated for weak models with external structure. If a model cannot hold a plan in its head, you give it a plan file. If it cannot decide what to do next, you give it a state machine. If it forgets your conventions halfway through, you repeat them in six places. Every one of those layers was a prosthetic for something the model could not do yet.
Then the models learned to do it. Ask a current frontier model to plan a multi-step refactor and it produces a better plan than our template did, in less time, without a state file. The prosthetic became a splint on a healthy leg.
Meanwhile the actual bottlenecks moved. There are three now, and a heavy framework helps with none of them.
Verification
The question is no longer whether the agent produced something. It is whether what it produced is true. Agents are very good at reporting success.
Boris Cherny, who built Claude Code, put it plainly: give Claude a way to verify its work, and that feedback loop will “2-3x the quality of the final result”. That is the biggest lever in the entire setup, and it has nothing to do with instructions.
Context
Short and sharp beats long and thorough. Every line of instruction competes for attention with every other line, including the code the agent is supposed to be reading. And the window grew. Thirteen models now ship a context window of a million tokens or more, which means the scarce resource is no longer space, it is attention.
Our own review time
With agents running in parallel, the human reading the diffs is the constraint. Anything that speeds the agent up but slows the review down is a net loss.
Modern coding models need skills less than you think
You might think the answer is to fall back on skills. They have slowly been taking over from development frameworks, and for good reason. A skill is a small self-contained instruction file that the agent loads only when it is relevant, which makes it a much lighter replacement. They are genuinely better.
But a large part of your skill library is already redundant, and the model made it so.
Something worth noticing is who bothers to publish official skills. Laravel, Supabase, HashiCorp and Cloudflare all ship them. Svelte ships an official MCP server with skills bundled in. FastAPI added one to its own repository.
Now look at the official skills directory, which indexes 55 organisations and 658 skills. Django is not there. Rails is not there. Vue is not there. Tailwind is not there. Search their repositories and you find plenty of community skills, and nothing official.
I want to be careful here, because absence is not a statement. None of those four projects has announced that models already know their framework well enough, and I am not going to put that in their mouths. But the pattern is hard to unsee: official skills cluster around cloud platforms, paid infrastructure and fast-moving APIs, and thin out across the mature web frameworks that have been thoroughly represented in training data for years. Make of that what you will. It is at least a reason to check whether your carefully written React skill is telling the model anything it did not already know.
The research is less ambiguous. An ETH Zurich study from February 2026 measured what context files actually do to coding agents. Providing them did not generally improve task success, while increasing inference cost by more than 20 percent. Auto-generated context files reduced success by about 3 percent. Human-written ones improved it by about 4 percent. The authors’ conclusion is worth quoting directly: unnecessary requirements from context files make tasks harder, and human-written files should describe only minimal requirements.
Writing more context for your agent is not free and not automatically positive. Generating that context with an AI is reliably negative.
There is a mechanical cost on top of the cognitive one. In Claude Code the list of available skills gets a budget of roughly one percent of the context window. Overflow it and descriptions get dropped, starting with the skills you invoke least. The eviction ranking is usageCount × 0.5^(days/7), which means a skill you have never used scores exactly zero. Its description goes first, so the agent cannot see what it is for, so it never fires, so it is never invoked. A catch-22 that people keep filing bugs about.
Every skill you install degrades the visibility of every other skill you install.
And there are a lot of them. SkillsMP indexes something like 1.9 million public skills scraped from GitHub. SkillsBench analysed 47,150 of them and scored the average at 6.2 out of 12. Half of what is on offer is mediocre, and installing it costs you the visibility of the skills you actually wrote.
So we capped it. Around ten active skills globally, everything project-specific installed only in the project that needs it. We ended up with four global ones.
What agent skills are still good for
Three categories survive, and they are exactly the categories the model cannot get from training.
Things that are true only about you
How our deploy actually works. That the image check has to run unauthenticated. How environment files are scoped per service. Our knowledge, not general knowledge, and it lives in no training set. We turned three deploy runbooks into thin skills for precisely this reason.
Things where the model’s map is stale
Fast-moving APIs, recent breaking changes, a vendor that reorganised its SDK last month. This is also where most of the official skills sit, which is at least consistent with the pattern above.
Sequencing you want enforced
Test-first development, a structured debugging loop, our two-pass review. The model knows perfectly well what TDD is. The problem is that under pressure it jumps straight to the fix. A skill is a commitment device.
What is not on that list: explaining Docker to the agent. Explaining React. Explaining what a good commit message looks like. If the model already knows it, writing it down makes your setup worse.
Workflows we repeat often can become a skill. We do not install or write them preventively. Every manual correction we catch ourselves making becomes a rule, or better, a hook.
Verification beats instruction: hooks, gates and two-pass review
The most useful shift was demoting instructions in favour of checks.
An instruction is advice. The agent may follow it. A hook is a gate that runs deterministically and returns an exit code, and the agent cannot talk its way past it. We put a stop-gate on every repository: the agent cannot claim it is finished until the repository’s own check script passes. Not “I reviewed the code and it looks correct”. A green exit code.
This is also the honest answer to reward hacking. Agents optimise for looking done. The defence is a check the agent runs itself and cannot fake.
On top of that we run a two-pass review. One model does a high-recall pass and reports everything it finds, including the uncertain items. A second model verifies each finding against the source and discards what does not hold up.
We split it that way because of how these reviewers actually behave. In CodeRabbit’s benchmark of GPT-5.6 Sol, the model caught 69.7 percent of known issues while only 31.6 percent of its comments were worth keeping. Two out of three comments are not actionable, deliberately, because a missed bug costs more than a filtered one. Which makes the filter the entire job.
We learned that the expensive way when a 40-line bugfix turned into 1,700 lines of dutifully-implemented review feedback. Nobody had decided to do that. It just happened, one reasonable-looking finding at a time.
Our AI coding setup now: five layers
Each one small enough to explain in a sentence.
Models
One capable model as daily driver, cheaper workers for mechanical fan-out, a separate model as reviewer. The lead runs one tier above the workers. In Anthropic’s own research evaluation that pattern scored 90.2 percent higher than the same frontier model working alone. That was a research and search evaluation, not a coding one, so do not carry the number over to your own work. We run the pattern because it is cheaper than putting the expensive model on everything, and we have not measured what it does to our quality.
The most expensive tier is a manual escalation for four specific triggers, not a default. We learned that one by burning a week’s quota of the priciest model in a single afternoon of routine git surgery.
Rules
One canonical AGENTS.md per repository, under 200 lines, containing only what the agent cannot guess. Build commands, forbidden directories, how to reach infrastructure. The test for every line: does leaving this out cause a mistake? If not, delete it.
Ours started at 71 lines. Today it is 265. In two weeks it grew past the limit I had just finished writing down, without anyone deciding to let it.
I could quietly fix that number before publishing. I would rather leave it in, because it is the whole argument in one data point. In the rules post I noted that compliance drops above 200 lines. Knowing the rule did not enforce the rule. Writing it down did not enforce the rule. Only a check would have, and I did not write one.
Skills
A small portable set, shared across tools, project-scoped wherever possible.
Verification
Hooks as hard gates, one runnable check per repository, escalating to cross-model review on high-risk paths like auth, payments and data migrations.
Parallelism
A handful of isolated workspaces, capped by how many diffs a human can actually review, not by how many agents we can start.
All of it lives in one dotfiles repository with symlinks into the tool-specific locations. One source of truth, and a new machine is one script away.
We had the new setup audited, and it was worse than we thought
After rebuilding, we pointed an adversarial review at our own work. It came back with 15 findings against our own “done” claims. Two were wrong, four partly right, nine correct.
Dead framework directories we thought we had deleted. A hook pointing at a script that did not exist. A quality gate silently failing open, which is the worst kind, because a gate that reports success while checking nothing is more dangerous than no gate at all. A test suite that had been red for weeks in a repository nobody had run locally.
All of that in a setup we had just spent a day building and were rather pleased with. If you take one practical thing from this post, let it be that: audit the thing you just built while you still believe in it.
What is left when the scaffolding goes
Nearly everything we deleted was information architecture we were supplying on the model’s behalf, and the model had stopped needing it. What survived is the part that is specific to us: our commands, our runbooks, our gates.
That is a comfortable place to land if you are a software company with a git history. It is a much less comfortable place if you are a normal organisation about to point an AI at a policy that exists in four versions across three systems, a process everyone knows is wrong and nobody has written down, and a shared drive where the authoritative file is called final_v3_DEFINITIEF_2.docx.
The AI will be fine. It arrives with its map in order. Yours is the variable, and that is a separate post.
Take ours and look at it
Our monorepo is open source, so the result of all this deleting is public.
AGENTS.mdis the canonical entry point, and the file that is 65 lines over its own limit. Read it as a specimen rather than a template.CLAUDE.mdis one line. That is the point of it..claude/skills/holds the project-scoped set, including the three deploy runbooks that exist because no model could ever guess them.
One honest caveat. Everything above is what worked for a small team on one monorepo with good test coverage, over a few weeks. I have a measured before and after for the line counts and the audit findings, and I do not have a controlled measurement of whether our output quality actually improved. It feels faster, the gates are real, and “it feels faster” is not evidence. If you rip out your framework on the strength of a blog post and it goes badly, that one is on both of us.
The part I would defend without hedging is the direction of travel: fewer instructions, more checks. Instructions rot quietly. Checks fail loudly. Ours went from 606 lines to one line and a stop-gate, and the stop-gate is the half that does the work.