/Articles
An AI maturity model for software engineering teams
Six dimensions and three stages, scored from how the team actually works rather than from how many tools it has bought.
Most AI maturity models ask how many use cases a company has deployed. That is the wrong question for a software team. The team can have Copilot on every laptop and still be unable to review what it produces.
This model is the one behind the readiness check. Six dimensions, each with a plain description of a weak spot and a stronger one. No level is a pass mark. A team can be further along on tools than on review, and that split is the useful finding.
The six dimensions
Tools. Who uses an AI coding tool, on whose account, and whether that is written down. The weak end is everyone on a personal login. The stronger end is seats the company provides, under a policy the team can point to.
Review. Whether a reviewer can tell that a change was generated, and whether review time was redesigned after the volume went up. Faros AI measured the volume: far more pull requests, and review time nearly doubled. A team that kept the old review habit is not mature on this dimension, however many licences it holds.
Testing. Whether generated code faces the same coverage bar, enforced in CI, and whether the suite would catch a change that is almost right. A test that only restates what the new code does is not that bar.
Delivery stability. Whether cycle time, review time and defects are read before and after the tool arrived. DORA’s 2025 report still ties higher AI adoption to less stable delivery. A team that cannot show its own stability number is guessing.
Governance. Which tools may see code, where customer data and secrets must not go, who is accountable for a generated change, and, for a product sold into the EU, whether Article 50 transparency duties apply. The policy template is this dimension written as clauses a team can fill in.
Skills. Whether engineers can explain a change they did not type, and whether leads know how to judge the rollout with numbers rather than with a demo. The METR trial is the reminder: people felt faster and were slower. Skill here includes knowing that gap exists.
Three stages, not a ladder to climb in public
The same work shows up as three stages of the person, which is how we teach it:
- AI-assisted engineer. Uses the tool on a task and checks every line.
- AI-native engineer. Designs the context and the guardrails, not only the prompt.
- AI team lead. Sets how a whole team adopts the tool, and measures whether it worked.
A company does not “become AI-native” by announcing stage two. A team is at a stage on each dimension separately. The usual pattern is tools ahead of review, and review ahead of governance.
How to use it
Score the six dimensions honestly. The readiness check does that in a few minutes, in the browser, and nothing is sent unless you choose to send it. Then pick the weakest dimension and change that one:
- Thin on governance → start from the policy template
- Thin on review → use the AI-generated code checklist
- Thin on delivery measurement → how to measure AI adoption
- Thin on tools/skills in the repo → context engineering
Read your own cycle time, review time, coverage and defects before and after.
A maturity model that ends in a badge is a poster. One that ends in a number you already collect is a management tool. The second is the one worth having at a licence renewal. This page exists to explain the six dimensions; the score you act on lives on /readiness.