AI coding maturity levels: what your team stopped reading

You think your team is a level higher than it is. The test is not which tools you bought. It is what you stopped reading, and whether anything replaced you.

Your team sits one level higher on the autonomy ladder in your head than it does in your repository. Not because anyone is inflating it. You answered with the level you have the tooling for, because that is the question everybody thinks is being asked.

The tooling is not the level. What decides it is a subtraction: something a person used to read, and no longer does.

How much a person still reads at each level of autonomy Five levels of autonomy shown as bars of decreasing length. At L1 a person reads every completion, at L2 every diff, at L3 the evidence and the gates rather than the code, at L3.5 only the risky changes, and at L4 only the exceptions. The largest drop is between L2 and L3. L1 every completion L2 every diff L3 the evidence, not the code L3.5 only the risky changes L4 the exceptions how much a person still reads, per change
The jump from L2 to L3 is not a tooling change. It is the point where a person stops reading the code and starts reading what the checks say about it, which is only safe if the checks deserve it. Illustrative — the shape of the argument, not measured data.

The ladder, as a sequence of things you stopped reading

The levels-of-autonomy framing has converged across the industry over the last couple of years, and the clearest articulation of it is Ben Blackmore’s six levels of agentic software engineering. The levels are usually described by what the machine does. Read them instead by what the human stopped doing, and they turn into a test you can actually apply:

level what a person stopped reading what has to be true for that to be safe
L1 nothing nothing; you judge every suggestion as it appears
L2 nothing yet, but faster you still read every diff before it merges
L3 the diff your tests, scans and gates are trustworthy enough to read instead
L3.5 the diff, on changes that qualify you can state which services qualify, and why
L4 the request itself the scope is narrow, bounded, and someone owns the escalations

Every row is a transfer of attention, not an addition of capability. You are not gaining a reviewer. You are giving up a reader and asking something else to take the shift.

The claim that gives it away

The most common overstatement is a team that has adopted L3 behaviour with L2 evidence. People have stopped reading diffs properly, because reading a forty-file generated change is miserable and the assistant is usually right. But nothing was strengthened to replace them. The tests are the same tests. The scans are the same scans.

That is not L3. That is L2 with the review quietly switched off, and it holds until the first change that is plausible and wrong, which is the exact failure mode automated review is supposed to catch and unexamined review never will.

The honest version of the question is not “are we at L3?” It is: what would have caught it?

Making the answer specific

The good news is that the question has a concrete answer, and it looks like this:

$ ./gates.sh feature/new-pricing
  contract tests           pass    covers the changed endpoints
  mutation score           71%     threshold 70
  dependency scan          pass    no new advisories
  architecture rules       pass    no new inbound edges to billing
  migration reversible     FAIL    2 of 3 have no down step

Something like that is what a person at L3 reads instead of the diff. If your equivalent is “CI is green” with no statement of what green covers, you have not moved up a level. You have moved the reading somewhere nobody does it.

This is the same split as a deterministic core with reasoning at the edges, applied to review rather than to work: the decidable part of a review becomes a check with a name and a threshold, and human attention concentrates on the part no check can express.

Where the leverage actually is

L1 and L2 arrive on their own within weeks of buying licences, and most teams land there without any deliberate effort. What still varies wildly inside those levels is whether anyone states an exit condition before they start, which is the difference between a good day and a bad one and is worth fixing before anybody argues about levels. L5 is a useful horizon and a poor objective. The distance that pays is L2 to L3.5, and it is not a tooling project.

It is a trust project, and trust here has a measurable form. Every level above L2 is a claim that something automated is a good enough substitute for a person’s attention on a class of change. That claim is either supported by evidence about your checks, or it is a hope with a dashboard.

The two-minute version

Pick a change that merged last week. Ask who read it, what they read, and what they would have caught. Then ask what would have caught it if nobody had.

If the answer to the second question is silence, your level is one lower than the one on your slide, and the work is not to move up. It is to earn the level you are already behaving as though you have.


If you need a truthful placement for each of your teams rather than the one on the slide, that’s the work I do.


Working through this in your own team?

I help engineering teams adopt AI coding assistants without giving up engineering rigour, and design the architecture underneath. If that's on your plate, let's talk.