Linux's escape from the one-approver bottleneck is a lesson for agent teams

When AI agents produce work faster than people can read it, the person approving that work becomes the bottleneck. CJ Avilla, a member of technical staff at Anthropic, drew that parallel on the AI Engineer show, using the history of Linux. He did not, in these excerpts, set out reviewer layers for agents. Applying the Linux model that way is WebPulse's own step.

What was said

Avilla told the story of Linus Torvalds, who created Linux. In 1998, the kernel mailing list showed him near a breakdown. Contributors emailed him patches, which are proposed code changes. They chased him when the patches were not merged. He said he was going on vacation.

The next day, Larry McVoy wrote that the problem was that Linus does not scale. According to Avilla, it took until around 2002 for Torvalds to agree. He moved from a star, where everyone sends work to him, to a network. Avilla described it this way: "we need to work more as a network where we have these layers of trust". Contributors send changes to trusted maintainers, who review them. Only exceptional cases travel upward, and Torvalds still commits to the main code.

Avilla said people who manage many agents might start to feel the same strain. Agents send in tons of pull requests, and the human sits in GitHub approving them. The show notes also mention IBM putting 1,000 engineers on OS/360. A speaker on the show said the team is, in many cases, trying to "reinvent the wheel of these organizational learnings that we had in the 60s and 70s" about building massive human teams.

Why it matters

The talk also treats old organisational knowledge as a design input, not baggage. Linux needed years to change its own structure. A team that skips those lessons may pay for the same breakdown again. A speaker on the show also said humans get lulled into approving everything, which suggests a single approver is a weak safeguard even before volume rises.

The other side

The speakers work at Anthropic and were introducing a product, Flows, built to run many agents. The excerpts do not show layered review working on agent output. They also do not say who the trusted layers should be or how trust is earned.

Linux's maintainers are people. A speaker on the show warned that an agent asked whether its own code is good will tend to say yes. Agents reviewing agents may therefore inherit bias. The OS/360 detail comes from the show notes, and the excerpts never spell out which 1960s and 70s lessons they mean.