On this page · 11 sections
- The number, and the footnote attached to it
- The J-curve is the part that gets people fired
- Where the gain is, and where it is not
- The cost line most rollouts never budget: code-IP governance
- What a 90-day rollout actually looks like
- Measuring it without fooling yourself
- India-specific considerations
- How we run this with clients
- FAQ
- How eCorpIT can help
- References
Summary. Google Cloud's DORA team published "The ROI of AI-Assisted Software Development (2026.01)" and modelled a first-year return of roughly $11.6 million against an $8.4 million investment for a 500-person engineering organisation at a fully loaded salary of $176,000 per head. That is a 39% ROI with an eight-month payback, and it is the number now being pasted into board decks. In the same report the authors write: "Treat these calculations as a high-uncertainty estimate meant to spark a conversation, rather than a rigid mathematical formula." Their own sample calculator carries a negative downtime line of $344,000, because the modelled change failure rate rises from 5% to 6% after adoption. Stanford's Software Engineering Productivity research, cited in the same report, found 35 to 40% gains on simple greenfield tasks and often 10% or less on complex legacy code. Two of those four facts usually survive into the business case. The other two decide whether the rollout works.
This is what we have learned matters when engineering organisations put coding agents into real teams, and where the money actually goes.
The number, and the footnote attached to it
The DORA report, covered by InfoQ on 11 May 2026, builds ROI from a value chain: adoption flows through seven capabilities, including a quality internal platform, version control practices and AI-accessible internal data, into DORA delivery metrics, then into developer and user experience, and finally into cost savings and revenue.
Nathen Harvey, the DORA team lead at Google Cloud, states the central finding directly: "The greatest returns on AI investment come not from the tools themselves but from a strategic focus on the underlying organizational system: the quality of the internal platform, the clarity of workflows, and the alignment of teams. Without this foundation, AI creates localized pockets of productivity that are often lost in downstream chaos."
Read that as a spend allocation instruction. If the majority of your AI budget is licence fees and token spend, and a minority is platform, workflow and review capacity, the model says you have the ratio backwards.
The report itself ships an interactive calculator, and the authors recommend running conservative, realistic and optimistic scenarios rather than quoting a single figure. Very few of the decks quoting 39% did that.
The J-curve is the part that gets people fired
DORA's central structural claim is that most organisations hit a temporary productivity dip before the gains arrive. The report attributes the dip to three causes:
The learning curve. Teams have to change how they work, not just install a tool.
The verification tax. Someone reviews the AI-generated code, and that someone is a senior engineer whose time is the most expensive input you have.
Downstream process strain. Testing, change approval and deployment pipelines were sized for the old code volume. More code moving faster overwhelms manual review gates.
The report calls this period "the tuition cost of transformation" and warns that leaders who read the dip as failure pull funding during it and forfeit the return. That is the single most useful sentence in the document, because the dip is predictable and the funding decision is usually made by someone watching a velocity chart.
The instability cost is real and quantified. In DORA's sample calculation the change failure rate rises from 5% to 6% after AI adoption, producing a $344,000 negative downtime impact inside the same model that yields the 39% return. The authors do not present that as a reason to delay; they present it as a reason to fund automated testing, continuous integration and small batch sizes before you scale agent usage. Which is to say: the money you save on typing, you spend on verification.
Where the gain is, and where it is not
| Work type | Reported productivity gain | Source | What it means for sequencing |
|---|---|---|---|
| Simple greenfield tasks | 35 to 40% | Stanford SEP, cited in DORA ROI report | Pilot here; the win is visible fast |
| Complex legacy code | Often 10% or less | Stanford SEP, cited in DORA ROI report | Do not build the business case on this |
| Overall throughput | 2 to 18% estimated | 2025 DORA State of DevOps | Modest, and paired with instability |
| Delivery stability | Declining, higher change failure rate | 2025 DORA State of DevOps | Budget review and test capacity |
That first-to-second row gap is the whole planning problem. Most enterprise engineering time goes into existing systems, and that is exactly where the measured gain is smallest. A pilot on a greenfield service will produce a 35% number that does not generalise to the monolith, and the organisation will then plan against a figure it cannot reproduce.
The honest sequencing is: pilot on greenfield to build the habit, measure on legacy to set the forecast.
The 2025 DORA research behind this drew on surveys of nearly 5,000 technology professionals and more than 100 hours of interviews, and its conclusion was blunt: AI will not fix broken engineering systems. It magnifies whatever is already there.
There is a related shift in where the money goes that is worth planning around. The DORA report notes that inference costs fell by a factor of 280 between November 2022 and October 2024, citing the Stanford Artificial Intelligence Index, and concludes that the real financial burden of adoption has moved to governance: managing the verification tax, adjusting workflows and upskilling staff. Token prices are no longer the constraint. The constraint is senior review capacity, and that does not get 280 times cheaper.
The report is also direct about the wrong way to book the return. It discourages headcount reduction as a strategy, arguing that retaining and training existing staff is more cost-effective and preserves institutional knowledge, and reframes the measure: "Return on investment is no longer a measure of how many developers an organization can replace. It is a measure of how much latent human creativity can be unlocked by offloading systemic toil to these autonomous agents." For the longer horizon the authors point to Google Cloud data showing an average 727% return on Google Cloud AI investment over three years with a payback of around eight months, treating year one as foundation building and expecting the compounding to arrive in years two and three. Whether that multiple survives contact with an organisation that is not Google Cloud's customer base is exactly the question a conservative scenario is for.
The cost line most rollouts never budget: code-IP governance
Every model vendor now sells a cheap tier, and increasingly the discount is paid for with your source code rather than with cash.
Meta's Muse Code, launched on 5 August 2026, is the clearest example. The standard tier bills $1.25 per million input tokens and $4.25 per million output tokens, and Meta does not train on those prompts and completions. The contributor tier bills $0.10 and $0.20 for the identical model, in exchange for permission to train on your session data. We worked through that trade in detail in Muse Code's contributor tier and what the discount really costs.
The governance problem is not that the cheap tier exists. It is that the decision sits with whoever runs the install command.
Three things follow, and none of them are technical.
Old contracts do not cover this. Most services agreements and NDAs predate generative AI, restrict disclosure to "third parties" and define a permitted purpose, and say nothing about model training. Bloomberg Law's analysis of NDA drafting and Carta's guide to AI clauses both land in the same place: silence is not consent, and a client who finds their code in a training corpus will not accept a drafting gap as an answer.
The clause may already be in your own vendor contracts. PYMNTS reported in 2026 that ordinary "improve, build or enhance the product" language in enterprise software agreements is already functioning as a training licence over customer data. The AI coding tool is the visible instance of a pattern that is probably already in your stack.
Enforcement has to be structural. A policy document does not stop an engineer choosing a cheaper tier on a laptop. Issuing keys per repository class, with the tier as a property of the key, produces an auditable control and a billing export you can reconcile. That is a two-day piece of platform work that removes an entire category of argument.
What a 90-day rollout actually looks like
| Phase | Weeks | Focus | Exit criterion |
|---|---|---|---|
| Baseline | 1 to 2 | Measure current delivery metrics and review load before any agent lands | You can state today's change failure rate and review latency |
| Classify | 2 to 3 | Sort repositories by confidentiality class; issue keys per class | No engineer can select a training tier on client code |
| Pilot | 3 to 6 | One greenfield service, one legacy service, same team | Two separate gain figures, not one blended number |
| Harden | 6 to 10 | Automated tests and CI capacity sized for the new code volume | Change failure rate back to baseline at higher throughput |
| Scale | 10 to 13 | Extend to remaining teams with the measured legacy figure as the forecast | Spend attributed per repository, reviewed monthly |
Two things about that table are deliberate.
The baseline phase comes before the tool, not after. Without a pre-adoption measurement you cannot distinguish the J-curve dip from a bad quarter, and you will be arguing about it with a CFO who has the 39% number in front of them.
The pilot runs greenfield and legacy in parallel with the same team. Running them sequentially, or with different teams, confounds the tool effect with the team effect and gives you a number you cannot defend.
Measuring it without fooling yourself
Deployment frequency and lead time become weak signals once a large share of committed code is machine-generated: both improve while review burden and defect risk shift somewhere the metric does not look. The DORA team's own framing is the better one: "We don't measure AI by the code it writes but by the bottlenecks it clears."
In practice that means tracking four things alongside the standard four.
Review latency and review load per senior engineer, because that is where the verification tax lands. Change failure rate specifically split by AI-assisted and human-authored changes, because a blended figure hides the shift. Rework rate within fourteen days of merge, which catches code that passed review and failed in contact with reality. And token spend attributed per repository, because unattributed AI spend is the fastest-growing untracked line in most engineering budgets.
We set out the instrumentation for these in measuring AI coding agent productivity with DORA metrics, and the harness-level differences that change the numbers in our comparison of Claude Code, Codex and Copilot CLI.
On cost control specifically, routing cheap work to a cheap model and reserving frontier models for work that justifies them is worth more than negotiating a licence discount; the decision framework is in LLM hybrid routing and API spend.
India-specific considerations
For Indian engineering organisations and services firms, three factors change the shape of this.
Client-owned code is the default case. A large share of engineering work in India happens on code the client owns. Tier selection is then a contractual decision belonging to the client, not a cost decision belonging to the delivery team. The practical control is per-client key issuance plus a written position in the master services agreement, and it is cheaper to establish that before an audit asks for it.
The ROI arithmetic does not transfer. DORA's model uses a fully loaded salary of $176,000 per engineer. Indian cost structures are materially different, which changes both sides of the equation: the value of time saved is lower in absolute dollars, while token spend is billed in USD and does not scale down with local salaries. The ratio of tool cost to labour cost is therefore worse here than in the model, and the case has to be rebuilt with local inputs rather than adopted wholesale. The underlying cost comparison sits in India versus US app development cost.
DPDP obligations follow the prompt. Source code is not personal data, but the fixtures, seed data, log samples and support tickets that get pasted into agent sessions frequently are. Under the Digital Personal Data Protection Act 2023 that is processing with a defined purpose, and it travels with the prompt if the tier permits training. Redact before the agent sees it, not after.
How we run this with clients
eCorpIT is a Gurugram-based technology consultancy founded in 2021, working with senior-led, multi-disciplinary engineering teams, and this is a service we deliver rather than a topic we write about. A typical engagement runs the five phases above: we baseline your delivery and review metrics before any agent is introduced, classify repositories and move tier selection into key issuance, run the parallel greenfield and legacy pilot so you get two defensible numbers, size CI and test capacity for the new code volume, and stand up spend attribution per repository.
We are ISO 27001:2022 certified, CMMI Level 5 assessed and MSME registered, and we are an AWS, Microsoft and Google partner, so the controls we design are meant to be inspected rather than described. Where an engagement touches regulated data or client-owned code, we design aligned with DPDP and your own contractual requirements and hand the evidence to your legal team rather than asserting a compliance status on your behalf.
The related work sits in our secure AI-assisted development and AppSec service, our release engineering and CI/CD platform service, and the sandboxing approach in VM isolation for AI coding agents. The wider agent-governance picture is in enterprise AI agents in production.
FAQ
How eCorpIT can help
eCorpIT's senior engineering teams run AI coding agent rollouts end to end: baseline measurement, repository classification and key-based tier control, a parallel greenfield and legacy pilot that produces two defensible numbers, CI and test capacity sizing, and per-repository spend attribution. We are ISO 27001:2022 certified and CMMI Level 5 assessed, and we hand your legal and audit teams evidence rather than assurances. If your organisation is scaling coding agents past the pilot and wants the governance to hold, talk to us.
References
- DORA, Google Cloud, The ROI of AI-Assisted Software Development (2026.01), 2026.
- DORA, Google Cloud, AI ROI interactive calculator, 2026.
- Matt Saunders, New DORA report claims strong engineering foundations drive AI return on investment, InfoQ, 11 May 2026.
- DORA, Google Cloud, 2025 State of AI-Assisted Software Development report, 2025.
- InfoQ, 2025 DORA State of AI-Assisted Software Development, September 2025.
- InfoQ, AI will not fix broken engineering systems: analysis of the DORA report, March 2026.
- Google Cloud, Value realization for AI, 2026.
- Meta Superintelligence Labs, Introducing Muse Code and Muse Spark 1.2, 5 August 2026.
- Juli Clover, Meta's new Mac coding agent costs up to 20x less if you let Meta train on your data, MacRumors, 5 August 2026.
- PYMNTS, Enterprise SaaS contracts are secret AI training licenses, 2026.
- Bloomberg Law, Non-disclosure agreement drafting must account for AI's risks, 2026.
- Carta, AI clauses in NDAs: protecting confidentiality, 2026.
Last updated: 6 August 2026.
