Game designers are having their moment. So why are hits so rare amid the flood of AI-made games?
By Professor Jung Musik (Gachon University, Department of Game and Media Art)
Two indie developers are building platformers in the same genre with the same AI tools. A few days later, they’re looking at completely different results.
They had the same tools and the same amount of time. What differed was how they approached the AI, or more precisely, whether they handed the work off or directed it.
“Vibe Coding”: A Term That Aged in a Year
Andrej Karpathy coined the term “vibe coding” in February 2025. Exactly one year later, in February 2026, he declared the term already outdated and proposed a new one: “agentic engineering.” The era of going with the vibe and accepting whatever code the AI produced was over, he said. Now the default for development is not writing code yourself, but directing and supervising agents.
For indie developers, this shift is both a trap and an opportunity. It’s an opportunity because a single person can now work like a team. But hand off the work wholesale without learning to direct and supervise, and you get games that are made quickly and that nobody plays to the end.
Development Got Faster. Finishing Didn’t.
Working developers point to the same limitation again and again. With AI, you can build a mechanically functioning game astonishingly fast. Refining that into a genuinely fun final product is still as hard as ever.
The most common misconception is mistaking “development got faster” for “games got easier to finish.” These are entirely different things. Code gets written faster, but the time it takes to define what’s fun, to play and judge, and to choose what to cut hasn’t shrunk. If anything, now that you can make so much more, there’s also so much more to throw away. In other words, the faster AI builds, the heavier the weight of human judgment becomes.
Keep the Judgment. Delegate the Documentation.
The moment you tell an AI “make me a game in genre X,” you’ve handed over your design judgment along with it. What’s fun, how far to take it — the AI decides all of that. Yet feeling whether something is fun is entirely a human domain.
Say instead, “Organize this analysis into a design document using this template,” and the judgment stays in your hands. The AI only takes on the task of documentation.
That’s why I sum up the essence of working with AI in a single sentence: turn your criteria into a document first. If you have criteria, you can verify. If you can verify, you can fix only what’s wrong. If you can fix only what’s wrong, the final say stays with a human from start to finish. Without criteria, the opposite happens. Every time you’re unhappy, you make the AI start over, and every time, it gives you a slightly different game.
So the order matters. Don’t hand over the design document and immediately ask for implementation. First, have the AI summarize the document and ask questions about anything ambiguous. Confirm it has understood correctly, and only then have it implement. Then keep the verified skeleton intact and vary and expand the content on top of it. It’s the same direction as what the software industry calls spec-driven development.
Decomposition: Translating the “Realm of Feel”
So what should go into the design document? If you’re making your first game, I recommend not starting from a blank page but reverse-engineering a defining game in your genre. Break down the two pillars of game design, core mechanics and level design, into numbers and data you can control yourself.
There’s an excellent textbook available. The developers of Celeste released the code for its player class, around 5,400 lines. In it, you can see exactly which mechanisms make up the vague sensation we call “game feel.” “Coyote time,” which still accepts a jump for a brief moment after you’ve walked off a ledge. A “jump buffer,” which remembers a jump pressed just before landing. Jump height that varies with how long you hold the button. Gravity that eases off briefly at the apex of a jump. “The jump players expect” is the sum of these named values.
The moment you name and decompose things this way, your conversation with the AI changes. “Make it feel tighter” is interpreted differently by the AI every time. “Turn on coyote time and expose its value as a slider” can only be interpreted one way.
There’s one more habit I strongly recommend: build the tuning panel before you build the game.
Pull every jump, gravity, and dash value out into constants at the top,
and attach a debug panel that lets me change them with sliders during play.
Save and load tuning values as preset JSON files.With that single instruction, the unit of collaboration with the AI drops from feel to values. “Make it snappier” becomes “widen the range on the gravity slider.” And finding the right feel — judging what’s fun — returns to human hands.
Levels Are Data, Not Code
Level design works on the same principle. Fortunately, you don’t have to reverse-engineer everything yourself from scratch. Fan communities for popular games have already built up wiki resources that break levels down room by room. Have the AI organize that material into tables, then play the game yourself to check whether the analysis holds up.
And the result must be saved as data files, not code. If levels are baked into the code, every change means asking the AI to modify the code, and every time there’s a risk of breaking something elsewhere. If levels are separated out as data, a person can edit them directly, and AI-generated levels can be checked automatically.
This brings designers a truly great gift: tools. In the past, getting a level editor for a designer meant asking a tools programmer and waiting your turn. Now, as long as the data format is defined in the design document, you can have the AI build a dedicated editor for you. That editor becomes a tool that makes the design document visible. This is why the age of vibe coding is the age of the game designer.
Closing: The Final Verdict Comes From Playing It Yourself
What vibe coding has given indie developers is the power to work like a team even when working alone. But that team doesn’t work on its own. Hand off the work, and the team builds the AI’s average, not your game. Direct the work, and the team moves according to your criteria.
Becoming the one who directs ultimately means never letting go of three things: the judgment that decides what’s fun; the decomposition that translates that judgment into numbers, data, and documents; and the final verdict you reach by playing the result with your own hands. AI can write the code. But whether the game is fun is a question only a human can answer, all the way to the end.
Don’t hand your work off to AI. Direct it.
By Professor Jung Musik
Department of Game and Visual Studies, Gachon University / Doctor of Game Engineering
Founder of Indiegame.com
Professor Jung Musik is an Associate Professor in the Department of Game and Visual Art Studies at Gachon University and holds a doctorate in engineering. He was a founding member of Trigger Soft in 1994 and has since served as Director at NCSoft, outside director at NASDAQ-listed Gravity, and Vice President of Lunosoft. He organized Korea’s first indie game contest in 2003 and has supported the domestic indie game ecosystem for more than two decades. He currently serves as a member of the Korea Game Rating and Administration Committee under the Ministry of Culture, Sports and Tourism, and as chair of the Content/Digital/Space division of Seongnam City’s Fourth Industrial Revolution Special Committee.
