When the agent writes most of the code: the bottleneck shifts from writing to verification

Updated: August 2026.

In the first half of 2026, the metrics for software teams began to tell a strange story: the number of completed feature branches skyrocketed, while the number of changes that actually made it into the main branch remained flat or even declined. CircleCI’s 2026 data shows that feature branch throughput increased by about 59% compared to the previous year, while the median team’s main branch throughput actually decreased. LinearB’s 2026 benchmark report found that the time a pull request generated by an agent had to wait before being reviewed was significantly longer than for pull requests written manually.

From a distance, it might seem like the team is slowing down. But a closer look reveals the opposite: the code-writing phase has become so fast that it’s no longer a bottleneck, and all the pressure has shifted to the phase that humans still have to handle—verification. What’s new here isn’t that “AI can write code”; that’s old news. What’s new is the ripple effect: as the cost of generating code approaches zero, all the unspoken conventions in the process—which were based on the assumption that “writing code is the most expensive part”—collapse simultaneously.

The bottleneck hasn't gone away; it's just shifted.

A production line moves only as fast as its narrowest bottleneck. For twenty years, the bottleneck in software development has been turning intent into executable code, so everything has been optimized for that stage: smarter IDEs, more readily available frameworks, and sprints divided by “story points.” Starting in 2026, that bottleneck will widen almost infinitely—a single engineer can run three or four agents in parallel across four branches, with each branch producing a complete diff in a few dozen minutes. But the next step—reading that diff and trusting that it’s correct—still operates at the biological speed of a human brain.

The most obvious symptom is the presence of two conflicting figures in the same report: the median review time has increased significantly, while the percentage of PRs merged without being reviewed has also risen. This isn’t a contradiction—it’s two different ways of responding to the same pressure. Teams that enforce discipline see their review queues balloon; teams that can’t handle the pressure open the floodgates, and code that no one has read flows straight into the main branch.

Why is code written by an agent harder to review than code written by a human?

The common assumption is: code is code; it doesn’t matter who writes it. Wrong. There are several differences in how the review process works, and it’s significantly more expensive.

• The decision trail is lost. When a colleague writes a function, they bring with them a chain of choices: which approaches they tried, which they discarded, and why—and the review process involves probing that chain. The diff from the developer reaches you in its final state, without any context; the reviewer must reconstruct the intent from the ticket and the code itself—essentially doing the hardest part of the design, but in reverse and after the fact.
• Wrong code looks like correct code. Human errors are exposed on the surface: poor naming, messy structure, missing branches—exactly the signals reviewers have learned to spot at a glance. Code generated by a model is smooth, well-named, and fully documented; it looks correct even when the semantics are wrong. It disables the very sensors that engineers have spent their entire careers honing.
• Masking errors instead of handling them. Repository analyses in 2026 point to a sharp rise in the “error masking” trend: agents often wrap a broad `try` block and swallow exceptions just to get tests to pass. Later on, no one knows which error-handling sections were intentional and which were merely meant to appease CI.
• Less reuse, more rewriting. The same analyses show a marked decline in the rate of “calls to existing functions” in new commits: agents often generate a local copy instead of looking for what already exists. Individual diffs are concise, but the codebase swells with many nearly identical versions—a debt that only becomes apparent when a single bug must be fixed in all six places.
• Diffs are too large. Because it’s cheap, the agent often does more than required: formatting cleanup, renaming variables, adding tests to unrelated sections. The reviewer is faced with 900 lines, but only 40 require thoughtful consideration.

All in all: the unit cost of reviewing a line of code written by an agent is higher than that of a line written by a human, while the number of lines that need to be reviewed has increased severalfold. That’s a recipe for a backlog crisis.

New Process: Specs as the Single Source of Truth, Code as a Derivative Product

The trend taking shape most clearly in 2026 is spec-driven development. The original idea isn’t new, but the reason it’s resurging is: agents are very good at writing code but terrible at guessing intent. If intent exists only within a conversation—vanishing once the chat window is closed—then every time the code runs, it has to guess all over again.

So teams should reverse the order: the specification is the asset that is saved, reviewed, and versioned; the code is what is generated from the specification and can be discarded and regenerated. By 2026, most major AI-powered programming toolkits will have released their own versions of this concept—GitHub Spec Kit, AWS Kiro, equivalent mechanisms in Claude Code and Cursor, along with a range of open-source projects like OpenSpec. The details vary, but the framework is the same: requirements → design → plan → execution, with documentation for each step to refer to.

What matters isn’t the file format, but where human effort is invested. A good agent specification isn’t a prose description; it contains elements that machines can verify:

• Invariants: what must always remain true after a change (the balance must not be negative; each order must correspond to exactly one payment record).
• Acceptance criteria can be directly translated into tests—not just “it must be fast and stable.”
• Non-goals: areas off-limits. This is the part most often overlooked and the one that saves the most—if left unsaid, the developer will “casually” refactor the entire adjacent module.
• Change size: one intention, one change. Small diffs aren’t just a matter of aesthetic preference; they’re a prerequisite for a review to be feasible.

In other words, engineers shift from “writing solutions” to “writing definitions of correct solutions”—the part that’s always harder, but has long been overshadowed because the other part takes more time.

Running an agent is like running code written by a stranger

