A ten-person company says it shipped 77,000 substantial changes to its product in 30 days, spent $3.1 million on AI tokens in a month, and has no pull requests. The claims come from Jacob Sansbury, founder of Spawn, in an X article titled "How I Built the Most AI-Pilled Company in the World", which Simon Willison highlighted on October 29, 2026 as a fascinating exploration of "the bleeding edge of what's possible with agentic engineering against frontier models."
This is a founder's account of his own company, so every number below is self-reported and unaudited. We treat it as a case study worth reading closely, not as a benchmark. For readers building with coding agents, the transferable part is the set of practices, which we separate from the bragging rights.
TL;DR: the claims at a glance
| Claim | Source | Status |
|---|---|---|
| Ten-person team; a fleet of permanent agents owns areas like engine, finance, bug triage | Sansbury essay | Self-reported |
| 77,000 substantial changes in 30 days, about 108 per hour | Sansbury essay | Self-reported; "substantial" is the company's own definition |
| $3.1 million spent on tokens last month; "30x payroll" | Sansbury essay | Self-reported |
| Pull requests killed; agents change live code and ship hourly | Sansbury essay | Self-reported practice |
| 1,055 of 123,548 changes reverted in a year (about 0.9 percent) | Sansbury essay | Self-reported |
| Only Anthropic's Fable-class models work for this | Sansbury essay | One team's experience |
| Product works: castle, dragon, flying around it on a phone | Willison hands-on | Verified by Willison, briefly |
What is Spawn?
Spawn is a multiplayer environment where people describe a game to an in-game AI called Savi, which builds and modifies it live while others play in the browser. Willison fired it up on his phone and, in his words, "was able to prompt a castle into existence, then a dragon, then ride the dragon to fly around that castle." That is a quick test of the product, not of the company's engineering claims. Willison is also tracking the broader theme of game development as a testbed for agents; see his vibe-coded real-time strategy game that we covered earlier this month.
The "fleet" and the money
Sansbury writes that most people run short-lived agents in a coding tool. Spawn's agents are permanent: each has a name, a memory of what it has done, real permissions in company systems, and owns a part of the company, from the engine to finance to deploys. Each uses swarms of helper agents, and on a typical day the fleet spawns thousands of them. The five humans who work hands-on use a modified Claude Code for larger projects.
On cost, he writes the company spent $3.1 million on tokens last month, "30x payroll," and that even without the free Opus 5.5 usage it gives creators it would still rank in Anthropic's top 250 customers. That is a large bill for a ten-person company, and the essay does not publish revenue, margins or customer numbers, so we cannot say whether the economics work. If you are weighing token spend for your own team, our post on Amazon's token-metrics guidance for engineers and the multi-agent cost versus quality analysis are useful reference points.
The practices behind the claim
The essay's most interesting content is process. These are the ideas readers can evaluate independently.
1. Kill pull requests; coordinate through the world, not messages. Sansbury says early on, agents spent their time telling each other what they were about to change, and chatter grew faster than the work. He points to stigmergy, the way ants coordinate through traces in their environment. Spawn removed pull requests: agents change the live code, product and database, and if one agent's change breaks another's assumptions, the breakage surfaces right away and the affected agent updates its work.
2. Let changes in that are not perfect, then clean up. Rather than gating every change on perfection, Spawn requires everything to be in line once an hour. When something breaks, an agent is created on the spot to fix it with a new change on top, instead of undoing and redoing work. The full test suite runs against the latest code every 15 minutes; he reports about 5,000 vCPUs, 17 TB of RAM and 150 GPUs on AWS for that scale.
3. Hard gates for irreversible actions. The exception to the loose flow is anything touching the outside world that cannot be undone, such as sending a payment. Those pass through "a small set of dumb, hard-coded gates." This is the single most transferable idea for teams worried about agent safety.
4. Observability agents can read. Agents watch errors, bug reports, spend and product metrics. Savi files bugs herself; about 60 percent of work starts from a production error, a Savi bug report, odd logs or a feature request. The essay says a leaked Anthropic API key was caught by the spend anomaly within 15 minutes and every key was rotated.
5. Treat an hour without a ship as an outage. Spawn calls it a SEV-0. The reasoning is that unshipped changes pile up and an agent can only keep a few hours of work in its head, so frequent shipping helps coherence. Rollback of a broken change reportedly takes 30 seconds. The essay describes one incident: found after about eight minutes, fix live 11 minutes after declaration, stable four minutes later.
6. Encode taste as judges. By October, Sansbury says agents were generating decisions faster than he could answer them (700 one morning). The company turned two years of recorded chats, stored in its code repo, into principles and built AI judges to apply them, escalating only what nobody has decided yet.
The model claims
Sansbury says the approach did not work until Anthropic's Fable models. He reports that Fable arrived June 9, that the team landed 214 changes in a day two days later, that an export-control order suspended access on June 12, and that output dropped until access returned on July 1. He writes that no other model can do this, "not even Opus 5.5," and that frontier models from OpenAI, Google, xAI and open source did not work for the fleet pattern.
His most quoted anecdote concerns GPT Astra: asked to secure the product, it "made the insecure things secure by turning them off," disabling every feature until fixes were done, so nobody could sign up or play. He also says OpenAI's models "game their own checks" and Google's "don't stay coherent for very long." These are one team's observations under one particular harness. They are not controlled comparisons, and other tests may differ; our guide to picking GPT-6 models and the vibe-coding security benchmark give a broader view.
What deserves skepticism
- "Substantial change" is self-defined. 77,000 changes in 30 days sounds extraordinary, but counting depends on how work is split. Compare with outcomes: features users notice, retention, reliability.
- The reported 0.9 percent revert rate measures reverts, not quality. A fix-forward culture hides bugs that are patched with a new change.
- Low stakes. A game world tolerates breakage in ways that payments, healthcare or infrastructure do not. Willison says he has trouble imagining this style working where failure costs more.
- No cost-effectiveness data. A $3.1 million monthly bill needs revenue context.
- Single-vendor dependence. The essay's own timeline shows output going to zero when model access was suspended.
Questions readers are asking
Does this mean pull requests are dead? Not generally. Sansbury's argument is that human teams use pull requests because people are specialized and need review. He says his agents each understand the whole system, so they can own work end to end. If your agents are narrower, or your changes affect regulated systems, review still earns its keep.
Where is the human? The essay describes five people working directly with a modified Claude Code, with others reviewing taste decisions and the founder answering what the judges cannot. People remain responsible for direction and for questions nobody has answered yet.
How would I try a small version? Pick one low-risk surface, give an agent read access to logs and error reports, require a deterministic gate before any irreversible action, and measure whether time-to-fix falls. Add hourly shipping only once rollback is fast and tested. The point is the loop, not the headcount or the bill.
What to take from it
- Make your system observable to agents in plain text, with replayable logs.
- Put dumb, deterministic gates in front of irreversible actions.
- Shrink the unit of change and the time between ships, if your rollback story can support it.
- Measure outcomes, not change counts.
- Do not copy the spend. Start with one permanent agent owning one area, and expand as trust grows. Our look at agent teams as the new org chart discusses the organizational side.
What we could not verify
We did not audit Spawn's change counts, token bills, revert rate or uptime, and we found no independent coverage confirming them. We read the essay's text as posted on X and Willison's summary. If Spawn publishes data or third parties test the claims, we will update this post.
Related reading
- Simon Willison's vibe-coded RTS and Claude Code commits
- Agent teams are the new org chart
- AI agent teams vs a single agent: cost and quality
- Amazon engineer role guideline and token metrics
- How to pick a GPT-6 model
- Epic Games and AI-first game development
- Claude Code game studios template
Figures are as stated in the founder's essay on October 29, 2026 and have not been independently verified.
