There is a lot of noise right now about AI writing software, and most of it is either breathless (“agents ship products while you sleep”) or dismissive (“it only autocompletes”). Neither matches our day to day. We build and ship small consumer games with a crew of AI agents doing the bulk of the hands-on work, coordinated by an orchestrator, with a human accountable for every release. This post is the first-hand version: how the pipeline is actually wired, what genuinely works, and where it still breaks in ways we have had to design around. No metrics we cannot stand behind, no tidy success story — just the shape of the thing.
What “AI-native studio” means here
The premise is simple to state. Instead of a team of people using AI as a tool, we run a team of AI agents and treat the human as the accountable operator rather than the person typing every line. An orchestrator receives the intake, decomposes the work, and dispatches it to specialist agents. The specialists do the implementation, the testing, the localization, the build and deploy. Review gates sit between the doing and the shipping. A person reviews, authorizes, and owns the outcome — especially the parts a regulator, a store reviewer, or a player would hold us responsible for.
The important word is accountable, not supervisory. It is tempting to describe the human as “overseeing” the agents, which quietly implies the agents are trustworthy by default and the human is a rubber stamp. We have found the opposite framing more honest and more useful: the agents are capable but fallible collaborators, and the human is the one who cannot delegate responsibility for what actually ships. That single distinction shapes every gate described below.
The actual pipeline, end to end
A unit of work moves through the same stages every time, whether it is a new game mode or a one-line bug fix. The stages are deliberately explicit, because the failure modes of an agent crew live in the seams between them.
Intake. A request arrives — a feature, a fix, a release. The first job is to decide how much machinery it deserves. A trivial, self-contained change (one typo, one isolated test) is handled directly; spinning up a full crew for it would cost more coordination than the change is worth. Anything with real ambiguity or risk goes to the orchestrator. Getting this triage right is underrated: over-orchestrating small work is one of the most common ways to waste effort in this model.
Planning and decomposition. The orchestrator turns a request into a plan: what the change is, what “done” means, and how to split it into tasks that can be handed to specialists. Crucially, this is where we decide what can run in parallel and what must run in sequence. A good decomposition names which files each task will touch, so two agents are never unknowingly editing the same thing at once. A bad decomposition is where most expensive mistakes originate — not in the code the agents write, but in the way the work was carved up before any of them started.
Specialist execution. The plan fans out to role-specialised agents. We think in archetypes rather than personalities: an implementer writes feature code and its tests; a backend agent handles services and data contracts; a QA and security agent verifies and probes; a localization agent handles translated content; a build-and-deploy agent produces artifacts and ships them; a design and architecture agent owns the shape of the system and the decisions that outlive any single feature. Each agent is given a tightly scoped task, the context it needs, and explicit acceptance criteria. The narrower the scope, the better the result — a lesson we relearn constantly.
Review gates. Nothing moves from “an agent finished” to “this is going out” without passing gates. Code is reviewed for correctness and for whether it actually solved the root problem rather than the nearest symptom. Tests must exist and must genuinely exercise the change. Security and store-policy checks run before anything is packaged. These gates are not decorative; they are the reason the model is safe enough to run at all.
Integration. Parallel work is brought back together. This is the highest-risk merge point, because independently correct changes can still collide — two agents that each edited a shared file, a feature that assumed a contract another agent quietly changed. Integration is deliberately owned as its own step rather than treated as an afterthought.
Deploy. Shipping is its own discipline with its own agent and its own rules. Store builds go to a staging channel first, a human verifies them on a real device, and only then does anything get promoted to production. Release is never bundled into the same step as writing the feature — the person authorizing a production release is looking at a built, verified artifact, not a promise.
What genuinely works well
Parallelism on truly independent work. When a plan decomposes cleanly into tasks that do not touch each other, running them concurrently is a real advantage. Several unrelated features, or the same feature split into non-overlapping slices, can progress at once without the context-switching tax a single worker would pay. The gain is real, but it is entirely contingent on the “truly independent” part — and independence is harder to guarantee than it looks, which is the subject of the next section.
Consistent, unskippable gates. Human teams get tired and let a review slide at 6pm on a Friday. A pipeline does not. The same checks run every time, in the same order, whether it is the first change of the day or the fortieth. That consistency is quietly one of the biggest quality wins — not because any single check is clever, but because none of them ever gets skipped “just this once”.
Documentation written as the work happens. Because each change is scoped, planned, and reviewed in writing, the record of why something was done lands alongside the change itself instead of being reconstructed months later. Architecture decisions, changelog entries, and the rationale behind a fix are produced as part of the work rather than as a chore afterward. This post exists because that habit exists.
Fast iteration on well-defined problems. When the problem is crisp and the acceptance criteria are concrete, the loop from “here is the bug” to “here is the verified fix” is genuinely quick. The speed comes from tight scope and clear success conditions, not from the agents being magic — give the same crew a vague problem and the speed evaporates.
Where it breaks down — honestly
This is the part most write-ups skip, and it is the part that earns any credibility the rest of the post has. The model has real, recurring failure modes, and pretending otherwise would be the dishonest move.
Coordination overhead is real and easy to underestimate. Every task handed to a specialist needs context, scope, and criteria assembled for it. For large or well-parallelised work that overhead pays for itself. For small work it does not, and the discipline of not orchestrating trivial changes is as important as orchestrating the big ones. More agents is not more throughput past a point; it is more seams to manage.
Concurrent edits on shared files silently collide. The single sharpest hazard we have hit is two agents editing the same file in parallel and one change quietly overwriting the other — no error, no crash, just work that evaporates. Our defence is process, not cleverness: a plan assigns any contested file to exactly one agent per batch, sequential work is not forced into parallel just because it could be, and after every change we grep the file for a marker the change introduced to prove it actually landed. We learned each of those rules by losing work to their absence.
Agents exceed their scope. Given a narrow task, an agent will sometimes “helpfully” refactor an adjacent function, rename a thing, or improve code it was never asked to touch. Occasionally that is welcome; often it is an unreviewed change riding along with a reviewed one, which is exactly the sort of thing a gate exists to catch. Tight scoping and explicit boundaries in the task itself are the only reliable curb, and even then it takes active review to hold the line.
Green tests are not the same as shipped. A passing test suite is necessary and nowhere near sufficient. For anything involving timing, real devices, concurrency, or resources, the honest question is whether the test could even reproduce the failure mode — and often it cannot. We treat runtime verification on a real device or environment as non-negotiable for those classes of change. “The tests are green” is a checkpoint, not a conclusion, and conflating the two is how confident-looking regressions reach production.
The human-in-the-loop is still accountable. For all the automation, a person authorizes production releases, verifies staging builds by hand, and owns the outcome when something goes wrong. This is not a transitional inconvenience we expect to automate away. It is the design. An agent can be wrong confidently and at speed; the accountable human is the backstop that keeps confidence and speed from becoming a liability. We would rather be candid that the loop is load-bearing than sell a fully autonomous fantasy we do not run.
What we learned
The lesson that keeps recurring is that the hard part of an agent crew is not the code the agents write — it is everything around the code. Decomposition, scoping, gates, integration, and accountability are where the outcomes are actually decided. Agents are fast and capable inside a well-defined box; the entire craft is in drawing the boxes well and refusing to trust the output just because it compiles. The gates are not bureaucracy slowing down a clever system; they are the system. Take them away and you do not get a faster studio, you get a confident one that ships its mistakes quickly.
If there is a single takeaway, it is that “AI-native” did not let us stop caring about engineering discipline — it raised the price of not having it. The same rigour a good human team relies on (clear scope, real review, verification before release, one owner accountable) matters more when the collaborators are fast, tireless, and occasionally wrong in ways that look right. You can read more about how we think about the crew on the Agents page and about the studio itself on the Studio page. And if you want the other half of this blog — the craft and dimensionality side rather than the process side — start with what game dimensions actually mean.
Notes
This is a first-hand account of our own working process, not a study of AI development in general. It deliberately contains no performance metrics, speed multipliers, or comparative benchmarks — we do not have numbers we would stand behind publicly, and inventing them would undercut the point of the piece. The role archetypes (orchestrator, implementer, backend, QA/security, localization, build/deploy, design/architecture) are described generically; the value here is in the honest shape of the pipeline, not in any claim about a specific internal tool. Where we describe a failure mode, it is one we have actually hit and designed a process rule around.
Keep reading: all posts on the WizusLabs Engineering blog.