How the Most AI-Pilled Company in the World Works

Context

This episode uses Spawn, an AI-first gaming startup, as an extreme case study in what happens when a company reorganizes around agents instead of employees. NLW walks through Jacob Sanbury's account of a 10-person team running a persistent agent fleet that shipped 77,000 code changes in a month and spent far more on compute than payroll. For PMs, the value is not the spectacle. It is the operating model: how to assign ownership to agents, how to close the feedback loop from production back into development, and what work is left for humans once agents can execute continuously.

The Big Idea

AI-native product development is not just faster execution of the old workflow. It is a different workflow, where agents own ongoing functions, production feeds them continuous feedback, and humans focus on precedent, taste, and direction.

Spawn's example matters because most of the gains came not from adding more AI to existing steps, but from deleting human-era process that no longer fit an agent-run system. For PMs, the takeaway is to redesign the loop, not just add copilots to the old one.

Key Insights

Persistent agents change work

Spawn did not treat agents as temporary helpers that spin up for isolated tasks. It built a persistent fleet where each agent had a name, an identity, memory, and ownership of a function such as engine maintenance, bug hunting, or finance. That matters because the unit of work shifts from one prompt at a time to an ongoing operating system.

A PM should read this as an org-design lesson, not a prompt-engineering lesson. Once agents have durable ownership, the product team has to think about responsibilities, handoffs, feedback signals, and escalation paths the same way it would for human teams.

Human processes became drag

• Spawn found that agents were spending too much time telling each other what they were doing, which copied human coordination patterns more than machine needs.
• Earlier in the year, Spawn removed pull requests and let agents work directly in the code base.
• Jacob's reasoning was that human specialists need lots of communication because each person only understands part of the system. In Spawn's setup, agents understood the broader system deeply enough that much of that communication added little value.
• The PM lesson is to inspect inherited rituals before adding more AI. Some steps exist only because humans need handoffs.

Closed loops beat handoffs

Jacob's critique of most agent setups was that humans still had to tell agents what broke in production. He called that loop messy and wasteful. Spawn instead designed the product so player agents automatically detect bugs and file reports as they move through the game world. A small model triages the issue or feature request and routes it to the relevant agent inside the fleet.

That setup made the software feel self-healing. In one example, an issue was detected eight minutes after it affected a player, the cause was named a minute later, and the fix was live 11 minutes after that. For PMs, the point is that agent autonomy depends on machine-readable feedback from the live product, not just better models.

Precedent scales product judgment

One morning Jacob woke up to 700 requests from the fleet. The key realization was that most of those decisions were not new. Spawn had already made versions of them many times before. So the team turned two years of decision logs into AI judges.

The judges had three jobs:

• If a similar human decision already existed, the judge applied the same outcome and preserved an audit trail.
• If the request was poorly formed, the judge kicked it back to the agent for revision.
• If the situation was genuinely new, the judge handed it to a human.

The result was a real scale effect, not a theoretical one. In the first eight days, the judges made more than 11,000 decisions. About 7,300 used human precedent, about 2,200 were sent back for revision, about 1,800 went to a human, and Jacob himself only had to decide 27 cases. Before judges, the fleet shipped around 1,000 changes per day. After the judges scaled, the fleet shipped more than 7,000 per day.

Human work becomes directional

Jacob's description of the human role changed sharply once the fleet took over more execution.

• Taste: humans play with the product, decide what should exist, and say no even when something technically works.
• Deletion: humans remove systems that are now obsolete because new model capabilities made old scaffolding unnecessary. Jacob said he scrapped six months of work that covered 70% of the engine because it kept feeling one commit away instead of truly coherent.
• Entropy: humans ask for things the models would not propose on their own. Jacob's example was pushing for a world a thousand times the size of GTA to load on a phone in one second.

His claim was that models are very good at building the next 2% of the platform each week, but bad at recognizing when the team has been heading in the wrong direction for days and needs a drastic change.

Advantage compounds with models

Jacob said none of this worked until Fable arrived, and that Fable 5.1 fixed many of the problems that remained. His broader point was that, with the right operating structure, every new model upgrade improves the whole company, not just one workflow.

That is why he thinks the approach is hard to catch up to. The advantage is not just today's automation. It is having a company structure that converts each model improvement into better throughput, better coherence, and faster recovery across the whole system.

Mental Models & Frameworks

Fleet over task bots

• Give agents durable ownership of a function, not just a single ticket.
• Pair that ownership with memory, system access, and a clear responsibility boundary.
• Spawn used this model for areas like engine maintenance, bug hunting, and finance.
• Use this model when the work is continuous. It reduces cold starts and makes accountability clearer than starting from scratch on every prompt.

Work carries the context

NLW's synthesis from Spawn's example was that the shared work artifact should hold most of the context, not endless coordination messages between agents.

• A current record of changes helps agents see what moved.
• A current record of ownership helps agents see who should act next.
• A current record of unresolved issues helps agents see what still matters.

Use this when coordination overhead starts to consume a meaningful share of agent time or token spend.

Precedent-based AI judges

This is the most reusable framework in the episode for PM teams.

• Step 1: search for a similar human decision in past logs.
• Step 2: if the request is unclear or malformed, send it back for revision.
• Step 3: if the case is genuinely novel, escalate to a human.

Use it when repeated judgment calls are creating a leadership bottleneck. Spawn's early results showed that this can remove huge amounts of routine decision traffic without removing human taste from the system.

Self-healing release loop

