How AI-Native Teams Organize

Give an engineer four coding agents and watch what happens to her day.

Before, she spent most of it producing: about four focused hours writing code, half an hour reviewing a colleague's change, an hour or so coordinating. Now each agent hands back a couple of candidate changes a day. She has to brief every one of them, look at every result, send the bad ones back and pass the good ones to a teammate, who has to read them. Add it up with plausible numbers and her day needs 6.6 hours of focused work. She has six.

Nothing in that day is spent writing code. All of it goes to saying what she wants and checking what she got. And because it doesn't fit, the review queue grows every day until someone notices.

That small piece of arithmetic is the whole argument of this piece. When agents do the producing, a team's capacity is set by how fast its people can direct and check work. How many agents one person can really run depends more on how review is designed than on how good the agents are. Teams that work this way end up reorganizing around that fact whether they plan to or not. The ones that plan it get the gain.

Three things get scarce

An agent here is an AI model that works through a task in steps on its own: reads files, writes code, runs tests, tries again. The examples come from software, where agents are furthest along, but the mechanism applies anywhere output can be produced in parallel and checked.

When one person can keep three or four agents busy, people who can write the work stop being the bottleneck. Three other activities take their place, and agents remove none of them.

Direction. Choosing what to build and describing it precisely enough that an agent can build it and a check can judge it: the outcome, the constraints, what's out of scope, how success will be shown. Before agents, most of this lived in the head of the person who would also write the code. It never had to be written down. Now it does, many times a day.

Verification. Knowing whether what came back is right. Part of it is automatic (tests pass, the build works) and part needs a person who understands what the change was for. An agent that reports success has told you its own checks passed, which isn't the same thing (What Changes When Code Gets Cheap).

Integration. Keeping many parallel streams of change consistent: one codebase that still builds, one set of decisions every stream respects. Agents raise the number of things changing at once.

Anthropic's survey of its own engineers shows the split from the inside. More than half said they could fully hand off at most a fifth of their work: the parts that were easy to verify, low in stakes and self-contained. They kept design and decisions that needed context or taste. One estimated that more than 70 percent of their work had become reviewing and revising code. Extreme early adopters, but the direction is clear.

Fewer people, more collisions

The usual case for small AI-native teams starts with an old observation. Fred Brooks explained in 1975 why adding people to a late software project makes it later: if everyone's work has to be coordinated with everyone else's, the number of pairs who might need to talk grows much faster than the team. Eight people have 28 pairs. Four people have 6.

Halve the team and you keep about a fifth of the conversations. That's the appeal. One person directing four agents can produce what several people produced before, so four people can cover the scope of eight without the meetings of eight.

Here's the catch most teams miss. Agents don't attend meetings, but they do change the same code. Four people running four agents each means sixteen streams of change in flight, and sixteen streams form 120 pairs that might touch the same files, assume different versions of an interface or make incompatible decisions. Brooks's pairs didn't disappear. They moved from conversations into the codebase.

Agents remove conversations between people and add collisions between changes.

What decides how many of those collisions anyone has to think about is ownership. If each person owns a distinct area of the system and points their agents only at it, 24 of the 120 pairs fall inside one person's area, where the owner sees both changes and can sequence them. The other 96 cross a boundary. Nobody sees both sides of those, so they have to be caught by mechanisms that don't depend on anyone noticing: stable interfaces, contract tests that fail when one side breaks what the other expects, small changes merged often, and a build that runs on every change.

This is Conway's law, Melvin Conway's 1968 observation that systems copy the communication structure of the organizations that build them, applied to ownership. Agents follow whatever partition their directors give them. Vague boundaries produce crossings; clear ones, enforced by tests, keep them few.

The review arithmetic

Back to the overfull day, because the numbers show where the team actually breaks and how to fix it. They're illustrative, chosen to be plausible, not measured.

