The AI-native game SDLC playbook

How to transform the game development lifecycle with AI — stage by stage.

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 produce a playable session in an afternoon. It can also produce a playable session that is not a game: a loop a stranger cannot read, a fantasy the player cannot name, content stacked on a slice 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, 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.
• The wrong work gets cheap. Extra modes, extra content, and polish used to be expensive, so a weak core was obvious. Now they ship in the same afternoon as the core, and they hide it.

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 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 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 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.

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.

Required, in any order, in the originator’s language:

1. Fantasy — who you are.
2. Gameplay — one verb. A job, not a theme.
3. Stakes — the named cost of failing. Not a score.
4. A public one-liner.
5. 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.

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. A person accepts this spec. An agent does not.

3. Prove the fantasy before the rest of the game

This is the gate the traditional lifecycle is missing. Agents make it cheap to skip. Skipping it is how a studio spends a week decorating a loop nobody would play twice.

Build the smallest session that proves the fantasy. Do not add campaigns, endings, meta, or extra modes on a weak slice.

The phase ends with two critics, not a vibe.

1. 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.
2. 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.

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.

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 version 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.

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:

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. 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.

9. 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.

1. Name what play taught. Not a vibe.
2. Propose the change.
3. Count the tickets it kills. More than three needs a yes. Emptying the backlog is a new game.
4. Update the consistency record. Move killed tickets out of the live backlog.
5. Log the decision.
6. 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.

10. 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 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 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.

The loop keeps running. Human judgement stays above it.