• Instrument the live product so issues are visible to machines, not just to people.
• Let an automated triage layer route bugs, logs, and feature signals to the right owner.
• Ship frequently enough that the system stays warm and recent changes do not sit stale.
• Back that speed with regular tests. Spawn ran test suites every 15 minutes and treated it as an outage if nothing shipped for an hour.

Use this model when the product can produce fast, structured feedback and the cost of delay is higher than the cost of quick correction.

Decision Principles

Principle: Remove human-shaped process

When: an AI-heavy workflow starts to look like a human team with long reviews, status passing, or rituals that mainly coordinate specialists.

Why: Jacob's core argument was that agents are not built like humans. Process designed for human limitations can become pure overhead in an agentic system.

Principle: Close loops before scale

When: a team wants to give agents more autonomy in production.

Why: Spawn worked because bugs, logs, and user issues flowed directly back into the fleet. If humans must notice failures and relay them, the system loses both speed and recovery quality.

Principle: Escalate only novel calls

When: product, design, or operational questions arrive faster than a leader can answer them.

Why: past decisions are reusable training data. Human attention should go to genuinely new judgment, not replaying the same call hundreds of times.

Trade-offs & Nuance

Autonomy raises infrastructure costs

• Spawn spent $3.1 million on tokens in one month, about 30 times what it spent on payroll.
• The fleet also ran on 5,000 CPUs, 17 TB of RAM, and 150 GPUs on AWS, with another 60% in surge capacity on standby.
• The lesson is not that every company should spend more on compute than people. The lesson is that high agent autonomy can move cost from headcount to infrastructure, and the economics only work if throughput and recovery speed justify it.

Speed needs observability discipline

• Direct code changes with minimal handoff would be reckless in most human teams.
• Spawn made that viable with automated bug intake, tight test cadence, and constant visibility into what the system was doing.
• Jacob's view was that blocking ships was more dangerous because the system functioned better when it kept moving steadily.

Fast recovery beats perfect accuracy

• Spawn accepts that agents will sometimes be a little wrong in code or customer support.
• That tolerance works because problems are noticed quickly and fixed quickly.
• This trade-off does not fit every product category. In categories where a small error is unacceptable or hard to detect, the bar for autonomy is much higher.

Big firms move slower

• Jacob argued that large companies will struggle with this model because closing the loop requires risk appetite.
• Leaders have to let agents break things, trust them to fix things, and redesign governance around that reality.
• That is much harder in organizations optimized for predictable approval paths and heavy process control.

Common Mistakes

Mistake: Stuffing agents into roles

• Jacob's strongest critique was trying to shove AI into human-shaped boxes.
• That mistake shows up when companies judge agents by whether they mimic human workflows instead of whether they solve the underlying problem faster and better.
• A better approach is to design around what agents are actually good at, such as instant response, broad system awareness, and high-frequency iteration.

Mistake: Making humans error relays

• Many teams let agents work on test copies of the product, then wait for humans to notice production failures and explain them back to the agents.
• Jacob said that loop wastes time and breaks the system's speed advantage.
• A better approach is to make the live product observable enough that bugs, logs, and user issues become machine-readable inputs automatically.

Mistake: Letting agents debate endlessly

• Spawn found that agents could waste major effort explaining their work to each other.
• That behavior copied human coordination without much benefit because agents were less specialized and already understood more of the system.
• A better approach is to put more state in the work itself and less state in cross-agent chatter.

Practical Application

Give one agent ownership

• Pick one continuous workflow such as bug triage, release-note drafting, or support-ticket clustering.
• Give one agent or workflow persistent memory, system access, a clear scope, and a success metric.
• The point is to test ongoing responsibility, not just one-off prompting.

Turn decisions into precedent

• Pull the last 20 to 50 product approval decisions from roadmap reviews, design reviews, or support escalations.
• Label why each decision was approved, rejected, or sent back.
• Use that log to build a first-pass AI judge or checklist that handles repeated calls and escalates only truly new cases.

Instrument automatic issue intake

• Route production logs, bug reports, failed user flows, and support complaints into one structured queue that an agent can read.
• Add lightweight triage rules before asking agents to fix anything automatically.
• Without machine-readable feedback, an agentic workflow will stall behind human observation.

Delete one human-era ritual

• Review one ritual such as pull requests, standups, or status updates on a team that already uses AI heavily.
• Ask what actual information the ritual creates, and whether the same signal could live in tests, logs, or a shared artifact instead.
• Remove only one ritual at a time and watch quality, cycle time, and rework.

Protect time for ambition

• Set aside regular product time for two questions: what should be deleted, and what would a 10x or 100x version of the experience look like?
• Jacob's point was that models are good at incremental progress but weak at radical redirection.
• PMs need to supply the ambition that agents will not introduce on their own.

Questions to Consider

• Which parts of your product have feedback loops fast enough that an agent could safely own them, and which parts still need human checkpoints because errors are expensive or hard to detect?
• What repeated product decisions already exist in past roadmap, design, or escalation logs that could become precedent instead of consuming fresh human attention each time?
• Which team rituals mainly exist because human specialists need coordination, and would those rituals still earn their keep if agents understood the full system state?
• If your team tried hourly shipping on one narrow surface area, what observability, test cadence, and rollback path would need to exist first?

Bottom Line

Spawn's example suggests that the real leverage of AI comes from redesigning the operating loop, not from asking the old team to use better tools. Agents can own far more of execution when the product is observable, precedent is codified, and humans spend their energy on taste, deletion, and ambition instead of relaying routine decisions.

Resources Mentioned

People to Follow

Jacob Sanbury

Jacob Sanbury is the person behind Spawn whose writeup anchors this episode. He is worth following if you want to study a concrete, extreme version of what an agent-first software company can look like in practice.