What is an AI-native engineering team?

A team whose structure, review process, and definition of done were rebuilt around the fact that most code is generated rather than typed. Buying assistant licences for an unchanged team is not the same thing, and it tends to produce more output with the same review capacity, which is why delivery stability gets worse.

Which engineering roles shrink on an AI-native team?

The hours spent producing lines of implementation code drop by a large amount, particularly for well-specified work. What does not shrink is the number of senior people needed, because the work they do changes to specification, architecture, and deciding whether generated output is correct rather than merely plausible.

Which step becomes the slowest?

Review and verification. The amount of code AI can write grew by a large factor and the amount people can read did not grow at all, so the queue of changes waiting for a person to confirm they are safe becomes the limit on delivery. Teams that do not automate the routine part of that check end up limiting their own throughput.

What is the job that has no title yet?

Ownership of the check suite: one person accountable for whether a passing build actually means the software works. This is distinct from writing tests. It covers deleting checks that cannot fail, fixing flaky ones (checks that pass or fail at random), and keeping the suite aligned with what the product must guarantee.

Do AI-native teams need fewer senior engineers?

No, and often they need more. Junior work was mostly the well-specified implementation work that AI handles well, while the work of specifying, reviewing, and deciding architecture, which depends on judgment, is exactly what senior engineers are paid for. Teams that cut seniors and keep volume tend to discover this within two quarters.

How does onboarding change on an AI-native team?

The thing a new engineer must learn first is the check suite and the specification format, not the codebase layout. Someone who understands what the system must always guarantee can be productive quickly even in unfamiliar code, whereas someone who has memorised the file structure but not the invariants will approve changes that break them.

What happens to code review?

It splits in two. The routine part, checking that behaviour is preserved and limits still work, moves to automated verification because a machine does it better and does not get tired over a long diff. The human part becomes design questions only: is this the right structure, does it belong here, is the abstraction going to hurt us later.

How do you measure an AI-native team?

By outcomes and stability rather than volume. Commits, pull requests, and lines released stopped being useful measures once producing code became cheap. Change failure rate, recovery time, escaped defect count, and the share of changes that revise something released within the last 30 days are the ones that still show real differences between teams.

How long does the transition take?

Roughly a quarter for a small team to change its process, and longer for the habits to last under deadline pressure. The common failure is going back to manual review the first time an incident happens, which loses the automated verification that would have prevented the next one.

Does this apply to teams that only use AI for part of their work?

Yes, proportionally. The structural pressure comes from the ratio of code produced to code verified, so a team generating a quarter of its changes feels a quarter of the pressure. The point at which structure has to change is when the review queue is no longer empty at the end of a normal week.

What an AI-native team actually looks like: Reveneau

We spent the last year working with teams at different stages of becoming AI-native, meaning they changed how they work around AI writing most of the code, and what separates the ones that got faster from the ones that only got busier is not tooling. Every team we saw had the tools. The difference was whether anyone had changed the structure of the team to match how the tools actually changed the work.

Here is what we keep seeing: one job shrinks, one job has more work than people can handle, one job becomes senior work, and one job appears that nobody has a title for.

The writing job shrinks, and that is the least interesting part

This is the change everyone mentions first and it is the one that matters least.

Yes, the hours a senior engineer spends producing implementation lines drop, by a large amount for well-specified work. No, that does not mean needing fewer senior engineers, and the teams that made that assumption are the ones currently hiring again.

The reason is that the work which got faster was the well-specified work: the endpoint whose contract was already written, the migration whose structure was decided, the form whose validation rules were listed. That work was mostly how junior engineers built skill and mostly what a large team spent its normal working days on. The work that did not get faster is deciding what should be true in the first place, and that is not a volume problem.

There is also a warning worth remembering here. In a randomised controlled trial published in July 2025, METR gave 16 experienced open-source developers 246 real tasks in codebases they already knew well. With AI tools they took 19 percent longer, and afterwards estimated they had been 20 percent faster. METR labels the finding historical, since the tools have improved, and that is a fair caveat. The part that stays true is the gap between measured speed and felt speed. If skilled professionals cannot tell whether they got faster or slower, then "the team feels faster" is not evidence of anything, and a restructure justified by that feeling is being justified by nothing.

The reviewing job has more work than people can handle, and this is the real limit

The amount of code AI can write went up by a large multiple. The amount humans can read went up by zero. That is the main structural fact of an AI-native team and everything else follows from it.

A reviewer reading the fourth substantial diff of the day is not the reviewer who read the first. Attention gets worse across a long diff and it gets worse faster when the code looks correct, because code that looks correct gives the reader nothing to stop at. Generated code almost always looks correct. It has consistent naming, sensible structure, and a comment on the function that does the wrong thing.

So a team that doubles its output and keeps one reviewer has not doubled its output. It has doubled the queue and moved the risk to a later stage, where it shows up as change failure rate.

