Agentic AI Experiment: Building dodolanan.com with Claude Code

A while back, during a lull between client work, I ran a casual experiment: how far can you actually trust agentic AI to build something from scratch, not just patch existing code? Instead of reading other people’s threads about “the optimal agentic workflow,” I decided to just do it — build a real project from zero using Claude Code, and actually ship it, not just a local demo that never leaves my laptop.

The result was dodolanan.com — a small collection of mini games you can play right in the browser. Not ambitious, on purpose. I wasn’t trying to build something that had to succeed, I was trying to understand the limits of the workflow.

What surprised me wasn’t “AI can write code” — that stopped being news a while ago. What was new was watching the agent go beyond smart autocomplete and actually carry a chain of tasks — scaffolding the project, writing each game’s logic, helping with deployment — inside one continuous work session, instead of disconnected pieces I had to stitch together myself afterward.

One moment stuck with me. While building one of the games (a simple grid puzzle), I just said “add an undo feature” without explaining how the state should be stored. The agent went with snapshotting the entire board on every move — not diffing, not the more “academically correct” command pattern — and honestly, for a game that small, that was the right call. I almost stepped in to change it, then thought about it again and left it alone.

A few things I took away from this:

Scoped instructions beat big ones. “Build me a number-guessing game” is too broad — the result is generic and I still had to correct a lot. Once I broke it down into per-feature tasks (game loop skeleton first, then scoring, then UI, then animation), the results got noticeably more precise and I needed far fewer total rewrites.

Small iterations beat a complete spec upfront. I tried writing a long spec for one game all at once, thinking it’d be more efficient. It came out messier than giving small tasks one at a time and reviewing each. That feels counterintuitive — a more detailed spec should mean a better result — but it doesn’t, because I get lazier about reviewing something that large in one go.

Big architectural decisions still have to stay mine. Folder structure, how game state gets stored across games (localStorage vs. in-memory), asset format — I decided all of that before the agent wrote anything. When I let the agent decide from scratch, things worked, but weren’t consistent from one game to the next.

For a solo developer, this felt like a different tier from “AI helps me code faster.” A project that would normally eat a few weeks of evening hours after client work got compressed into days — not because the AI wrote flawless code, but because the scaffold-review-continue loop moved a lot faster than working alone usually does.

Not everything went smoothly, though. There was one simple rhythm game where the agent struggled — precise requestAnimationFrame-based timing is the kind of code that’s hard to validate just by reading, you have to actually play it slowly and feel it out. I threw away a few iterations that looked correct in the code but felt laggy in practice. That part can’t really be delegated — feel can only be checked by actually playing, not by reading a diff.

I consider dodolanan.com done as an experiment — no plan to keep adding games on a regular schedule. But the way of working I found there is now my default on client projects too: small scope, break it down by feature, review each piece before moving on.