​Before Scaling AI Coding Tools, Find Your Engineering Bottleneck

Illia Smoliienko is the founder of Sivense and an expert with over a decade of experience in industrial IoT and predictive maintenance.

​AI has done exactly what was expected: Code has started appearing faster. However, code is the output of a single stage, whereas a team’s result is a feature that has reached production and delivered value. Speeding up the former doesn’t guarantee the latter.

This is where the core management problem arises. A manager might see more code, tasks and pull requests and then conclude that AI has boosted productivity. However, these metrics still don’t answer two questions: Has the stage that truly held the team back actually sped up? Has the outcome for the user or the business changed?

I’ll break down why higher output doesn’t always lead to an outcome and how managers can find their bottlenecks before scaling tools across the whole team.

Which Part Of Developers’ Work AI Has Sped Up

When Fred Brooks analyzed candidates for the role of a “silver bullet” for development in 1987, AI was already among them. Brooks didn’t deny AI’s usefulness, but he doubted it could radically increase development productivity and software quality. He explained that “the hard thing about building software is deciding what one wants to say, not saying it.” Speeding up expression itself doesn’t remove the main difficulty and yields only a marginal gain.

Forty years later, we have a tool that speeds up expression. What results has it brought us?

According to a 2025 report published by DORA, Google Cloud’s research program, over 80% of surveyed technology professionals believed AI made them more productive. For writing code, however, this productivity has a flip side: The time saved on creating code is spent reviewing it.

A developer generates a large piece of code in minutes, but the engineer reviewing it works at the same pace as before. One person’s gain becomes another’s burden. As one respondent put it: “I feel somewhat more productive, but it’s at a cost.”

Review is just one of the stages where speed gains get canceled out. In another team, work might slow down at testing, security or release. Whatever the stage, writing code faster still doesn’t mean the whole path from task to production has shortened.

Why AI Doesn’t Result In Local Acceleration For The Team

I think the greatest return from AI in development depends less on choosing the right tool and more on how clearly a manager sees the team’s processes. If they don’t see the team’s work as a system, they make two mistakes.

First, they roll out AI without any diagnosis. AI often appears in teams spontaneously; developers adopt tools, each for their own tasks. No one decides which stage to speed up or how—the direction just shapes itself. The tool ends up accelerating not what’s holding the team back but whatever gave way first.

This is hard to notice because from the outside, everything looks like progress. People are busy; there’s more code. However, speeding up a stage that wasn’t the constraint doesn’t make the overall work any faster.

Then, they measure output instead of outcome. It seems logical to judge work by tasks completed and code written. With AI, though, activity grows on its own, while the result (what reaches the user) doesn’t keep up.

In a 2026 CloudBees survey of over 200 technical leaders, 67% reported a significant increase in code volume that year, but only 52% saw a corresponding increase in output. What’s more, only 31% could tie their AI spending to a concrete business result. Ironically, the ability to measure returns is what these companies rated most highly in themselves.

These mistakes reinforce each other. The manager doesn’t know exactly what’s slowing the team down, and the metrics don’t help them figure it out.

How To Understand What’s Slowing The Team Down

It’s not enough to look at how busy people are or how much code gets written. You need to see the task’s entire path to production. Three actions help find what’s limiting the team’s speed.

Break down the task’s path.

Walk the whole route from “task taken into work” to “feature in production,” and for each stage, measure active working time and waiting time. This isn’t about diagnosing flow; it’s about turning the vague feeling of “we’re slow” into a concrete picture of the delays.

Focus on the slowest stage.

Now, it’s clear where the task gets stuck the longest. This is your real constraint, and that’s exactly where the team’s attention and effort should go. You can speed up the other stages, too, but by Amdahl’s law, the gain can’t exceed the share of time that stage takes. If a stage is a tenth of the path, then even cutting it to zero shortens the path by a tenth at most.

Determine what exactly needs to change.

Finding a bottleneck doesn’t necessarily mean it should be automated with AI.

If work piles up at review, the questions aren’t for the developers but for the review process itself. Who conducts it? By what rules are they conducting it? Are the volumes submitted for review too large? If work gets stuck at the requirements stage, AI will only do the wrong thing faster. It will confidently and neatly implement a poorly defined task.

You must first understand the nature of the constraint. Only then can you choose the tool. Often, you need to improve the workflow, not speed it up.

In the context of AI adoption, one of a leader’s key tasks is ultimately to understand the entire flow—where work waits and why. You can test yourself with a simple thought experiment: If the team started writing code twice as fast tomorrow, what would become the next constraint? If the answer is obvious, you have a hypothesis about where to look next. If not, it’s too early to scale AI for the sake of speed alone.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?