Engineering Delivery

AI

New to DORA? Start with What is DORA?, then come back here.

AI coding tools are now part of most software teams' working day, but buying them does not by itself make a team deliver better. DORA's research finds that AI acts as an amplifier: it makes strong teams stronger and struggling teams' problems bigger. This page explains what the research says, the seven capabilities that decide whether AI helps, how to think about the return on AI spend, and every part of the AI page in Engineering Delivery.

What the AI assistance page shows

In Engineering Delivery you find it under AI, then AI assistance. It answers one question: does AI pay for itself in how your teams deliver? The page opens with a short summary, for example: "45% of merged changes were AI assisted. They merge in 18 hours against 26 hours for the rest, and need a fix 12% of the time against 8%." Its status word reads Improving when AI-assisted changes merge faster without needing more fixes, Mixed when they merge faster but need more fixes, Needs attention when they are slower and need more fixes, and Steady otherwise.

Below the summary you find:

Every figure is at team level, never a person. AI-assisted work is read from commit tags, never from the code.

What does DORA's research say about AI?

AI helps individuals feel more effective, but it is still linked to less stable delivery unless the team's practices keep up. That has been the consistent picture across DORA's last two reports.

The 2024 report: better process, worse delivery

The 2024 Accelerate State of DevOps Report (pages 37 to 40) looked at what changes as AI adoption goes up. For every 25% increase in AI adoption, it estimated:

  • a 7.5% increase in documentation quality
  • a 3.4% increase in code quality
  • a 3.1% increase in code review speed
  • a 1.3% increase in approval speed
  • a 1.8% decrease in code complexity

Those are all things DORA's past research links to better delivery. Yet the same 25% increase in AI adoption was associated with an estimated 1.5% drop in delivery throughput (how fast changes move) and a 7.2% drop in delivery stability (how often deployments go well). DORA's conclusion: "AI does not appear to be a panacea." Its suggested explanation is that improving how code is written does not automatically improve delivery "without proper adherence to the basics of successful software delivery, like small batch sizes and robust testing mechanisms."

The same report found that 39.2% of respondents had little or no trust in AI (executive summary).

The 2025 report: AI is an amplifier

The 2025 report, renamed the State of AI-assisted Software Development, surveyed nearly 5,000 technology professionals. Its headline (page 3): "AI's primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones."

Key findings:

  • Adoption is nearly universal. 90% of respondents use AI as part of their work, and more than 80% believe it has increased their productivity (page 4).
  • Trust is mixed. 30% report little to no trust in the code AI generates (page 4).
  • It is a big part of the day. Respondents spent a median of two hours of their most recent workday interacting with AI, about a quarter of an eight-hour day, and had a median of 16 months of experience with AI tools (page 25).
  • Throughput is now up, stability still down. AI adoption is now associated with higher delivery throughput, a shift from 2024, but it still goes with higher delivery instability, meaning more deployments that need fixing (page 4).
  • Burnout and friction do not move. Higher AI adoption showed no relationship with burnout or with friction (pages 38 to 39). DORA's reading is that these depend on the system and culture people work in, not on a tool at the keyboard. See Well-being and burnout.
  • Being able to undo helps. Teams that use their version control system's rollback and revert features more often get more benefit from AI on team performance (page 56). When changes come faster, the ability to undo them quickly matters more.

In short: AI makes people faster at writing code, and that extra code lands on the rest of the delivery system. If reviews, tests and releases cannot absorb it, the result is bigger, riskier changes and more fixes.

What are the DORA AI capabilities?

The DORA AI Capabilities Model names seven conditions that DORA found make AI's positive effects larger. A capability in DORA's language is a practice or condition its research links to better results. The seven are:

  1. Clear and communicated AI stance: everyone knows which AI tools are allowed and how they may be used. Ambiguity creates risk; clarity gives people the confidence to experiment.
  2. Healthy data ecosystems: the organisation's internal data is high quality, easy to reach and joined up, so AI tools have good material to work from.
  3. AI-accessible internal data: AI tools are connected to your own documentation and code, which turns a generic assistant into one that knows your systems.
  4. Strong version control practices: frequent commits and confident use of rollback. As AI speeds up change, version control is the safety net that makes experimenting safe.
  5. Working in small batches: keeping each change small. This counteracts AI's tendency to produce large, unstable changes. See Change size.
  6. User-centric focus: keeping the needs of the people you build for at the centre, so a faster team is moving in the right direction.
  7. Quality internal platforms: shared, automated and secure paths to production that let AI's benefits scale across the organisation.

