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. One year later, in early February 2026, he said the term had already become outdated, and that professionals prefer the name “agentic engineering.”
His explanation is worth noting. “Agentic” means developers now spend almost no time writing code themselves, and most of their time orchestrating and supervising agents. “Engineering” means that this, too, demands skill, science, and expertise. In other words, the era of going with the vibe and accepting whatever code the AI produced is over. What has become the default for development is orchestration — the art of directing — something you have to learn and practice.
For indie developers, this shift is both an opportunity and a trap. It’s an opportunity because a single person can now work like a team. But hand off the work wholesale without learning how to direct, and you get games that are made quickly and never played 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 it 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.” The time spent writing code has shrunk, but the time it takes to define what’s fun, to play and judge, and to choose what to cut has not. If anything, now that you can make so much more, there’s also so much more to throw away.
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, what to leave out — the AI decides all of that. By then, the space where the developer controls the fun has already passed them by. Say instead, “Organize this analysis into a design document in this format,” and the judgment stays in your hands while the AI takes on the work 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, you keep making the AI start over until you’re satisfied, and every time, it gives you a slightly different game.
This is also the direction the entire software industry is heading. Applied to game development, the order goes like this. 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, then have it implement. Keep the verified skeleton intact, and vary and expand the content on top of it.
Decomposition: Translating the “Realm of Feel”
If you already have a proven design document and source code, AI can turn them into a game in no time. But what about developers trying to make a game for the first time? 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 its player class code, around 5,400 lines, and co-creator Maddy Thorson personally documented and shared the game’s “forgiveness” mechanics. Look at that list, and you can see exactly which mechanisms make up the vague sensation we call “game feel”:
- Coyote time — For a brief moment after you walk off a ledge, the game still accepts a jump.
- Jump buffer — A jump pressed just before landing is remembered and executed the instant you land.
- Reduced gravity at the apex — Holding the jump button halves gravity near the peak of the jump, giving you time to steer in midair.
- Corner correction — If you bump your head on a corner while jumping, or catch a corner while dashing, the game nudges you slightly sideways or upward.
- Generous wall-jump detection — Wall jumps are allowed even when you’re about two pixels away from the wall.
“The jump players expect” is the sum of named values like these. And the moment you name and decompose things this way, your conversation with the AI changes. “Make the controls feel better” 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: have the AI build the tuning panel before it builds 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. “Better controls” 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 against the rules.
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.
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 clearly, 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.
