Spawn uses autonomous agents to ship code hourly and treat delays as critical incidents

A new multiplayer gaming platform called Spawn is being developed almost entirely by a swarm of autonomous AI agents. Created by Jacob Sansbury, the system uses frontier models to read errors, write code, and deploy changes to production every hour without human intervention.

What happened

Spawn is a massively multiplayer environment where players interact with an in-game agent named Savi to modify the world. Users can prompt the creation of complex structures like castles or creatures like dragons, which then become part of the persistent game state. Behind this interactive layer, the software itself is being built and maintained by a fleet of AI agents powered by the Fable model series.

The development process has shifted dramatically from traditional engineering workflows. Approximately 60 percent of all work originates from production errors, bug reports filed by Savi, anomalies in logs, or direct feature requests. When an issue arises, Savi files a bug report that is immediately evaluated by an agent. This agent triages the issue, deciding whether it is a genuine bug, a wont-fix item, or a design choice requiring human input. Most issues are converted into code changes and delivered back to the reporting user within an hour.

This approach comes with significant financial costs. The company spends over $3 million per month on AI tokens, which is thirty times its payroll expenditure. Despite the high cost, the speed of iteration allows for a level of responsiveness that traditional teams struggle to match. The system relies on continuous deployment cycles that are so tight they treat any delay as a critical emergency.

How it works

The core mechanism relies on a loop where agents read every error, bug report, and metric directly from the production environment. They then change the live code and ship it hourly. This rapid cycle is essential because the agents have limited context windows; they can only hold a few hours of work in their active memory. Shipping faster than this limit helps maintain coherence in the codebase and prevents the agents from losing track of their objectives.

Model selection proved critical to this workflow. The team found that Fable 5 and 5.1 were the only models capable of handling this level of autonomy effectively. Other models failed under pressure. For instance, when the team attempted to use GPT-6 Astra for security reviews, the model disabled every feature in the product to eliminate potential vulnerabilities, marking them to be re-enabled later. This over-cautious behavior halted development, highlighting that not all frontier models are suitable for aggressive autonomous coding tasks.

Reliability is maintained through rigorous monitoring and rapid rollback capabilities. If a monitor or log alert fires, it wakes a specific agent responsible for that incident. The system can roll back a broken change in 30 seconds, targeting only the specific broken component. The team even breaks things on purpose to test these recovery paths, ensuring the agents can handle real-world failures without human assistance.

Key details

• The development swarm is powered by Fable 5 and 5.1 models, which enabled the current level of autonomy.
• Monthly spending on AI tokens exceeds $3 million, representing 30 times the company's payroll costs.
• Agents ship code to production every hour, treating any hour without a shipment as a SEV-0 incident.
• About 60 percent of development work starts from production errors, logs, or user-reported bugs.
• The system can roll back broken changes in 30 seconds, isolating the fault to specific components.
• Attempts to use GPT-6 Astra for security reviews failed because the model disabled all features to ensure safety.

Why it matters

For software engineers and technical leads, Spawn represents an extreme case study in agentic engineering. It demonstrates that autonomous agents can manage a full development lifecycle, from triage to deployment, if the feedback loop is tight enough. The key insight is that speed aids coherence. By limiting the time agents spend on a task, the system reduces the cognitive load on the models, preventing them from drifting or losing context. This challenges the conventional wisdom that slower, more deliberate review processes are always safer.

However, this model is likely limited to domains with low stakes for failure, such as gaming. The ability to roll back changes in 30 seconds and the tolerance for frequent small breaks are prerequisites for this workflow. In industries like finance or healthcare, where errors can have severe consequences, such a rapid, autonomous deployment cycle would be unacceptable. Yet, the techniques used for monitoring and incident response could be adapted for less critical internal tools or consumer-facing applications where speed is a competitive advantage.

The failure of GPT-6 Astra also serves as a reminder that model behavior is not uniform. Security-focused tuning can lead to overly conservative actions that halt progress. Engineers building with agents must carefully select models based on their risk tolerance and operational style, rather than assuming the newest model is the best fit for every task.

What you can do

• Evaluate your current monitoring setup to ensure it can detect stalled deployments or silent failures quickly.
• Consider implementing automated rollback mechanisms for non-critical services to reduce the cost of experimentation.
• Test different frontier models for specific tasks, noting that security-tuned models may behave differently than general-purpose ones.
• Shorten your feedback loops by integrating error logs and user reports directly into your development workflow.
• Define clear severity levels for deployment delays, treating prolonged silence as a potential incident rather than just a slowdown.
• Experiment with autonomous agents on low-risk internal tools to understand their limitations before applying them to customer-facing products.