AI Tool ROI for Your Dev Team: Why 80% See Nothing

The return on investment of AI tools for a development team too often boils down to one hollow sentence: "it goes faster". McKinsey put numbers on the reality in 2026, surveying nearly 2,000 companies: 80% measure no significant impact on their profitability (EBIT), and only 5.5% get a real, measured gain. The difference is not the tool you pick, it is the method you build around it.

I see it on every engagement where a client asks me whether Claude Code or Cursor will "save time". The question is always the right instinct, never the right measurement. What follows is the calculation I run before I answer.

Why 80% of companies see no return on their AI investments

The McKinsey figure does not stand alone. According to Worklytics, 95% of US companies said they were using generative AI in 2025, but a Wall Street Journal article cited by Worklytics in April 2025 showed that only 1% had obtained a measurable return. Still according to Worklytics, 74% of companies have so far extracted no tangible value from their AI projects.

This is not an adoption problem. It is a two-speed perception gap between the people who decide and the people who code.

Why is the perception gap between executives and developers so wide?

A Black Duck webinar measured that gap precisely. Close to three quarters of executives report major improvements from AI in their development processes. Among individual contributors and their direct managers, the figure drops below half. More striking still: 48% of executives rate AI assistant output as excellent and ready to merge, against only 8% of the developers who actually have to ship and maintain it.

An executive sees a Claude Code subscription and an impressive demo. A senior developer sees the code they will be fixing at three in the morning. Both are right, they are simply not measuring the same thing.

Why coding faster does not speed up delivery

That perception gap has a mechanical explanation, not just a cultural one. The software project lifecycle (requirements, design, build, release, operations) has several stages, and writing code is only one part of it. According to IBM Technology, a good chunk of the time in that cycle is actually waiting: a developer waiting on a product spec, a QA team waiting on a build to test.

When AI only accelerates the coding stage, the gains get absorbed by every stage that has not changed. You may be coding three times faster, but the rest of the pipeline still moves at the same pace.

What is the verification tax?

The DORA report on AI in software development, relayed by Google Cloud, calls this the "J-curve": a temporary productivity dip early in adoption. Three causes explain it, one of them the verification tax (the extra time spent reviewing a far larger volume of generated code than before, to catch hallucinations and architectural mistakes). A controlled study on open source developers cited by IBM goes further: developers convinced they were 20% faster thanks to their AI tools were in reality 20% less productive.

I saw this syndrome on a recent engagement where an AI-augmented dev was shipping pull requests twice as fast as before. Code review time (the stage where a colleague reads and approves the work before it is merged) more than doubled in return. On paper, velocity (features shipped per month) had gone up. In practice, time to production had not moved by a single day.

What an AI developer tool really costs

That gap between perceived speed and delivered speed carries a hidden price most teams never put in the budget. According to GetDX, a mid-sized tech company spends between $100,000 and $250,000 a year on AI tools, and large enterprises often go past $2 million annually. GitHub Copilot Business alone costs $19 per user per month, which is $114,000 a year for 500 developers.

The real trap is not the sticker price, it is the gap between seats paid for and seats actually used. Proxify reports an average adoption rate of only 40 to 65% in the first six months. Paying for 100 licences when 42 developers genuinely use them changes the per-head economics entirely.

How much does a Copilot or Claude Code licence cost per developer?

The method that turns a tool into a measurable result

So the problem is not the tool, it is the absence of a method to turn its speed into delivered results. French SMB Alegria Group, 35 employees, illustrates the opposite: 600,000 euros in documented savings over twelve months, 170 automations deployed, and one absolute rule before launching anything: no project without a quantified business case.

Their formula fits on one line: annual value equals time saved, multiplied by frequency, by the number of people involved, by the hourly rate, adjusted by three correction factors. A realistic adoption rate (70% in year one, nobody adopts immediately), an annual efficiency coefficient (75%, an automation is never live for twelve full months), and a maintenance cost (3 to 10% a year). Concrete result: a theoretical gain of 100,000 euros becomes roughly 47,000 real euros in the first year. That gap, owned and calculated from the start, is what makes the number credible in front of a CFO.

"The real advantage is never the AI tool itself. It is the production system you build around it, with precise specs, testable blocks, and a project memory the agent re-reads on every task."

Vincent, September 2026

I believe a poorly scoped AI project (a vague prompt along the lines of "rebuild this feature for me") produces exactly the negative return on investment McKinsey measures. What I recommend on every engagement is to break the work into short, testable blocks, with an acceptance criterion written before the agent touches a single line of code, and a project memory file (a document that centralises the architecture, the conventions and the decisions already made) that the AI re-reads on every new task. Full disclosure: I run a team of senior developers on staff augmentation contracts at Extra Dev, so my leaning towards this discipline is not neutral. It also comes from seeing that difference in outcome, project after project, well before invoicing ever comes up.

On this blog I apply the same honest measurement rule I preach here: my own Search Console numbers for extradev.fr show 6 clicks and 1,004 impressions this month, with an average position of 10.1. That is not a volume argument, it is proof that an ROI calculation is done with the real numbers, however small, never with the ones you wish you had. If you want to dig into how to measure the real velocity of an AI-augmented team, I have laid out the full method in a dedicated article.

The risk no ROI spreadsheet captures

A German discussion thread on r/SoftwareDACH describes a symptom McKinsey does not measure: several developers, some of them inside large technology groups, report that AI tool usage is now an explicit part of their performance review. The result is "performative" use of these tools, to tick the box, even when the output is bad. One designer quoted in the thread talks about an "inextricable nest of technical debt" (badly structured code that gets more and more expensive to evolve), and review requests of more than 1,000 lines of AI code causing rapid mental exhaustion.

That debt feeds straight into the two bottlenecks Black Duck identified: manual review and security testing. When production speed outruns the capacity to check, the risk does not disappear, it moves downstream. That is exactly what I observe when I supervise an engagement: the real bottleneck is almost never writing speed, it is the capacity to review and approve what the AI has just produced. I covered this specific point in an article on the hidden bottleneck of code review, because it is the most underestimated variable in any ROI calculation.

Faced with that risk, 56% of the teams surveyed by Black Duck prefer an independent, specialised AI security agent to check the code produced by coding assistants, rather than letting the tool that wrote the code proofread itself. The logic is basic separation of duties: you do not let a student grade their own paper.

So the verdict is a number, not a matter of faith in AI. Do not equip the whole team at once: test on a bounded scope (one module, one sprint, a secondary product), with a senior developer who already applies a discipline of specs and testable blocks, and measure only three numbers over 90 days: time to production, code review time, and production bug rate. If all three improve together, scale the investment. If only the first one moves, you have found the real hidden cost before it spreads to the whole team. To go further on orchestrating AI agents across a full project, the GoLive Software blog covers the business and staff augmentation angle of the same question.