Notice how many of these are ordinary good engineering. That is the point of the amplifier finding: the foundations that made delivery good before AI are the ones that make AI pay off.

AI-assisted changes

AI-assisted changes is the share of delivered changes that an AI tool helped write. It tells you how much of the team's shipped work AI took part in, so you can read its effect on speed and quality next to it.

How to read it

On its own the share means little. Our running example team of six, building an online booking app, sees 45% of its merged changes marked as AI-assisted this month. The useful question is how those changes compare with the rest: do they merge faster, are they bigger, do they need fixing more often?

What does good look like?

No published source gives a figure, and more is not better on its own. Read it next to how AI-assisted changes compare with the rest.

How to improve the outcome

  • Keep AI-assisted changes small. DORA names working in small batches as the counter to AI producing large, unstable changes, and the side-by-side comparison below shows whether your AI-assisted changes run larger than the rest.
  • Review them as carefully as any other change. See Changes merged without review.
  • Make sure rolling back is quick and routine. See Failed deployment recovery time.

How Solidafy measures it

The app counts the share of changes merged in the period you choose whose commits carry an AI co-author tag. It reads the tags, never the code. Only hosts that link commits to changes are read; a change from any other host is left out, never counted as written without AI. Changes opened by bots are left out.

Under AI assisted work against the rest, the table "How the two compare" puts AI-assisted changes next to the others for "Changes merged in the period, from commit tags, never from the code":

MeasureWhat it tells you
ChangesHow many changes each side has, so you know how much each number rests on.
Time to mergeThe median time from opening a change to merging it.
Change sizeThe median lines added and removed.
Needed a fixThe share of changes whose deploy was rolled back or hotfixed.

Under the table the app adds its own advice: "Keep AI assisted changes small: size is where the extra fixes usually come from." See AI assisted changes opens the list. Next to it, "AI assisted, by team" shows the share of each team's merged changes that were AI assisted; open a team for its AI-assisted changes.

Weekly AI users

Weekly AI users is the share of a team's engineers who used an AI tool in a typical week. It shows whether the tools have become part of how the team works, or were bought and left unused.

How to read it

A team where two of six engineers use AI each week is in a very different place from one where all six do. Look at it next to spend: low adoption with high spend means paid seats nobody uses. Remember DORA's finding that adoption alone does not improve delivery; it is a starting point, not a goal.

What does good look like?

No published source gives a figure. Compare with your own past.

How Solidafy measures it

The share of each team's mapped engineers who used an AI tool in a typical week of the period you choose, read from the tools' own sessions (for example Claude Code through Anthropic). Only whole weeks count, and only weeks since the app began reading sessions. People in no team are left out, and a shared or bot account is never counted unless bots count in Settings. Teams smaller than the smallest team shown on its own (3 engineers by default, set in Settings) are not shown on their own, so no one is singled out.

The chart "Weekly AI users, by team" shows each team's share with the people behind it, for example "67%, 4 of 6". Open a team to see its AI spend.

AI spend

AI spend is what the organisation pays for AI tools over a period. Spend only means something next to what it buys, so it belongs beside delivery, not on its own.

How to read it

Spend tends to rise as adoption grows and tools change. The question is never just "is it going up?" but "what are we getting for it?". That is what cost per merged change and payback, below, try to answer.

What does good look like?

No published source gives a figure. Compare with your own past, and set a budget.

How Solidafy measures it

The app adds up measured spend from connected AI billing over the period you choose, plus subscriptions entered in Settings, each labelled. Per engineer uses the headcount of the mapped teams. The chart "AI spend by team" splits each tool's spend by each team's share of its active users each week. A tool that does not report who used it cannot be split, so its spend shows as "Not split to a team". Subscriptions you entered in Settings are split by the seats you enter per team, or by each team's share of active users.

AI budgets this month shows each tool and team against its monthly budget, for example "64% of the $2,000 budget used, 12 days left", with a state in words: Under budget, Nearing the budget (80% or more used) or Over budget, and where the month will end at the current pace ("On pace for $X by month end"). Where no budget is set it says Set a budget and suggests one from your recent spend plus 10%. Entered seats count toward the whole bill only.

Claude Code's tools, models, sessions and security have a place of their own: see The Claude Code place.

AI cost per merged change

AI cost per merged change is AI spend divided by the number of changes the team delivered. It turns a bill into something you can weigh against what a change is worth to you.

How to read it

