AI platform readiness — what the DORA research actually tells you

TL;DR. The DORA 2025 report found that AI amplifies existing engineering conditions: strong teams become stronger, weak teams become weaker. AI platform readiness is not a question of whether your developers can use Copilot or Cursor. It is a question of whether your platform can absorb the increased throughput, the new verification work, and the changed trust model that AI-assisted development introduces. Four signals tell you where you stand before the evidence arrives in incident logs.

The DORA 2025 report on AI-assisted software development contains a finding that most organizations have not read carefully enough. The report found that AI acts as an amplifier of existing engineering conditions: strong teams become stronger, weak teams become weaker. Source: DORA State of AI-assisted Software Development 2025.

The implication is specific. If you adopt AI coding tools on top of a platform that is already absorbing well, the AI will accelerate the delivery that the platform already supports. If you adopt AI coding tools on top of a platform with unresolved reliability problems, undocumented processes, and weak golden paths, the AI will accelerate the volume of work flowing through a system that is not equipped to handle it. More code, more deployments, more changes — all moving through the same bottlenecks that were already causing problems.

AI platform readiness is not a question of whether your developers can use GitHub Copilot or Cursor. It is a question of whether your platform can absorb the increased throughput, the new verification work, and the changed trust model that AI-assisted development introduces.

What the DORA 2025 data actually shows — three findings worth reading carefully

The DORA 2025 report surveyed nearly 5,000 technology professionals globally. Three findings are directly relevant to platform readiness.

Fifty-nine percent of respondents reported that AI has a positive influence on code quality. Source: DORA State of AI-assisted Software Development 2025. This is a self-report of positive influence, not a measured improvement in defect rates. The distinction matters: developers who accept AI suggestions tend to report feeling that code quality improved, while measured escaped defect rates do not always confirm the self-report. The METR 2025 study found that senior developers using AI were nineteen percent slower than baseline in unfamiliar codebases even when they self-reported feeling faster. Source: METR, Measuring the impact of early 2025 AI on experienced open source developer productivity.

Only 24 percent of developers firmly trust AI-generated code. Source: DORA 2025, cited above. This means 76 percent are reviewing AI output with significant skepticism, which is the correct behavior — but it places a new category of cognitive work on the developer that the platform needs to support. Reviewing AI output is different work from writing code. The platform's job is to reduce the cost of that review work.

The amplifier finding is the one that changes what platform teams need to do before AI adoption reaches scale. The report characterizes AI not as a uniform productivity multiplier but as a force that makes existing conditions more extreme. Organizations with strong delivery reliability, good golden paths, and clear ownership structures saw measurable improvement. Organizations without those foundations saw degradation patterns accelerate.

Four signals that tell you whether your platform is ready for AI-assisted development

Four signals tell you whether your platform is ready to support AI-assisted development without amplifying existing weaknesses.

Golden path quality under AI-generated load. A golden path is ready for AI-assisted development when AI-generated code can follow it without human intervention to handle edge cases. Test this directly: take your most common service creation golden path and ask an AI coding assistant to follow it using only the documented process. Observe where the AI deviates, gets stuck, or produces output that requires human correction before it can proceed through the path. Each deviation is a place where the golden path's API surface, documentation, or automation is insufficient for non-human users.

Most golden paths were designed for humans: they rely on human judgment to fill in undocumented assumptions, to handle ambiguous steps, and to evaluate tradeoffs that the documentation does not resolve. These implicit requirements are not a problem when the user is always human. They become blockers when a significant portion of the work going through the golden path is AI-generated.

Review infrastructure for AI output. The 76 percent of developers who do not fully trust AI-generated code are performing additional review work that was not part of the development workflow before AI adoption. This review work is real cognitive labor. The platform's job is to support it.

Review infrastructure for AI output includes: automated testing coverage sufficient to catch the categories of errors AI tools commonly introduce (context mismatches, subtle logic errors, security anti-patterns), code review tooling that surfaces AI-generated code explicitly so reviewers know to apply additional scrutiny, and deployment guardrails that prevent AI-generated code from reaching production without passing the same validation gates as human-written code.

Measure the review infrastructure gap: what percentage of AI-generated code that reaches production has been validated by automated tests, and what percentage relied on human review alone? Human review is not a reliable quality gate for AI output at scale, because humans reviewing AI output are subject to automation bias — they tend to approve AI suggestions that look plausible without verifying correctness. Automated tests are not subject to automation bias.

Measurement definitions that account for AI-generated activity. The Signal Integrity pillar becomes critical when AI tools are added to the development workflow. Every DORA metric denominator changes when AI tools are widely adopted. Deployment frequency inflated by AI-generated dependency updates is not the same as deployment frequency from engineer-initiated feature deployments. Lead time compressed by AI generating code faster is not the same as lead time compressed by removing process bottlenecks. Change failure rate in a codebase where 30 to 60 percent of code is AI-generated may have different failure mode distributions than a human-written codebase.

