Two indie developers are using the same AI tool to create a platformer of the same genre. However, a few days later, they receive completely different results.
The tools and the allotted time were the same. What differed was the attitude toward the AI—more precisely, whether the work was ‘delegated’ or ‘ordered’ .
A phrase that became outdated in just one year, ‘Vibe Coding’
It was February 2025 when Andrei Kappasi coined the term ‘Vibe Coding.’ Then, a year later in early February 2026, he stated that the term was already outdated and that experts preferred the name ‘Agentic Engineering.’
The explanation he provided is interesting. ‘Agentic’ means that developers now spend almost no time writing code themselves, but rather spend most of their time coordinating and supervising agents . ‘Engineering’ implies that even this requires technology, science, and expertise. In other words, it is a declaration that the era of simply going with the flow and accepting code produced by AI has passed, and that ‘ orchestration —the art of command—which must now be learned and practiced , has become the default setting for development.
For indie developers, this change is both an opportunity and a trap. It is an opportunity in that one can now work like a team even alone. However, if the entire project is handed over without learning how to lead, the result is a game that is made quickly but never played to the end.
What has been accelerated is development, not completion.
There is a limitation that working developers commonly point out. Games that operate mechanically using AI can be created surprisingly quickly. However, the process of refining them into an entertaining final product is still not easy.
The most common misconception is mistaking “faster development” for “easier game completion.” While the time spent writing code has decreased, the time spent defining what is fun, judging it through play, and choosing what to discard has not. On the contrary, just as there are more things that can be created, there are also more things that must be discarded.
Hold onto the judgment, and document it.
The moment you tell the AI, “Make a game in the OO genre,” the decision-making process for the design is handed over along with it. The AI determines what is fun, how much to include, and what to omit. The developer’s ability to control the fun factor has already passed. On the other hand, if you say, “Organize these analysis results into a design document in the OO format,” the decision-making remains in your hands, and the AI takes on the task of documentation.
Therefore, I summarize the core of working with AI in a single sentence: document the standards first. If standards exist, verification is possible. If verification is possible, only the incorrect parts can be identified and corrected. If only parts can be corrected, the decision-making authority remains with the human until the end. Without standards, one is forced to start over from the beginning until satisfied, and each time, the AI produces a slightly different game.
This is also the path the entire software industry is taking. When applied to game development, the process is as follows: implementation is not initiated immediately after the design document is handed over. Instead, the AI is first asked to summarize the document and question ambiguous parts. After verifying proper understanding, implementation is initiated, and content is modified and expanded upon while maintaining the verified framework.
The work of translating the “realm of senses,” decomposition
If you have already proven game design documents and source code, you can create a work in an instant using AI. However, how should a developer attempting game development for the first time approach this? I recommend that instead of starting from a blank slate, you reverse -engineer a representative title in the genre . This involves breaking down the two pillars of game design—core mechanics and level design—separating them into numerical values and data, and making them controllable yourself.
There is a good textbook. The ‘Celeste’ development team released approximately 5,400 lines of player class code, and co-developer Maddie Thorson personally compiled and shared Celeste’s ‘forgiveness’ mechanism. Looking at that list, it clearly reveals what kind of mechanisms make up the vague feeling of ‘control.’
- Coyote Time — It still catches your jump for a brief moment immediately after you fall off the platform.
- Jump Buffer — Remembers the jump input pressed just before landing and executes it the moment of landing.
- Peak Gravity Reduction — Holding down the jump button reduces gravity by half at the peak of the jump, giving you more time to adjust your direction in mid-air.
- Corner Correction — If you hit your head on a corner while jumping or get stuck on a corner while dashing, gently push it to the side or upward.
- Generous wall jump hitbox — Allows wall jumps even when you are about 2 pixels away from the wall.
“The jump the user expects” is the sum of these named values. And the moment you break them down by naming them, the conversation with the AI changes. While the AI interprets “make the controls feel better” differently every time, “turn on Coyote Time and display the value as a slider” is interpreted in exactly one way.
There is one more habit I would like to recommend here. It is to have them create a tuning panel before making a game .
Subtract all jump, gravity, and dash-related values as the top constant, Please add a debug panel that changes with a slider during gameplay. Adjustment values are saved and loaded as preset JSON.
With this single instruction, the unit of collaboration with AI moves down from ‘feel’ to ‘value.’ “Better control feel” becomes “Widen the range of the gravity slider.” And the task of finding that tactile sensation—that is, judging the fun—returns back to human hands.
Levels are data, not code.
Level design follows the same principle. Fortunately, there is no need to reverse engineer from scratch alone. Fan communities of popular games already have a wealth of wiki data that breaks down levels into rooms. You simply need to have an AI organize this information into a table, and then play the game yourself to verify if the analysis is correct.
And the result must be saved as a data file, not code . If the level is embedded in the code, the AI must be made to modify the code every time it is fixed, and there is a risk that other parts will break each time. If it is separated into data, humans can fix it directly, and the AI can also mechanically check whether the level it creates complies with the rules.
Here, planners receive a truly significant gift: a tool . In the past, if a planner wanted a level editor to use, they had to ask a tool programmer and wait in line. Now, as long as the data format is defined in the planning document, they can have AI create a dedicated editor. That editor then becomes a tool that visually displays the planning document.
In conclusion: I will make the final judgment based on my own gameplay.
What VIVE Coding gave to indie developers was the ‘power to work like a team even alone.’ However, that team does not work on its own. When I assign work, the team produces the average value of an AI rather than my game. If I give clear instructions, the team moves according to my standards.
Becoming an authoritative figure ultimately means holding onto three things: the judgment of determining what is fun, the decomposition of translating that judgment into numbers, data, and documents, and the final verdict made after playing through the results with your own hands. AI can write the code. However, only a human can answer, to the very end, whether that game is fun.
Don’t leave the work to AI; have it do it.
Written by: Professor Moo-Sik Jeong (Associate Professor, Department of Game & Video, Gachon University / Ph.D. in Engineering)
Who is Professor Jeong Mu-sik?
He is a first-generation Korean game developer who started as a founding member of Trigger Soft in 1994 and served as a director at NCSoft, an outside director at NASDAQ-listed company Gravity, and a vice president at Runosoft. Since planning and hosting Korea’s first indie game contest in 2003, he has maintained a long-standing interest in and support for the nurturing of domestic indie games. Currently, he serves as a member and director of the Game Rating and Administration Committee under the Ministry of Culture, Sports and Tourism, and as the head of the Content/Digital/Space subcommittee of the Seongnam City Special Committee on the 4th Industrial Revolution, striving for the development of the domestic game industry and the establishment of a sound culture.
