Agentic Maturity Models

A way to locate where an organization actually is on the path from ad-hoc AI use to agent-native delivery -- so investment and measurement match reality. Pace the metrics to the maturity stage; measuring for autonomy before the foundations exist just produces noise.

The Pattern

An agentic maturity model is a staged framework for locating where an organization actually sits on the path from ad-hoc, individual AI use to agent-native delivery -- and for investing accordingly. It names the stages so leaders can tell the difference between a few enthusiastic power users and an organization that has genuinely changed how it builds.

Most published models borrow their shape from an existing ladder. Sourcegraph frames "levels of code AI" as six steps explicitly modelled on the SAE self-driving levels, running from human-initiated assistance through AI-initiated work to AI-led code where "the AI then designs the architecture, writes production quality code, handles deployment" with the human only validating the result. The AI Codebase Maturity Model (ACMM), inspired by CMMI, instead defines each level by its feedback-loop topology -- "the specific mechanisms that must exist before the next level becomes possible." Both share one claim: the stages are ordered, and "you cannot skip levels."

The model's most load-bearing insight is where the capability actually lives. ACMM's central finding is that "the intelligence of an AI-driven development system resides not in the AI model itself, but in the infrastructure of instructions, tests, metrics, and feedback loops that surround it" -- with test volume, coverage thresholds, and execution reliability called out as "the single most important investment in the entire journey." A maturity model is therefore less a scorecard for the model and more a map of the surrounding pipeline, evals, and context.

Why It Matters

The main use is honesty and pacing. It is easy to mistake a handful of adopters for organizational change, and easy to demand metrics a stage too early. Pace the measurement to the maturity: early on, track adoption and enablement; only later track delivery and autonomy. Skipping stages -- chasing the dark factory before the pipeline can tame it -- automates chaos rather than removing it.

A model also disciplines the metrics conversation. Self-reported numbers exist -- ACMM's reference system reports 91% code coverage, bug-to-fix times under 30 minutes, and 5x PR / 37x issue throughput gains from Level 2 to Level 6 -- but these come from a single open-source experience report, not a controlled study, and should be read as directional. Headline adoption figures are similarly slippery: one engineering org reached 93% developer adoption (only six of roughly 150 not using AI), but got there by treating onboarding as the real problem and training "engineers to train engineers" first, not by handing out tools. A maturity model that reports a high adoption percentage without naming what unlocked it tells you little.

The honest caveat is that a stage label can flatter you. Personal productivity does not automatically become organizational productivity; as Cecilia Borg observes from adopting AI across a 110-person product org, when coding and review time collapse, "the bottleneck just moves to the backlog and product strategy." A maturity model measures the development system, not the value it delivers -- an org can climb the autonomy ladder while its real constraint quietly relocates upstream to ROI and product strategy. Use the model to pace investment and force honest conversation; do not mistake the rung you are standing on for the outcome you owe the business.

Last reviewed: 2026-06-25