The AI-native game SDLC playbook
How to run a game through v1 and after, when agents write most of the code.
The build is no longer the bottleneck
Studios have started using agents to write game code at a speed that was unthinkable a year ago. The processes around that code have not changed at the same pace.
Most teams still run some version of the same lifecycle: a design document, a production plan, a long implementation, QA at the end, then ship. Each stage is owned by a different role. Work moves between them through documents, tickets, and sign-offs. That lifecycle was designed to maximize efficiency in an era when the most time-consuming and expensive stage was writing the game.
That is no longer the case. An agent can write a playable loop in a day. It can also write a loop a stranger cannot read, a data model that will not survive v1, and a pile of content on a core nobody would play twice. The traditional controls assume every step is performed by humans, at human speed. They stall the gains, or they rubber-stamp them.
When the build phase runs faster than the rest of the studio, three things become true:
- The bottleneck moves to the steps on either side of the build. Pitch, v1, proof of the loop, review, and the decision to continue still run at human speed.
- The controls stop matching reality. Reading every line by hand made sense when a person had written it. It cannot keep up once agents write most of the diff. A green check made sense when QA sat at the end of months of work. It cannot tell a good loop from a running one, or a v1 data model from one that merely compiles.
- The wrong work gets cheap. Extra modes, extra content, and polish used to be expensive, so a weak core was obvious. A first-compile architecture used to be expensive too. Now both ship in the same day as the core. Polish hides a weak loop. A first compile hides the rewrite you will do next month.
A security review that is sized for human output is the software version of this problem. Game development has its own: a critic who can tell whether the fantasy is on screen, and a player who can tell whether they would run it again. Those judgements do not get faster because the code did. The lifecycle has to keep pace with the agents without giving those judgements away.
This playbook rebuilds the studio around that. It is for a game you mean to keep. The first loop is the start of v1. It is engine-agnostic and platform-agnostic. The same loop holds for a compiled title, a streamed session, or anything else a player can run. The files and tools you already have can sit underneath it. The approach is the point.
What an AI-native game SDLC is
The AI-native game SDLC keeps the old control objectives and changes the enforcement. Instead of a linear handoff, the process is a loop. An agent is embedded at each stage. A human sits on the gates.
Each stage ends by writing an artifact the next stage can read. A pitch the designer accepts starts the spec. A spec that names v1 and the art bar starts the slice. A slice that survives two critics starts the backlog. A ticket with observable acceptance starts the build. A session that has checked itself starts review. A finding is routed, not lost in a chat. A play note writes the next ticket.
Humans remain accountable for every decision that requires judgement: the fantasy, the v1, the next unit of work, whether the loop is worth continuing, whether a pillar may change, and whether the game is done.
The shifts
The table below is a spectrum. Most studios sit somewhere between the two columns. The right-hand column is the destination this playbook describes.
| Stage | Traditional | AI-native |
|---|---|---|
| Plan | A design document gathered by committee, written up by hand, several steps removed from what the originator meant. | The originator brainstorms with an agent and writes a pitch: what is wanted, why, and under which constraints. A person accepts it. |
| Design | Requirements and design as separate phases, parsed by separate roles. | Both happen in one session. The spec names v1, the art bar, and the voice. Concerns are flagged while it is written, not weeks later. |
| Prove | The full game is built, then playtested. | The v1 loop is built first, at the art bar. Two critics decide whether to continue. Content waits. |
| Build | An engineer reads the design and starts writing. The plan stays in their head. | Nothing is implemented without an accepted ticket. One owner of shared systems. The agent names the files, the proof, and the v1 approach before it edits. |
| Check | QA at a stage boundary, days or weeks later. | The session checks its own work before a person sees it. Depth matches the change. Green means the check ran. It does not mean the loop is good. |
| Review | Humans read the diff, at a capacity planned for human output. | Named lenses after the code. Each critic gets one question and the evidence. Critics do not edit. Findings are routed into four boxes. |
| Ship | A release train. The player sees the build last. | Checks green, then the live build. The player is the review surface. A reviewer never publishes. |
| Maintain | Notes sit in a tracker until someone restarts the process. | A play note is a ticket. A note on the live ticket stays on that ticket. The loop feeds itself. |
The committed artifact
The thread running through the right-hand column is the artifact. Markdown, a ticket, a filmstrip, a review block: whatever form you use, both a person and an agent can read it, and it is versioned. From build onward the artifact is the running game and the record of what was asked of it.
The chain of those records is the audit trail: who asked for what, what the agent produced, who approved it, what play taught.
Plays
The plays are modular. Adopt them in this order only where the arrows require it. A studio can replace a tool. It should not replace a gate.
1. Capture intent as a pitch
Ideas stop waiting for someone to write them up. Intent is captured once, in the originator’s own words, as an artifact the next stage can act on.
Traditional
An idea passes through a design document, user stories, and refinement meetings before anyone can act on it. Ownership transfers at each handoff, so what reaches production is several steps removed from what the originator meant.
AI-native
The originator describes the problem to an agent. The agent asks what a designer would ask: who you are in the game, what you do, what failure costs. The result is a pitch. A person corrects it and accepts it.
Required, in any order, in the originator’s language:
- Fantasy — who you are.
- Gameplay — one verb. A job, not a theme.
- Stakes — the named cost of failing. Not a score.
- A public one-liner.
- A working title, last.
Read it back as one spine: you are X who must Y before Z. Do not write tickets yet. Do not pick an engine in this conversation. Engine and platform are constraints, not the idea.
The evidence is the accepted pitch. The product owner signs it. That accept is what starts the next play.
2. Collapse design into one session
Requirements and design happen together. Studio policy is applied while the spec is written, not discovered in a review weeks later.
Traditional
Analysts formalize the idea. Designers parse those requirements back into a design. The separation exists for accountability. It is slow, and it loses meaning.
AI-native
An agent takes the accepted pitch and produces a spec, constrained by the studio’s skills: voice, interface standards, what the player already knows. The spec names v1 and the art bar. Concerns are flagged in the same pass. The owner reviews the spec. They do not write it.
Fill voice enough that a later critic can fail the words. Declare whether the game has fiction. Name the register. Name the interface voice. An empty placeholder is not a pass.
Name v1: world size, session count, systems that ship. Name the art bar: three rules a later critic can fail — silhouette, palette, style lock. Fill the feel rules enough that a later critic can fail the feedback. The slice is a subset of that v1. It is not a rewrite of it. A person accepts this spec. An agent does not.
Do not write slice tickets until that spec is accepted. The declarations are the work of this play. They are not a player-facing outcome, and they still have to be observable on disk.
For generated art, preview the finished screen first
Use this loop when ImageGen supplies a new UI direction or a family of assets. A small replacement can reuse an existing selected preview.
- Write the requirements: content, player decisions, states, screen sizes, controls, and the art bar.
- Generate finished-screen previews with representative content. Compare the layouts and materials against those requirements, then select a direction.
- Use the selected preview as an image reference for each production asset. Generate separate environments, illustrations, and reusable surfaces.
- Build the live UI with native text, values, and controls. Check asset dimensions and real transparency.
- Compare captures from target devices beside the selected preview. Fix lost hierarchy, artwork scale, framing, or material quality.
Pathfinder used this loop for five docking tabs. The concepts guided the hangar, bar, item art, and panel material. The final comparison still preferred the concepts’ richer framing and larger artwork. That gap remained in the review record.
A mockup does not prove touch targets, overflow, or readability on a device. Functional checks and visual comparison answer separate questions.
3. Prove the fantasy before the rest of v1
This is the gate the traditional lifecycle is missing. Agents make it cheap to skip. Skipping it is how a studio spends a month decorating a loop nobody would play twice.
Build the smallest session that proves the fantasy, at the art bar. That session is the v1 loop. Keep it. Do not add campaigns, endings, meta, or extra modes on a weak slice.
The phase ends with two critics, not a vibe.
cold-player— a stranger gets the filmstrip only. No ticket, no pitch, no code. Five questions: what am I, what do I want, what did my last input do, what changed and why, what happens if I do nothing. Any “cannot tell” is a finding.second-run— one critic, the filmstrip, and the pitch’s develops lines. One verdict: would you play a second run, yes or no, one reason.
A no stops the loop and asks the human. It does not pivot the game. It does not open more tickets. The human decides.
Response before polish. Feel, art, and audio wait if the player still cannot read the last input, or cannot tell what changed. Polish cannot rescue those. It hides them.
4. One ticket is the unit of work
A ticket is one player-facing outcome. Not “make it better.” Live work sits in a backlog. Closed work leaves it, so the live file stays small enough to open every turn.
Traditional
The plan for a change stays in an engineer’s head, or at best a ticket comment. The first thing a reviewer sees is the finished diff. Rework is slow. Two people touch the same system because nothing said not to.
AI-native
Nothing is implemented without an accepted ticket. The ticket names observable acceptance, which critics must look at it, every other site of the same control, and how a developer reaches this state without playing to it. Before it edits, the agent names the v1 approach for this one outcome. The agent says which ticket it took before it starts, so a person can still stop it.
Shared systems stay serial. One owner of the scene that everyone touches. Parallel work is for isolated art, copy, or helpers. A standing yes — a named list — is the exception that lets several tickets run without a person between them. New notes wait for the next list.
Acceptance must be observable: a command, a played beat, or a captured frame. “Feels better” is not acceptance unless a written feel rule names it.
When two implementations both pass the check, take the one that still holds at v1. Schema, art source, and copy on a ticket are the production ones for that one outcome. You do not also build the rest of v1 on this ticket. A placeholder that must come out names Until and the ticket that replaces it. A placeholder with no replacement is a finding. Bigger games mean more tickets, not bigger tickets.
Missing polish the v1 or the bars already promised is a ticket. Later content, extra modes, and systems v1 did not name go to ideas. They are not a queue to drain.
5. Give the session a way to check itself
Always give the agent a way to verify its own work before a person sees it. A late signal means a person has to check all of the output, and that person becomes the bottleneck.
A game is a running session, not a document. Checks that read a page as a form will miss it. Drive the player view. Ask the game which state is running. A blank frame is a failure. A frame that drew something can pass liveness. Liveness is not taste.
Run the deepest step the change needs, not every step.
Protect the loop. An agent fixing code must not weaken the check on that code. A debug route that jumps to a late state is allowed for development. It does not ship. A cheated capture is not evidence for a critic.
6. Publish when the check is green
The player should see the same build the studio is arguing about. A published host running code that is not in version control is the drift every studio pays for twice.
Deepest applicable check green, then commit and publish. Failed checks ship nothing. A critic never publishes. A standing-yes run still commits per ticket. It publishes once at the end, or when a person is about to play.
Ship is not “the agent liked the loop.” Ship is: the live build, on the player’s machine, with no open finding against a shipped surface, and a person saying the v1 is done.
7. Named critics after the code
Review capacity was planned around human output. Once agents write most of the diff, a person cannot read all of it, and a person who tries will rubber-stamp it. Move human attention up a level: did the change do what the ticket intended, and is the risk acceptable.
Green checks leave the ticket at review. A later pass runs the listed lenses. Each critic gets one question, the ticket, and the evidence. Not the sibling lenses. Not the whole constitution.
| Lens | Question |
|---|---|
design | Does this serve a named pillar? |
ux | Can the player use it on the intended device? Does the form say what it is? |
writing | The words, in that string’s register. |
art | The bar the game wrote. |
feel | Feedback readable, not noisy. |
balance | The stated band. |
consistency | Rules do not fight the fiction. |
tech | Build and the deepest check still green. |
cold-player | Can a stranger read the view? |
second-run | Worth playing twice? Slice gate only. |
Those ten names are the whole set. A vague extra name is how a review stops meaning anything.
A critic reports approve or a finding. It does not route. It does not edit. Separation of duties is preserved: the agent that wrote the code has no way to approve it. The parent puts every finding in one of four boxes when it arrives:
The work itself is wrong.
Small, no decision.
Wrong, and the fix needs a decision or several files. Fold several findings on one surface into one ticket.
Unpromised. v1 did not name it.
cold-player is not every publish. It runs at the slice gate, at ship, when the opening or the core loop surface moved, or when a person asks. A pass on every ticket is a pass that gets rubber-stamped.
8. Author content after the loop is locked
Most of a long-lived game is this play. It starts when the slice gate has passed and a person says the loop is done. It does not start because the backlog is empty.
A content ticket authors one beat. It does not invent a system, a control, or a pillar. Those stay ordinary tickets, and they land before the beats that need them. Split by beat, not by chapter and not by card.
A game with no way to sweep its catalogue cannot take this path. Add the sweep first, as an ordinary ticket. cold-player and second-run do not run on ordinary content. They run when their own triggers fire.
9. Play notes re-enter the loop
Maintenance is not a separate phase that waits for a person to restart the process. A note, a capture, or a one-line complaint is a ticket.
If the note names the ticket still in progress, it belongs inside that ticket. Acceptance grows if it must. Nothing new is filed. The note rides the checks and lenses that ticket already owes.
Anything else files first, does not start in the same turn, and waits in order. Quote the player’s words. Reply with the id. Ask which note goes first. A human note does not skip review. They saw one surface. The lenses see the rest.
Drop the current ticket only when the build is broken, the game cannot be played, or a person says to do it now.
10. Pivot in the open
A ticket may not change a pillar. That is a question for a person. Play will contradict the pitch. That is expected. Unlogged pivots are three half-games in one project.
- Name what play taught. Not a vibe.
- Propose the change.
- Count the tickets it kills. More than three needs a yes. Emptying the backlog is a new game.
- Update the consistency record. Move killed tickets out of the live backlog.
- Log the decision.
- Make pitch, design, backlog, and the build describe the same game before the next ticket.
A reviewer never pivots. It files a finding and asks. A ticket that makes a declared control or a consistency row wrong still edits that row in the same turn. That is not a pivot.
11. Polish only with a bar
An inner polish loop belongs on a ticket that already has a written bar and observable acceptance. Cap the rounds. A fresh critic sees artifacts only, not the builder’s reasoning. Tie goes to the bar.
Forbidden when the core loop is still unproven, when there is no bar, or when the work is inventing the genre. A polish win is not a skip of the check ladder.
Human judgement stays above it
The human still owns the pitch, the v1, the next ticket or named list, the slice gate when second-run says no, a pivot that kills more than three tickets, any ticket that still needs a decision, and ship.
Agents implement, check, publish, and criticise. They stop and report.
This is not a 300-page design document before a playable loop. It is not a first compile you rewrite for v1. It is not forty-eight agent roles. It is not polish on everything. It is not auto-starting the next ticket because the last one shipped. It is not a document tester pointed at a rendered game. It is not one ticket for the whole v1.
The loop keeps running. Human judgement stays above it.