Every engineering leader adopting AI coding tools eventually has the same meeting. Finance asks what the return is, and the honest answer is harder than the deck suggests.
The temptation is to reach for a vendor number: "engineers are 55% faster." It is a bad foundation. It measures a narrow task in a controlled setting, it does not survive a sceptical CFO, and it sets an expectation the rollout cannot meet. When the promised productivity does not show up in delivery, the tool looks like a failure even when it was quietly worth the money.
We help engineering and finance leaders build the case differently: from costs they can verify and benefits they can defend, sized honestly. The goal is not the biggest number. It is a number that holds up six months later when someone checks.
Start with the full cost, not the licence price
The licence is the visible cost and the smallest one. A defensible case prices the whole thing.
| Cost | What it includes | Why teams miss it |
|---|---|---|
| Licences | Per-seat subscription, annualised | The only line most cases include |
| Rollout | Setup, tool evaluation, security review, procurement time | Treated as free because it is internal |
| Enablement | Training, internal champions, the slow first weeks | Real time, rarely counted |
| Review overhead | More code arriving at review, more scrutiny per change | A genuine new cost AI creates |
| Remediation | Fixing AI-introduced defects and technical debt | Shows up later, surprises everyone |
You do not need these to the cent. You need them present, because a case that shows only the licence cost is the one finance learns not to trust. Naming the soft costs is what makes the benefit side believable.
Size the benefit from your own delivery data
The benefit is real, but it is specific to your team and your work mix. Anchor it in numbers you already have.
- Fully loaded engineering cost. Use your real average cost per engineer, including overhead, not a headline salary.
- Where the time actually goes. AI helps most on boilerplate, tests, scaffolding, and unfamiliar-language work; it helps least on the hard design and judgement work that fills senior calendars. Estimate the share of your team's time in the bucket AI actually accelerates.
- A conservative uplift on that share only. A modest gain on the fraction of work AI touches is far more defensible than a large gain applied to all engineering time. Applying a vendor percentage to a whole salary line is the single most common way these cases lose credibility.
The arithmetic that survives scrutiny looks like: cost-per-engineer × share-of-work-AI-affects × conservative-uplift, minus the full cost above. A smaller, defensible result beats a large, fragile one every time.
Count the benefits that are not speed
The strongest part of the case is often not raw velocity. It is the things that are easier to stand behind.
- Faster onboarding. New hires and engineers moving into an unfamiliar codebase or language reach productivity sooner. This is one of the clearest, most repeatable wins.
- Less time stuck. Fewer long stalls on syntax, unfamiliar APIs, and the kind of lookup that used to cost half a day.
- Better test coverage. When writing tests is cheaper, more get written, provided review insists they assert real behaviour.
- Retention and hiring signal. Engineers increasingly expect good tooling. This is hard to quantify and worth naming as a qualitative benefit rather than faking a number.
Put quantified items in the model and qualitative ones in a clearly-labelled separate list. Mixing a real euro figure with a hand-waved one contaminates both.
Be honest about what erodes the return
A credible case names its own risks. These are the ways the return shrinks, and acknowledging them is what makes the rest believable.
| Risk to ROI | Mechanism | Mitigation |
|---|---|---|
| Review becomes the bottleneck | More code, same reviewers, queue backs up | Route review depth by risk, push understanding onto authors |
| Technical debt compounds | Fast generation outruns maintenance | Treat AI debt as debt: spot it, price it, contain it |
| Productivity is faked | Activity metrics rise, delivery does not | Measure outcomes, not lines or commits |
| Shadow usage | Unapproved tools create cost and risk you cannot see | Provide an approved path that is easier than the workaround |
Each of these connects to work we cover elsewhere: on measuring adoption without fake productivity math, on managing AI-generated technical debt, and on keeping review quality high as volume rises. The business case is only as good as the operational discipline behind it.
Measure the return after rollout, not just before
A pre-rollout model is a hypothesis. The case is only complete when you check it against reality, using the same delivery signals you would track anyway.
- Cycle time from first commit to merged, by change type.
- Change failure rate: whether faster delivery is also more fragile.
- Review latency: whether review is holding the line or backing up.
- Onboarding ramp: time for new engineers to reach steady output.
If these move in the right direction, the ROI was real and you can defend the next renewal with evidence instead of a forecast. If they do not, you have found a workflow problem the tool exposed, not a reason the tool failed.
Our view
The ROI of AI coding tools is real, but it is smaller and more specific than vendor numbers suggest, and it is conditional on the discipline around the tool. A case built on a borrowed productivity percentage gets approved once and distrusted forever.
Build the case from your own fully-loaded cost, apply a conservative uplift only to the share of work AI actually touches, count the non-speed benefits honestly, and name the risks that erode the return. Then measure it after rollout against the delivery signals you already trust. A modest number you can defend is worth more than an impressive one you cannot, because the second meeting, the renewal, is the one that decides whether the investment continues.
Sources
- DORA,
Accelerate State of DevOps, on cycle time, change failure rate, and delivery performance, accessed 2026-06-10 - McKinsey,
The economic potential of generative AI, on developer productivity ranges and their conditions, accessed 2026-06-10 - GitHub, research on Copilot and developer task completion, accessed 2026-06-10
Frequently asked questions
- Why do vendor productivity numbers fail in a finance review?
- Vendor figures like '55% faster' measure a narrow, controlled task and do not reflect a real team's work mix. Applying that percentage to an entire engineering salary line is the single most common way ROI cases lose credibility with a sceptical CFO. A defensible case uses your own fully-loaded cost data and applies a conservative uplift only to the share of work AI actually accelerates.
- What costs beyond licences should an AI coding tools business case include?
- The full cost picture includes rollout (setup, security review, procurement time), enablement (training and the slow first weeks), increased review overhead as more code arrives at the same number of reviewers, and future remediation of AI-introduced defects and technical debt. A case that shows only the licence cost is the one finance learns not to trust.
- How should we measure the ROI of AI coding tools after rollout?
- Track four delivery signals you would monitor regardless: cycle time from first commit to merge, change failure rate, review latency, and onboarding ramp for new engineers. If these move in the right direction, the ROI was real and you can defend the next renewal with evidence rather than a forecast. If they do not, you have found a workflow problem the tool exposed, not a reason the tool failed.
- What non-speed benefits are easiest to defend in an AI coding tools ROI case?
- Faster onboarding is the clearest and most repeatable win: engineers moving into an unfamiliar codebase or language reach steady output sooner. Reduced time stuck on syntax, unfamiliar APIs, and lookup tasks is also concrete. Better test coverage is credible provided reviewers insist tests assert real behaviour. Retention and hiring signal should be named as a qualitative benefit rather than attached to a fabricated number.
