Complexity Management

A four-person team ships a subscription-proration feature after one afternoon session with an agent. The diff is eighty lines, cleanly named, and it passes every existing test. Three weeks later, a customer who downgrades mid-cycle gets billed twice, because a five-line branch handles the common case correctly and silently mishandles one of six proration scenarios the business actually has. Nobody who approved the diff could have told you there were six scenarios, because the diff never mentioned them — it just computed.

This is not a story about a careless reviewer or a broken agent. The code was correct for the cases it was tested against, readable, and shorter than a person would likely have written it. The problem is that the diff looked exactly as simple as the underlying business rule was not. Complexity did not disappear between the goal being typed and the pull request being opened — it moved somewhere the team was not looking, and it stayed there until a production incident put it back in view.

What the diff doesn’t show

The pattern generalizes past one anecdote. A large 2026 study tracking roughly 300,000 AI-authored commits across more than six thousand repositories found that more than 15% introduced at least one new issue, and nearly nine in ten of those issues were code smells rather than outright bugs — broad exception handling, unused variables, silently unhandled branches. The researchers’ own framing is the useful part: these problems typically do not break the system immediately, which is exactly what makes them easy to accept in review and expensive to find later. Roughly a fifth of the tracked issues were still unresolved at the most recent snapshot, months after being introduced.

None of this means agents write worse code than people on average — plenty of evidence elsewhere in this Library says the opposite for routine work. It means fluency and correctness are different properties, and an agent optimized to produce a plausible, well-formatted diff will produce one whether or not it reasoned through every edge case the business actually has. A messy human first draft tends to signal its own uncertainty — half-finished branches, a TODO comment, a function bluntly named handleWeirdCase. A clean AI-generated diff signals nothing about how much of the domain it actually covered.

Essential and accidental, precisely

The vocabulary for this is forty years old. In 1986, Fred Brooks published No Silver Bullet — Essence and Accident in Software Engineering, arguing that software’s difficulty splits into two distinct kinds. Accidental complexity is difficulty introduced by the tools and methods used to build a system — the friction of expressing a solution in a given language, on a given machine, under a given process. Essential complexity is difficulty inherent to the problem itself — genuinely intricate business rules, genuine domain constraints, genuinely conflicting requirements — and it does not go away no matter how the solution is expressed, because it belongs to the problem, not to the tool.

Brooks’s conclusion was specific, not a vague warning. He evaluated the leading candidates of his moment — high-level languages, object-oriented programming, artificial intelligence and expert systems, automatic programming, graphical programming, formal verification, better workstations and environments — and argued that none of them, alone or combined, would deliver a tenfold improvement in software productivity within a decade. The reasoning was not that these tools were bad. It was that even fully eliminating accidental complexity could not multiply out to the same order of magnitude as essential complexity, because by the mid-1980s most of the remaining difficulty in building software was already essential, not accidental.

Brooks wasn’t predicting that no tool would help. He was predicting that no tool would help enough — because most of what was left to solve was the problem, not the code.

On Brooks’s 1986 argument in No Silver Bullet

Where AI actually helps — and where it can’t

Forty years on, which half of Brooks’s split an AI coding agent attacks is not a hypothetical question anymore — it is a live argument with credible people on more than one side of it — and the honest answer is: mostly the accidental half, and only that half. Agents are very good at exactly the kind of friction Brooks meant by accidental complexity — boilerplate, repetitive scaffolding, the syntax-level tax of translating an intention into a particular language’s idioms. One essay revisiting Brooks for its fortieth anniversary calls AI-assisted coding the largest single reduction in accidental complexity since the high-level language itself, which was Brooks’s own headline example of a genuine, if bounded, win.

