Leadership1 publisher3 min readPublished
Faster AI-written code pays off only where writing was the bottleneck
Only 31% of technical leaders in a CloudBees survey could tie AI spending to a business result, Sivense founder Illia Smoliienko writes in Forbes. He argues that a team that has not timed where its work waits cannot tell whether the tools sped up the stage holding it back.
The Board Room · Leadership desk
What happened
- Illia Smoliienko, founder of Sivense, argued in Forbes that managers should find their engineering bottleneck before scaling AI coding tools across a whole team.
- A 2026 CloudBees survey of more than 200 technical leaders found 67% saw a significant rise in code volume, while 52% saw a matching rise in output.
- According to Smoliienko, the companies CloudBees surveyed rated their ability to measure returns as their strongest trait.
- He recommends timing every stage from task taken into work to feature in production, for active and waiting time, then focusing effort on the slowest one.
Compiled by The Board RoomSomething wrong?How this is made
Why it matters
- decision Scaling the tools without naming a target stage leaves that choice to whoever adopts first. The stage they speed up may not be the one delaying releases.
- cost When review absorbs the minutes authors save, the engineers who approve code pay for faster generation with more of their own time.
- exposure AI budgets justified with code-volume charts are open to challenge once finance asks for business results that most surveyed leaders say they cannot show.
The board-deck version of an AI coding rollout is a slide showing more code, more tasks and more pull requests. Smoliienko expects a manager looking at that slide to conclude that AI has boosted productivity [2]. The slide is incomplete because everything on it is output from one stage of delivery. He replaces it with a narrower question: "Has the stage that truly held the team back actually sped up?" [3]
The CloudBees figures put a size on that gap. The share of leaders who saw output rise trailed the share who saw code volume rise by 15 percentage points [11]. Some 69% of respondents could not tie their AI spending to a business result [12]. These are shares of people reporting what they observed. They are not measurements of throughput.
Smoliienko puts the lost time in review. DORA, Google Cloud's research program, reported in 2025 that more than 80% of surveyed technology professionals believed AI made them more productive [4]. He reads the same report as showing that the time saved creating code is spent reviewing it. A developer produces a large piece of code in minutes, and the reviewer works at the same pace as before [5]. "One person's gain becomes another's burden," he wrote [7]. One respondent said: "I feel somewhat more productive, but it's at a cost." [6]
A skeptic would say that more than 80% of professionals reporting a gain is reason enough to hand the tools to everyone. My answer is that the figure records belief, reported by people describing their own work. The cost shows up further down the line: in review for some teams, and in testing, security or release for others [16]. Fred Brooks made the older version of this point in 1987, when AI was already among his candidates for a "silver bullet": "the hard thing about building software is deciding what one wants to say, not saying it." [13]
This quarter, the trade-off is between time spent on diagnosis and adoption that is already happening. Smoliienko wrote that developers often pick up tools on their own, each for their own tasks, and nobody decides which stage to speed up [14]. Timing each stage for active and waiting time costs a manager attention now [15]. It also gives the team a baseline. A team that scales the tools first will have next quarter's delivery numbers but no record of where work waited before. It will not be able to say whether the tools moved the constraint or only raised the code count.
In my view, the case for measuring before scaling holds up on this evidence. The column does not report which stage most often turns out to be the constraint, and neither survey, as cited, breaks its results down by stage. Smoliienko puts the weight on the manager: "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," he wrote [17].
What to watch
- Whether DORA's next report pairs self-reported productivity with measured review time or delivery throughput.
- Whether CloudBees or other surveys break code-volume and output results down by delivery stage.
- Whether teams that timed their stages before rollout report different delivery results from teams whose adoption was spontaneous.