DORA AI-Assisted Development: Throughput Up, Instability Up

The question that keeps coming up in Q4 planning is some version of this: if agents can open pull requests all day, should the pipeline simply be opened up to them? The usual answer cites DORA, and the usual citation is a single sentence that AI makes teams faster. The sentence is incomplete, and the missing half is the one a platform team pays for.

This post reads DORA's own pages and the two InfoQ write-ups closely, separates what each report actually measured, and turns the findings into a metrics query, a CI gate and a Monday checklist. I have not run a DORA-style study on an agent fleet myself. Every number below comes from a source I read, and the SQL and workflow are my sketches, labelled as such.

Which report says what

Most posts about DORA's 2026 findings blur three different documents. The throughput and instability result is from the 2025 State of AI-assisted Software Development survey. The 2026 material builds on it, so it helps to keep the three apart before quoting anything.

One caveat travels with all of it. The Balancing AI tensions sample is Google engineers only, and DORA itself notes respondents may have been primed to talk about code generation by earlier survey questions. Treat it as a close look at one environment, not a census.

What throughput and instability mean in DORA's terms

DORA groups its five software delivery metrics into two families. The pairing matters here because the headline finding is that AI moves the two families in the same direction, which is a change from the previous year's result.

Notice what an agent fleet inflates first. Deployment frequency and lead time are the easiest numbers to improve with automation, and they sit in the throughput family. The two instability metrics only move when something reaches production and breaks, which is why a dashboard built on the first family alone can look excellent while the second quietly worsens.

The finding: more throughput and more instability

Google's summary of the 2025 report says AI adoption among software professionals reached 90%, up 14% from the previous year, and that over 80% of respondents say AI has enhanced their productivity. It also says AI adoption is now linked to higher software delivery throughput, which it describes as a reversal of the previous year's finding.

InfoQ's coverage of the same report adds the other half: software delivery instability continues to rise. The researchers also tested whether AI's speed could offset instability through rapid failure and quick repair, and found no benefit from that. Fast recovery did not cancel out the extra failures.

InfoQ also reports a quieter result that platform teams should read twice: high-quality internal platforms correlate with a slight increase in instability, which the researchers call risk compensation. My reading, and it is only a reading, is that a safer-feeling pipeline invites larger or riskier changes. That makes an agent behind a good platform a case for guardrails, not an argument against them.

Where the instability comes from

The Balancing AI tensions article names three tensions. The first is a verification tax: it cites the 2025 report as finding that 30% of developers report little to no trust in AI-generated code, and says time saved writing code is re-spent on verification and prompting. Google's own summary puts the other end at 24% reporting a great deal or a lot of trust.

The article's sharpest line is that verification is a fundamentally different cognitive task than creation. A reviewer who skims a plausible diff is the mechanism by which subtle bugs, technical debt and hollow documentation reach production, which the authors flag as a short-term risk they expect to shrink as tools mature.

The other two tensions are an expertise paradox, where AI lowers the barrier to entry but can bypass productive struggle, and a workflow gap, where prototypes arrive fast but production integration with internal systems and edge cases can take longer than writing the code by hand. The article attributes the gap to AI mostly serving inner-loop work so far, and expects it to narrow as agents reach outer-loop workflows such as CI/CD.

The J-curve and the instability tax

The 2026 ROI report is where the cost side gets a price. As InfoQ summarises it, most organisations should expect a temporary productivity dip before long-term gains, caused by the learning curve, the verification tax and the need to adapt testing and change approval to higher code volumes. The report calls this the tuition cost of transformation, and warns that leaders who read the dip as failure risk pulling funding before the return arrives.

Its sample calculator turns instability into money. InfoQ reports that the example assumes a change failure rate rising from 5% to 6% after adoption, which produces a negative downtime impact of $344,000. The authors present this as a reason to invest in automated testing, continuous integration and small batches, not as a reason to delay adoption.

Two cautions apply. The report itself calls its calculations a high-uncertainty estimate meant to spark a conversation, so the $344,000 is an illustration of method, not a forecast for your company. And the productivity side is uneven: InfoQ cites a Stanford finding of a 35 to 40% gain on simple greenfield tasks but often 10% or less on complex legacy code, which is where most platform teams actually work.

Measure it yourself before adding agents

DORA's definitions only help if you can split them by author. The query below assumes a deployments table, which most teams can build from their CD tool's history, and an author_kind column set from a pull request label. The shape of the query is mine; the five metric definitions are the ones in the table above.

