Beyond adoption: measure how teams do, delegate, and automate

Two companies report the same number to their boards: 90% of engineers use AI. In one, developers use AI as a faster autocomplete. In the other, they delegate work to parallel agents and automate proven workflows. 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 how teams shift more software work to AI. We now use three plain verbs for that journey: do, delegate, automate. This post shows how those modes appear in usage data.

Do, delegate, automate

Do. Work is human-led, interactive, and focused on one task. The developer writes the code while AI assists. Ona Environments give both the developer and AI the same code, tools, and dependencies.

Delegate. Work is agent-led, runs in the background, and can span parallel tasks. The developer hands outcomes to agents, then reviews, redirects, and approves their work.

Automate. Work is system-led, event-driven, and continuous. A new issue, pull request, or schedule starts an automation. The human sets priorities, defines boundaries, and verifies outcomes.

Most organizations mix all three modes. A developer might do ambiguous product work, delegate a migration, and automate dependency updates in the same week. The question is not "which stage are we in?" It is "how much work happens in each mode, and is that mix changing?"

What the modes look like in real data

The charts below are representative patterns from anonymized usage. Each chart is one developer. Every row is one agent or automation. Every mark is an active run across about ten days. The pattern is a fingerprint of how that person works.

Start with a developer working in a human-led way.

The two rows never light up at the same time. When Agent 2 runs, Agent 1 goes quiet. This developer starts one task, waits, reviews, then starts the next. AI helps, but the human still drives each step. This is Do, and it is where most people begin.

Now look at Delegate.

Several agents run at once. The rows overlap constantly. This person is not writing code and waiting. They hand off outcomes, check progress, redirect, and approve. The move from doing each task to delegating several tasks changes the scale at which one person can work.

Then Automate.

The rows above the line are delegated agents. The two rows below it are automations: background agents that start from events and schedules. The person still sets the policy and checks the outcome, but nobody has to start each run.

Two signals of progress in the data

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

Parallelism: the signal for Delegate

A person in Do has no agent parallelism to measure. As they begin to delegate, the score starts at one and climbs as they run more agents at once. Parallelism is the clearest sign that someone has moved from using AI interactively to handing it work in the background.

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.

Automation rate: the signal for Automate

Count the runs a person started and the ones an event or schedule started. The ratio tells you how much work has moved from one-off delegation into a repeatable system. In Do and Delegate it is zero because a person starts every run. In Automate it climbs as proven workflows run in the background.

The simple definition: out of every agent run, count how many an automation started.

A score of 0 means a person started every run. A score of 0.4 means an event or schedule started four in ten. 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 how much work people delegate at once. Automation rate shows how much repeatable work the system starts. Together they separate broad access from changed behavior.

These signals 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 automation rate tell you whether your teams changed how they work.

What teams furthest along do differently

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

They choose what to do. Ambiguous work, product judgment, and unfamiliar problems often need an interactive loop. Strong users keep those tasks close instead of treating delegation as the goal for every task.

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 automate proven work. Once a delegated workflow works reliably, they connect it to an event or schedule. A review workflow that runs on every pull request can execute hundreds of times a month without anyone remembering to start it. Delegate creates leverage for one person. Automate turns that leverage into a system.

Measure movement, not just access

Adoption tells you who has access to AI. Parallelism shows whether they delegate work. Automation rate shows whether proven workflows run on their own. Pair both 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 can now see work moving from Do to Delegate to Automate, and see whether that movement reaches production. The other is still guessing.