Audit your metric definitions against the AI adoption level in your organization before reading your DORA numbers as indicators of AI productivity. Organizations that adopt AI tools and see their DORA metrics improve may be observing genuine improvement, or may be observing metric definitions that were calibrated to a different workflow. You need the definition audit to tell the difference.

Platform permission model for AI agents. AI coding assistants are increasingly operating as agents: running tests, committing code, opening PRs, triggering deployments in automated pipelines. Each of these operations uses platform capabilities that were designed for human operators with human judgment about scope and appropriateness.

An AI agent that has the same permissions as a senior engineer and operates in an automated pipeline without continuous human oversight is a risk the platform was not designed to manage. The blast radius of an agent error is bounded by the platform's permission model. If the platform's permission model was designed for humans, it is almost certainly too broad for agents. Assess your current permission model against the agent use case. Which platform capabilities can an AI agent invoke without human review? What is the worst case if those capabilities are invoked in error? Are there deployment or infrastructure operations the agent can trigger that a human would normally evaluate against context the agent does not have?

The sequencing the DORA research implies: fix weaknesses before scaling AI

The amplifier finding implies a specific sequencing for AI tooling adoption.

Fix the weaknesses before adopting AI at scale. An organization with high change failure rate, poor runbook coverage, and inconsistent golden path adoption will see each of those problems worsen under AI-assisted development. The AI increases the volume of changes. The volume accelerates the expression of existing weaknesses.

Establish the measurement baseline before adopting AI. If you do not have a pre-AI baseline for your DORA metrics and operational signals, you cannot measure whether the AI improved or degraded your performance. The before state is typically lost within two to three months of AI adoption as the team's memory of the previous workflow fades.

Design the golden paths for both human and AI users before adoption reaches scale. A golden path that requires human judgment at three decision points will not be reliably followed by AI-generated code. Redesigning golden paths after AI adoption is more expensive than designing them for AI users before adoption.

The Foundations Framework v3.0 includes a platform readiness checklist for AI tooling adoption in Appendix D. The checklist covers the four signals above plus permission model review, measurement definition audit, and golden path AI compatibility assessment.

What a platform ready for AI-assisted development looks like in practice

A platform that is ready for AI-assisted development shows four observable characteristics.

Golden paths that AI tools can follow without human intervention for standard service creation and deployment. This does not require redesigning the entire platform. It requires identifying the three to five most common workflows and removing the implicit human judgment requirements from each.

Automated test coverage sufficient to validate AI-generated code at the same rate as human-generated code. This typically means expanding test coverage in the specific domains where AI tools are most commonly used, and adding contract tests for the interfaces most likely to be affected by AI-generated code.

Metric definitions that explicitly account for AI-generated activity. Deployment frequency updated to distinguish human-initiated and AI-initiated deployments. Change failure rate updated to track AI-generated code separately from human-generated code until the differential is understood. Lead time definition confirmed against current workflow.

Permission model reviewed for agent use cases, with agent tokens scoped to the minimum capabilities required for their task and blast radius documented for each agent permission grant.

Frequently asked questions

What does AI platform readiness actually mean?

It means your platform can absorb the increased throughput, the new verification work, and the changed trust model that AI-assisted development introduces. A golden path that requires human judgment at three implicit decision points will not be reliably followed by AI-generated code. An AI agent with the same permissions as a senior engineer is a risk the platform was not designed to manage.

How do only 24 percent of developers firmly trust AI-generated code?

The DORA 2025 survey found that only 24 percent of developers firmly trust AI-generated code. The remaining 76 percent are reviewing AI output with significant skepticism — which is the correct behavior, but it places a new category of cognitive work on the developer that the platform needs to support. Reviewing AI output is different work from writing code. The platform's job is to reduce the cost of that review work through automated testing, clear deployment constraints, and explicit contract validation.

What is the minimum readiness work before scaling AI tooling?

Establish a pre-AI baseline for your DORA metrics. Audit your metric definitions against current workflow — definitions calibrated before feature flags and AI tooling are measuring something different from what the label claims. Review the permission model for AI agent tokens. Design at least three golden paths for AI compatibility by removing implicit human judgment requirements.

Why does fixing weaknesses matter before adopting AI?

Because AI increases the volume of changes flowing through your delivery system. If the system has unresolved reliability problems, weak golden paths, or undocumented processes, AI accelerates the expression of those weaknesses. An organization with a high change failure rate that adds AI tooling without fixing the pipeline will see that failure rate climb, not improve — because more changes means more opportunities for the existing failures to surface.

---

The Foundations Assessment includes an AI platform readiness evaluation as part of the Horizon phase. The assessment produces a specific readiness gap report and sequencing recommendation for AI tooling adoption. The free Platform Score surfaces the most critical readiness gaps in fifteen minutes.

For the mechanism behind the amplifier effect, read The AI mirror effect. Why your platform decides whether AI helps or hurts..

For the three DORA signals that tell you which side of the AI amplifier curve you are on, read the AI amplifier — what DORA 2025 is actually telling you about your platform.

For the Cognitive Absorption work that determines whether AI suggestions land in an absorbed platform context or get delegated back to the developer, read Cognitive Absorption in platform engineering — the definitive reference.