If the booking team spent 1,200 dollars on AI tools last month and merged 150 changes, that is 8 dollars per merged change. Whether that is a lot depends on what a change is worth and how much time AI saved on it. Watch the trend: falling cost per change with stable quality is a good sign; rising cost per change with more fixes is not.

What does good look like?

No published source gives a figure. Compare with your own past.

How Solidafy measures it

AI spend in the period you choose, measured and entered, over every change merged in the same days. Changes opened by bots are left out.

Is AI paying back?

AI pays back when the value it creates is larger than everything it costs, including the hidden costs of learning to use it well. DORA's ROI of AI-assisted Software Development report gives a framework for working this out.

The J-curve

DORA expects most organisations to follow a J-curve: productivity dips for a while after adopting AI, then rises above where it started. DORA calls the dip "the tuition cost of transformation". Three things cause it:

  • The learning curve: people spend time learning new tools and ways of working.
  • The verification tax: people spend time checking AI-generated code they do not yet trust, and there is simply more code to review.
  • Pipeline adaptation: testing and change approval have to scale up to handle the extra volume.

DORA's warning is that initiatives often fail because leaders read the dip as failure and pull funding. The depth and length of the dip depend on how mature your engineering practices already are. DORA names automated testing and continuous integration as keys to bouncing back.

How DORA calculates return on investment

Return on investment (ROI) compares what you gain with what you spend:

ROI = (value minus investment) divided by investment.

On the value side, DORA's framework counts:

  • Headcount reinvestment capacity: time saved, priced as the hiring you no longer need, because the freed capacity goes into new work.
  • Revenue from extra features: more features shipped, times how often a feature succeeds, times its revenue impact.
  • Downtime avoided, or added: based on how many deployments fail (change fail rate), how long recovery takes (failed deployment recovery time) and the cost of an hour of downtime. Because AI is linked to more instability, this can come out negative. DORA calls this the instability tax.

On the cost side: direct hard costs (licences, usage fees, infrastructure and training) plus the J-curve cost (the productivity lost during the dip).

DORA's illustrative example

DORA's report works through a sample scenario. It is an example to start a conversation, not a benchmark: DORA itself calls it "a high-uncertainty estimate meant to spark a conversation, rather than a rigid mathematical formula."

  • An organisation with 500 technical staff on a fully loaded salary of 176,000 dollars.
  • A J-curve dip of 15% lasting three months, costing 3.3 million dollars.
  • Direct hard costs of 5.065 million dollars.
  • A total first-year investment of about 8.4 million dollars.
  • About 11.6 million dollars of value in the year.
  • A first-year ROI of 39%, and a payback period of about eight months.

As a rule of thumb, the report suggests a payback period of 6 to 9 months is a highly successful target for agile teams, while 12 to 18 months is acceptable for large enterprise rollouts that need heavy governance. It also recommends planning conservative, realistic and optimistic scenarios by applying multipliers to value and cost, rather than relying on one number. You can try your own figures in DORA's ROI calculator.

Warning: DORA strongly recommends against using AI productivity gains to cut headcount. The report says it harms morale and culture, can reduce efficiency, and can even discourage people from improving their processes. It frames the gains as capacity to reinvest in new work.

What to watch while you wait for the return

Financial returns arrive late. DORA suggests watching leading indicators first: how often teams use AI to try out new ideas (experiment frequency) and deployment frequency. To make sure speed is not coming at the cost of stability, watch change fail rate and rework.

How Solidafy works out payback

The AI section of the Engineering Delivery app answers "Is AI paying back?" with a worked-out figure, not a measured one. It takes the hands-on hours AI-assisted changes save, less the review time they add, priced at your loaded hourly rate. It subtracts the cost of the extra fixes they need compared with other changes, at your cost of a failed release. Then it sets the result against AI spend.

The card answers with a verdict: "Yes, about 1.4 times" when it returned more than it cost, "Not yet, about 0.6 times" when it returned less, or "Not yet" when it returned nothing. Under it the app shows what it cost, what it returned in engineering time and how many extra fixes it took, and lists the assumptions it used ("Worked out from your assumptions, not measured"). An admin can change them with Change the assumptions in Settings.

The assumptions are yours, in Settings. The defaults are 1.5 hours saved per change, 75 dollars an hour, 0.25 hours of review added per change and 600 dollars per failed release. Change them to match your team. When payback cannot be worked out, the card says Not available and why:

  • "Payback weighs the time AI saves against what it costs, so it needs your AI cost. Add your AI subscriptions in Settings, or connect AI billing. Nothing is estimated."
  • "No AI assisted change was merged in this period, so there is nothing to weigh."
  • "Every change merged in this period was AI assisted, so there is nothing to compare it with."
  • "AI spend is billed per tool, never per team, and this view does not read it, so payback is not worked out here. Nothing is estimated."

