Board 9 min read

ADLC: more code from AI doesn't mean more software shipped

Serhii Horstka

When more output creates more work

Notebook page showing how AI writing more code creates a review bottleneck, illustrated as a pipeline where code output outpaces human verification.

Your AI writes a proposed code change in the time it takes to make coffee. You come back to a queue of changes waiting for someone to read, understand, and approve them. The team moves faster on paper and slower in practice.

This is the central tension in agentic development, and it has a number attached. RealClearMarkets covered a study in October 2026 that found the efficiency gains AI agents bring to writing code are fully absorbed at the human review stage. Producing more code does not translate into shipping more software. (RealClearMarkets)

Researchers in a September 2026 arXiv paper named the pattern the Verification Tax. Writing code faster does not help when verification, review and testing remain the binding constraint on delivery. (arXiv)

This is a practical observation about pipelines, and it points directly to the fix. Add agents to the writing stage without changing the review stage, and you have not redesigned your process. You have added pressure to the part that was already the bottleneck.

What the agentic development lifecycle actually is

The software development lifecycle, or SDLC, is how a code change travels from an idea to something that ships. A description goes first, then the code, then a review, then an approval. For most of computing history, humans did all four jobs and moved at roughly comparable speeds. The reviewer was never waiting for a hundred changes at once.

The agentic development lifecycle, or ADLC, is what happens when AI agents join that sequence. An agent can produce a proposed change in seconds. Another can run a first automated pass before a human sees anything. The sequence on a whiteboard looks the same. The speeds at each stage are not.

Think of a restaurant kitchen where one cook used to both prepare and plate every dish. The preparation was the slow part. You add a machine that prepares dishes ten times faster. If the same cook still has to plate each one by hand, the kitchen does not go ten times faster. It produces ten times more half-finished dishes waiting at the pass.

When humans wrote all the code and one proposed change a day was considered productive, a single reviewer could keep up. When an agent writes ten proposed changes before lunch, the same reviewer is lost before lunchtime ends. The bottleneck moved to review.

The ADLC is a different lifecycle. The old assumptions about pace and balance no longer hold. The fixes that worked for a slow SDLC do not scale to an ADLC.

Last time we looked at how a vague brief causes an AI to write the wrong code at speed.

What a study found when it measured the whole pipeline

A four-stage pipeline showing Spec, Write, Scan, and Approve, with the control point moved upstream before any file changes.

SD Times reported in 2026 that once agents generate most of the code, reviewing every line of every proposed change stops scaling. (SD Times) A human reading every agent-generated change in detail is the same cook plating every dish by hand. The output accumulates faster than the reviewer can process it.

The recommendation that follows is to move the control point upstream, to before files change, rather than after. A design decision caught in a one-page description costs almost nothing to fix. The same decision caught after a thousand lines of code exist costs a great deal more. There is always a pull to keep the code because it is already there.

That insight shapes the four stages of a working ADLC.

The four stages of a working ADLC

1. Spec first, then code.

Before any file changes, a human approves a written description of what the change needs to do. This is the spec, and it is the anchor for every step that follows. The software engineering body of knowledge, SWEBOK, covers verification and validation as a distinct discipline. Checking requirements, reviewing them, and confirming they are complete is work that must be resourced separately from writing code. It is its own engineering activity with its own quality criteria.

A spec approved before the agent starts is the cheapest place to catch a wrong assumption. If the spec says "show the last ten orders for this customer", the agent has a concrete target and the reviewer has a concrete reference. If the spec says "improve the orders page", the agent has a guess and will work quickly on the wrong thing. The spec does two jobs: it constrains what the agent produces, and it gives the reviewer something to check against.

2. Write the code from the spec.

The agent works from the approved spec. Because the target is fixed, the proposed change is more likely to match what was intended. This is the fast stage, and it is the whole reason agents are useful here. It is also the stage that creates the problem when the rest of the pipeline is not ready for it.

