The Delivery System Has Three Stages

It helps to stop thinking about "writing code" and start thinking about the whole path that turns an idea into something running in production. That path has three stages, and they sit in a loop that feeds the next round of work.

Each stage has an owner, and any of them can be the bottleneck. That was easy to ignore while all three moved at roughly the same speed, which until recently they did.

Planning: Turning Intent Into Ready Work

Planning is where the team turns intent into work that can safely move through the system, which is a much bigger job than grooming the backlog on Tuesday. Good planning settles a few things before anyone writes a line of code: the smallest useful slice, what must not change, and what rollback looks like if the slice turns out to be wrong. It also decides what "done" means before a pull request forces the question.

In the old model, slow execution often hid weak planning. If it took two weeks to build something, leadership had two weeks to clarify requirements, notice the gaps, and change direction before much was wasted. The slowness was painful, but it bought time to think.

AI removes that buffer. When the implementation lands the same afternoon the ticket was picked up, nobody got the two weeks, and it turns out nobody decided the boundary of the change either. The work moves fast and lands in the wrong place, or in three places at once, and planning becomes the bottleneck precisely because execution stopped being one. Vague work used to stall long enough for someone to notice it was vague. Now it reaches production on the same schedule as everything else.

Execution: The Part Everyone Notices

Execution is where AI is most obvious, and it's the first thing people point to when they talk about productivity: the generated test suite, the migration script, the API client nobody had to write by hand. The individual contributor got an amplifier, and the amplifier is good.

Faster execution is great. The trouble is that most teams treat faster code production as the whole win, when it's one stage out of three. If execution speeds up while validation stays the same, the extra work piles up in pull request review, in the test pipeline, and in a deployment approval that sits until somebody feels confident enough to ship it.

Validation: Where the Constraint Actually Lives

Validation covers everything between a finished change and a customer who depends on it, from pull request review and the test pipeline to whether anyone watched production after the release. This is where AI-assisted execution does the most damage. A developer can now produce far more change, and a human still has to understand, test, and own every piece of it.

Pull request review is where it hurts first, because reviewers are reading code that may have been generated faster than its author can explain it. That quietly changes what review is for. The old question was whether the code was acceptable. The question now is whether the team understands the change well enough to own it in production, and that bar gets harder to clear as the volume of change climbs.

The IC-Plus-AI Model: Faster Locally, Slower Globally

The most common way teams adopt AI is also the simplest. Every individual contributor gets an AI tool, execution accelerates, and planning and validation are left alone. Up close the team looks more productive, and as a whole it gets less stable.

Two queues form. The first is work waiting to be clarified, because leadership can't shape intent as fast as developers can now consume it. The second is finished work waiting to be reviewed and deployed, because the safety system still runs at its old speed.

The team is busier than ever and shipping no faster.

That one lands on leadership. When developers run out of ready work, the gap is in how intent gets turned into tickets someone can pick up, and slow execution spent years papering over it.

Leadership Plans With AI

The move people tend to reach for next is putting one person in charge of the whole flow. The better one is to point AI at the stage that broke first. If developers starved because leadership couldn't shape intent as fast as they now consume it, give leadership the same amplifier. Leadership uses AI to break intent into smaller, better-sequenced slices, surface the risky parts, and write down what "done" means before the work starts.

It works, and it fixes the front of the system. The people who own intent can produce ready work at something close to the speed execution runs, so developers stop sitting idle between tickets.

What it doesn't touch is the back. Faster planning and faster execution now pour into the same validation stage, and review, the test pipeline, and deployment approval all run at the speed they ran last year. You've fixed two of the three stages and moved the whole backlog onto the third, which is where the constraint was always going to end up.

The Evidence Model: Humans Decide, Faster

With the front fixed, the constraint sits in validation, and the last move is aimed there. It's worth being precise about what that means. AI doesn't validate the work or ship it, and a human still owns every release decision. What changes is what that human is handed when they sit down to make one.

Today, approving a change is mostly assembly before judgment. A reviewer pulls up the diff to work out what it touches and what the tests covered. Then they ping the author to ask what rollback looks like. The judgment is quick once the facts are in hand. The gathering is what eats the day, and the evidence model moves it off the human and onto the system.

For that to be trustworthy, the system has to produce evidence a reviewer can check, and "the agent said it passed" doesn't count. So a change arrives with the dossier already attached: a plain-language summary of what the diff does and which services it touches, test results showing what ran and what isn't covered, static analysis and security output, feature flag state, a diff of the deploy config against what is in production now, a stated rollback plan, and, after release, the production health signal tied back to that change. The human reads that and makes one call, whether this risk is acceptable to ship.

Approving risk against clear evidence is a far better use of a senior engineer than running a status-collection service, and you can get there gradually. Start with diff summaries and test coverage, add flag and rollback state later, and keep a human approving the risk the whole time. Where this ends up is a pipeline that still waits for a person, and a person who can decide in a fraction of the time it takes today.

Improve the Loop, Not the Middle

AI-assisted development breaks when teams use it to speed up execution without redesigning planning and validation, and that failure is everywhere right now. The first wave of adoption makes individual developers faster, which is useful, and it also exposes the parts of the team that were already fragile. Planning has to produce smaller, better-shaped work. Execution has to produce changes somebody can explain. Validation has to move from manual inspection to evidence. Skip those and the team builds a bigger pile of work waiting for someone to understand it.

The system was never a developer writing code. It's the whole loop from intent to plan to change to safe production and back again, and if AI only improves the change step, every other step inherits the pressure.

The developer who showed up with three pull requests before the end of the day did their part. Whether any of those pull requests reaches a customer safely depends on the other two stages, and that's the work AI has made urgent.