The pitch for agent-driven development is simple. The agent writes the code, so the team ships faster. Point it at a ticket, it produces a working change, a human signs off, the change merges. The slow, manual part of building software gets handed to a system that works at machine speed.
Teams adopt it expecting the calendar to compress. Some of that compression is real. But the lifecycle doesn't shrink the way the pitch implies, because writing the code was never the only thing the lifecycle was waiting on. When an agent absorbs the authoring, the constraint that used to sit there doesn't vanish. It moves to whatever the authoring was hiding.
That relocation is the frame worth holding onto. Agent-driven development doesn't remove the bottleneck in the software lifecycle. It changes where the bottleneck lives, and the new location is the part most teams haven't reorganized around.
What the agent takes over
For most of the lifecycle's history, the rate-limiting step was a person translating intent into working code. Design discussions, tickets, and architecture decisions all funneled down to someone sitting at a keyboard turning a description of the desired behavior into syntax the machine would run. That translation was slow, and because it was slow, it set the pace of everything downstream of it.
Agents are good at exactly that translation. Given a clear enough description, an agent produces a plausible change in the time it takes to read the ticket. The step that used to govern the schedule stops governing it.
When the slowest step in a process gets faster, the schedule doesn't get proportionally faster. It gets bounded by whatever was the second-slowest step, which now becomes the slowest. The interesting question about agent-driven development isn't how fast the agent writes. It's what the agent's speed exposes on either side of it.
The work moves upstream
The first thing it exposes is specification. An agent produces output against the description it's given, and the quality of that output is mostly determined before the agent runs, by how precisely the intent was stated. Vague intent in, plausible-but-wrong code out. The work of being exact about what you actually want, which edge cases matter, which invariants must hold, which existing patterns to follow, used to be partly absorbed into the act of writing the code, where a careful engineer would notice the ambiguity while implementing and resolve it in their head.
With the implementation handed off, that resolution has to happen explicitly and up front. The ambiguity an engineer would once have caught mid-keystroke now ships, because the agent doesn't pause to ask what a careful person would have asked. Specification stops being a preamble to the real work and becomes a large share of the real work.
Upstream isn't where the squeeze concentrates, though, and the reason is worth being explicit about rather than waving past. A vague specification doesn't stay upstream and cost the person who wrote it. Its cost travels. The agent confidently builds the wrong thing, and the error surfaces downstream, where a reviewer either catches it or it reaches the running system. Getting better at specification reduces how often that happens. It doesn't change where the failures land when it does, and it doesn't move the place all of this converges. Both relocation sites empty into the same one. What the specification pinned down and what it left ambiguous both arrive, in the end, at the same human who has to verify the change is right. That's why the constraint is worth following to the far side of the agent.
The review bottleneck
When generating a change becomes cheap, a team can produce far more change than before in the same window. Every one of those changes still has to be understood, checked against intent, tested, and judged safe to merge by a human who's accountable for the result. That verification is still moving at human speed. The volume of work arriving at it is not.
This is the condition that defines agent-driven development in practice. Throughput stops being limited by how fast anyone can write code and starts being limited by how fast humans can verify it. Call it the review bottleneck. It's the structural fact that the team's output is now gated by its verification capacity rather than its authoring capacity, and verification capacity is the thing nobody scaled up when they adopted the agent.
The obvious objection is that review isn't new. Teams have done code review for decades. That's true, and it's also why the change is easy to miss.
What's new is the breaking of a coupling. Review used to be human-paced on both sides. The rate at which changes arrived for review was bounded by the same human speed that bounded writing them, so one reviewer could roughly keep pace with one author without anyone designing it that way. That balance wasn't a process someone chose and tuned. It was a property of everyone working at the same speed, and it's what made review feel like a step the work passed through rather than a place the work piled up. Agents break it. The authoring side jumps to machine speed while the reviewing side stays exactly where it was, still bounded by how fast a human can read a change and stand behind it. The ratio that quietly held the lifecycle together comes apart, and review stops being a step and becomes the place the work waits.
Consider a platform team at a mid-size fintech that lets agents open database migration changes, but keeps a standing rule that no agent-generated schema change merges without a named human reviewing it line by line. The rule is sound. It also means the team's real throughput on migrations is set entirely by how much one accountable person can carefully read, no matter how many changes the agents produce. The agent didn't make migrations faster. It made the reviewer the bottleneck and put a name on exactly where the limit sits.
What this changes about the work
Once the constraint sits at specification and review, the shape of the developer's job changes with it. The center of gravity moves away from authoring, which the agent now does, toward defining the work precisely enough that the output is right, and verifying the output well enough to be accountable for it. Writing was the visible craft for decades. It becomes the part that's delegated, and the parts that used to bracket it become the job.
That has an organizational consequence teams tend to discover late. A team that's structured, measured, and staffed around how fast it can write code is optimized for the step that's no longer the constraint. The capacity that now governs throughput, careful specification before and careful review after, is usually nobody's explicit responsibility and shows up on no dashboard. The work happens, distributed across whoever has the context, the same way it always did when it was a small share of the effort. It's now the large share, and it's still being treated as overhead.
The teams adapting well are the ones treating verification as a first-class part of the lifecycle, with owners and capacity planning of its own, rather than as the quick sign-off it used to be when changes arrived at a human pace. They're building review tooling, defining what good specification looks like for their codebase, and deciding deliberately which classes of change a human must read versus which can clear on tests alone.
What still isn't standard is measuring the constraint that now sets the pace. The instrumentation built up over years tracks how fast code gets written. Cycle time on authoring, commits, velocity. Almost none of it tracks how fast change gets verified, which is the number that now determines how fast anything actually ships. The teams that have started looking are watching things the old dashboards never named. How deep the review queue runs, how long a change sits between generation and merge, how many agent-opened changes land on a single reviewer in a week. Most teams keep optimizing the step the agent already made fast, because that's the step they know how to measure, and the queue builds at the step they don't. The bottleneck moved. The dashboards didn't.
Agent-driven development is usually sold as a way to remove the slow human step from building software. What it does instead is shift which human step is slow. The writing gets fast. The specifying and the verifying don't, and they're now what the schedule waits on. The teams that get the most out of it aren't the ones whose agents write the most code. They're the ones who noticed where the constraint went and rebuilt around it before an incident forced the conversation.