Research / 2026-09-11

Three levels of AI adoption in an engineering team: where your team is and what changes next

A way to place an engineering team on one of three levels of AI adoption, the signals you can see in a week, a ten question self check, and what moves a team from one level to the next.

For CTOs, VPs of Engineering and founders who own an AI initiativeRoc Rizzardini, CEO of Viaro Networks8 min read
Three levels of AI adoption in an engineering team: where your team is and what changes next

What this document is. A way to place an engineering team on one of three levels of AI adoption, using signals you can observe in a week, and a description of what changes when a team moves from one level to the next. The levels come from running the shift to AI driven development inside client teams over the past year. The numbers come from four published sources, each cited with its date. Where I say what I saw, it is experience, not a statistic.

1. Why "adoption" is the wrong number

Every survey now reports adoption above ninety percent, and every one of them reports a different second number that matters more.

DORA's 2025 State of AI-assisted Software Development report, based on responses from nearly 5,000 technology professionals, found that 90% report using AI at work and more than 80% perceive that it increased their productivity. But only 65% rely on AI "at least a moderate amount", and 60% use it about half the time or more when they hit a problem. Nine in ten touch it. Six in ten lean on it.

DX, which measures AI use at more than 500 organizations each quarter, reported on April 1, 2026 that the average share of merged code written by AI moved from 22% to 27.4% between two quarters. Among daily users the figure was 30.8%. DX's own reading: the tooling improved faster than teams adapted to it.

Faros AI's 2026 engineering report, built on two years of telemetry from 22,000 developers and more than 4,000 teams, found that 80% of teams now exceed the 50% weekly active user threshold for AI tools and that the acceptance rate of generated code rose from 20% to 60%. The same report found median time in code review up 441.5% and incidents per merged pull request up 242.7% between periods of low and high adoption.

Jellyfish's 2026 State of Engineering Management report, a survey of more than 635 CTOs, engineering managers and engineers, found that 91% say their team's productivity increased in the past twelve months, 84% say productivity is a top management concern, and 64% report a velocity increase of 25% or more with AI.

Put those together and the picture is not "adopted or not". It is a team where nearly everyone has a license, a third of the merged code comes from an agent, the review queue is the new bottleneck, and management is convinced it is working while still worried about it. Which of those sentences describes your team depends on the level it is on.

2. Level 1. Mandate without practice

What it looks like. The board or the CEO asked for results with AI. There are licenses. Each developer uses them their own way, mostly for autocomplete and questions. There is no standard for what gets delegated to an agent, no rule for how generated code is reviewed, and no baseline to compare against. Someone was recently named responsible and does not know where to start.

Signals you can observe in a week.

What the sources say about this level. DORA's 2025 model lists a clear and communicated AI stance as one of seven capabilities that amplify AI's effect; without it, DORA writes, developers act either too conservatively or too permissively, and use goes underground. McKinsey's August 2026 global survey found that 80% of respondents say AI improved their individual productivity while only 37% of organizations report any effect on earnings. Level 1 is where that gap lives: individuals gain, the team does not.

What changes next. One team, not the whole organization. A written stance (which tools, for what, reviewed how). Tools configured to the stack. A baseline taken before anything else: cycle time, review time, rework rate, share of the team with AI in its daily flow.

3. Level 2. Half the team adopted, the other half did not

What it looks like. Some developers visibly produce more with agents. Others do not touch them or do not trust the output. The quality of generated code varies by who prompted it. Review has become the bottleneck, and nobody can say with numbers whether the team is faster. This is the most common level and the one I have spent the most time in.

Signals you can observe in a week.

What the sources say about this level. Faros calls it the senior engineer tax: median time in review up 441.5%, average time in review up 199.6%, and pull requests merged with no review at all up 31.3%, because reviewers cannot keep pace. GitClear, on 623 million code changes from 2023 to 2026, found duplicated blocks up 81% and refactoring down to 3.8% of changed lines. DORA's capabilities for this stage are working in small batches (amplifies AI's effect on product performance and turns friction into a net positive) and strong version control practices, including frequent rollback.

What changes next. The senior who already works well with agents stops being an exception and becomes the standard: a delegation list (what the agent does alone, what it does with supervision, what it never does), a review rule that runs on every generated change before a human looks, and a PR size limit that is enforced. The laggards are brought in on real tickets, next to that senior, not in a training. Before and after metrics are published to the team.

4. Level 3. The practice exists and they want to take it everywhere

What it looks like. One team works well with agents and has measured the improvement. The organization wants to replicate it in five teams, extend it to QA, CI/CD, documentation and integrations, and make it survive when the two enthusiasts who built it rotate out.

Signals you can observe in a week.

What the sources say about this level. DORA's remaining capabilities are the ones that matter here: AI accessible internal data (a multiplier for individual effectiveness and code quality), healthy data ecosystems (amplifies the effect on organizational performance), a quality internal platform (when platform quality is high the effect of AI on organizational performance is strong and positive; when it is low, negligible) and a user centric focus (without it, DORA writes, AI can propel a team faster in the wrong direction). McKinsey's high performers, 6% of respondents, are the ones who redesign workflows rather than insert AI into existing ones: nearly three quarters of them did, against one quarter of everyone else.

What changes next. A pod, not a person: several seniors with specialties (development, automated QA, platform) working across teams with a formal transfer plan. The practice becomes part of the platform. Measurement moves from the team to the organization.

5. A ten question self check

Answer yes or no. Mostly no in the first block means Level 1. Yes in the first block and no in the second means Level 2. Yes in both means Level 3.

Block one.

  1. Can you state the share of the team with AI in its daily flow, from data rather than a guess?
  2. Is there a written stance on which tools are allowed and for what?
  3. Does the repository contain context for the agent (architecture, conventions, how to run tests)?
  4. Did you take a baseline of cycle time, review time and rework before the initiative?
  5. Is one team, with one owner, running the practice on real tickets?

Block two.

  1. Is there a delegation list that says what the agent does alone and what it never does?
  2. Does an automated check run on every generated change before a human reviews it?
  3. Has median time to first review stopped climbing?
  4. Can the pilot team show a before and after with the Level 1 metrics?
  5. Would the practice survive if the two people who built it left?

6. What I have seen move a team one level

Three things, in every team where it worked.

The first was a senior inside the team, not a consultant beside it, doing the same tickets as everyone else with the agent and showing the work. Developers copy what they see a peer do on their own codebase. They do not copy a slide.

The second was measuring before touching anything. The teams that skipped the baseline spent the following quarter arguing about whether it was working. The teams that took it spent that quarter improving the number.

The third was treating review as the product of the practice rather than its casualty. Every time a reviewer caught the same kind of mistake twice, that mistake became a rule the agent read or a check that ran before the pull request opened. The review queue came down not because people reviewed less, but because less arrived that needed a senior.

None of this is a statistic. It is what held.

Sources