AI game development: what AI actually carries
AI has made the distance from an idea to something playable very short. It has left the distance from playable to good exactly where it was.
Jump to a section
The question worth asking about AI game development is not whether a model can make a game. It can, and has been able to for a while. The useful question is which parts of the work it takes off you, and which parts it only appears to take off you.
One test sorts most of it. Can the result be checked by reading, or only by playing? Models are strong wherever reading is enough. They are weak everywhere else, and that line runs straight through the middle of a game.
AI carries scaffolding, prototypes, tool scripts and first-pass content. It helps on systems code, performance work and anything that has to match an existing codebase, as long as somebody reads the result. It is still poor at feel, difficulty and level design, because those are judged by playing and nothing in the loop plays.
The test that sorts the work#
Most arguments about AI in this field are really arguments about which kind of work the speaker has in mind. A programmer who just watched a model write a serialisation layer in four minutes is not describing the same job as a designer. The designer spent a week on one jump arc. Both are right about their own half.
The dividing line is verification. If you can tell whether the output is correct by reading it, running it, or watching a test go green, a model is a serious tool. If the only way to tell is to play for ten minutes and notice you are bored, the model is working blind.
Where it genuinely carries the work#
In the places below the model is not assisting. It is doing the task, and doing it fast enough to change how you plan a week.
- Boilerplate and scaffolding. Input handling, a fixed timestep loop, save and load, state machines, a camera that follows a target. This code has been written many times before, and it is the part of a game nobody is precious about.
- One-file prototypes. A single HTML file with no build step goes from brief to playable in one pass. It is the cheapest way to find out whether a mechanic survives contact with a hand on a keyboard.
- Editor and build scripts. Asset importers, atlas packers, a script that renames two hundred files, a build that stamps a version number. Nobody enjoys this work and a model does not mind it.
- A design document turned into a grey-box. Hand over the loop, the controls and the win condition, and you get boxes moving on a screen the same afternoon. That is a better argument than the document was.
- The hundred small tools nobody has time for. A spawn table viewer, a replay scrubber, a key that draws every collider, a dump of the balance numbers as a spreadsheet. These get skipped because they are never the priority. They are an hour each now.
- First-pass placeholder art and copy. Flat shapes, icon stand-ins, item names, enemy barks, tooltip text. Good enough to test against, and clearly marked as temporary.
None of that is the interesting part of making a game, which is exactly why it is worth handing over. It is also most of the hours.
Where it helps, with a hand on it#
The middle band is where the output looks finished and is not. A model writes plausible systems code quickly, and plausible is a dangerous property in something other systems depend on.
| The work | What you get first | What you still do |
|---|---|---|
| Systems code with any depth | A clean version of the common case, written faster than you would write it. | Decide what happens at the edges, and own the data model it hangs off. |
| Anything under a performance budget | Code that is correct and allocates freely, with no sense of a frame cost. | Profile it, then state the budget in numbers and the device it has to hold on. |
| Code inside an existing codebase | A reasonable solution written in its own style rather than yours. | Point at the file it should resemble, and read the diff before it merges. |
The pattern repeats in all three rows. The model gets you a version quickly. You decide whether it is the right version, and that part has not moved.
Performance is the clearest of the three. Ask for a particle system and you get one that works and allocates on every frame. The model has no frame budget, no target device and no profiler. Give it those three things and the second attempt is usually close.
A model cannot infer that this ships on a six year old phone, that the update budget is four milliseconds, or that your project forbids allocation in the inner loop. Those are facts about your world, not about games. Written down they are instructions. Left unwritten they are nothing.
Where it is currently poor#
Now the half that has not moved. Feel, difficulty, level design and the choice between two options are all decided the same way. Somebody plays, and then somebody judges. A model does neither.
- The feel of a game. Jump weight, hit pause, acceleration curves, how long a menu takes to close. Ask whether the jump feels right and you get a paragraph about coyote time. The question was never about coyote time.
- Difficulty tuning. A difficulty curve is a claim about what a stranger can do on their second attempt. The only instrument for that is a stranger. Curves that look sensible on paper come out either trivial or brutal in the hand.
- Levels that teach. A good first level introduces a rule, makes the player use it, then makes them use it under pressure. A model can place platforms. It cannot tell whether the player understood the platform.
- Which of two options is more fun. This is the one that matters and the one to stop asking. A model will pick, confidently, in a tone that suggests it knows. It is pattern matching on what similar games did.
This is not a gap that closes by the model getting better at code. It is a gap about having a body in a chair that gets bored, frustrated or hooked. Until playing is part of the loop, that judgement stays with you.
Prototyping is where this pays#
If you take one thing from all of this, take this. A prototype that used to cost two weeks now costs an afternoon, and that changes which ideas are worth building at all.
An idea that costs a fortnight has to be argued for. Somebody writes a document, somebody pushes back, and the version that gets built is the one that survived a meeting. An idea that costs an afternoon needs no argument. You build it, play it, and the prototype settles it the way no document has.
The second effect is that you can afford to build the version you expect to fail. Side by side comparisons become practical. Three variants of one combat loop, built in a day, is a question you can actually answer.
One habit separates usable output from noise. Write a short brief before the prompt: the loop, the controls, the win and lose conditions, and the one question the prototype exists to answer. The seven fields are set out in how to make a game with AI, with ready-made prompts in the prompt guide.
Turn the brief below into a grey-box prototype as ONE self-contained
.html file. No frameworks, no build step, no art, no audio. Boxes and
flat colour only. This exists to answer one design question, not to look
finished.
BRIEF
Core loop: <what the player does over and over>
Win / lose: <both conditions, stated plainly>
Controls: <the actual keys, and what a touchscreen does>
The question I am testing: <one sentence, the reason this exists>
BUILD
- Canvas only. Every entity is a labelled rectangle.
- requestAnimationFrame with delta time in seconds, clamped to 0.05.
- Pause when document.hidden is true.
TUNING, which is the part that matters
- One CONFIG object at the top holding every number that affects play:
speeds, cooldowns, spawn rates, damage, timers, level length. One
comment each, saying what the number does and the range worth trying.
- A debug overlay toggled by F1, showing the live value of every CONFIG
entry, the current frame time, and a readout of the state machine.
- Number keys 1 to 5 load five preset CONFIG variants, switchable
mid-run without a reload, so two versions can be compared back to back.
- R restarts the level immediately with the current values.
- A one-key dump of the current CONFIG to the console as JSON, so a run
worth keeping can be pasted back later.
Do not add menus, sound, particles, score polish or a title screen.
Return the complete file and nothing else.The tuning block is the whole point. A prototype you cannot retune mid-run only answers a question about one set of numbers, which is rarely the question you had.
A prototype testing nothing in particular turns into a small game you feel bad about deleting. Put the question in a comment at the top of the file. Once it has an answer, the prototype has done its job and can go.
Two risks worth naming#
Both of these are cheap to handle early and expensive to handle late, which is the only reason they are worth a section.
Code nobody on the team has read#
Generated code that goes in unread becomes code nobody can change. The problem is not that the code is bad. It is that no one holds a model of how it works, so the first bug in it is an archaeology job. That cost never shows up in the week it was written.
The handling is ordinary. Review it the way you would review a pull request from somebody new. If a file is too long to read, it is too long to merge.
Where the generated assets came from#
Generated art, audio and text carry provenance questions that a shipped product has to answer. Who owns the output. What the tool's terms say about commercial use. What a platform, a publisher or a client requires you to disclose.
That is not something a guide can settle for you, and nothing here is legal advice. It is something your team settles in writing, before the placeholder art quietly becomes the final art. That last part is how it usually goes wrong.
What this actually changed#
The honest summary is narrow and still large. AI compresses the distance between an idea and something playable. It does not compress the distance between playable and good.
That second distance is most of a game. It is the passes where the jump gets reworked, the level that gets cut, the three enemy types that become one. None of that work got faster. What changed is that you reach it sooner, with more ideas worth taking there.
More prototypes now reach the point where a human judgement is required. That judgement is the bottleneck, and it was always the expensive part of the job.
Where the bar actually sits#
Claims about what models can build are cheap. The catalogue on Agent Games is the other thing: real games, with the model and the prompt recorded on every page.
🛠️Games here, with the model and prompt behind each
Fable 5.1
GPT-6.1 SolOpening three of these is faster than reading another argument about capability. The made-with pages group them by the model that wrote them, if you want to compare output rather than benchmarks.
Common questions#
Can AI replace game developers?
Not on current evidence, and the shape of the gap is specific. A model writes code, tools and prototypes well. It does not play, so it cannot judge feel, difficulty or whether a level teaches. An AI game developer who hands over the first category and keeps the second gets far more done. One who hands over both ships something that works and nobody finishes.
What is AI genuinely good at in game development?
Scaffolding and boilerplate, one-file prototypes, editor and build scripts, turning a design brief into a grey-box, the small internal tools that always get cut, and first-pass placeholder art and copy. The common thread is that you can check the result by reading or running it, without a long session of play.
Can AI do game design?
It can do the parts of AI game design that are writing. Systems on paper, enemy tables, economy numbers, variant ideas by the dozen. It cannot do the part that is judgement, because judgement comes from playing. Treat design output as a list of options to test, never as a decision already made.
Is AI-written game code safe to ship?
It is exactly as safe as any code nobody reviewed, which is to say no. The practical rule is that generated code enters the project the same way human code does, through review. The real risk is rarely a dramatic bug. It is a file that works and that nobody on the team can confidently change six months later.
Can a model tune difficulty for me?
It can propose a curve, and the curve will sound reasonable. Whether it is right is a fact about real players on their second attempt, and the model has no access to that. Use it to generate the parameters and the preset variants. Then decide by watching somebody play, preferably somebody who has not seen the game.
Should we prototype in a browser or in our engine?
In a browser first, for anything you expect to throw away. A single file runs in a second and fits inside one conversation, which keeps the loop tight. Move into the engine once the question the prototype asked has an answer, and not before.
Where to go next#
If what you want is the method rather than the map, how to make a game with AI covers the brief, the one-file constraint and the iteration loop in full.
For the code itself, the HTML game code guide covers the structure a single-file game settles into. If your prototypes come out of a coding agent, the MCP endpoint publishes one without leaving the editor. Anything worth putting in front of players can go up through the upload page.
Built something? Put it on Agent Games.
Publishing takes a file and a minute. Your game gets its own page listing the model, the prompt and the token count, and anyone can play it without signing up.
Read next