What an agent does not do is make a genuinely hard domain rule easier to reason about. A proration policy with six edge cases has six edge cases whether a person writes the branch logic over two days or an agent writes it in ninety seconds. What changes is visibility. A slow, effortful human implementation tends to surface the difficulty as it is solved — the engineer complains about the edge cases out loud, in commit messages, in a Slack thread, because working through essential complexity is exactly what makes the work feel hard. An agent can absorb that same difficulty and hand back a diff that reads as if there was nothing hard to solve, because from the agent’s side, in that moment, generating the tokens genuinely wasn’t hard.

The conservation principle

A useful framing for this already exists, just outside software engineering. Larry Tesler, working on interaction design at Xerox PARC in the 1980s, argued that every system carries an irreducible amount of complexity — sometimes called Tesler’s Law, or the law of conservation of complexity — and the real design choice is only ever who absorbs it: the engineer, in the time spent building it well, or the user, in the time spent fighting it. The same logic holds one layer up the stack. AI-assisted engineering does not remove complexity from a codebase; it relocates it, the way every prior shift in tooling has — assembly to high-level languages moved complexity from machine instructions into business logic, procedural code to objects moved it from procedure management into class design, monoliths to microservices moved it from the codebase into the network.

What is different about the AI-assisted relocation is the direction. Earlier shifts mostly moved complexity sideways, from one construction activity to another — still something a person built, just built differently. The relocation underway now moves it from a constructive activity to an evaluative one: from writing logic to verifying logic someone, or something, else wrote. That is a different skill, exercised at a different pace, by different people than the ones who used to carry the load. It is also exactly the shape of the DORA AI Capabilities Model’s central finding — that AI amplifies whatever organizational strengths and dysfunctions already exist — since a team with a strong verification culture will absorb the relocated complexity there, and a team without one will only discover where it went during an incident.

Where it actually goes: review, verification, harness

Naming the destination matters more than naming the principle, because the destination is where a team can actually intervene. Complexity that leaves an agent’s working context does not vanish; it lands in roughly three places, and this Library covers each in its own volume.

The first row is this Library’s own territory in Volume VII — see “The New Code Review” for the mechanics — but the short version is that a fluent, well-tested diff removes the visual cues a reviewer used to rely on to gauge where the hard parts were. That is one reason review time has grown even as raw output has: one dataset spanning ten thousand developers found AI usage correlated with 21% more completed tasks and nearly double the pull-request volume, while review time itself grew 91% over the same period. The generation gains were real. Verification absorbed them.

The second row is Volume VII in full. Its thesis — generation is cheap, verification is the job — is the direct consequence of essential complexity staying essential while it becomes harder to spot on sight. A test suite, an eval, or an LLM-as-judge pass does not care whether the code reads as simple; it is the mechanism built specifically to catch the difficulty a fluent diff hides.

The third row is Volume IV, The Harness — built on the premise that the model is the engine and the harness is the vehicle. Complexity that used to live in an individual engineer’s judgment about what was safe to touch now has to live somewhere else, if nobody is exercising that judgment call by call: in scope boundaries, permission tiers, checkpoints, and the rest of the guardrail machinery a team designs once and then trusts, rather than re-deciding every session. A team that skips designing that layer has not made the judgment go away. It has made the judgment nobody’s job.

What to check on Monday

1. Stop treating diff size as a complexity proxy. A short diff and a simple problem are not the same claim, and an agent will hand back a diff that looks short whether or not the problem underneath it was.
2. Ask reviewers to name the domain rule, not just approve the syntax. If nobody reviewing a change can state the business rule it encodes in one sentence, the review checked the code, not the logic.
3. Push essential-complexity checks into verification, not review. A person skimming a clean diff under time pressure is the worst place to catch a missed edge case; a test or eval that encodes the six proration scenarios explicitly is not.
4. Write down what the harness is trusted to decide alone. If nobody can say which changes an agent may make without a human in the loop, that judgment has not been designed — it is being improvised, once per session.

None of this is an argument against using agents on genuinely complex features — it is an argument against mistaking a clean diff for proof the complexity has been handled. It hasn’t been eliminated. It has been moved to whichever of review, verification, or harness design a team has invested in least, and a team can find out which one that is before an incident tells them, or after.