AI Is Not Extra Headcount
AI is a multiplier, but that phrase only helps if we are clear about what is being multiplied.
The headline numbers make it easy to reach the wrong conclusion. An analysis of 2,172 developer-weeks found that heavy AI users produced 14 times more commit activity than non-users, while regular users opened 3.7 times more pull requests. Read as productivity, those numbers make an AI license look like several additional developers.
The same analysis becomes more useful when it compares developers with their own performance from the previous year. Regular AI users improved by about 25 percent. The much larger activity gap also included differences in experience, company environment, codebase access, and the kind of work happening during periods of heavy AI use.
AI was part of the gain, but it did not create the entire gap. It multiplied developers and teams that were already working under different conditions.
The result changes with the work
Section titled “The result changes with the work”Controlled studies give us a better view of what AI contributes.
Three randomized field experiments involving 4,867 developers found that developers with access to an AI coding assistant completed about 26 percent more tasks. The experiments took place at Microsoft, Accenture, and another large company, and the tool primarily supplied code completions. Less-experienced developers adopted it more often and received larger gains.
A separate randomized study of 96 Google developers found that AI reduced the time spent on a complex enterprise task by about 21 percent. The confidence interval was wide, but the direction was positive. Developers who spent more of their day working with code received the larger benefit.
Then METR studied 16 experienced open-source developers working on 246 real issues in repositories they had known for years. The developers used early-2025 versions of Cursor and Claude while completing bug fixes, features, and refactoring work. With AI, they took 19 percent longer.
The developers expected AI to make them 24 percent faster before the study. After the study, they still believed it had made them 20 percent faster. The measured result went in the opposite direction.
These findings do not cancel one another. Code completion inside a large company, a defined enterprise task, and issue-level work in a mature open-source repository are not the same kind of work. The value of AI changed with the task, the developer’s familiarity with it, and the effort required to verify the result.
A randomized field experiment with 758 consultants helps explain this difference. For tasks that were within the model’s capability, people using AI worked more than 25 percent faster and produced results rated more than 40 percent higher in quality. For a task outside that capability, the people using AI were 19 percentage points less likely to reach the correct answer.
They completed the work faster and produced persuasive answers. The answers were simply wrong more often.
For an engineering team, this makes the feedback loop more important than the amount of code an agent can generate. When a compiler, automated test, static check, benchmark, or small production experiment can expose a bad result quickly, the team can safely give AI more room to work. When correctness depends on an architectural trade-off, an unclear product decision, or behavior that cannot be tested cheaply, AI can still help explore the problem, but it should not choose the direction.
The multiplier includes the delivery system
Section titled “The multiplier includes the delivery system”The team’s existing engineering system determines what happens after AI produces a change.
The 2025 DORA research collected survey responses from nearly 5,000 technology professionals. It found a positive relationship between AI adoption, software delivery throughput, and product performance. It also found that increased AI adoption continued to have a negative relationship with delivery stability.
DORA’s evidence is observational, so it does not prove that AI caused either result. It does show that teams did not receive the same benefit from the same category of tools. Teams working with loosely coupled systems and fast feedback reported better results, while teams constrained by tightly connected systems and slow processes saw less benefit.
DORA then examined which existing capabilities were associated with better AI outcomes. Its AI Capabilities Model identified mature version control, frequent rollback and recovery, small batches, a clear focus on user needs, accessible internal information, and good internal platforms as important conditions.
None of those practices began with AI. They already helped teams change software safely. AI increases their value because it increases the speed and volume of possible changes.
A team with fast automated checks can reject a bad change while it is still small. A team with reliable deployment and rollback can test a change without turning every release into a major event. A team with a good internal platform can give developers and agents the same supported path into testing, security, deployment, and operations.
A team without those capabilities gets the same faster generation, but it has no faster way to decide whether the result belongs in production. The multiplier is working. It is multiplying unfinished work, instability, and the cost of finding mistakes later.
Keep the team where judgment matters
Section titled “Keep the team where judgment matters”Using AI as a multiplier does not mean placing a person at the end of the process to approve whatever the agent produced. People need to remain involved in framing the problem, comparing options, and deciding which risks are acceptable.
A randomized experiment with 791 professionals at Procter & Gamble tested that distinction. Participants worked on real product-development problems either alone or in teams, with or without AI. An individual using AI performed about as well as a two-person team without it, but teams using AI produced the strongest overall results and were roughly three times more likely than the control group to produce a top-decile solution.
The researchers then separated the generation of ideas from the selection of the best idea. AI increased the average quality of the ideas people produced. Human-only teams were better at identifying their strongest idea, choosing correctly about 50 percent of the time compared with roughly 37 percent in the AI-assisted conditions.
The study was about product innovation, not software development, so it does not prove that engineering teams will behave the same way. It does offer a useful division of work. AI can increase the number and quality of options available to a team, while the team applies the product knowledge, system understanding, and judgment required to select one.
In software work, that can mean using AI to investigate several approaches, trace how each one affects the system, and build enough of a solution to make the trade-offs visible. The engineers are not waiting for a finished pull request so they can approve it. They are using AI while they shape the change and decide what should be built.
That human capability still has to be developed.
A small randomized study of 52 software developers examined what happened when people used AI while learning an unfamiliar Python library. The developers using AI finished slightly faster, but the difference was not statistically significant. They scored 17 percent lower when tested on the code and concepts they had just used.
The people who delegated the task completely finished fastest and understood the least. Developers who asked conceptual questions, requested explanations, or examined the generated code showed better understanding, although the study was too small to prove that those interaction patterns caused the difference.
This is where the leadership argument about AI as a multiplier becomes important. Jeremy Utley argues that organizations should not reduce investment in human capability while increasing investment in AI. The available evidence makes that concern specific for engineering teams: AI can help less-experienced developers complete bounded work sooner, but careless delegation can also remove the debugging, code-reading, and problem-solving experience through which they become experienced developers.
I would introduce AI through kinds of work, not through a target number of licenses.
Start with work that has a clear result and a short path to proving whether that result is correct. Measure how long the same team takes to complete it today, how often it returns as rework, and which failures appear after release. Then introduce AI and compare the complete outcome, including verification and correction, rather than counting generated code or asking whether the developers felt faster.
When the result improves, make the working pattern available to the rest of the team. When the result does not improve, change the way AI is being used or stop using it for that work. As the team builds evidence across more kinds of work, the useful boundary will become clearer.
AI can multiply a team’s ability to explore and execute. The team’s engineering practices determine whether that additional work can be verified and released safely, while its people provide the judgment needed to decide which work should exist.
That is a better basis for investment than converting licenses into imaginary headcount.