How I Built a Puzzle Game with AI

I'm an indie developer in Lafayette, Louisiana. I work on two projects right now: Pointy Puzzle, a browser-based logic game, and MazeDrop, an AR maze game for iOS. I do this solo. No team, no budget to hire one. Just me, a laptop, and whatever hours I can carve out after everything else in life.

When I started building Pointy Puzzle, I decided to lean heavily into AI tools — specifically Claude Code, Anthropic's CLI for working with AI in your development environment. I want to be honest about what that actually looked like, because the narrative online tends to swing between two extremes: either "AI writes your entire app for you" or "AI is useless hype." Neither of those matched my experience.

Here's what actually happened.

Why I Decided to Try Building with AI

The simple answer is time. I don't have much of it. Building solo means every hour I spend fighting boilerplate or hunting down a bug is an hour I'm not spending on the parts of the game that actually matter — the puzzle design, the feel of the interactions, whether the thing is actually fun to play.

I'd been watching the AI coding tools get better over the past couple of years, and at some point I figured I'd either try it for real or stop pretending I was going to. So I went all in on Claude Code for Pointy Puzzle. I wanted to move fast, ship something real, and document what the process looked like — not the polished pitch deck version, but the actual messy day-to-day of it.

Spoiler: it helped a lot. But not in the ways I expected, and it had some real limitations I didn't anticipate.

What AI Is Actually Good At

Let me start with where AI genuinely accelerated things, because there's real value here and I don't want to undersell it.

Scaffolding and boilerplate. Setting up a project structure, writing the initial file layout, getting a canvas rendering loop going — all the stuff that's necessary but not interesting. AI handles this fast. What might take me an hour of looking things up and wiring together, I can get a working first draft of in a few minutes. Then I actually read it, understand it, and modify it. That part doesn't go away.

Debugging with a second set of eyes. This one surprised me the most. When I'm staring at code I wrote and something is broken, I have blind spots. I stop seeing what's actually there and start seeing what I think should be there. Pasting a problem into Claude Code and asking "what am I missing here" catches things fast. It's not magic — it still gets it wrong sometimes, and I still have to evaluate whether the suggested fix actually makes sense. But as a second-opinion tool, it's genuinely useful.

Iteration speed. I'd come up with an idea for a mechanic, describe it, get a rough implementation, try it, hate it, iterate. That loop is a lot faster with AI in it. The cost of trying something dropped significantly, which meant I was more willing to experiment. For a puzzle game, that matters a lot — so much of design is throwing things at the wall and seeing what sticks.

Code I don't love writing. Event listeners, state management boilerplate, accessibility attributes, CSS that needs to work across browsers — the stuff that I know how to do but find tedious. AI handles the tedious stuff better than I expected, which freed me up to focus on the logic at the core of the game.

What AI Struggles With

Here's where it gets honest.

Game feel. AI can write code that technically implements something, but it has no sense of whether that thing feels good when you interact with it. The timing of an animation, whether a tap response feels snappy or laggy, whether clearing a row of arrows feels satisfying — all of that requires playing the game, feeling it in your hands, and iterating based on physical intuition. AI doesn't play games. It can't tell you whether something is fun.

Design decisions. When I was designing the core mechanic for Pointy Puzzle — the rules around which arrows are blocked, what order you can clear them in — I had to make a lot of calls that were fundamentally about taste and player experience. AI would offer options, but it couldn't tell me which one was right. Those decisions still require a human who cares about the player sitting on the other side of the screen.

Knowing when to stop. AI will keep generating. It doesn't get tired, and it doesn't have a strong intuition about "this is good enough, ship it." That judgment is still entirely on you. And for an indie developer trying to actually finish something rather than endlessly polish it, that's an important judgment to make.

Context drift. On longer sessions or across multiple conversations, AI loses track of decisions you made earlier. I'd explain an architectural choice, go work on something else, come back, and find suggestions that contradicted what we'd already established. You have to manage the context. That's overhead that adds up.

The Honest Reality: AI Doesn't Replace the Developer

I want to be direct about this because I think the hype sets up a misleading expectation.

AI didn't build Pointy Puzzle. I built Pointy Puzzle. I made every design decision. I decided what the game was about, what made it interesting, when the difficulty curve felt right, when a level was too easy or too frustrating. I reviewed every piece of generated code before it went in. I threw out a lot of it. I rewrote plenty of it. I debugged things the AI couldn't figure out.

What AI did was lower the cost of execution so I could spend more of my limited time on the parts that require a human. For a solo developer, that's genuinely meaningful. It's the difference between having a capable junior developer handling the grunt work and doing all of it yourself. You still need to know what you're building and why. You still need to understand the code well enough to know when something is wrong. The developer doesn't go away — the developer just gets faster.

What the Workflow Actually Looks Like

I've seen people describe AI development like you just type "build me a puzzle game" and come back an hour later. That is not what this is.

My actual workflow looks something like this: I have a specific thing I want to build or fix. I think about it enough to know what I'm asking for. I write a clear prompt — the clearer the better, because vague prompts produce vague code. I get back something that's in the ballpark, read through it carefully, catch the parts that are wrong or that don't match how the rest of the codebase works, give feedback, get a revised version, and then usually edit it by hand before it goes in. Then I test it. Then I probably fix something that broke.

It's iterative. It's back and forth. It's not a vending machine where you put in a description and get out working software. Claude Code is good enough that the iterations are usually productive, but you're still the one steering the whole time.

I document this process on my YouTube channel, NicksDevStories, if you want to see what it actually looks like in practice rather than taking my word for it.

Would I Do It Again?

Yes, without hesitation. For an indie developer working alone with limited time, having an AI coding tool in the workflow is a genuine advantage. It let me build Pointy Puzzle faster than I would have otherwise, and it let me experiment more freely because the cost of trying something dropped.

But I want to be clear that it's a tool, not a replacement for the craft. The interesting problems in game development — making something that's actually fun, designing a difficulty curve that doesn't frustrate people, making interactions feel good — none of that got easier. The boring-but-necessary parts got faster. That's a worthwhile trade, but it's a narrower win than the hype suggests.

If you're a developer thinking about leaning into AI tools, I'd say go for it. Just go in with realistic expectations. You're still the one building something. The AI is just helping you build it faster.

Frequently Asked Questions