AI Maturity Levels for Engineering Teams: L1 to L4 Explained
Most teams using AI tools are stuck at L2. Here are the four AI maturity levels, how to assess where your team sits, and what the move to L3 actually requires.
The AI engineering maturity model is a framework for understanding how deeply AI is embedded in an engineering system, not just how many AI tools the team has access to. It is a useful diagnostic because it separates two things that get conflated constantly: tool adoption and system transformation.
A team can have Copilot, Cursor, and Claude Code installed across every developer's machine and still be operating at L1. Tool access is not the same as AI-native capability. The maturity model describes the difference.
There are four levels. Most teams that have been actively using AI tools for six months or more are somewhere between L1 and L2. Very few have reached L3. Almost none are at L4. The distribution is not because L3 and L4 are technically hard to reach. It is because the move from L2 to L3 requires changing how the engineering system works, not just what tools it uses, and most organisations have not made that transition deliberately.
Quick Reference: The Four AI Maturity Levels
| Level | Name | What It Looks Like | Key Signal |
|---|---|---|---|
| L1 | Individual Experimentation | Some devs use Copilot/ChatGPT, no shared approach | High variation in AI usage across the team |
| L2 | Consistent Adoption | Most devs use AI daily, velocity metrics up | No quality measurement, no adapted review process |
| L3 | Systematic Embedding | Context infrastructure, Skills library, risk-tiered reviews | You can measure whether AI improved your change failure rate |
| L4 | Full Agentic Workflows | Agents close real production tickets | Engineers direct and verify, not primarily write code |
The rest of this post explains what each level means in practice, how to tell where your team actually sits, and what the move from L2 to L3 requires.
L1: Awareness and Individual Experimentation
At L1, the team understands that AI tools exist and has started experimenting with them. Individual developers are using Copilot for autocomplete or asking ChatGPT to help debug. The tools are being used, but the usage is informal, inconsistent, and not coordinated at the team level.
The characteristics of L1 are: high variation across developers in how much they use AI tools and how effectively, no shared context infrastructure, no agreed-upon workflows, no measurement of impact. Some developers on a L1 team are getting significant individual productivity gains. Others have tried the tools and found them unhelpful. The gap between the two groups is large and unexplained.
L1 teams often believe they are more advanced than they are because they are measuring tool access rather than system integration. "We rolled out Copilot to all engineers" describes tool access. It says nothing about whether the team has changed how it works.
L2: Consistent Adoption but No Systems Change
At L2, AI tools are part of the standard engineering workflow. Most developers use them daily. The productivity gains are real and visible in individual velocity metrics. This is the level where teams typically declare their AI adoption a success and stop investing.
The specific characteristics of L2: developers regularly use AI for code completion, PR description generation, test scaffolding, and basic debugging. The team may have a CLAUDE.md or equivalent in the repository. Sprint velocity metrics have improved. Leadership is happy with the rollout.
What L2 does not have: a shared Skills library, consistent quality measurement, AI-adapted code review processes, or agent-ready infrastructure. AI tools are accelerating individual work. They are not transforming how the system produces and validates software.
The gap between L2 and L3 is where most teams stall. L2 looks like success by the metrics most teams track. The problems of L2, rising incident rates, degraded code review quality, compounding technical debt from AI-generated code that nobody reads carefully, are not visible in the metrics most teams are looking at.
The DORA 2025 report found that teams at this stage show individual productivity gains that do not translate to system-level improvement. More PRs, more incidents. Faster cycle time, higher change failure rate. L2 is where the velocity trap is set.
L3: Systematic Embedding
L3 is the level where AI stops being a productivity tool and starts being part of the engineering system. The distinction is significant and specific.
At L3, the team has context infrastructure: a maintained CLAUDE.md that accurately describes the system, a Skills library that encodes team conventions, and subdirectory-level context files for major components. AI tools in this codebase produce architecturally consistent output because they have accurate context to work from, not because individual developers write good prompts.
At L3, the team has adapted its code review process for AI-generated volume. Not all PRs receive the same review intensity. High-risk changes are routed to senior review. Low-risk changes with full automated check passes go through a lighter process. Review bandwidth is allocated by risk, not by queue order.
At L3, quality is measured at the system level. The team has a baseline for change failure rate, incident frequency, and mean time to recovery. They know whether AI adoption is improving those numbers or degrading them. The measurement exists to be wrong: if it shows things getting worse, that information is used.
At L3, test coverage is agent-ready. Tests describe behaviour, not implementation. They run reliably in CI. Agents can run them and interpret the results. A test suite that only passes when run by a human who knows which tests to skip is not agent-ready, regardless of how comprehensive it looks on paper.
The move from L2 to L3 is not primarily a technical change. It is a decision to treat AI tools as part of the engineering system rather than as accessories to it. That requires changing how context infrastructure is maintained, how reviews work, how quality is measured, and how tests are written. Each of those changes is straightforward in isolation. Together, they represent a change to how the team works that requires deliberate investment and leadership commitment.
L4: Full Agentic Workflows
At L4, autonomous agents are closing real tickets in the production codebase. Not demos. Not sandboxes. Actual tickets with actual acceptance criteria, where an agent does the implementation, runs the tests, and opens a PR that an engineer reviews and merges.
The specific conditions that make L4 possible: excellent context infrastructure (agents navigate the codebase accurately without manual direction), high test coverage with clear behavioural specifications (agents can verify their own work), a Hooks layer that enforces hard constraints deterministically (agents operate within defined boundaries reliably), and clear ticket specifications with acceptance criteria that an agent can verify.
L4 is not primarily about agent capability. The models that can close complex tickets in well-structured codebases exist today. L4 is about codebase readiness: whether the codebase provides the context, the tests, the constraints, and the specification quality that agents need to operate reliably.
Most teams that believe they are close to L4 are actually at L2. The gap is not the model. It is the infrastructure the model needs to work in.
At L4, the engineering team's operating model changes materially. Engineers are directing and verifying systems rather than primarily writing code. The bottleneck is no longer execution. It is context quality, specification clarity, and verification infrastructure. The skills that matter most are different from the ones that mattered most before.
How to Tell Where Your Team Actually Is
The honest diagnostic is simpler than most teams want it to be.
You are at L1 if: AI tool usage varies widely across the team with no shared approach, there is no repository-level context file, and there is no measurement of AI impact on quality metrics.
You are at L2 if: most developers use AI tools daily, you have some repository context in place, velocity metrics have improved, but you have not adapted your code review process, you do not have a Skills library, and you cannot say whether AI adoption has improved or degraded your change failure rate.
You are at L3 if: you have maintained context infrastructure, a Skills library, risk-tiered code review, and active quality measurement that includes system-level metrics. You know whether AI adoption is improving outcomes, not just velocity.
You are at L4 if: agents are closing real production tickets regularly, with engineer review and merge, using your actual codebase and your actual issue tracker.
The most common misclassification: teams that have invested in L1 and L2 infrastructure and call it L3. The test for L3 is measurement. If you cannot say whether AI adoption has improved your change failure rate, you are not at L3 regardless of how good your CLAUDE.md is.
The Investment the Move to L3 Actually Requires
The move from L2 to L3 requires three things that most teams do not have in place.
Accurate context infrastructure. Not a CLAUDE.md that was written once and never updated. A file that is maintained as part of the development process, reviewed when architecture changes, and accurate enough that AI tools produce consistent output based on it. This is an ongoing maintenance commitment, not a one-time setup task.
Quality measurement before velocity measurement. If you do not have a baseline for change failure rate and incident frequency before making the move to L3, you cannot tell whether it worked. Setting the baseline is a prerequisite, not an afterthought. Most teams skip this and then have no way to evaluate whether their investment produced results.
Leadership commitment to the process change. The review process change, the test infrastructure investment, and the context maintenance discipline all require sustained attention from engineering leadership. They do not happen organically. Teams that make the L2 to L3 transition successfully have a leader who treats it as a significant investment, not as something developers will figure out on the side.
The return on that investment is substantial. L3 teams consistently report lower incident rates, faster delivery with higher quality, and better developer experience than L2 teams with comparable tool access. The tools are the same. The system they are running on is completely different. If you want the step-by-step sequence, I wrote a detailed playbook for moving from L2 to L3. And if you are not sure whether your team structure itself is the bottleneck, that is worth examining before investing in the maturity move.
I help engineering teams close the gap between "we use AI tools" and "AI actually changed how we deliver." Book a 20-minute call and I'll tell you where the leverage is.
Working on something similar?
I work with founders and engineering leaders who want to close the gap between what their technology can do and what it's actually delivering.