Software engineering looks different when a small team can keep a fleet of AI agents working around the clock. Spawn offers an unusually detailed account of what that can mean, including how much infrastructure and engineering discipline sit behind the output.
In his October 2026 essay, founder Jacob Sansbury says Spawn’s ten-person team shipped 77,000 substantial changes in the preceding 30 days, at about 108 an hour, while spending US$3.1 million on AI tokens. These are the founder’s self-reported figures. We have not audited them. A “change” is his unit of code work, not a separate production deployment or a measure of customer value.
The number catches the eye. The operating model deserves the closer look.
What Spawn is building
Spawn is a multiplayer game-creation platform. People describe what they want to build to its AI, Savi, and can change games while playing them. Its public release history describes work on rendering, multiplayer behaviour, game creation and the underlying engine.
That matters because this account concerns a live software product with connected users and difficult engineering problems. It is also a game platform. A bank’s payment service or an advice firm’s approval process has different consequences when an agent gets something wrong.
Persistent agents take responsibility for areas of work
Sansbury describes a fleet of permanent agents with names, memory and defined responsibilities. They work on areas such as the engine, operations and bug triage, and create temporary helpers to complete tasks. Human engineers also work directly with agents on larger experiments.
The distinction from an occasional coding assistant is continuity. An agent can retain the context of a subsystem and respond when it behaves unexpectedly. That only helps if the context stays current, the responsibilities are clear and the agent has a reliable way to observe what happened.
For an enterprise team, I would start with a bounded service whose ownership is already understood. Give the agent access to the relevant source, tests and incident history, then specify what it can change and which actions require a person. An agent with a broad goal and unclear permissions inherits every ambiguity in the organisation.
The product becomes part of the engineering feedback loop
In the founder’s account, production errors, user bug reports and product observations can create work for an agent directly. The system can investigate, make a change and check the result without waiting for a person to relay each step. He calls the supporting instrumentation “hyper observability”.
This changes what good instrumentation needs to provide. An alert saying “request failed” is often insufficient. An agent needs a trace it can follow: the request, the relevant system state, the failure and a way to reproduce it without causing more harm.
There is a practical enterprise starting point here. Take one recurring support incident and ask whether the evidence is sufficient for someone outside the original team to diagnose it. Improve the trace and the reproduction path before giving an agent more autonomy. That work makes the service easier for people to support as well.
Validation and recovery have to keep up with output
Spawn’s account includes checks by agents that did not write the change, regular testing against current code and automated responses to failures. It also describes accepting some temporary inconsistency and repairing it quickly. The founder says irreversible external actions, such as payments, go through fixed gates.
That is a consequential choice about the product’s tolerance for failure. I would not transfer its release policy wholesale into financial services. The useful engineering question is which changes are reversible, how quickly a failure becomes visible, and what happens to people or records before recovery.
A presentation change, a calculation-rule change and a payment instruction need different controls. For a regulated platform, the evidence needed before release should reflect those consequences. A quick rollback of application code does not reverse an incorrect payment or erase information already disclosed.
The ambition should still be a short path from a well-defined change to a checked release. Our article on AI-written changes sets out the evidence a reviewer needs for that decision.
Human judgement becomes a constraint worth engineering
One of the more interesting parts of the essay concerns repeated decisions. Sansbury describes using recorded decisions to build AI judges that apply prior preferences, send poorly framed questions back and leave new questions for a person.
That is more specific than asking an agent to “use good judgement”. A decision record can state what was chosen, why, and under what conditions it should be revisited. An agent can then distinguish a settled constraint from a question nobody has answered.
There is a limit. A past decision can become wrong when the product, regulation or business changes. The record needs an owner, an effective date where relevant, and a route for challenge. Otherwise a fast system can repeat yesterday’s mistake consistently.
People still need to use the product and exercise taste. Working code can be awkward, slow or unnecessary. The engineer’s job includes rejecting it, tightening the brief and sometimes choosing a different architecture rather than accepting another small improvement.
What an established business can take from this
A financial services firm does not need Spawn’s reported token budget or its tolerance for production disruption to learn from the account. It can examine how work reaches engineers, what information they can act on and how a release is checked.
For a first experiment, choose one service with a named business owner and a recoverable class of changes. Record the baseline time from agreed requirement to release, the effort spent reviewing and correcting the work, and the incidents that follow it. Include model and infrastructure cost. Then let an agent handle a bounded share of the delivery with independent review.
Use the results to decide what to change next. Missing tests, unclear business rules and poor incident traces are valuable findings. Fixing them expands the work that can be delegated responsibly.
Spawn’s account suggests that engineering teams may spend much more of their time defining outcomes, improving feedback and judging what should exist. It does not show that code volume is a substitute for those decisions. A business buying software should ask how the team will know the result works, and who can intervene when it does not.
We work with leadership and engineering teams on that delivery model, from the first scoped release through to training and the team’s ability to run it.
Sources and limits
- Jacob Sansbury’s founder essay on X, October 2026. Operational practices and numerical claims above are his account, not independently verified findings.
- Spawn’s public product and engine release history. This establishes what the company publicly describes building; it does not audit the essay’s throughput or cost figures.
The enterprise examples and recommendations in this article are our interpretation. High change volume alone cannot establish quality, reliability or commercial return.