Beyond adoption, the 2 metrics that show real transformation

Two companies report the same number to their boards: 90% of engineers use AI. In one, AI helps developers take on work they would not or could not have done before. In the other, they still use AI as a faster autocomplete. The adoption rate makes them look identical, but they are not.

To tell them apart, you have to look beyond who uses AI and examine how they use it. Day-to-day usage leaves clues about whether a team has changed how it builds or simply sped up the old way.

Earlier this year we published the AI-SDLC framework, a model for the AI maturity stages teams move through as they adopt AI and shift more of the work to it. It describes three stages in the evolving relationship between users and AI. This post is a follow-up: it shows how those stages appear in actual usage data.

A quick recap of the stages

Stage 1, in the loop. The developer writes the code. AI assists: autocomplete, inline suggestions, chat. One developer, one problem, one agent at a time.

Stage 2, on the loop. The developer stops overseeing each agent at all times and instead starts orchestrating several that run in parallel, reviewing, redirecting, and approving as they go.

Stage 3, autonomous loops. Agents run without a human starting them. A trigger fires: a new ticket, a scheduled scan, a merged PR. The human sets direction and validates outcomes.

Most orgs have teams at every stage at once. The question is not "which stage are we in?" It is "where is each team, and are they moving?"

For the full breakdown of each stage, read the AI-SDLC framework.

What the stages look like in real data

The charts below are representative examples of patterns we see across many users. Each is one developer. Every row is one agent or automation. Every mark is an active run, laid out across about ten days. The pattern of marks is the fingerprint of how that person works.

Start with a developer getting going.

Look at the two rows. They never light up at the same time. When Agent 2 runs, Agent 1 goes quiet. This developer drives one agent, waits, reviews, then starts the next. The human is inside every loop. This is Stage 1, and it is where most people begin.

Now a developer further along.

Same kind of chart, a different way of working. Several agents run at once. The rows overlap constantly. This person is not writing code and waiting. They are steering a fleet: kicking off work, checking in, redirecting, approving. They moved from doing the work to directing it. This is Stage 2, and it reflects a completely new way of working.

Then the last stage.

The rows above the line are human-directed agents, the same fleet pattern as before. The two rows below the line are different. These are automations: background agents that fire on events and schedules, taking the human out of the loop. This is Stage 3, where more and more work is being done completely in the background.

Two signals of maturity in the data

There are two numbers that help quantify what these charts show:

Parallelism: how many agents run at once

In Stage 1 it sits at one. In Stage 2 it climbs as people run several at once. Parallelism is the clearest sign that someone has stopped coding and started orchestrating. It is the difference between a faster individual and a multiplied one. When a developer runs several agents in parallel, they are not just faster; they operate at a different scale.

The simple definition: take all the time agents were running for a person, and divide it by the wall-clock time they had at least one agent running.

A score of 1 means one agent at a time. A score of 5 means five agents running, on average, whenever any are running. For example, one agent can update an API while others write tests and migrate its callers.

Autonomy: the share of runs with no human trigger

This is the Stage 3 signal. Count the agent runs that a person started, and the ones that fired on their own from an event or a schedule. The ratio tells you how much of the work now runs without anyone in the loop. At Stage 1 and 2 it is zero: every run has a human behind it. At Stage 3 it climbs, and a growing share of the work happens before anyone opens their laptop.

The simple definition: out of every agent run, count how many were not started by a person.

A score of 0 means every run has a person behind it. A score of 0.4 means four in ten runs fired on their own. A scheduled CVE remediation automation, for example, can scan for vulnerabilities, fix them, and open a PR without a developer starting the run.

Track these two and you learn something seat counts never tell you. Parallelism shows breadth of leverage per person. Autonomy shows how much work has left human hands entirely. Together they separate the teams getting real value from the teams with a lot of licenses.

Parallelism and autonomy measure how work gets done. Output remains the final test, so pair them with an outcome measure your organization already trusts, such as shipping velocity. Output tells you whether results improved. Parallelism and autonomy tell you whether your teams changed how they work.

What the top users do differently

The developers with the highest parallelism and autonomy did not get there by working faster. They changed how they approach their work:

They delegate instead of operate. The Stage 1 developer asks, "can the agent help me write this?" The Stage 2 developer asks, "what can I hand off so I can start three more things?" That shift, from operating a tool to delegating work, is what fills the chart with overlapping runs.

They decompose well. Running several agents in parallel is only useful if you can break work into independent pieces that do not collide. Splitting a problem into independent, delegatable chunks is the new core competency. It looks less like coding and more like running a team.

They build for autonomy. Once a workflow is proven by hand, they wire it to a trigger so it runs without them. Every task they move below the line is capacity they get back, and it compounds: a review workflow that fires on every pull request runs hundreds of times a month, each one a task no person had to start. That is why autonomy is worth more than parallelism. Parallelism multiplies one person's output; autonomy takes the work off their plate entirely.

Change your metrics to transform your outcomes

Adoption tells you who uses AI. Parallelism and autonomy tell you how work gets done. Pair those signals with shipped output to see whether the change produces better results.

The two companies from the start still report the same 90%. But one of them can now see that its engineers have changed how they build, and that the change is reaching production. The other is still guessing.