The measurement of this is in Google's 2025 DORA report, which surveyed nearly 5,000 technology professionals. Ninety percent use AI at work. AI adoption showed a positive relationship with delivery throughput and a negative relationship with delivery stability at the same time. More changes reaching production, a higher share of them going wrong. DORA's own description is that AI makes stronger whatever the organisation already is, which is another way of saying that a team with weak verification gets faster at producing rework.

The structural answer is that the routine half of review has to move to a machine. Whether behaviour was preserved, whether a permission limit still works, whether an unusual case is handled: these are exact questions, a computer answers them better than a tired human, and it answers the four hundredth one as well as the first. What stays with people is the half a machine cannot do, which is design judgment. Is this the right structure. Does this belong in this service. Will this abstraction hurt us in six months. We covered what remains in what good code review looks like and the specific reading technique for generated diffs in how to review AI-generated code.

The specification job becomes the most valuable hour in the week

This job became more important, and nobody announced it.

Writing down what must always be true, precisely enough that a machine can enforce it, used to be paperwork that a senior engineer did unwillingly after the work was done. On an AI-native team it is the input that determines whether the generated implementation is correct or merely convincing. An ambiguous sentence in a specification does not produce a clarifying question from a model. It produces confident code that chooses one meaning, whichever one was most common in the model's training data.

That makes specification a senior activity, and it changes what a good week looks like for your most experienced people. Less time reading diffs, more time in meetings deciding what the system must guarantee and writing those guarantees in a form that can fail. We wrote the mechanics of this up separately in how to write an acceptance test a machine can run, and the longer treatment is in writing specs an agent can verify.

One practical consequence: the document that new engineers should read first is no longer the codebase overview. It is the set of invariants. Someone who knows what the system must always guarantee can work safely in code they have never seen. Someone who has memorised the folder structure but not the guarantees will approve the change that breaks one.

The job with no title: somebody owns the check suite

Every AI-native team that stayed fast had one person responsible for whether a passing build meant anything. Every team that slowed down had a suite that belonged to everyone, which is to say nobody.

This is not "writes the tests". Everyone writes checks. Ownership is a different job and it is mostly deleting and fixing checks:

Finding checks that cannot fail. A surprising number of suites contain assertions that would pass against an empty function. Nobody notices, because they pass.
Removing flaky checks fast. A check that fails one run in twenty teaches the team to re-run the build, and once that habit forms the suite has stopped blocking bad changes.
Removing checks that mirror the implementation. These break on every refactor while catching nothing, and they are the main reason engineers start to dislike the suite.
Keeping the suite focused on what the product must guarantee rather than at whatever was easy to test.

Without an owner, a suite becomes useless in about two quarters and the team quietly goes back to manual review, which removes the throughput gain. The failure modes are described in when evals give false confidence.

Where the role sits varies. On small teams it is a rotating responsibility with a named person each quarter. On larger ones it is a job for the platform team. What does not work is assuming it will happen because everyone agrees it is important.

What to measure once the structure changes

Volume metrics stopped being useful the moment producing code became cheap. Counting commits or merged pull requests on an AI-native team measures the tool, not the team.

The ones that still show real differences:

Change failure rate. The share of changes that require a fix, rollback, or patch.
Failed deployment recovery time. How long from breakage to restored service.
Escaped defects. Found by customers rather than by a check.
Rework share. What proportion of this month's changes revise something released in the last 30 days. This is the clearest early signal that the team produces code faster than it can verify it.

If throughput is up and the last three are up with it, the team is not faster. It is creating problems for later, and they show up as more incidents and as parts of the codebase nobody will change. We covered the wider argument in measure engineers by outcomes not output and the specific set in metrics for AI code quality.

What the transition actually costs

A quarter, roughly, for a small team to change its process. Less than people expect, provided it is not run as a large company-wide change programme.

The sequence that works: pick the three flows where a silent failure would be most expensive, write the guarantees for those flows as checks, add them to the pipeline as a check that blocks bad changes, name an owner for the suite, and then stop. The suite grows as part of normal work after that, following two rules. Cover the area you are about to change, and turn every escaped defect into a permanent check so the same bug cannot happen twice.

The sequence that fails is the coverage-target initiative running for a quarter. It produces a large number of low-value checks around the easiest code, gets cancelled when a deadline arrives, and then gets cited for years as proof that verification does not pay.

The other failure worth naming: going back to old habits under pressure. The first serious incident after the transition creates strong pressure toward "everyone reviews everything again". That instinct removes the automated verification which would have caught the second incident. The correct response to an escaped defect is a new permanent check, not a new manual step.

Thanks to the engineering leaders who let us sit in their planning sessions during a restructure and were honest about what was not working. The honest version is more useful than the version people present at conferences.

The tools changed what a team produces. Only the structure changes what a team can be sure of.

Related guide: Moving a team to AI-native development.

Sources

Google Cloud, Announcing the 2025 DORA report: nearly 5,000 respondents, 90 percent using AI at work, positive relationship with delivery throughput and negative relationship with delivery stability.
METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (July 2025): 16 developers, 246 tasks, 19 percent longer with AI tools against a self-estimated 20 percent speed-up. METR labels the result historical.

What an AI-native team actually looks like