When Code Is Cheap, Complexity Is the Budget

Agents have made code cheap to produce. I do not want to argue that part. What I want to work out is what becomes scarce once writing stops being the constraint.

Lee Robinson's answer, in two posts from December 2025, is complexity. A codebase can only carry so much of it. Every abstraction and every dependency draws on that allowance. His claim is that agents changed the price of the draw, and also the price of paying it back.

I read both posts this week alongside notes I already had on Matt Pocock's design-fundamentals talk. On the surface the two disagree about whether code is cheap. I think they are describing the same budget from opposite sides.

Robinson's argument

His thesis is that with coding agents, the cost of an abstraction has never been higher. Over-abstraction was always a smell. What changed is that the remedy got cheap: spend tokens and delete it.

The case study is Cursor's own website. It had been rebuilt on a headless CMS, and shipping content got harder, because an agent could no longer change code and content in one pass. Robinson itemizes what the CMS cost: a second account system beside GitHub, previews that needed logins, translation split into per-language content items, and a CDN bill he reports as $56,848 since the September launch.

The fifth cost is the one that transfers. Content fetched over a network boundary in a bespoke query syntax cannot be found with grep, by a person or by an agent. That is what makes "budget" more than a figure of speech for me. An indirection used to cost a reader some time. Now it costs agent capability, and that is observable: after he moved the data inline, changing the site navigation became one prompt.

He pushes past the CMS. He argues against the React habit of turning everything into an array and mapping over it, and says duplicated markup is often better than a premature abstraction.

His reported result: three days over a long weekend against an estimate of one to two weeks plus an agency, $260.32 in usage, 344 agent requests, and roughly 322,000 lines removed against 43,000 added.

Where the old books agree

Matt Pocock's AI Engineer keynote sounds like the opposite claim. He says code is the most expensive it has ever been. An agent in a good codebase compounds productivity, and an agent in a bad one compounds entropy faster than a human team could. Robinson and Pocock are pricing different things. Writing a line is cheap. Carrying it is expensive, and it gets more expensive when the thing reading the codebase is an agent that treats existing code as the template.

Pocock leans on John Ousterhout's idea of deep modules: a few large modules with simple interfaces. He says AI is good at producing shallow modules and then gets lost among them. At first that looked to me like a conflict with Robinson's advice to duplicate before abstracting. I no longer think it is one. A deep module hides a lot behind a small interface, so the interface is paid for once and the implementation leaves my head. A shallow abstraction charges the interface and hides very little. Both writers are telling me to stop paying for indirection that hides nothing. The CMS was the extreme case: accounts, a query language and a network hop in front of what was mostly markdown.

So before I add an abstraction or a dependency, these are the questions I would now ask:

After this change, can an agent still find the answer with a text search?
Does the interface hide more than it exposes?
Is there a check that would fail if this were deleted wrongly?
How long would it take to remove?

Deleting is only safe with checks

The third question comes from Robinson's second post. He built a Rust image compressor without writing code by hand, in a language and a domain he chose because he expected agents to be bad at them. He reports about 38,000 lines, more than half of them tests, and over 900 tests.

What he credits is verifiable output: tests, lints, benchmarks and CI that the agent can run by itself and learn from. My reading is that this did more of the work than the choice of model. It is also what makes the budget practical. Spending tokens to delete complexity only works if something tells the agent it broke nothing.

I have one clear instance of this in my own tooling. My yt-research skill writes a research note whose claims carry timestamp anchors, and it refuses to finish until those anchors verify. The grep argument is also the outside case for a choice I already made: my research library's retrieval index is generated from note frontmatter, with no vector database between the agent and the files.

What I do not take at face value

All of the numbers are self-reported by a Cursor employee, about work done with Cursor, on Cursor's website. The mechanism is credible and something I could test for myself. The dollar figures are unaudited.

He mentions that about ten agent runs got 80 percent of the way and the last 20 percent took most of the time. The headline of three days hides that distribution. I would plan from the second number.

His forecast of multi-day autonomous agent runs within a year is a forecast. I am not planning around it.

The part that points at me

Robinson closes with advice that cuts against most agent-workflow content: do not over-optimize. He started with zero custom rules and added a rules file only after watching the model make specific mistakes.

I maintain dozens of skills, and my vault was largely designed up front and then populated. By his standard some of that is abstraction bought before I had a failure to justify it. The obvious defense is that he is describing a new project and mine is a long-lived personal system. I think that is partly true, and I should not lean on it.

Key Takeaways

Writing code is cheap. Carrying it is where the cost went, and an agent reading the codebase raises that cost.
An indirection an agent cannot search through has a price that shows up as lost agent capability.
Deep modules and duplicating before abstracting agree: pay for an interface only when it hides a lot.
Deleting complexity with agents depends on checks the agent can run without a person.
Robinson's cost figures are a vendor measuring its own product. Keep the mechanism, not the numbers.

Sources

The question I am taking to my own skills library: which of these were written after a failure I can name, and which were written in advance?