What good looks like: more returned than spent. No published source gives a ratio, so watch it move against your own past.

AI against the rest

AI against the rest compares the changes AI helped write with every other change your teams merged. It answers the question that matters more than adoption: are AI-assisted changes reaching customers faster, and are they as safe?

Why watch it over time

DORA's 2026 ROI report expects a J-curve: "a temporary productivity dip and period of instability associated with early adoption," before the gain (ROI report, page 4). It also says that "the depth of the productivity trough, and the duration before growth accelerates remain unpredictable" (page 10). So one month tells you little. The shape over several months tells you whether you are in the dip, coming out of it, or stuck.

The report names the early warning to watch: lead time for changes, to see the effect on speed, and change failure rate, to see whether quality holds (ROI report, page 10). Those are the two lines the app draws.

Where to find it

  • On AI, then AI assistance, the AI assisted work against the rest table compares AI-assisted changes with the rest for the period you chose: how fast they merge, their size, and how often they needed a fix, with the share per team.
  • On Delivery, then Speed, the AI-assisted work against the rest card draws the same comparison month by month, as two charts: median lead time, and the share that needed a fix. Each chart has one line for AI-assisted changes and one for the rest. The card shows once there are at least two months with AI-assisted changes.

How to read it

Read the two charts together. Faster with more fixes is not a gain yet. A good sign is the AI line on lead time staying below the rest while its line on fixes comes down to meet the rest. If AI-assisted changes need more fixes month after month, look at their size and the review they get, and work in small batches, one of the seven AI capabilities.

What does good look like?

No published source gives a figure. DORA expects the AI line to dip before it gains, and says how deep and how long cannot be predicted. Watch it against the rest of your own changes.

How Solidafy measures it

Each month, the app takes the changes merged that were AI assisted and the changes that were not. For each side it shows the median lead time, from first commit to production, and the share that needed a fix. A change counts as AI assisted when its commits carry an AI co-author tag, and only on a code host that links commits to changes. A change from any other host is left out, never counted as written without AI. A month with no change on one side has no point on that line. Changes opened by bots, such as Dependabot, are left out.

Questions the app raises

AI-assisted changes merge faster but need more fixes. Is that bad?

It is a common pattern, and it matches DORA's research: AI is linked to more throughput and more instability at the same time. The status reads Mixed because both are true. Look at the "Change size" row first. If AI-assisted changes are much larger, that is the likely cause: big changes are harder to review and more likely to break. Ask the team to keep AI-assisted changes small, review them as carefully as any other, and make rolling back quick. Then watch whether "Needed a fix" comes down.

AI-assisted changes are slower to merge. Why?

Often because they are larger, so they take longer to review, or because reviewers check AI output more carefully when they do not trust it yet. DORA calls this extra checking the verification tax. Smaller AI-assisted changes and a quick first review help. See time to first review.

Payback says Not yet. What should we change?

First check the assumptions: if the hours saved per change or your hourly rate are far from reality, the answer will be too. Then look at what pulls payback down. Extra fixes cost the most, so fewer failed releases from AI-assisted changes moves it furthest; keeping those changes small is the main lever. Unused seats also add cost without return, so compare weekly AI users with what you pay for. Remember the J-curve: early in adoption a dip is expected.

Why is payback not shown?

The card says Not available with the reason. It needs your AI cost (add subscriptions in Settings or connect AI billing), at least one AI-assisted change merged in the period, and at least one change that was not AI-assisted to compare with. See Setting it up.

Why does the AI-assisted share look low?

The app only knows a change was AI-assisted from an AI co-author tag on its commits, and only for code hosts that link commits to changes. A change from any other host is left out, never counted as written without AI. If your team uses AI but does not add the tag, the share will read low.

Why is our AI spend "Not split to a team"?

Spend can only be split by team when a tool reports who used it. Claude Code usage does; a plain bill does not. Spend nobody can be placed for stays in "Not split to a team".

A budget says Nearing the budget. What now?

It means 80% or more of the month's budget is used. Check the forecast ("On pace for ... by month end"), see which team or tool is driving it, and decide whether the budget or the usage should change. A budget is a line your team chose, not a judgement of anyone.

Learn more

Official sources used on this page:

Related Solidafy guides: