R&D Management 21 min read

How a 10-Person Team Ships Hourly with an AI Agent Fleet (No PRs)

Spawn, a 10-person multiplayer game platform company, uses a fleet of persistent AI agents to handle development tasks from bug reports to deployment, achieving 77,000 changes in 30 days with hourly releases, automated testing every 15 minutes, and AI-assisted decision-making, while humans focus on product experimentation and high-level trade-offs.

Architect
Architect
Architect
How a 10-Person Team Ships Hourly with an AI Agent Fleet (No PRs)

Resident Agent Fleet Handles End-to-End Development

Spawn, a multiplayer game creation platform, operates with five engineers and a large fleet of persistent AI agents called fleet . Each agent has a name, remembers its past work, holds actual system permissions, and owns a domain such as engine, operations, finance, bug triage, or deployment. They also spawn helper agents for subtasks, reaching thousands of concurrent helpers on typical days. The engineers use a modified Claude Code for large, exploratory projects.

This setup became viable only after the Fable model appeared; earlier models caused too much chaos. Spawn's user-facing AI, Savi , files bug reports when users hit issues or when Savi itself encounters errors. Reports go directly to a triage agent that classifies them as genuine bugs, known non-fixes, or product decisions needing human input. Fixes are often delivered to the affected user within an hour, with results posted back to the original Savi chat. One incident went from report to production in 15 minutes, including a review rejection and rework.

Canceling Pull Requests: Who Finishes Last Adapts

Agents initially spent excessive time coordinating. With humans, different specialists must collaborate via PRs; but each agent understands the whole system and can own a task end-to-end. Spawn abolished PRs. Agents now read the latest code, live product, and database directly and proceed. If Agent A changes player data structures while Agent B writes a leaderboard, whichever finishes second adapts to the other's changes. No upfront consensus is required.

To avoid a queue of perfectly correct changes, Spawn tolerates short-term incompatibilities and requires agents to resolve them within the hourly cadence. When a conflict appears, a new agent is spawned on the spot to append a fix. This relies on agents being available 24/7 — even at 2 AM on Christmas — so no human wake-up is needed.

Review by Fresh Agents; Full Test Suite Every 15 Minutes

Reviews still happen before merge. The authoring agent asks a helper agent that did not write the code to inspect and actively trigger errors. The 15-minute fix mentioned above included such a review rejection.

Pre-submit: the agent runs the code and uses the product to validate its own change.

Full test suite runs against the latest code every 15 minutes.

Changes do not wait for a full test run individually. When the periodic suite catches a regression, an agent examines the last 15 minutes of changes, locates the cause, and appends a fix. The founder notes this window is sufficient for root-cause isolation. This demands heavy compute: ~5,000 vCPUs, 17 TB RAM, and 150 GPUs on AWS. Irreversible external actions (payments) are guarded by a few hard-coded rules. Over the past year, 1,055 of 123,548 changes (0.9%) were reverted; some issues were fixed by follow-up changes instead, so 0.9% is not a defect rate.

Agents Monitor Production Directly

To eliminate human reporting latency, production errors, bug reports, logs, and metrics are fed straight to agents. ~60% of work originates from these sources plus user feature requests. Every execution step must leave a traceable, replayable text record. Errors are first triaged by a small model, then routed to an agent.

Agents also watch product metrics. A login flow may pass automated tests yet leave users confused; such issues surface only from real usage patterns. In the creator-facing tooling, agents actually playtest games using the public @spawnco/client (same client Savi uses). Commands: spawn client join enters a room as a player; spawn client run play.js executes scripted actions (e.g., walk to a cube, press E, verify state change). The client returns ordered action logs and script results; errors and timeouts are recorded. Keys are released and movements cancelled at script end to avoid contaminating the next playtest.

Debugging entry points: agent/logs returns script logs from live rooms with file paths; agent/health checks server liveness, throughput, and memory; agent/report lets external agents file platform bugs with a failed request ID, replies routed back to the creator's Savi chat. Internal fleet scheduling, memory, and full-test orchestration are not publicly documented.

Agents also monitor costs. When an Anthropic API key leaked, they detected anomalous spend within 15 minutes, revoked the key, and rotated all team keys.

Hourly Deploy Rule: Unshipped Changes Rot Agent Context

The founder explains the "one hour without deploy = SEV-0" rule: unshipped changes accumulate, existing production issues keep hurting users, and agent feedback loops stretch. Agents can only retain a few hours of working context; frequent shipping keeps their reasoning coherent. Achieving hourly, zero-downtime deploys took weeks of dedicated engineering; the old system ran in parallel during transition.

Rollback is pre-engineered: partial rollback of only the faulty component within 30 seconds. Alerts from monitoring or logs wake or spawn an incident agent. The team also runs deliberate fault injection to verify recovery. In one recorded incident, players were affected for ~8 minutes before detection; cause identified 1 minute later; fix deployed 11 minutes after incident declaration; stability restored 4 minutes after that.

AI Judges: 700 Pending Decisions → Automated Precedent Lookup

By October, the founder faced 700 pending decisions in one morning — feature go/no-go, API additions, deletions — exceeding his throughput. Many repeated past judgments: "too complex," "acceptable trade-off," "runs but feels wrong." Since inception, Spawn stored call transcripts as text in the code repo. Two years later, they extracted each person's decision principles and built AI judges that answer new questions by retrieving prior rulings.

On receiving a question, an AI judge:

If a clear past answer exists, it decides and cites the record.

If the question is malformed, it returns it to the asking agent.

If no precedent exists, it escalates to a human.

From Oct 6 (first AI judge ruling) over eight days: 7,296 auto-decisions, 2,213 returned, 1,863 escalated. The founder personally ruled on only 27 items. Corrections are written down and fed back into the judge's context for future cases.

Starting Small: One Real Bug End-to-End

The article contrasts Spawn's no-PR model with Stripe's Minions (which keep human review) and StrongDM's three-person AI pod (which uses spec and end-to-end scenario acceptance outside the implementation repo, plus third-party service mocks for boundary/failure testing). A concrete starting point for existing projects: Feed a real ticket (version, repro steps, expected result, logs) to an agent in an isolated environment; it must reproduce the bug or return missing evidence. Human defines acceptance criteria; agent codes, runs independent verification and regression tests. Adopt Stripe's two-CI-attempt limit: first CI failure → retry; second failure → hand back to human with failure logs. Continue through existing PR, human review, and release flow. Post-deploy, verify via original steps; close the loop in the original ticket or user session. Measure time-to-fix, human interventions, token cost, and reopen rate; compare against the old process to see which step was eliminated.

Humans Still Do Trade-offs and Experiments

Despite automation, the five engineers spend significant time personally using the product . They build games, test playstyles, and feed discovered gaps to agents. One engineer builds a 2D game to probe Spawn's 2D capabilities. Working results can still be vetoed. An agent substituted distant players with capsules and spheres; the founder rejected it: "render properly or don't render stand-ins." Another agent made Savi think longer on every message; deployed at 22:22, reverted at 22:40 for excessive latency. Humans also delete long-standing systems. After a model upgrade, designs added for the previous model can become constraints. In June, the founder re-evaluated a server-side simulation system built over six months (~70% of engine code) that was perpetually "one more commit away." He asked: "What reason remains to keep it?" The team deleted it; in July they decommissioned its servers. Humans set goals agents wouldn't conceive. The founder stopped an agent that had spent two days and $100k chasing 1-3% incremental gains, redirecting to a ground-up faster architecture. Another goal: "load a world 1000× larger than GTA on a phone in one second." This drove Spawn 6; the release notes describe streaming only the player's vicinity and progressively loading the rest. "One second" was the target; no measured result is disclosed. Some problems require physical hardware. A crash on an old AMD GPU couldn't be reproduced in cloud rentals. A rendering engineer spent a day sourcing the card in European shops, brought it home, networked it, and gave agents access to reproduce . Agents fixed the bug in hours. The bottleneck was a human plugging in the legacy GPU.

References

@jsnnsa: How I Built the Most AI-Pilled Company in the World (X/Twitter thread)

Spawn website, product intro, agent interface docs: https://www.spawn.co, https://www.spawn.co/about, https://www.spawn.co/llms.txt, https://www.spawn.co/openapi.json Spawn official playtest client: @spawnco/client 0.2.0 (npm, README, launch scripts)

Spawn: One Place · engine v6.0.0 release notes

Stripe: Minions: Stripe's one-shot, end-to-end coding agents (parts 1 & 2)

Stripe official X post on Minions

StrongDM: Software Factories And The Agentic Moment

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

R&D managementAI AgentsAI-assisted developmentsoftware engineeringautomated testingcontinuous deploymentSpawnFable
Architect
Written by

Architect

Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.