If building games with AI makes you think of "vibe coding," I want to show you what it is really like. I am a professional software engineer by trade. Like at most companies, I am required to leverage AI coding tools to do my work. I have been doing so for over a year, and in the last few months I no longer write or review any code by hand.
For most of my personal game projects I write the code myself "for fun" as a diminishing opportunity to practice the mechanics of my craft. But on my latest project I decided to build it the same way I build software at work. Note, I'm only going to talk about using AI to write the code and won't address AI generated assets.
My game is called Crossword Dungeon. Imagine a crossword forming the layout of an old-school dungeon crawler. Each letter is a "room" and each room has a treasure, trap or monster. Solving a letter of the crossword levels-up the connected rooms, making the dungeon harder. The puzzle solving confounds the RPG elements and the RPG mechanics confound the puzzle solving.
Bootstrapping
I had the original idea for the game a long time ago. I kicked it around and eventually landed on this ASCII approach because I had already made a few ASCII games and had prior art to draw from. I started by making a design doc sketch completely by hand (follow the links to see the exact content checked in to my Github repo). This sketch had all of the conceptual ideas and mechanics I had worked through and contained the main hook of the game.
From there I shared it with Claude Code (using Sonnet 4.6) and had it ask me questions about it with the goal of formalizing it into a full design doc. This fleshed out version had the same essential content as my sketch, but filling in the gaps and specifics.
From there, I had Claude break down the design doc into a series of milestones. Each milestone recorded all necessary information, including design, behavior, technical aspects, and validation criteria. I instructed it to scope milestones as chunks of deliverable value, similar to an agile workflow. For example, being able to simply render a dungeon, then navigate through it, then see unique encounters, and so on. This limited the scope of work, but more importantly game me a way to try it out at every step of the way to accept the work or request changes if it didn't work right or feel right.
Implementation
Before having Claude write any code, I made two more important documents. The first was a technical design doc. Having already figured out useful libraries and coding patterns from my other games, I wanted to enforce some patterns and also provide examples. I also outlined some gotchas I expected Claude to stumble on or try to get too fancy with.
The second was a short but powerful CLAUDE.md. This clearly pointed at the code for the prior art references, outlined the agile milestone-driven workflow, and guided the validation steps I wanted after writing any code.
With that in place I would fire up a new instance of Claude Code and type
Time for milestone 1
Thanks to the described setup, Claude would read the required documents, reference the prior art code bases, and walk through a series of questions to get clarification as needed. Any important decisions on technical approaches or design tradeoffs were captured in a decisions doc. Then it would begin coding. I would walk away and come back a few minutes later to a running game in my browser!
Continued development
Once all of the initial milestones were complete the game was at a functional MVP. I wanted to add more content and special-case features. At this point I noticed Claude kept getting confused about how certain parts of the code base worked. It kept making similar mistakes or trying to make poor code design choices. We spent some time reviewing the architecture and talking about coding design patterns and I let it through some refactors to make the code more robust and easy to work with, resulting in an architecture document that it would consult and keep up to date as things changed.
Time breakdown
Here is a representative breakdown of how I spent my time on adding new milestones. This example is for the milestone to add new types of special rooms for varied content.
Play the game and collect notes over multiple days
1hr conversation with Claude to outline ideas from notes and turn into a new milestone
2hr manually editing the milestone (writing the display text strings and adjusting desired behavior specs)
30m Claude implements the milestone autonomously
5+hr manual play-testing and tweaking with Claude interactively to find bugs, adjust design for clarity and get the right feel
At these later stages of development, the time commitment was fairly high. Only thirty minutes spent by Claude, with multiple hours of dedicated manual time. The play-testing and acceptance after implementation took most of that time. At work I would validate the generated code with a "testing harness." In game dev it is much harder because games require so much squishy human play-testing for look and feel and play-ability.
UPDATE - I found a way to do autonomous AI play-testing to offload the tedious validation and bug squashing and let me focus on the play and feel.
All in all, I have leaned very heavily in AI to make this game. And yet, it still required significant time and attention and creative direction. I enjoyed this approach. At this point in my career, I don't get much value out of writing code for yet another game system. Leveraging AI in this way let's me focus on the creative ideas and player experience with a much faster feedback loop, which is a very satisfying workflow.
