When agents write the code, who owns verifying it?

In the first week of June, an engineering leader can open two browser tabs and read one story from opposite ends. The first tab is the May jobs report, surfaced by Tom’s Hardware on June 4: US tech shed 38,242 roles last month, the single worst month in two years, with AI named the most cited reason for layoffs three months running. The second tab is a Fortune piece from June 5, in which Amazon engineers stood up at a Seattle data center hearing and pointed at the capital budget rather than the staffing plan.

Strip the politics out and both tabs say the same thing. Money is moving off the headcount line and onto the compute line, the compute that runs coding agents. So the decision that actually lands on an engineering leader’s desk this month is not whether to adopt agents. That argument is over. It is what shape the team takes on the other side of the move.

What GitLab and Coinbase agent-fleet reorgs actually did

Two companies already redrew the chart in public, and the shape is legible enough to learn from.

GitLab’s board approved a restructuring on June 1, detailed in its own filing and earnings the next day: roughly 14% of staff cut, an exit from about 22 countries, and the part that matters for org design, a reorganization of R&D into close to 60 smaller autonomous teams with AI agents automating the internal reviews, approvals, and handoffs between them. CEO Bill Staples was careful about the framing. He called it “not an AI optimization or cost cutting exercise,” said the savings would be reinvested “to accelerate our unique opportunity in the agentic era,” and added that “in some cases AI can augment and accelerate what team members have been doing, in other places we need to expand certain roles to go faster.” Read that last clause twice. Even in the company most aggressively wiring agents into its own workflow, the plan is not pure subtraction. Some roles expand.

Coinbase drew the sharper version a few weeks earlier, in early May. Its AI-native restructuring cut about 700 people and reorganized around what Brian Armstrong called “AI-native talent who can manage fleets of agents,” with no pure managers and five layers maximum below the top. The headline that traveled was the “one-person team,” a single human carrying engineering, design, and product, backed by a fleet of agents. Armstrong’s stated reason was that he had watched engineers “use AI to ship in days what used to take a team weeks.”

Both moves do the same thing structurally. They collapse the number of people authoring code and re-center the remaining humans on two jobs: directing the agents, and judging what comes back. The first job gets all the press. The second job is where the trouble hides.

Why AI code review becomes the new engineering bottleneck

Here is the trap, and it is a quiet one. When the authoring headcount falls, the work it was doing does not vanish. A meaningful chunk of it relocates to the review queue, and that queue lands on the smaller group of humans who survived the reorg.

The numbers on this are not subtle. LinearB’s analysis of 8.1 million pull requests across more than 4,800 organizations found that AI-generated code waits 4.6 times longer for review than human-written code, and that PR review time has climbed 91%. Sonar’s 2026 developer survey put the other half of the picture on the table: AI now writes 42% of committed code, 96% of developers say they do not fully trust that code, and only 48% always verify it before committing.

Put those two facts next to a reorg that stands up agent fleets and trims the people, and the result is predictable. You have multiplied the volume of code that needs judging while shrinking the pool of judges. The authoring side got cheaper and faster. The verifying side got more expensive and stayed human. An org chart that names who manages the agents but never names who has the capacity to verify their output is a chart that is only half drawn.

Staffing a verification owner in the post-agent org chart

The unit a leader is managing has changed. It used to be engineers who write. It is now a hybrid: fewer engineers who direct, fleets of agents that produce, and a verification capacity that gates what ships. The last of those three is the one that keeps getting left off the diagram.

So before the next reorg, three boxes have to be real, not implied.

First, who directs each agent-bearing pod. This is the GitLab and Coinbase “manages fleets of agents” role, and the only useful version of it is a named, staffed one, not a hopeful relabeling of whoever is left.

Second, who verifies. This is the box almost everyone forgets. It means treating review capacity as an actual number, set against the volume the pod ships. A reviewer-to-output ratio that someone owns and staffs, rather than a tax everyone assumes will pay itself.

Third, where juniors enter. The authoring rungs that used to train new engineers are precisely the rungs being automated away, and this week’s layoff data shows the bottom of the ladder hollowing out fastest. If there is no deliberate path in, the verification role has no one to grow into it in two years.

The post-agent org chart either names a verification owner with real capacity, or it just renames your authors "agent managers" and assumes the review tax pays itself.

That is the decision-question for any leader staring at a reorg slide right now. Not “how flat can we make this,” but “does this chart staff the step that became the bottleneck.”

What I’d tell you over coffee

Do not copy the “one-person team” headline onto a slide and call it a strategy. That is the press-release shape, not the operating shape, and the gap between the two is where good engineering orgs quietly break.

The durable move is unglamorous and takes an afternoon. Before the reorg, write down the reviewer-to-output ratio the team can actually staff. Name the specific human who owns verification for each pod. Protect one onboarding path that survives the automation of grunt work, so the role has a future occupant. None of that fits on a keynote slide, which is probably why so few charts have it.

The companies that look calm two quarters from now will not be the ones with the flattest org chart. They will be the ones whose chart had a verification owner with real capacity, drawn in on purpose, before the agents started shipping faster than anyone could read.