The second line of attack comes from the security side. A code-writing agent doesn’t just generate text: it runs commands, installs dependencies, calls APIs, and reads files. In terms of the threat model, it’s untrusted code running with your privileges, plus a characteristic that processes typically don’t have—it reads external data (issues, websites, package READMEs) and then lets that data influence its next actions. That is precisely the nature of indirect prompt injection.

So by 2026, the industry standard had shifted from “running agents on dev machines” to a single-use, hardware-isolated environment: Firecracker-style microVMs or gVisor-style kernel isolation layers, with one machine per task, which is destroyed upon completion. Accompanying this will be mandatory access control: mount only the directories that are truly necessary, use short-lived keys instead of permanent API keys, use masked copies of data, and all outbound connections must be pre-authorized.

The third gate is at CI, and this is where many teams still let their guard down. Traditional test suites are designed to catch human errors—so they test a few representative examples. Agents are very good at making those examples pass without understanding the problem. For CI to remain valuable as evidence, it must generate results that are difficult to fake:

• Property testing and fuzz testing: verifying that a rule holds true for all randomly generated inputs, rather than just for three known test cases.
• Mutation testing: intentionally corrupting the code to see if the test suite fails—it measures the quality of the tests, which are now largely written by agents.
• Deterministic builds and hash-based dependency locking: Agents adding packages on their own is an everyday occurrence; without locking, the supply chain surface area expands after every run.
• Traceability: Which agent, which model, based on which spec, in which sandbox. When an issue arises six months later, this is the only way to determine “who made this decision.”

Economics Corner: The unit of cost has changed

The unit of measurement for software costs has always been, by default, a line of code written, because that is where the actual wages go. Starting in 2026, the cost of writing a single line of code will drop to a level measured in cents, while the cost of verifying and taking responsibility for that line will not decrease—it will actually increase, because the code is harder to review. The true unit of cost has therefore shifted to a change that has been verified and deployed into production. The consequences are very specific:

• Cost savings in the coding phase are easily swallowed up in later stages. If a senior engineer—the most expensive member of the team—spends most of the day reading and fixing agent code, the costs merely shift; they don’t disappear. Some teams have observed this very paradox: throughput looks great on the charts, while the number of hours spent on rework and issues also increases.
• Technical debt changes form. The old kind of debt is bad code that everyone can see. The new kind is code that looks good but no one really understands, is repeated in many places, and is littered with meaningless error messages. It doesn’t cause immediate problems, so it isn’t prioritized for repayment—and therefore ends up costing more.
• The labor market is skewed toward experience. The tasks that entry-level engineers used to do to learn the ropes—fixing minor bugs, writing CRUD code, integrating a few APIs—are precisely the tasks that agents can do most cheaply, so demand has shifted toward roles requiring judgment. This is a time-lagged problem: cutting the lower tier today means cutting off the supply of the upper tier in 2032, while the benefits are seen immediately this quarter. Everyone sees this, but the incentive for each individual company remains to cut.
• There’s no escaping responsibility. No vendor guarantees the model’s output. Legally and operationally, the person who hits the “merge” button is the one on the hook—a process that doesn’t generate verifiable evidence is shifting risk onto their own team without documenting it.

What has the programming profession actually become?

It’s not that “engineers have disappeared,” nor is it that “engineers now just sit around reviewing code.” What has changed is the balance: four tasks that previously accounted for a small portion of the day have now become the main components—specification (turning vague requirements into verifiable constants), verification (building a robust test suite so that the CI “green” light is meaningful), architecture and boundaries (agents perform well within narrow, well-defined scopes, so clean contracts between modules become more valuable), and failure handling (reading logs, reconstructing the causal chain, deciding on a rollback—the area where agents are weakest). A pleasant paradox: this has always been the true “technical” aspect of software engineering, but it has long been overshadowed by the manual work of writing code.

Prediction

• Team metrics have been redefined around the verification process. Feature branch throughput is no longer used as a metric; instead, we will focus on the time from spec to verified code deployment, the rework rate for PRs created by agents, and the rate of merges that bypass review.
• Reviews are split into two tiers. Low-risk changes pass through an automated gate (property tests, mutation tests, static analysis, and independent agent reviews); human review is focused on high-risk areas: security, money, data migration, and inter-module contracts. “Merge first, review later” is common where rollbacks are inexpensive and ineffective where they aren’t.
• Sandboxes are the default infrastructure. Running agents directly on dev machines with full privileges is viewed as running an untrusted binary with root privileges—some people still do it, but it’s no longer acceptable.
• A wave of maintenance issues is on the horizon. Code generated in large volumes during 2025–2026 will reach the point where it needs to be fixed in 2027–2028, in repositories where no one still maintains the original intent. Teams that preserve specifications and provenance will pay a much lower price than teams that only preserve the code.
• The pressure is shifting back toward hiring. After a few quarters of seeing verification costs fail to decrease, some companies will start hiring at the entry level again—with a different job description: entering the field through reading, testing, and operations, rather than writing the first lines of code.

In short: 2026 isn’t the year software is written by machines. It’s the year the software industry realizes that writing code has never been the most expensive part—just the most visible one. As that part becomes cheaper, what remains is revealed: a system that is only as reliable as the evidence we have about it.