AI coding ROI: measure the work that survives review
A practical way to measure AI coding returns using completed outcomes, review effort and real costs, informed by studies that found very different effects.
An AI coding tool can increase the number of changes an engineer produces while leaving the delivery team with more work. It can also make a previously uneconomic project feasible. Both possibilities disappear in a dashboard that counts accepted suggestions.
The useful investment question is specific: For this kind of work, with this team and these tools, what changes in the cost and quality of a completed outcome? That question connects engineering evidence to finance without turning every keystroke into a performance score.
This guide uses research available on October 7, 2026. Its operating method and numerical example are Proforma’s proposed approach, not results from a customer deployment.
Why the research does not produce one universal ROI number
A June 2025 paper reports randomized field experiments across Microsoft, Accenture and an unnamed Fortune 100 company. Across 4,867 developers, its pooled estimate was a 26.08% increase in completed tasks, with a standard error of 10.3%. The intervention provided access to an AI coding assistant; the result is specific to those experiments and their outcome definitions. Microsoft Research publication.
METR’s early-2025 experiment studied a different setting: 16 experienced open-source developers completing 246 tasks in familiar repositories. AI access increased completion time by 19%. That result concerns experienced maintainers, particular tasks and the tools available then. It is not an estimate of every developer’s current experience. METR’s original study.
The update matters. In February 2026, METR reported that selection effects and difficulties measuring concurrent agent work made its follow-up an unreliable estimate of current productivity effects. Developers and tasks that benefited most might be missing because participants resisted working without AI. The researchers regarded the newer data as weak evidence about the size of improvement. METR’s follow-up.
DORA’s March 2026 discussion of its 2025 research describes higher AI adoption as associated with both greater delivery throughput and greater delivery instability. Those are associations, not a randomized estimate of what your rollout will cause. DORA’s analysis.
These findings support a practical conclusion: measure your workflow, and retain enough context to understand why its results differ.
Define the outcome before choosing a metric
Choose one repeatable class of work: dependency upgrades, a customer integration, incident investigation or test maintenance. Define completion in language the receiving team accepts. “Merged with passing tests and no related rollback within 14 days” is more useful than “generated a patch.” For an investigation, completion might instead mean a reviewed explanation with reproducible evidence.
Keep four measurements together:
| Question | Example measure | What to retain |
|---|---|---|
| Did useful work finish? | Accepted outcomes per period | Acceptance criteria and reviewer decision |
| How much effort did it require? | Authoring, review and rework hours | Time definition and sampling method |
| Did quality hold? | Reopens, escapes and rollbacks | Issue links and observation window |
| What did it cost? | Tools, usage and implementation effort | Invoices, allocation basis and exclusions |
Also ask engineers whether the workflow improves concentration, learning or collaboration. Those effects can matter without immediately becoming cash savings. The SPACE research framework similarly treats developer productivity as multidimensional rather than reducible to a single activity metric. SPACE paper.
Run a comparison that can survive scrutiny
For a manageable pilot, agree on eligible task types before the work starts. Record complexity, repository familiarity and whether AI was used. If practical, randomize eligible tasks or teams into comparison conditions. If randomization is impractical, use matched cohorts or a before-and-after comparison, while explicitly recording the weaker causal evidence.
Do not let the team place only easy tasks in the AI group. Preserve abandoned tasks, failed runs and work that moves into the next reporting period. Record changes in staffing, tooling and requirements. Otherwise, apparent improvement may simply reflect a different mix of work.
Separate elapsed time from human effort. An agent working for an hour while an engineer reviews another project consumes compute and may increase throughput; it does not necessarily consume an additional hour of that engineer’s attention. Conversely, a ten-minute generation can create two hours of review. Count each cost once.
A worked example: capacity is not automatically cash
Illustrative example in USD, not a forecast. A team compares 40 similarly scoped maintenance tasks in each condition, using the same acceptance criteria and follow-up window.
| Human effort | Baseline | AI-assisted |
|---|---|---|
| Implementation | 200 hours | 150 hours |
| Review | 40 hours | 55 hours |
| Rework | 20 hours | 25 hours |
| Total | 260 hours | 230 hours |
The observed difference is 30 hours. At an assumed loaded labor cost of $100 an hour, that is $3,000 of capacity value. Suppose incremental tools and model usage cost $1,200, with $800 of training and setup allocated to the period. The pilot’s modeled net capacity value is $1,000. Its modeled return is ($3,000 − $2,000) / $2,000 = 50%.
That calculation does not mean the bank balance improved by $1,000. If salaries remain unchanged and the released time is not used, immediate cash savings could be zero. Report the capacity result alongside a separate realized outcome, such as additional accepted work or a documented reduction in contractor expense. Do not add both values if they describe the same benefit.
The estimate is sensitive. If comparable effort saved was only 10 hours, capacity value would be $1,000 and net value negative $1,000. At 50 hours, net value would be $3,000. Show that range before presenting a confident percentage. The same table should disclose quality differences and the limits of the comparison.
Make the decision repeatable
A useful monthly review ends with a decision: expand for a particular task class, change the workflow, gather more evidence or stop. Keep the experiment definition, tool versions, accepted outputs, observed costs and reviewer notes together. This lets finance understand the claim and engineering challenge an unfair comparison.
Engineering ROI and R&D tax eligibility answer different questions. Faster delivery is not proof of qualifying research; an unsuccessful technical investigation can still produce valuable knowledge. Assess tax treatment separately using the applicable jurisdiction and facts.
Proforma’s starting point is to collect engineering records and available cost evidence for an initial review. A configured Workspace agent can assist investigation, while preparation and review can remain manual. The goal is a more inspectable decision, with the missing evidence visible. Explore the R&D evidence workflow.
Sources and scope
- Microsoft Research: three developer field experiments, June 2025
- METR: early-2025 developer experiment
- METR: February 2026 design update and limitations
- DORA: AI adoption and delivery tradeoffs, March 2026
- SPACE: multidimensional developer productivity
The arithmetic above is an original illustrative model. None of these sources validates a Proforma savings claim or predicts a particular company’s return.
Put the records to work
Start with a clearer evidence picture.
Bring project records and costs into an initial review. See what supports the story, what is missing and what to ask next. Preparation can be manual.