Why teams with AI tools don't ship faster
Abstract. Most companies add AI to the way they already work. The code gets written faster, and then it waits.
Most companies are trying to fit AI into the way they already work. That is the problem.
Goldman Sachs put a name on it back in 2024 with a report titled “Gen AI: too much spend, too little benefit?” The tools have improved a great deal since then, and in many engineering teams the question still stands. Everyone has a license. Code gets written faster than ever. The release cadence looks the same as it did before.
The bottleneck was always there
I hear a version of the same question from engineering leaders, from people I interview, and from the teams I’ve led: AI is great, but now we suddenly have a code-review bottleneck. How do we fix that?
That question reveals the core issue. The bottleneck didn’t appear because of AI. It appeared because the process around it was never designed for this volume, this speed, or this way of working.
That’s what happens when you treat AI as an add-on. You get faster output feeding into a system that wasn’t built to handle it. Reviews pile up and ownership gets blurry. Decisions that used to take a day now take a week, because it’s unclear who approves what. The speed is there. The structure to capture it is missing.
You are paying senior rates for it
It’s tempting to see AI tools as a cheap experiment. They aren’t. Earlier this year I ran a frontier model on a real engineering task, and a single prompt cost me €7 to €8. Extrapolate that to sustained work and you’re looking at €100 to €200 an hour. That is a rough estimate, and it is also the hourly rate of a very senior engineer.
Nobody would hire a very senior engineer and then let their work sit in a queue for a week. With AI, that is what many teams do every day.
It’s the people
Companies ask which AI tools to invest in and how to measure the return on adoption. Those are reasonable questions. I asked the same ones, and I’ve stopped. The tools still matter, but the deciding factor in whether any of it sticks is the people.
I see the same pattern regardless of role. The people who already approach their work with curiosity use AI to learn faster, ask better questions, and push their judgment further than they could on their own. The people who treat their role as a fixed identity use AI to protect it, sometimes by rejecting it outright, sometimes by quietly using it to coast while still looking productive.
AI didn’t create either pattern. It accelerated who the person already was.
That’s why most adoption strategies underdeliver. Companies treat adoption as a tooling problem and end up paying for tools that the culture absorbs, neutralizes, or reshapes into something it can tolerate. Your organization’s reaction to AI is one of the cleanest cultural diagnostics you have right now.
Waiting is a direction too
Engineering teams track risk religiously through post-mortems, rollback plans, and risk assessments. What few track is the risk of doing nothing: the call you delayed until the moment closed, the capability your team didn’t build because the timing felt uncertain. Those losses count. They just don’t appear in incident reports.
When I look at teams that are behind on AI, the story is almost never recklessness. It’s the opposite. Reasonable people make reasonable decisions and wait for more certainty before committing to a direction. Waiting is a direction, even though it may not feel like one.
Caution feels like the absence of risk. It rarely is.
What to do instead
The answer is to rethink how the work gets delivered instead of bolting AI onto the existing process. That sounds bigger than it has to be. You don’t start with the whole organization. You start with one workflow and redesign it from start to finish.
Three things stay permanently human: defining success, approving what gets built, and measuring and steering. Everything else in that workflow is open for redesign.
One condition holds it together: you own what you ship, whether it was written by a human or AI. Tools and processes only work once that is true.
Most teams aren’t ready for that conversation. Letting go of how things have always been done is hard. The pull back toward familiar processes feels safe, and that’s what makes it dangerous.