Four people each direct four agents. Each agent produces two candidate changes a day, so each person faces eight. Briefing an agent takes ten minutes. Looking at a result takes ten more. Six in ten pass and go to a teammate for a 30-minute read; the rest cost another ten minutes to redirect. Add half an hour of coordination and half an hour keeping shared context up to date. That's the 6.6 hours.

Scroll sideways to see the whole figure

The problem is that every passing change gets the same careful read. Most changes don't need it.

Now design review around risk. Every change arrives with standard evidence attached (test results, a short summary of what changed and why), which halves the time to triage it. Then reviews come in tiers. Six in ten changes are low risk, mechanical, inside one area and covered by tests: an eight-minute check of the tests and the evidence. Three in ten are medium: twenty minutes. One in ten is high risk because it touches security, money, data deletion, a shared interface or the tests themselves: a full hour, twice the old uniform read.

The average review falls from 30 minutes to about 17. The day falls to 4.9 hours. Same people, same agents.

The clearest way to see it is to ask how many agents one person can keep busy before the day overflows.

Scroll sideways to see the whole figure

With uniform review, the day fills at about 3.6 agents. With tiered review, at about 5.2. Nothing about the agents changed.

How many agents a person can direct depends more on how review is designed than on the agents.

Two second-order effects matter.

Better briefs raise review load. If clearer specifications lift the share of agent work that passes triage from 60 to 80 percent, human time per merged change falls, from about 48 minutes to about 38. But each person's day rises, because more output now reaches review. Investment in direction lands as load on verification, so the two have to be planned together.

The output count is not a forecast. Under these assumptions the four-person team merges about 19 changes a day against the eight-person team's 8. Measured averages are far smaller. Anthropic reported 67 percent more merged pull requests per engineer per day; vendor telemetry from Faros AI found high-adoption teams merging 98 percent more pull requests while review time rose 91 percent (Where the Saved Time Goes). Notice that last number: review time rising almost as fast as output is exactly the bottleneck the arithmetic predicts.

Roles that grow

In a team of four, each person holds several of these. In a larger organization some become jobs.

The specifier turns goals into briefs an agent can execute and a check can judge, with the acceptance test written before work starts. The role merges what product managers and senior engineers used to split, because "what exactly do we want?" and "how will we know?" are now asked by the same person, in writing, many times a day.

The verifier owns the team's ability to tell good output from bad: the test suite and its speed, the risk tiers, the evidence each change must carry, the reading of high-risk changes. Verification is now the largest block of human time, and a weak test suite caps everything else.

The boundary owner answers for an area of the system: approves changes that cross into it, decides merge order when several streams touch it, gets paged when it breaks. Ownership is how those 96 cross-boundary pairs get a home. It also sets a floor on team size that agents don't remove, because someone has to be reachable at night and someone has to cover their vacation.

The keeper of shared context maintains the instruction files, test sets, sandboxes and permissions every agent runs with. It's the role most often left unowned, because each improvement helps everyone a little and nobody in particular.

What shrinks is the handoff: a ticket written by one person, built by another and handed back. When the specifier directs the agents, the middle step goes.

The cost falls on learning. Juniors used to learn by writing code a senior reviewed, and that route narrows when agents write the code. A team built only of seniors directing agents has no pipeline (Skills That Fade When the Machine Does Them). My advice: put people who are learning on verification, with high-risk changes still read by someone experienced. Reviewing is where they now meet the most code.

Review is a capacity, so design it like one

Review grew up as a courtesy, done at whatever depth time allowed. With agents it becomes the constraint, and it has to be sized and tiered like any other capacity.

Decide depth by risk, in advance. Can the change be undone? What can it break if wrong: money, personal data, security, a public interface? Does it cross an ownership boundary? Does it change tests? Test changes deserve suspicion, because an agent that can't make a test pass can sometimes make it pass by weakening the test.

Let machines check first. Build, tests and type checks run before anyone looks. Then a second agent in a fresh session, seeing only the change and the requirements and not the reasoning that produced them, looks for problems. A model reviewing its own work in the same session tends to agree with itself. People see what survives, with evidence attached.

