Over the past few years, I have worked hands-on with multiple software engineering teams delivering software for large enterprises. I have helped teams establish and scale AI use across the software and product development lifecycle, built adoption accelerators, and led demos and training. I have also spoken with dozens of companies about what is working, what is stalling, and what changes when AI-assisted work reaches normal enterprise delivery.
The pattern I keep seeing is straightforward. A person or small group gets an AI coding tool. The demonstrations look promising. Then the work reaches the team. Reviewers need to understand it, security rules apply, domain knowledge is incomplete, and product decisions are still ambiguous. The constraint shifts from whether the model can produce something to whether the organization has made context, workflow, verification, and learning shared enough for the work to be trusted.
This is a draft maturity model built from those observations, not an industry standard or certification. The technology is moving quickly, and I expect parts of the model to evolve as models and tools improve. The organizational capabilities underneath it should remain useful even as the implementation gets easier.
Model at a glance
Jump to the part of the model that is most useful for the workflow you are assessing.
Overview: Three horizons · The maturity model
Levels: L1 · L2 · L3 · L4 · L5
Synthesis: The key leaps
Five observations shaped the model
- Access is not adoption. A license creates experimentation. It does not create a shared way of working.
- Repeatability is an organizational asset. Useful context, instructions, tools, checks, and handoffs need to move out of individual habits.
- A trace is not proof. A complete activity record can still lead to the wrong result. Trust requires evidence connected to intent.
- Shipping reliably is different from learning what to build. Delivery and product learning are related but separate capabilities.
- Enterprise scale changes the risk. Shared practices can spread a useful pattern or a weak assumption across many teams.
Three horizons organize the progression
The five maturity levels sit inside three broader horizons. I use the horizons to distinguish the kind of value an organization is creating and the investments needed to support it.
Horizon 1: Individual productivity / personal acceleration (L1). The value belongs primarily to the person using the tool. An engineer understands a codebase, drafts a test, investigates a failure, or prepares a change faster. A product owner drafts a story, improves acceptance criteria, creates a mockup, or examines business logic hidden in code. The individual still supplies most of the context and judgment.
Horizon 2: Trusted team delivery (L2–L3). Effective individual patterns become repeatable team workflows. Verification and control then make those workflows safe enough to participate in delivery. The value moves from faster personal execution to repeatable throughput and trusted change.
Horizon 3: Governed product evolution (L4–L5). Delivery evidence connects to product and operational outcomes. Learning changes priorities, evaluations, and shared capabilities. At the highest level, those changes can travel across a portfolio without erasing local ownership or exceeding the organization’s ability to govern them.
The maturity model
Maturity belongs to a workflow, not to a company as a permanent label. A mature enterprise may keep an infrequent or highly ambiguous workflow at Level 1 while requiring Level 3 controls for routine work near production. The consequence of the work should determine the control.
Level 1: AI-Assisted Execution
Level 1 is where useful adoption begins. People use copilots, chat tools, and agents inside an otherwise familiar delivery process. They may work much faster, but the result still depends on personal context and judgment.
What I see
The best Level 1 users are not simply better at prompting. They understand the system well enough to choose the right files, bound the task, notice a hidden contract, and ask for evidence before accepting a change. Much of that practice remains invisible. One person has a careful routine, another accepts the first plausible result, and a third repairs every weak output manually. The team sees finished work but cannot tell which practices produced it.
What to put in place
- Approve tools and start with bounded, reversible tasks.
- Teach task framing, context selection, output review, and safe escalation.
- Keep normal source control, tests, review, and release controls in force.
- Measure accepted work, review effort, rework, and defects rather than prompts or generated lines.
- Capture recurring task shapes that could become Level 2 workflows.
The gate
Advance when the team can name a repeated task, the context and checks it needs, the conditions that should stop it, and the person who owns the result. If success depends on one person remembering the right prompt sequence, the capability is not yet shared.
Level 2: Engineered Agent Workflows
Level 2 begins when a team packages repeatable work. The agent can retrieve approved context, call scoped tools, follow a task sequence, run checks, and prepare a handoff. The workflow carries the practice instead of relying on one person’s memory.
What I see
This is where enterprise adoption starts to become durable. A second person or team can run the workflow and get a comparable result. When it fails, the team can inspect the source list, tool contract, instruction, check, or handoff. The durable assets are not the model choice. They are the organization’s context, task definitions, permissions, examples, evaluation cases, and operating rules.
What to put in place
- Build a shared context layer with named owners, source authority, and freshness expectations.
- Package reusable skills, examples, scripts, checks, and stopping rules with the workflow.
- Use a spec-driven development flow so intent, constraints, and acceptance criteria arrive before execution.
- Integrate Jira or Azure DevOps, repositories, documentation, and CI through scoped tool contracts.
- Fund enablement through champions, office hours, feedback channels, and visible disposition of failures.
The gate
Advance when the output can be checked against explicit intent and acceptance criteria, and a responsible person can inspect what remains uncertain. Repeatability earns the right to verify the workflow more seriously. It does not earn release authority.
Level 3: Verified Delivery System
Level 3 connects intent, execution, independent verification, review, and release. This is where I am willing to discuss meaningful AI-assisted delivery performance because the organization can explain why a result should be trusted.
What I see
The delivery record starts before the code. It includes the task, constraints, acceptance criteria, plan, sources, changes, checks, failures, and unresolved questions. Retries and corrections remain visible.
Practitioner evidence. In one deliberately narrow benchmark suite that I built, context-assisted execution completed 9/9 acceptance cases, compared with 1/9 for direct prompting and 5/9 for the harness's native planning alone. This does not prove that one approach wins everywhere. It shows what happened when controlled work received stronger context and verification. In a separate modernization effort, work estimated at 12–16 weeks was delivered in four. AI acceleration helped, but the schedule changed because scope, dependencies, isolation, review, and verification were explicit enough for the team to move quickly without losing control.
What to put in place
- Start with reviewable intent, constraints, and acceptance criteria.
- Run relevant evaluation suites, independent tests, security checks, and policy checks.
- Give reviewers a concise evidence packet with failures, exceptions, and unresolved questions.
- Establish enough provenance and traceability to replay a set of work.
- Match release gates and rollback or recovery paths to the consequence of the work.
- Pair cycle time with review effort, rework, failed changes, escaped defects, and recovery time.
The DORA delivery guidance is useful because it treats throughput and stability together.
The gate
Advance when delivery evidence connects to the product in use and can change priorities, evaluations, controls, or workflow design. Reliable release and a basic feedback loop are necessary, but together they do not yet create a product-learning system.
Level 4: Closed-Loop Product System
Level 4 connects product intent, delivery records, production behavior, user feedback, and the next decision. Agents can collect and synthesize evidence, while people decide what the evidence means and what should change.
What I see
The workflow no longer ends at merge or deployment. Teams define the expected outcome, release the change, observe the result, inspect unexpected effects, and update the backlog, context, evaluation set, or control. The hard part is not adding telemetry. It is agreeing on which signals matter and who can act on them. I often see corrections disappear at organizational boundaries because operations, reviewers, product teams, and customer-facing teams learn in separate queues.
What to put in place
- Define a product hypothesis, expected signals, important segments, and intervention conditions.
- Connect product telemetry and operational evidence to the delivery record.
- Route feedback across product, engineering, operations, security, risk, and customer-facing teams.
- Measure task success, reliability, exceptions, support burden, cost, accessibility, and security where relevant.
- Protect customer data and distinguish useful correlation from evidence of causation.
- Feed learning back into the backlog, shared context, evaluation cases, and controls.
The gate
Advance when local learning can improve shared capabilities without overriding local context. The organization needs to know which adaptations may travel, who approves them, how their effects are observed, and how a harmful change is contained.
Level 5: Governed Adaptive Software Factory
I use Level 5 cautiously. It does not describe a self-governing organization. It describes an enterprise that can reuse and improve AI-assisted delivery capabilities across a portfolio while keeping policy, ownership, evidence, and intervention visible.
What I see
Shared platform owners provide context services, approved workflow components, controls, observability, and evaluation infrastructure. Product and domain teams retain authority over intent, customer commitments, local context, and acceptance of domain risk. The system can detect stale sources, evaluation drift, weak model-routing rules, or recurring failures across teams. The failure mode is centralization without accountability, where one weak assumption travels farther and faster.
What to put in place
- Use a federated operating model with explicit platform, product, domain, security, and risk ownership.
- Govern context through authority, access, freshness, retention, provenance, and named owners.
- Version skills, prompts, evaluation sets, tool contracts, routing rules, and policy controls.
- Tier autonomy by consequence, reversibility, production exposure, and regulatory impact.
- Monitor evaluation drift, policy exceptions, source freshness, incidents, and the distribution of risk.
- Preserve exception handling, change management, and the ability to pause or contain shared behavior.
The OWASP Top 10 for LLM Applications is a practical reminder that the surrounding system must address threats such as prompt injection.
The gate
There is no final gate where the system governs itself. The continuing test is whether adaptation remains observable, bounded, correctable, and accountable to named people. If the organization cannot pause, inspect, and contain a shared behavior, the system has exceeded its operating maturity.
The key leaps
Repeatable workflow to verified delivery
Level 2 can show what the agent read, changed, and ran. Level 3 must show that the delivered change met an explicit requirement and identify who accepted the remaining risk. Both may use agents, tests, traces, and review. The difference is whether those artifacts support a delivery decision.
Many teams can remain productively at Level 2. The investment required for Level 3 may not be justified for every product or workflow. Adopt the controls that match the consequence of the work instead of pursuing a higher label.
Verified delivery to product learning
Level 3 asks whether the intended change was built and released with adequate evidence. Level 4 asks whether the change improved the work, product, or outcome it was meant to affect. A traceable deployment can still teach nothing about customers or operations. Product signals without a delivery record can be just as hard to interpret.
Product learning to governed reuse
Level 4 can learn inside one product or workflow. Level 5 allows context, controls, evaluations, routing, and workflow components to improve across products. That reuse can compound value and mistakes. Governance keeps a local lesson from becoming an unexamined portfolio rule.
Start with one workflow
Choose a workflow that matters, identify the consequence of getting it wrong, and assess the context, evidence, controls, and feedback it already has. Build the next missing capability before expanding authority. The goal is not to claim a higher level. It is to make useful work easier to trust.