TLDR overview
- More generated code is not ROI. Review effort, corrective changes, defects, and maintenance are costs that generation dashboards do not show.
- Rework is work done to correct an earlier change. Verification debt builds when checking falls behind generation, and the work moves downstream.
- Cost per accepted change measures efficiency, not ROI on its own. A true ROI claim also compares the value of benefits with the full investment.
- Measure trust through outcomes: first-pass gate acceptance, review overrides, corrective changes within 30 and 90 days, and attributable incidents.
- One shared scorecard lets engineering, security, and finance judge the same changes. Start with one team and a baseline.
Is your team shipping more, or just generating more?
AI-generated output is rising. Leaders are asked whether delivery costs, quality, and maintenance are improving as a result, and many have no evidence beyond activity counts. This page gives CTOs, engineering directors, security leaders, and finance partners a way to answer with outcomes. It covers what to count as rework, how to calculate cost per accepted change, how to measure trust, and how to build a scorecard the three groups can share.
Why does more generated code not establish AI coding ROI?
Generated code is an input, not a result. AI coding ROI depends on whether changes are accepted, hold up in production, and cost less to deliver than they save. Four costs sit behind every generated change and rarely appear on a generation dashboard:
- Review effort. People read, test, and approve agent changes.
- Corrective changes. Rewrites, reversions, and fixes that follow an earlier change.
- Defects. Bugs and vulnerabilities that reach production.
- Maintenance. Duplicated or complex code that makes later changes more expensive.
Volume and confidence are poor stand-ins for these costs. In Sonar’s 2026 State of Code Developer Survey of more than 1,100 developers, AI accounted for 42% of committed code. Yet 96% did not fully trust AI-generated code to be functionally correct, only 48% said they always check it before committing, and 38% said reviewing it takes more effort than reviewing a colleague’s code. That is a vendor-run, self-reported survey. It shows where the pressure is, not what it costs.
Measured outcomes and self-reported productivity can disagree. In a randomized controlled trial by METR, experienced open source developers expected AI tools to make them 24% faster. On measured tasks they were 19% slower, and afterward they still believed they had been 20% faster. The trial involved 16 developers using early-2025 tools, and METR now says the results no longer reflect current tools and has published newer data. The lasting point is that perceived and measured speed can diverge, so ROI claims need measured outcomes.
Delivery telemetry shows the same tension. In Faros AI’s 2026 report, drawn from about 22,000 developers, each organization’s periods of higher AI adoption were associated with 66% more epics completed per developer. They were also associated with median time in review up 441.5%, bugs per developer up 54%, and incidents per pull request up 242.7%. Faros describes the incident figure as a ratio, not a probability. This is vendor telemetry that compares each organization with itself, so it shows correlation, not cause. DORA’s 2025 summary points the same way: AI improves throughput, but often at the cost of stability if the foundation is not solid.
How to read the evidence on this page:
What are rework and verification debt?
Rework is work done to correct an earlier change. Count it separately from the iteration every change goes through on the way to acceptance.
- Necessary iteration (not rework). Attempts and refinements before a change is first submitted for review. Count these as attempts, with their model usage and CI compute.
- Corrective rewrite. A change redone because it failed review, failed the gate, or missed the intent.
- Reversion. A merged change that is backed out.
- Fix. A follow-up change that corrects a defect from an earlier one.
Verification debt is the term AWS CTO Werner Vogels uses for what builds when AI writes code faster than people can understand it. The understanding has to be rebuilt later, usually in review. Delayed code verification does not remove work. It moves the work downstream, and the kind of work changes:
This table describes the kind of work added at each stage, not how much. The multiplier varies by team and codebase, and no universal figure should be assumed.
Evidence on downstream cost. A Carnegie Mellon study compared more than 800 open source projects that adopted Cursor with matched projects that did not. It found a large but short-lived rise in lines added (3x to 5x in the first month, fading after about two months), and a persistent rise in static analysis warnings (30%) and code complexity (41%) that was linked to a later slowdown. It covers open source projects and one tool. GitClear analyzed 211 million changed lines and found moved lines, a proxy for refactoring, fell from 25% of changed lines in 2021 to under 10% in 2024, while cloned lines rose from 8.3% to 12.3%. That is a trend that coincides with AI adoption, not proof of cause. For security, Veracode tested 100+ models on 80 coding tasks and found they chose an insecure option 45% of the time. That is a share of test cases built to carry known weaknesses, not a rate for real projects.
How do you measure cost per accepted change?
Cost per accepted change adds up everything spent to deliver changes that last, then divides by the number of those changes.
Cost per accepted change
(model usage across all attempts + CI compute + review labor + corrective work + attributable defects) ÷ accepted changes
Failed attempts count in the cost but not in the changes, so retries show up as cost. Corrective work and defects are included, so fast but wrong code does not look cheap.
Define acceptance and an observation window before you start. A change is accepted when it passes the quality gate, an automated check a change must pass before merge, is reviewed and merged, and is not reverted within the window. Use 30 days for most work and 90 days for areas where maintenance cost matters. A change reverted inside the window leaves the accepted count, and its cost stays in the numerator. Longer-term maintenance is harder to attribute to one change, so treat it as a trend to watch rather than a per-change figure.
Count each hour once. Time spent re-reviewing a corrected change belongs to corrective work, not to review. Without that rule, review and rework labor get counted twice and the figure overstates cost.
A hypothetical example
The inputs below are assumptions chosen to show the method. They are not customer data or Sonar results. Assume $4.00 in model usage per attempt, $2.00 of CI compute per attempt, $100.00 per loaded engineering hour, one hour per corrective change, and $800.00 per attributable defect.
In this example, model usage is under 10% of the total in both workflows. Halving the model price in Workflow A would save about 3.3% per accepted change. Moving from A to B saves about $50.67, roughly 46%, and most of that is engineering time. At 1,000 accepted changes a month, that would be about $51,000. Your own split will differ. What the example shows is where to look: review time, corrective work, and defects can outweigh model usage.
Efficiency is not ROI
Cost per accepted change measures efficiency. A true ROI claim also needs the value of the benefits compared with the investment: ROI = (value of benefits − total investment) ÷ total investment. Benefits can include engineering time freed, incidents avoided, and delivery capacity gained. Investment includes licenses and usage, tooling, adoption and training, and the platform work to run agents safely. Track the efficiency metric every month, and state ROI only when both sides of that ratio are measured.
How do you measure trust in AI-generated code?
Measure what happens to changes after the code is written, not how confident people feel about it. Four observable signals, tracked together, show whether trust is earned:
- First-pass gate acceptance. The share of agent changes that pass the quality gate on the first CI run.
- Review overrides. How often reviewers reject, rewrite, or send back an agent change.
- Corrective changes within 30 and 90 days. The share of accepted changes later fixed, rewritten, or reverted.
- Attributable incidents. Production issues traced to agent changes.
Code survival, the share of AI-authored lines unchanged after 30 or 90 days, is a useful extra signal, but treat it as a signal and not proof of quality. Legitimate improvements also change lines, and low survival in an area under active development is not a defect. Compare similar areas and exclude planned refactoring before you read it.
Do not substitute surveys for these signals. Developers’ stated trust and their checking behavior can differ, as the 96% and 48% figures above show. When the four signals improve together, giving agents more autonomy is justified. When they diverge, add verification where they diverge.
How do teams reduce rework in agentic development?
Catch problems while they are cheapest to fix. Give the agent the right guidance before it writes, verify as it works, keep an independent check before merge, and keep changes small enough to review. Six practices make that concrete:
- Provide project guidance before generation. Architecture, standards, and dependency rules reduce changes that are correct but do not fit.
- Verify during the work. Issues found while the code is still in context cost one more step, not a review round trip.
- Retain independent checks. Hold human and AI code to the same standard, using a check that does not depend on the model or agent that wrote the code.
- Keep changes reviewable. Small changes are cheaper to verify, review, and roll back.
- Feed recurring findings back into guidance. A finding that repeats should become a rule the agent sees before it writes.
- Prioritize maintenance in agent-heavy areas. Fixing existing issues where agents work most lowers the cost of every later change there.
Guide, Verify, Solve: an operating model
Sonar calls its operating model for the Agent Centric Development Cycle (AC/DC), the agentic development lifecycle from first prompt to main branch. It has three continuous stages:
- Guide gives agents the context and constraints a task needs before they write. Sonar Vortex does this inside the agent’s work.
- Verify checks every change independently, in the agent’s work and again in CI, using SonarQube’s algorithmic analysis and Gitar AI code review.
- Solve routes verified findings to fixes, through the SonarQube Remediation Agent, and feeds lessons back into Guide.
For the token side of Guide, see Sonar’s token optimization approach. The metrics in this page are how you check whether any of it is working.
What metrics matter for agentic development governance?
One outcome metric, cost per accepted change, plus a small set of driver metrics for each function that share the same definition of acceptance and the same observation window. A shared scorecard lets each group judge the same changes from its own angle:
Record the savings you expect before a change, then compare them with what you realize after the observation window. Tag AI-authored changes at the pull request so attribution is possible, and accept that it will be imperfect. Finance is already moving: the FinOps Foundation’s State of FinOps survey found 98% of 1,192 practitioners now manage AI spend, up from 31% two years earlier.
Start with one team
- Pick one team and repository with meaningful agent use.
- Agree on acceptance and the window. Use the definitions above, and write them down.
- Pull 30 days of data: model usage, CI runs, review time, and changes corrected or reverted.
- Calculate the baseline cost per accepted change and the four trust signals, and note where issues are caught: in the agent’s work, CI, review, or production.
- Follow up after the observation window. Change one thing, such as guidance or earlier verification, and compare the same measures. Keep the change only if cost falls and quality holds.
Assess your agentic development workflow with a cost-and-quality baseline
A baseline turns an AI spend debate into a measurement. SonarQube applies one consistent standard to human and agent code, which gives the baseline a common definition of acceptance.