Most of the cost of making a game isn't writing it — it's the wait around every change. Build queues, review backlogs, a playtest scheduled for next week, a release that's a whole afternoon's ceremony. We spent that budget once, building a pipeline that erases the waiting, and now we spend it on the game. The distance from an idea to playing it is seconds.
Here's the loop we work inside.
Every change is already playable
The moment anyone touches a game, it rebuilds itself and appears, live, on every device we own — laptop, desktop, the phone in your pocket. Nothing to publish, nothing to wait for. It travels over a private network only our machines can see, so the whole team is always on the newest build without anyone pushing anything.
That single fact changes how a game gets made. Design reviews stop being meetings about screenshots and become everyone playing the same fresh build at once. A control scheme gets tested on a touchscreen and a keyboard in the same five minutes. We feel the game constantly, on real hardware, the way players will — and that tight, always-on contact is the biggest reason our games end up feeling good.
An agent guards every change
Speed is dangerous without a guard, so we built one. An agent sits on every change and runs the full battery before anyone trusts it — the tests, the checks that keep the code honest, the rules that keep the engine fast. It never tires and never skips, so problems surface the instant they appear instead of a week later.
This is what lets us move fast without breaking things. Speed and quality usually pull against each other; automation is what makes them pull the same way.
Shipping is one click
When something's ready for the world, it goes out in a single action — finished change to real players, globally, in moments. No release-day ritual, no fear. Because shipping is that cheap and that safe, we do it constantly, which means players are always on the newest, best version of every game.
Design is the thing a human writes
When an agent can turn intent into working code, the scarce skill stops being the typing and becomes the precise statement of what a mechanic should *be*. So that's the layer we write by hand. Every mechanic starts as a short design document in plain language — a designer's words, no engine terms allowed in. The agent translates that intent down into the code the machine runs, and keeps the two honest to the same behaviour while letting each stay worded for its own reader.
It runs in reverse, too. When the code changes, the design document is reconciled back to match — and the gaps that matter (intent with no code behind it yet, or code with no intent on record) are cheap to spot and surface. The design layer becomes a living source of truth that outlives any one implementation, instead of documentation that rots the day it's written. We wrote about this pipeline on its own; this is the short version.
The design corpus grows itself. Writing one spec almost always raises the next question — what happens when the thing you collect is full? — and that question gets written down as the seed of a future spec. The abstractions we end up with are the ones real mechanics demanded, not the ones we guessed we'd need.
The game tunes itself while we play
Great game feel isn't designed once — it's tuned endlessly. So we folded the tuning into play itself. As we play, the game quietly remembers what happened. The instant something feels off, you say so in one sentence, right there in the game; the agent reads the exact stretch of play you were reacting to and makes the change it calls for — a number, or new code when the fix needs it — and the game reloads under you. You feel the difference on the next wave and keep going.
The gap between *this feels wrong* and *this is fixed* stopped being measured in sessions and became one reload. Balance stops being a phase you schedule and becomes a heartbeat — games that get better the more they're played.
touch a change → it rebuilds and lands on every device, instantly
an agent checks → tests + code checks run before anyone trusts it
play it live → on a phone, a laptop, the same fresh build for all
say what's off → one sentence in-game; the agent reads the play, fixes it
ship it → one click to players worldwide
...and the design doc stays true the whole way through Why it adds up
None of these is the trick on its own. The point is that they're one loop. Instant builds are only worth it because an agent guards them; guarding only matters because shipping is one click away; shipping constantly only works because the design stays true to the code; and the whole thing is worth tightening because we never stop playing the result. Each piece removes a wait the next piece would have hit.
What's left, once the waiting is gone, is the part that matters: more time playing, more time making, and games that reach players the moment they're ready. We build small, real games in the open as a proving ground for exactly this — an AI-native studio where the same agent that writes a mechanic can sit beside you and tune it while you play.
Read next
Two pieces of this loop have their own deep dives:
- Two languages, one mechanic — why we let the design doc and the code disagree on purpose — and how an agent keeps them honest in both directions. /devlog/spec-driven-game-design
- Balancing while you play — the agentic loop that tunes a game from one sentence, mid-session, without ever asking you to stop playing. /devlog/balancing-while-you-play