Contents
I recently built two full games with AI:
- Inkline Town, a 3D town builder drawn in ink
- Spirit Call, a 3D top-down shooter
I did not write a line of code. I did not read one either.
My "game editor" was a chat, a link to playtest the game, and a web page with previews of 3D models. My "work" was sending text and screenshots. Nothing else.
And still, making those games has been hard and intense. Like never before. For weeks.
AI made writing a game faster and easier. It did not make it easy.
My goal was getting an answer to the question all game devs are asking themselves:
If AI implements everything, what's left for me?
I found the answer: The hard part didn't go away, it moved. Away from implementation, and into the choices only you can make: what game, what style, what is fun, what is broken.
AI frees your time, so you can think about the core of your game. And that's hard, and now it's all you have to do, all the time. No coding break.
Great. Well, what does this mean, in practice, for you?
Here are all the steps I will take for my next game, everything that I learned, and how you can steal all of it.
Choosing your game is choosing your bottleneck
The first decision is yours, and it will always be so: "What game do I want to make?"
The answer you choose has the potential to make or break you and your game. Literally.
Any step in your pipeline the AI can't do becomes your full-time job.
So when you pick a genre and a style, you are also picking where your time will go. Agents go fast, so whatever still needs you becomes the bottleneck. Make sure that step is one worth your time: taste, fun, playtest.
My plan for Spirit Call was a game like Genshin Impact (原神), with a new character every few weeks.
So the question became: can the agent produce high-quality characters, without me stepping in? And, spoiler, the answer was no (after two days of attempts).
Simple stylized models worked well. Detailed anime characters failed every time.
I tried every route I could think of: reference sheets, prebuilt models, a full studio-style pipeline, even copying a character from another game. The results were bad, and worse, never repeatable. And all of this before animation.
I could have done the anime characters by hand (maybe). Even with AI support, one decent character would have taken me weeks, next to a game that took three weeks overall, from the first commit to the last.
So I changed the style instead of the game. Not the initial vision, but one I could ship, fast, with AI in every step of the pipeline.
I switched from full anime characters to simple stylized spirits.
Even the simple spirits would have cost more by hand than the whole game took: about a month for all ten, against three weeks for all of Spirit Call. With the agent, they took about 20 minutes each:
- 2D design from ChatGPT
- Low-poly version of the design, again from ChatGPT
- Breakdown of every view for 3D modeling, still ChatGPT
- 3D modeling with Blender MCP
They were also far easier to animate. Each enemy went through the same steps.
I learned my lesson with my second game, Inkline Town: an ink style, assets made by an agent, with a repeatable pipeline from day one.
Agents are not yet good at anything that requires taste: character design, detailed 3D models, animation, story. Any of it adds more work for you, personally.
If you want an agent-first fast loop, your role should only be playtesting and taste. Anything else, and the loop is broken.
Build a system that verifies for you
You should not need to read the code. The agent can handle it all. But you need layers of verification on top to make the output reliable.
It starts with structure. I use an Entity Component System (ECS): every object in the game is an entity, a bag of data (components) like position, velocity or health. Each piece of logic (a system) declares which components it reads and writes, and runs on every entity that has them.
Systems never call each other. That's what makes the architecture composable: the agent can add or rewrite one system without touching the rest, and since every system declares what it touches, the checks have something concrete to verify.
Spawn a Projectile below: it has a position and a velocity, so the same Move system that moves the player moves it too. No new code.
On top of that structure, you layer checks. Each one takes a kind of mistake off your mind:
- Types: a wrong call doesn't compile, and the error tells the agent how to fix it. That's usually the first layer of checks
- Headless tests and simulation: the game runs as numbers and text, no graphics. The agent can play thousands of frames and verify behavior without you
- Lints: rules that catch the mistakes an agent keeps repeating. When the same thing breaks twice, ask for a lint
- Every bug becomes a test: once fixed, it can't come back silently in the same form
- Recorded playtests: the game records what happens while you play. Your session becomes data the agent can read
- Debug sessions: the agent asks why a value changed and gets an answer, instead of guessing
The checks run between my prompt and my next playtest: the agent sees the failures, fixes them, and I never hear about most of them.
And you can get creative with checks, depending on your game.
In Spirit Call, I made the agent write a balance model to mathematically prove that clearing each main quest once pays for leveling a character up to the next one, without grinding.
Drag the sliders: cut the quest rewards or make level-ups pricier, and see which quest first needs replays to afford.
None of these is mandatory. But the more of them you add (where they make sense for your game), the faster you iterate, and the more of your attention goes to taste instead of code and bugs.
You still need to know what each layer is for. Not how it works, but what it protects you from. That's what lets you direct the agent when something keeps going wrong.
I created Ritmo for this exact purpose: a TypeScript ECS runtime I built in parallel with the two games, to collect all the checks in one place.
But the principles work with any engine.
The first playable is fast, the game is not
With all of that in place, the first version of your game loop comes quickly. Days, sometimes hours.
That is not the game. It's the start of it.
Three quarters of Inkline Town's commits came after the first two days, when the game was already playable.
The start was fast. I found a style reference on X, a short video, and asked the agent to recreate it, animations included: five minutes.
Then I asked the agent to turn it into a town simulation with a few basic buildings: working ten minutes later. The core of the game took about 20 minutes. Defining the buildings and a few mechanics came next. All of that fit in the first two days.
The other six went to content, fun and balance.
Mechanics that interact in ways you didn't plan. An economy that needs to hold up for an hour of play. UI that explains itself. Tutorials. Balancing.
Inkline Town's own commits show it. From day two on, most of them tune something after a play session instead of building something new: nearly two thirds of all game commits.
The agent implements every piece of it in minutes. What takes time is figuring out what to implement: which mechanic is missing, why a system is boring, what a new player doesn't get.
This is where "AI made game dev easy" breaks down. The loop is: play, notice, decide, ask, play again. Every round needs you.
Playtest as a player, report as a player
I never touched a number in Inkline Town. To this day, I don't know how they're computed or how they move: I only ever saw the game.
I play for around 45 minutes, as a player. Then I report what I see:
- a strategy that dominates every other one
- an exploit that breaks the economy
- a moment where I didn't know what to do
- a mechanic the game clearly needs and doesn't have
Inkline Town's clearest case was food.
The town eats fish or bread. A fishery is one building; bread needs three buildings, all running. So I built fisheries, side by side on the same lake, and food stopped being a problem. Everyone was living on fish; bread had no reason to exist.
So I spoke the prompt below to the agent, as any human playtester would.
The agent turns that into a fix, and then proves it, often with an automated economy simulation. And since my playtests are recorded, it also has the exact numbers of the session I just played.
For the fisheries, the fix started with a model, not a number.
I knew that if one hole like this had slipped through, there were others, and that an economy like this can be checked with math: an agent can write that check as a test.
So I asked for an economy model that weighs every number in the game against the others.
It confirmed the fishery, and showed it wasn't alone: twelve rules of the economy were broken. Finding the issues took most of the time; fixing them was fast and easy.
The problems that broke the economy never came back, because for each one we added the assumption behind it to the model. What still needed my playtests was the kind of choices I wanted the player to face.
From the ledger to the fix took the agent under an hour. My part was the 45-minute match, the report, and knowing to ask for the model.
You describe the experience. The data gives the numbers. The agent connects the two.
You don't read the code. You trust the output
Some of the agent's work takes hours. I don't watch it. I don't review it.
When it's done, the checks have already run. Types compile, tests pass, lints are clean, simulations hold. Implementation is verified before it reaches me, against what the checks encode.
Passing the checks doesn't mean the game is ready. What reaches me is what they miss: a side panel hiding a button, an unclear tutorial line, a mechanic that works exactly as specified but isn't fun.
I don't open the code. I open the game. And I restart it from the very beginning, to judge the only thing no check can measure: whether it's fun.
Since I never know what the agent changed, every time I open the game I meet it fresh, like a new player: I read the UI for the first time and follow the tutorial step by step.
My reports mention what felt off and why, never how to fix it. Since my sessions are recorded, the agent can replay my actions, take its own screenshots, and see the issue.
That's the confidence the verification system buys you. Without it, every output is a code review. With it, every output is a playtest.
But the checks are only as good as the rules behind them. When one keeps failing, you need to tell whether the agent got it wrong or a rule is missing, and for that you need to know the tools underneath.
The trust came from the stack: my own engine plus Effect, which I know well enough to let the agent run.
If you're not into development or math, expect to hit a wall at some point.
Remember the fisheries: there, the wall was knowing to ask for a math model. Without that, you would be stuck in a much longer loop, fixing each case by hand from playtests.
Your contribution was never the code
If you have been building your game by hand for years, I know you are screaming: "But it stops being my game if I don't write any of it!"
It doesn't. Your contribution was never the code. It was the ideas, the feel, the hundreds of small decisions about what's fun. That is exactly the part AI can't do, and the part that now gets all your time.
If you enjoy writing every line, keep doing it. But if you want to make and sell games, building by hand means years on a game you're not sure will work, while an agent writes a full system in minutes, and the models keep getting better.
My prediction: on average, games made with an AI system will ship faster and sell better.
Not because AI makes better games, but because the time no longer spent on code goes into playtesting, fun, and the bugs only a human catches. If you keep writing code, you simply don't have enough resources for all of it.
If you want to make a game, here is the order:
- Pick your game and style with the bottleneck in mind: test early that the AI can produce what you need
- Build verification alongside the first playable: start with types, lints and tests for the core rules, whatever your engine. Add headless simulations and math models of your numbers as playtests show what needs protecting. Ritmo has them all built in, but it isn't required
- Verify that the core gameplay is fun, early: and expect most of the work to come after it
- Playtest as a player, report what's broken, let the agent fix and prove it: repeat. Ask for what the player would notice, never for code
It's still hard. It's faster. And, if you ask me, way more fun than before.