-- Wrong: this is the number an AI rollout makes look wonderful, and it
-- says nothing about whether the changes held.
SELECT date_trunc('week', deployed_at) AS week, count(*) AS deployments
FROM deployments
GROUP BY 1 ORDER BY 1;

-- Right: the five DORA software delivery metrics, split by who authored
-- the change. Assumes one row per production deployment:
--   committed_at, deployed_at   timestamptz
--   author_kind                 'human' | 'agent' (set from a PR label)
--   needs_intervention          bool  (rollback, hotfix or manual fix)
--   is_rework                   bool  (unplanned deploy caused by an incident)
--   recovered_at                timestamptz, null when the deploy was fine
SELECT
  date_trunc('week', deployed_at)                         AS week,
  author_kind,
  count(*)                                                AS deployment_frequency,
  percentile_cont(0.5) WITHIN GROUP
    (ORDER BY deployed_at - committed_at)                 AS median_change_lead_time,
  percentile_cont(0.5) WITHIN GROUP
    (ORDER BY recovered_at - deployed_at)
    FILTER (WHERE needs_intervention)                     AS median_failed_deploy_recovery,
  round(100.0 * count(*) FILTER (WHERE needs_intervention)
        / count(*), 1)                                    AS change_fail_rate_pct,
  round(100.0 * count(*) FILTER (WHERE is_rework)
        / count(*), 1)                                    AS deployment_rework_rate_pct
FROM deployments
WHERE deployed_at >= now() - interval '90 days'
GROUP BY 1, 2
ORDER BY 1, 2;

Run it for a human-only baseline first, then re-run it after agents are enabled on one repository. If deployment frequency rises and the change fail rate or rework rate rises with it, you have reproduced DORA's finding locally and you know which lever to pull. If only the throughput columns move, that is the good outcome the amplifier framing describes.

Guardrails in CI, and what they cost

DORA's recommendation to work in small batches so AI-generated changes stay reviewable and testable can be enforced mechanically. This workflow rejects agent-labelled pull requests above a changed-line limit. The 400 lines is an arbitrary starting point of mine, chosen to be reviewable in one sitting, and nothing in the DORA material endorses that exact figure.

# .github/workflows/agent-batch-gate.yml
# Keeps agent-authored changes small enough for a human to verify.
# The 400-line ceiling is MY starting policy, not a DORA number: tune it
# against your own change fail rate.
name: agent-batch-gate
on:
  pull_request:
    types: [opened, synchronize, labeled]

jobs:
  size:
    if: contains(github.event.pull_request.labels.*.name, 'agent-authored')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0   # the three-dot diff needs the merge base
      - name: Fail when an agent PR is too big to review
        env:
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          MAX_CHANGED_LINES: "400"
        run: |
          CHANGED=$(git diff --numstat "$BASE_SHA"...HEAD \
            | awk '{ s += $1 + $2 } END { print s + 0 }')
          echo "changed lines: $CHANGED (limit $MAX_CHANGED_LINES)"
          if [ "$CHANGED" -gt "$MAX_CHANGED_LINES" ]; then
            echo "::error::Split this change. Small batches stay verifiable."
            exit 1
          fi

The trade-off is real. A hard ceiling pushes agents to split work into many small pull requests, which raises review count and queue time, the very verification load the first tension describes. A gate that cuts instability but doubles reviewer interruptions has only moved the cost, so watch median change lead time after you enable it.

A second limit: the label that marks agent-authored work is only as honest as the people applying it. If agents open pull requests through a shared bot account, tag by that identity rather than trusting a manual label, or the split in the SQL above will quietly mix both populations.

What to do on Monday

Start with measurement, because every other decision depends on a baseline you do not yet have.

1. Pull 90 days of deployments and compute all five DORA metrics for human-authored changes only. Save that as the baseline.
2. Add an agent-authored marker to pull requests, preferably from the bot identity, and split the dashboard by author_kind.
3. Enable the batch-size gate on a single repository in warning mode first, then enforce it once reviewers agree the limit is workable.
4. Replace any dashboard tile showing lines or suggestions accepted with change fail rate, deployment rework rate and review turnaround.
5. Tell leadership to expect a dip. Write down the J-curve before the first rollout so a slow quarter is not read as failure.

Re-read the split after one full month. A rising rework rate with a flat lead time says your tests are the bottleneck, not your agents.

The rule I take from DORA is that throughput gains are not evidence of a healthy pipeline. Adopt agents the way you would adopt any change that raises deployment volume: with the instability metrics on the same dashboard, a baseline taken first, and batch sizes small enough for a person to verify.