Your Agent Wrote 40,000 Lines Last Sprint. Who Reads Them?

An agent opens a pull request before breakfast. The tests are green. The diff is 1,800 lines. It adds the requested feature, changes two abstractions, introduces a dependency, and rewrites a helper nobody asked it to touch.

By 9:15, the team has a choice. Merge code that nobody fully understands, or spend the morning reconstructing the agent's decisions.

That choice is becoming the job.

The sales pitch for agentic coding still revolves around production: more code, faster. A model can take a ticket, inspect a repository, edit several files, run tests, and return a plausible patch. Qwen described Qwen3.6-35B-A3B as an open model built for this kind of multi-step coding work. Similar capabilities now sit inside commercial tools used every day.

This is real progress. Small teams can test ideas that previously died in the backlog. A good engineer can explore three implementations before lunch instead of committing to the first affordable one. Old internal tools, neglected integrations, and boring migration work have become easier to attempt.

The output meter is the wrong meter. The scarce resource is no longer the first draft of the code. It is the attention required to decide whether that code belongs in the system.

Code production moved the bottleneck

Drew Breunig's Lessons for Agentic Coding: What should we do when code is cheap? starts from the useful premise that cheaper code changes which work matters. If producing a patch takes minutes, clearer product decisions, tighter architecture, and better quality assurance become more valuable.

There is a nasty asymmetry here. Writing code gives the author a mental model as a by-product. Reviewing generated code does not. The reviewer receives the finished diff without the false starts, trade-offs, and local context that shaped it. To judge the patch properly, that reviewer must rebuild the missing model while also looking for failure modes the agent did not consider.

A 400-line diff can therefore be harder to review than to write. The syntax may be clean. The tests may pass. The real questions sit outside both: Why did this module gain another responsibility? Why was this dependency chosen? What happens when the API times out after the database write? Which existing assumption did the new cache quietly invalidate?

Those are engineering questions, not proofreading questions.

Lars Faye's argument that agentic coding can become a trap is strongest at this point. Code accepted without understanding becomes maintenance debt. The risk is not that an agent occasionally emits an obvious error. Obvious errors are cheap. The expensive failure is a reasonable-looking implementation that passes its local checks while weakening the system in a way nobody notices until later.

That also explains why lines of code and pull-request counts become less useful as productivity measures. They record how much material entered the review queue. They say little about whether the material improved the product, simplified the codebase, or increased the number of assumptions someone must remember during the next incident.

Agentic coding can increase output while reducing comprehension. A team that measures only the first effect will reward itself for creating the second.

Green tests are evidence, not absolution

Sam Sutch's grumpy screed about AI in software engineering captures the daily irritation well: the model can produce a confident implementation that uses an invented API, misunderstands a library, or repairs its own failing test by changing the test. The familiar lesson that models can be wrong is not useful by itself. The specific problem is that the same system can produce the implementation and the evidence offered in its defence.

That is a weak control loop. If an agent misreads the requirement, it can write code for the wrong behaviour and tests that confirm the same wrong behaviour. More generated tests do not fix the shared misunderstanding.

Teams need independent checks at the boundaries where mistakes become expensive. A payment change needs invariants around amounts, retries, and idempotency. A permissions change needs adversarial cases built from the threat model, not merely examples derived from the ticket. A migration needs a rollback path and a check against real data shapes. An architectural rule should be executable where possible, so a patch cannot quietly route around it.

None of this argues for slower models or less automation. It argues for separating generation from judgement.

The useful agent workflow is not “ticket in, pull request out, green means merge.” It is a controlled pipeline. The task states the constraints and forbidden moves. The agent proposes a plan before editing. Tests encode behaviour from a source independent of the implementation. Small diffs keep review within human limits. High-risk changes require a named owner who can explain the design without reopening the chat transcript.

The model can still do a large share of the mechanical work. Stronger controls make more ambitious automation possible. Teams can let agents attempt broad refactors, dependency upgrades, or tedious migrations when failures are easy to detect and changes are easy to reverse. Verification is what turns cheap code from a liability into usable capacity.

The senior job is changing

The most valuable engineer in an agent-heavy team may write fewer lines than before. That is not a loss of craft. The craft has moved toward defining boundaries, reducing ambiguity, designing checks, and rejecting plausible nonsense quickly.

Companies will struggle with this because their rituals still reward visible production. A large pull request looks like progress. A careful specification looks like a document. A reviewer who deletes half the generated patch appears less productive than the agent that wrote it. Those optics are backwards.

Review also cannot remain the task senior engineers squeeze between meetings and feature work. If agents multiply the volume of proposed changes, review capacity must become an explicit planning constraint. Otherwise the queue grows, scrutiny falls, and “the tests passed” becomes permission to stop thinking.

The practical response is straightforward. Track accepted change, rework, escaped defects, and time spent understanding generated patches. Keep agent diffs narrow enough that a reviewer can explain them. Require ownership of the merged design, not ownership of the prompt. Delete generated code freely when a simpler implementation will do.

This is still an optimistic story. Cheap implementation expands what a small team can build. It gives engineers room to explore alternatives and clear work that never justified weeks of manual effort. The gain survives only if teams stop treating generated volume as the result.

Open the largest agent-written pull request in your queue. Ask one engineer to explain its design, failure modes, and rollback plan without consulting the agent transcript. If that takes longer than writing the feature would have taken, your next investment should go into specification and verification before you buy more generation capacity.