AI adoption is easy to count. Licences, active users, chat sessions, accepted suggestions, prompt libraries: all of them can tell us that a tool is present. They say rather less about whether an engineering organization can entrust meaningful work to an agent without losing control of the result.
That is the distinction I want an AI maturity model to expose.
Safe delegation capacity is the amount and risk class of work which an organization can delegate to agents while preserving its required security, reliability, architectural, delivery and accountability properties.
This is my working definition for the series, not a standardized metric. It is also deliberately about the surrounding system. A stronger model may increase what is technically possible during one run. It does not, on its own, make the requirement clearer, the repository more legible, the tests more discriminating, the permission narrower or the production change reversible.
The decision for an engineering leader is therefore not merely whether to provide an assistant. It is which classes of work may be delegated, under which authority, with what evidence, and how quickly the organization can recover when that evidence turns out to be incomplete.
Candidate production is not delivery capacity
Coding agents can produce candidate changes quickly. This is useful. It can also move the constraint downstream.
Consider a repository in which the system boundary is implicit, tests are intermittent, ownership is unclear and rollback depends on the one person who remembers the deployment. Faster code generation gives that repository more changes to interpret. It does not give it more capacity to accept change safely. Review queues grow, CI results become harder to trust, and plausible local improvements can violate an invariant which the agent was never shown.
The opposite case is more interesting. Intent and non-goals are explicit. Interfaces and ownership are visible. Tests fail for useful reasons. Policy constrains tool access and promotion. A proposed change arrives with evidence, and the production path can stop or reverse it. The model has not become the authority; the organization has made a bounded class of execution delegable.
This is why I would not use model adoption, prompt fluency or generated-code volume as proxies for maturity. They describe activity. The capability I care about is an end-to-end property of specification, execution, verification, governance and operations.
A qualitative systems model
I use the following relationship as a compact review device:
In prose: safe delegation capacity tends to improve with all eight factors shown above.
This is a qualitative model, not a calibrated numerical equation. The plus signs preserve the additive reading of the checklist; they do not claim that the factors are independent, equally weighted or even directly measurable on a common scale. In practice they interact, and a severe weakness in one can bound the usefulness of the rest.
Excellent repository context with weak verification can produce a well-informed mistake. Strong tests with an incomplete architecture view can verify the wrong boundary. Tight policy with poor reversibility can prevent many failures but still make an accepted failure unnecessarily expensive. Measurement without a clear specification can optimize an outcome nobody intended.
So I do not suggest calculating one organization-wide score. I would use the model to examine a particular change class: dependency updates, routine service changes, infrastructure plans, schema evolution, or a progressively rolled-out product experiment. The evidence, risk and reversibility differ. Its permitted delegation should differ too.
Evidence may increase authority; confidence may not
An agent can propose a patch, run a test suite and describe why it believes the result is correct. The description is useful context. It is not the authority source.
Authority belongs to the operating model: approved intent, IAM policy, change classification, deterministic checks, accountable review and production promotion rules. The platform applies those controls and retains the evidence; people remain accountable for the policy, its exceptions and the residual risk. This is the same inner-loop and outer-loop distinction I use in the AI platform architecture series.
The evidence should become stronger as authority increases. Explaining code locally requires little production authority. Opening a pull request requires identity, traceability and a bounded repository permission. Merging, provisioning infrastructure or widening a rollout crosses different boundaries. The model’s fluency should not collapse them into one permission called “agent”.
This is partly a governance concern, but not governance in the decorative sense. The NIST AI Risk Management Framework Core separates govern, map, measure and manage functions, makes governance cross-cutting, and calls for documented roles, testing, monitoring and risk response. It explicitly does not present its actions as an ordered checklist. ISO/IEC 42001:2023 similarly specifies an AI management system built around policies, objectives, processes and continual improvement. Neither source defines safe delegation capacity. They support the less glamorous point underneath it: AI risk control is organizational and lifecycle-wide, not a property inferred from a successful model response.
Why the SDLC platform comes first
Once an agent can act, maturity depends on the machinery through which action becomes a controlled change. That machinery already has familiar parts: repositories, requirements and decisions, CI, test and evaluation systems, artifact provenance, IAM, environments, observability, promotion and rollback.
The NIST Secure Software Development Framework is useful here because it defines high-level secure-development practices intended for integration into an organization’s SDLC. DORA’s catalogue of software-delivery capabilities takes a similar capability lens across technical, process and cultural concerns. I am borrowing that general way of reasoning, not claiming that either source specifies an agentic maturity model.
An AI platform therefore cannot be a model gateway with a collection of prompts attached. It needs the SDLC platform underneath it, because the SDLC is where intent becomes a versioned change, evidence is produced, authority is checked and production consequences are observed. Spec-driven development helps make intent legible to the agent. The delivery system makes execution governable.
This also explains why the term capacity matters. Capacity is not the maximum autonomy demonstrated in a carefully selected pilot. It is repeatable ability under normal constraints: across the repositories and change classes for which the organization can supply adequate context, enforce policy, interpret evidence and recover from failure.
Measure the boundary, not the theatre
A useful maturity review should finish with operational questions:
- Which change classes may an agent attempt, and which remain excluded?
- Which evidence is mandatory before each authority boundary?
- Which permissions exist only for the duration and scope of the task?
- Who owns the requirement, the acceptance decision and the residual risk?
- Can the resulting change be observed, stopped and reversed?
- What have incidents, rejected changes and failed evaluations taught the platform?
The answers will be uneven. Good. An organization may safely delegate routine application changes while keeping schema migrations or production IAM changes under much tighter supervision. Another may have excellent CI and poor system context. A single maturity badge would hide precisely what needs work.
AI raises the rate at which engineering intent can be turned into candidate execution. Mature organizations use that speed without pretending it removes uncertainty. They make the boundary explicit, collect evidence at it, and expand delegation only where the complete system can carry the additional authority.
That—not the number of people prompting a model—is the maturity claim worth testing.