Read a random sample of the low-risk tier. Without it a team can't tell whether "low risk" still means low risk, and reviewers drift into automation bias, approving whatever looks familiar (Reviewing Code You Didn't Write).

Measure two numbers. Hours between a change being ready and someone starting to review it, which tells you whether capacity is short. Defects found after merge, traced to the tier that let them through, which tells you whether the tiers are honest.

And make "done" something that runs. A definition of done in a wiki is a wish. One written as checks (tests that pass, a contract that holds) lets an agent work toward it unwatched and lets a reviewer confirm it without rebuilding the reasoning. The more of "done" that can run, the more agents each person can direct.

Shared context is infrastructure

Every agent starts each session knowing about the team only what its harness, the software around the model, loads into it. That shared material (conventions, commands, architectural decisions, known pitfalls) is now team infrastructure, like the build system.

The conventions have converged on plain text files that agents read automatically, such as AGENTS.md, which its site says more than 60,000 open-source projects use, and Claude Code's CLAUDE.md (Write for the Model That Doesn't Exist Yet).

The team-level point is about authority. An edit to a shared instruction file changes the behavior of every agent every teammate runs, from the next session on. One rule added in a hurry, "always mock the database in tests", can quietly shape hundreds of changes.

A line in a shared instruction file is a team decision with team-wide reach. Review it like one.

Give these files an owner, review changes to them at the high-risk tier, and record why each rule exists. Decisions that agents must respect go into a short log with the reason and the condition for revisiting them, a decision record, so the next brief inherits them.

"This only works in startups"

The strongest objection is that small AI-native teams are a startup luxury. A large company has legacy systems without tests, rules that separate who writes a change from who approves it, on-call rotations, budgets that reward headcount and dozens of interdependent teams.

Much of that is right. The arithmetic above assumed fast tests and clear boundaries. In a legacy system where checking a change means rebuilding its reasoning, review minutes are large, and one person might sustain one agent profitably, or none. The gain from directing agents scales with how cheap verification is. Where checking is expensive, there's little to reorganize around yet.

But the mechanism works at the level of one team, and a large company is many teams. Most of the changes here need no reorganization at all: briefs with executable acceptance checks, review tiered by risk, named boundary owners, instruction files under review. They raise how many agents each existing person can direct well. Some existing rules even fit: segregation of duties already says a change's author can't approve it, the same rule that should hold between an agent and its reviewer.

My forecast, and it is a forecast: in large companies the first visible effect will be teams taking on more scope at the same size. Smaller teams will come later, and mainly where tests are strong.

One caution over everything. In METR's 2025 trial, experienced developers using AI were measured 19 percent slower and still believed afterwards that they'd been about 20 percent faster. A team's sense of its own speed is unreliable. Nobody has yet compared teams that restructured around agents with teams that only adopted the tools. Measure your own.

What to do

Do the arithmetic for your team first. Minutes to brief, minutes to triage, share that passes, minutes to review. If the total exceeds the day, more agents only grow the queue.

Tier review before adding agents. It's the cheapest capacity you'll ever buy.

Draw ownership boundaries and enforce them with tests. Every collision caught automatically is one nobody has to notice.

Keep a learning path. Put juniors on verification and budget it as training.

Measure lead time from request to use, review queue time and escapes by tier. Not how busy the agents look.

Check yourself

Why do four people each running four agents create more collisions than a team of eight?

Sixteen streams of change form 120 pairs that might touch the same files. The pairs Brooks described moved from conversations into the codebase.

What happens to the day if every passing change gets the same careful read?

Review fills the day, 6.6 hours against six, and the queue grows. Tiering review by risk brings the day down to about 4.9 hours with the same people and agents.

Why is a line in a shared instruction file worth reviewing like a high-risk change?

It changes the behavior of every agent every teammate runs, from the next session on. One rule added in a hurry can shape hundreds of changes.