Your AI coding gains are stuck before the code is even written

At some point this year, you likely approved a request to expand AI coding tool access across the team. The pitch was straightforward: engineers write code faster, the team ships more, the investment pays for itself.

The first half happened. Engineers are writing code faster. If you're now being asked whether the investment paid off, and you're finding the honest answer is more complicated than a yes, you are not alone, and you have not been sold something broken. You've run into a pattern that shows up almost everywhere this gets tried.

Where the gain actually goes

Key takeaway: Writing code was always the bottleneck, which is why teams built so much process around planning and specs before handing work to engineers. AI removed that constraint, but the rest of the SDLC wasn't rebuilt to match, so the individual gain gets absorbed by the queue instead of reaching the team

Writing code has always been the real constraint on how fast a team could ship. That's why so much of the old SDLC was built around planning and specs before implementation ever started, engineers were expensive, and changing code once implementation began was slow and costly, so teams tried to get everything right on paper first. 

AI has genuinely removed that constraint. Code gets written fast now, and changing it is cheap. What hasn't changed is everything downstream of it: review, approval, making sure a change is safe to release. The constraint didn't disappear. It moved.

That has a specific, predictable effect. More code moves into review at a higher rate, and the number of people doing that review, and the pace at which they can do it, hasn't changed. The queue absorbs the difference. A senior engineer who used to clear a manageable stack of pull requests each day is now looking at meaningfully more, much of it written by a model rather than a colleague they can walk over and ask a question.

The individual gain is real. It just doesn't reach the team level, because it gets spent entirely on absorbing a bigger queue rather than on shipping something new.

Why this isn't a tooling problem

Key takeaway: The review process was built for human-paced authorship. AI-generated code breaks that assumption, and no tool fixes a process that was never redesigned to match.

The instinct, understandably, is to look for a better tool, or tighter rules on what engineers can generate, or more reviewers. None of that addresses the actual mechanism.

The real issue is that the review and approval process your team already has was built for a world where a human wrote every line, at a human pace. That process assumed a certain relationship between the person writing the code and the reasoning behind it. AI-generated code breaks that assumption without anyone deciding to change the process to match.

This is an organizational design question, not a tooling one. Who reviews what, how much scrutiny a given change actually needs, and where a decision genuinely requires a person versus where it doesn't, none of that was rethought when the volume changed. It's still running on the assumptions that were true before AI tools arrived.

What this actually asks of you as a leader

Key takeaway: Three deliberate changes, all upstream of code: making specs carry the clarity a human used to supply informally, bringing non-engineers into the definition stage rather than just review, and treating the cost of a late change as the number that matters.

The old fix for this lived downstream, in review and approval. The real fix now lives upstream, before code gets written at all.

• Make specs do the work a human engineer used to do informally 
  An engineer working from a vague ticket used to fill the gaps through judgment and a Slack thread. An agent working from the same ticket builds exactly what's written, ambiguity included. Spec quality that used to get quietly corrected in conversation now has to be explicit from the start.
• Get non-engineers into the definition stage, not just the review stage 
  Product, security, and design showing up after code is written is a habit left over from when writing code was slow enough to leave room for that. If a decision belongs to someone outside engineering, it belongs earlier in the process, not as a final sign-off.
• Treat the cost of a late change as the number that actually matters 
  The old constraint was how long code took to write. The new one is how expensive it is to redirect work that started from an unclear spec. That's the cost worth measuring and reducing, not review throughput.

The honest version of this advice is that fixing the process costs something now, in exchange for not paying a larger, less predictable cost later, once the backlog and the trust gap have both grown past the point where a deliberate fix is easy.

This pattern, individual speed outpacing team-level delivery, is the starting point for a broader framework worth understanding.  

Read the 8 stages of AI engineering maturity to see where your team actually sits and what tends to happen at each stage from here.

Frequently asked questions (FAQ)

Why didn't AI coding tools make our team faster overall, even though individual output clearly went up?  
Because AI removed the bottleneck that used to justify so much upfront planning, writing code got fast, and cheap to change, but review, approval, and release readiness didn't speed up with it. The individual gain gets absorbed by the queue rather than reaching team-level delivery

Is adding more reviewers the right response to a growing backlog?  
Usually not on its own. A growing backlog is a symptom. The cause usually starts upstream, in specs that weren't clear enough for an agent to build from correctly the first time. The more durable fix is catching that ambiguity before code is written, not adding people to catch it after.

How do we know if this is happening on our team specifically?  
The clearest sign is a growing gap between how fast engineers report they're working and how fast features are actually reaching production. If that gap exists and nobody can explain it with a number, it's worth investigating before assuming the AI investment isn't working.

Where does a platform like Upsun Dispatch™ fit into this?  
Upsun Dispatch is built around the idea that the workflow, not any individual tool, is the thing worth designing deliberately: where a human decision is required, who makes it, and what gets recorded when they do. It's one way to make the organizational choices above concrete rather than aspirational.