The Self-Coordinating AI Company

The AI industry has crowned a new measure of success: revenue per employee. The bragging rights that once went to a valuation now go to whoever keeps the headcount lowest, and the numbers behind it are real. Bloomberg has called this the era of the tiny team, and the most-watched AI companies now report millions of dollars of revenue for every person they employ. Bolt, the coding tool from StackBlitz, reached twenty million dollars of annual revenue within two months of launching — on a team you could fit in a single room. The lesson everyone draws is simple: use more AI, hire fewer people.

That lesson is half right, and it is the dangerous half. Revenue per employee is a scoreboard. It tells you the game was won; it does not tell you how. The thing that actually wins the game is hidden behind the number — a single system that coordinates a small group of people and a fleet of AI agents so they build as one team, at the same speed. Build that system and a small team out-builds a far larger one, and keeps pulling ahead. Skip it, and the same AI tools produce a bigger mess, faster. This is the real prize, and it is invisible from the outside, which is exactly why it lasts.

The problem the metric hides

The moment a team starts building by prompting an AI instead of typing code by hand, something changes that no one warns them about. The work comes out faster, but so do the collisions. A developer writing by hand merges work into the shared codebase a few times a day. A team building by prompt produces finished changes by the hour, and every one of those changes is a chance for two people to touch the same file, make the same assumption, or half-build the same feature at once.

This is not a feeling; it has been measured. Researchers at Stanford's Institute for Human-Centered AI found, in a 2025 study, that the best coding agents lose close to half their capability the moment they have to share work with another. The same study found that an AI agent will read a warning that it is about to overwrite someone else's change — and overwrite it anyway. The natural response is to reach for the tools that used to keep human teams in step — a ticket queue, a daily stand-up, a shared board. They do not work here, and the reason is precise. A ticket is sized for a day of work, and it adds a slow translation in the middle: someone writes the ticket, a builder reads it, and only then turns it into a prompt. You have placed a human-paced pipe in front of machine-paced work. Two people building from two laptops feel quick on their own and slow together, and they blame the clashes when the real fault is the pipe.

We learned this before we fixed it. Our own operating manual still carries the record — a run of incidents where one session's work quietly overwrote another's, where the shared working folder left changes half-saved and unrecoverable, where two builders reached for the same code at the same time. We did not write a rule about it because we read a study; we wrote it because we lived it. What followed is the heart of everything else. We stopped trying to keep people in step with each other and let the system keep the work in step instead. Every builder, human or agent, works in their own isolated copy of the code. A piece of work has to be claimed before it can be touched, and only one builder can hold it. A guard at the moment of saving refuses any change that comes from the wrong place. Two builders can no longer collide, because the system will not let them — and the same rules hold whether the builder is a founder at a laptop or an AI agent running in the cloud.

Every problem the industry reports, and the answer we already run

Once that first system was in place, something became clear: nearly every failure the industry now documents about building with AI is a version of the same missing thing. They look like a dozen separate problems needing a dozen separate fixes. They are symptoms of one gap, and we had been closing it incident by incident.

Take the quality of what the AI writes. Independent analysis has found that code written with AI carries noticeably more defects, and in security terms markedly more weaknesses, than code written by hand. We have felt the sharp end of this, and built for it. Any change to the parts of the business that move money — pricing, payouts, scoring — is blocked at the moment it is committed unless a named person signs it off, with every override recorded. An AI agent can write such a change; it cannot ship one quietly.

Take the flood of duplicated code. A 2025 analysis by the code-analytics firm GitClear found that AI roughly multiplied the amount of copy-pasted code in projects, and that this is where hidden debt gathers. We watched a version of it in our own product, where a feature copied from a slightly stale source carried a small inconsistency across the codebase. So we made reuse the default and regeneration the exception: before anyone writes a line, a lookup names the single correct source to copy from. The duplication never starts.

Take the bottleneck that has moved from writing code to trusting it. The industry now reports that AI lets teams merge far more code while the time spent reviewing it climbs steeply, because there are not enough human hours to check it all. We hit this in the ordinary run of work: in one recent session an agent quietly broke part of how our articles are prepared for search, and introduced a flaw that would have stopped the next morning's content from publishing. Neither reached a customer, because the checking is no longer done by a tired person reading every line. A single sweep runs the full set of automated checks over the combined work: the type checks, well over a thousand tests, a security scan, a check that flags any database change not yet applied. It caught both faults before release. A human reviews only where human judgement actually matters.

The quieter problems fall the same way. Agents lose the thread of a project after a few exchanges, so we keep the thread in the codebase, not in the AI's short memory. It is an operating manual and a set of notes that every builder re-reads at the start of every session. Knowledge gathering dangerously in a few heads is a known risk for small teams. For us it lives in the repository, so bringing a new human or a new AI agent up to speed is the same act of reading the same rules. Nothing is trapped in anyone's head. And the hardest one — that judgement does not compress, that strategy and pricing and a security call can be helped by AI but never owned by it — we do not pretend to solve. We route those decisions to a person, at fixed points: the decision to release, the sign-off on anything that touches money, the decision to publish. The machine carries everything else.

There is an honest point to make here, and it belongs in the open. None of these guards stop a mistake from being made; they stop it from being made quietly. The broken search step happened in a recent session; the collisions happened before we built the claim system. What changed is that the system now catches them before a customer does, every time, without depending on a human being watchful on the day. That is the difference between building with AI and being safe with it.

Why the lead grows instead of holding

Here is the part that turns careful practice into a real advantage. The same system that keeps two founders from colliding keeps the two dozen AI agents we run from colliding, and would keep many more in step the same way, without a single change to how it works. That quietly rewrites the cost of growing.

The same coordination that holds two builders together holds two dozen — so adding capacity stops meaning adding cost, and growth stops slowing the company down. (What that collapse in the price of capacity does to a company's economics is a subject of its own.) Two teams built differently are not a fixed distance apart; they are on different paths, and the gap between them widens with every step.

A rival with three founders and the very same AI tools does not escape this, because the tool is now the same on both sides. If anything it hurts them, because a powerful AI takes away the effort that used to enforce good habits. Writing a fourth copy of something by hand was painful enough that you reused instead. But an AI agent writes the fourth copy in seconds, so a team without discipline copies more, not less. And they cannot attach a fleet of AI agents to a ticket queue and a chat channel — a ticket cannot be handed to a program running in the cloud. The day they decide they want that capacity, they have to stop and build the coordinating system first. One road ends at the limits of a human team. The other is the way in to a workforce.

So the honest answer to why a tiny team out-builds a larger one is not "we used AI." Everyone will use AI. It is that we built the system that lets people and AI agents work as a single team at the speed the AI writes, and that same system is the way in to the workforce. It runs two founders and two dozen AI agents today without being rebuilt, and would run far more the same way. That is why the lead keeps growing instead of holding — and why the real prize of an AI company was never the intelligence. It was the coordination.