A growing record of past mistakes, read by the agent before it starts planning, helps close the gap. An agent that knows what went wrong in previous changes avoids at least some of those errors. The record grows over time. Early entries might be small things: a variable named inconsistently, a boundary check omitted. Over several months, the record reads like a project's accumulated experience, and the agent's first proposals become measurably closer to what gets approved.

Surgeons use checklists because they work. The same logic applies here.

3. Automated first-pass review.

A separate agent, or a plain script that accepts the proposed change and checks it, runs before any human sees anything. It looks for known error patterns, confirms the change stays within the scope the spec describes, and flags anything that needs a person's time.

OWASP's guidance on AI applications names agents given more permissions or autonomy than their task requires as a specific security risk. An automated first-pass review that checks whether a proposed change stays within its expected scope catches that problem early, before a human approves it. The human does not read everything. The human reads what the automated check could not resolve, which is a much shorter list.

4. Human approval for changes that carry real weight.

A change to a comment in the code carries different weight than a change to how a user's payment information is stored. A well-designed ADLC routes only the changes that need judgment to a person, with the automated review's findings already attached. The human makes a decision with context, on things worth deciding.

This is where the pipeline pays off. The human is the final check on changes that could genuinely go wrong. That is a narrower job, and it scales.

Why the writer and the reviewer must be different

Notebook page showing why a separate reviewer catches gaps a writing agent misses, and how a spec plus mistake record shorten review cycles.

The agent that writes a proposed change should not be the one that checks it. A student marking their own exam will miss errors they introduced themselves. Their eyes fill in what was intended.

The same happens with AI agents. An agent that wrote a change is working from its own understanding of the spec. When it reviews that same change, it checks whether the change matches its understanding. It will miss the gap between its understanding and the spec's actual meaning. A separate reviewer, working from the spec, is more likely to catch that gap.

Keeping the writing and reviewing steps separate is what makes this pipeline safe to run at speed. The writing agent focuses on producing a change that matches the spec. The reviewing agent or script focuses on checking that the change does what it claims. They have different inputs, different jobs, and different failure modes.

This matters more at scale. One agent writing one proposed change a day is manageable even if the review is informal. One agent writing fifty proposed changes a day with no separate review is a liability. The point at which the separation becomes necessary arrives faster than most teams expect.

SD Times put it clearly: once agents generate most of the code, judgment must move upstream. A design problem found in a one-page spec is cheap to fix. The same problem found in a thousand lines of existing code is expensive. There is always a temptation to keep the code because it already exists.

Giving the agent a target and a memory

Two things consistently bring the quality of an agent's first proposal close enough to the target that review is fast.

The first is the approved spec. The agent fills in a known shape rather than guessing at intent. The reviewer checks a change against an agreed description. Both are working from the same reference, and gaps between intent and output become visible.

The second is the record of past mistakes. An agent that reads what went wrong on previous changes, before it starts planning, brings that context into its proposal. The record is not complicated to maintain. It is a list, updated after each review cycle, of things that were wrong and what was expected instead. It grows more useful the longer a project runs.

Together, these two inputs shift the agent's starting point. The first proposal arrives closer to what will be approved. The review cycle is shorter. The human's attention goes where it is actually needed.

In my own projects, I combined an approved spec with a pre-planning check of past mistakes before each change. The proposed changes that reached human review were closer to what was intended. Review time went to decisions that needed real judgment. Avoidable errors were caught earlier in the process.

The short version

Adding agents to the writing stage does not automatically speed up delivery. The verification, review and approval stages must scale with the code output, or the pipeline just has a bigger queue at a different point.

A working ADLC has four stages. First, a written spec approved before any files change. Second, the agent writes from that spec, guided by a record of past mistakes. Third, a separate agent or script runs a first-pass automated review. Fourth, a human approves changes that carry real weight. The writer and the reviewer stay separate. Judgment moves to the earliest possible point.

Speed up the writing and you have to speed up the checking too. The two move together, or the second swallows the gains from the first.

What does your current review pipeline look like, and where does the work pile up most?

Sources

The post on one page
The post on one page