Blind Coding: My AI Workflow for Building a Game from My Phone
TL;DR: I built Inselnova’s core gameplay loop on a road trip using Claude Code on mobile. The key: tests first, skill files for context, AGENTS.md as a living spec, plan mode to prevent scope creep, and honestly, just giving the AI room to work. Three weeks in, one bad release. Most mistakes caught at CI/CD. I ship 4-5 changes a day from a coffee shop.
What Blind Coding Actually Is
People throw around “vibe coding,” but there’s a stigma. It implies you’re making it up as you go. That’s not what I’m doing.
Blind coding is deliberate. You set up tests. You write skill files with context. You maintain AGENTS.md as a spec. You let CI/CD catch what your eyes miss. It’s disciplined engineering where an AI is the executor instead of you typing.
The constraint is: I rarely look at the code. I plan, I review the output, I move on. The benefit is velocity. On a phone, over three weeks, I went from empty repo to a working strategy game.
The Setup: Making It Work
Before the first line of code:
I created an empty GitHub repo. Wired it into Claude Code. Then I pulled every scrap of documentation about Inselnova’s mechanics. Old wiki pages, balance spreadsheets, calculations for resource production and combat formulas. Everything went into skill files and AGENTS.md.
AGENTS.md became the single source of truth. It describes the architecture, the folder structure, naming conventions, database schema patterns. It even lists gotchas I’ve learned: “No SQLite-only SQL in runtime queries” because we need PostgreSQL compatibility later. When the AI reads AGENTS.md, it knows how to write code that fits.
Tests run in under 10 seconds because we use SQLite for dev. The CI/CD pipeline is tight: build backend, run tests, build frontend, deploy. If something breaks, the host stops it going live and I see the error.
CLAUDE.md just says “read AGENTS.md.” Same file works whether I’m in Codex web view or Claude on Android.
The Road Trip
Three days. Packed a car, plugged Claude Code into my phone, and asked it to find the old wiki pages with all the calculations. Building blind means I wasn’t opening files to check logic. I was asking it to pull the spec, then write tests that verify the spec, then write code that passes the tests.
Day one was rough. Day two, the patterns clicked. Day three, I had building systems, resource production, and basic unit logic. The frontend looked terrible. The backend worked.
Came home after three days, pulled the code. Week one was all logic. Week two was graphics.
Daily Cadence: Coffee Shop Workflow
This is the rhythm now. I wake up, go to a coffee shop, play the game on my phone for 30 minutes. Then I flip to Claude Code, think about what felt wrong or what’s next, and queue up 4-5 small changes.
Each change is concrete. “Add a timer UI for when the next research finishes.” “Fix the unit count display so it shows total units, not just trained units.” “Let players navigate between islands faster.”
I tell Claude what I want, it makes the change, I scan the diff on mobile, I merge to main. The CI/CD pipeline runs. In a few minutes, it’s live. Then I play the change on my phone.
This loop repeats 4-5 times a day.
The 2,000-Line Problem
After two weeks, one file had exploded to 2,000 lines. I wasn’t looking at the code often, but I could feel it. Changes were taking longer. Bugs were getting stranger. The file was a pressure cooker.
I put Claude into plan mode. Literally: “Before making any changes, write out a plan in plain English. What are you going to do and why.”
Then I asked it to split the file into smaller domain modules. I had to use technical language, words like “domain” and “separation of concerns,” but the work was straightforward. It refactored the file into focused modules, wrote tests for each module, and kept the public API the same.
The lesson: if you can feel the code getting unwieldy, you’re right. Fix it early. Plan mode helps because it forces the AI to think before acting.
The One Bad Release
Three weeks in, only one bad release. It happened on day 18.
I was refactoring the island-switching code while out. The change seemed small: reorganize how we load island data, reduce API calls. I merged it. It broke. Players couldn’t switch islands.
Here’s the catch: the AI couldn’t debug it on its own. I’d queued the change from my phone. It passed local tests. But the bug only showed up in production with actual player behavior.
I had to wait until I was home, at my desk with VS Code open. Looked at the code. Found an unusual pattern where we were caching data in the wrong scope. Pointed it out. The AI undid all its “fixes” and applied a single-line correction.
The takeaway: blind coding works for features and small refactors. For tricky domain logic that touches player state, sit down and review. The AI is good at execution, not at second-guessing its own assumptions when it can’t see the full picture.
Multi-AI Workflow
I learned to use different AIs for different tasks.
Claude Code on mobile writes code. ChatGPT shapes ideas. For larger features, I’ll chat with ChatGPT about the design while watching TV, copy the spec into Claude Code in the morning, and it’s ready to review.
Here’s the practical flow: when I’m stuck, I ask Claude Code to explain the current state of the game. I copy that explanation into ChatGPT and ask for help ideating the next feature. Then I paste the spec back into Claude Code to implement.
One AI documents what exists. The other imagines what’s next. They’re good at different things.
Prompt Tricks That Work
Two habits changed how I work with the AI:
First, be fluffy. Instead of “Add the island name display,” I ask “What if we showed the island name? Maybe in the top corner, sometimes with an icon?” Fluffy language puts it into brainstorming mode instead of just telling you what you want to hear.
Second, steal ideas from creative people. I once asked Claude, “What would Rory Sutherland do with this interaction?” It changed the angle completely. The prompt trick is naming someone whose thinking you respect.
These feel small. They’re not. They change whether you get compliance or collaboration.
What Makes This Different from Vibe Coding
Vibe coding is hoping for the best. Blind coding is architecture plus surrender.
I maintain a living spec in AGENTS.md. I write tests before features. I review diffs before merging. I have CI/CD as a safety net. I sit at my desk when the logic is tricky. But I surrender the execution to the AI and trust the setup to catch mistakes.
Vibe coding skips the setup and hopes the AI figures it out. It usually doesn’t, not at scale.
The Daughter
I started this experiment to test how far AI coding workflows could go, not just to build a game. Turns out, the answer is pretty far.
I’m now helping four people get better at AI-assisted development. One is my seven-year-old daughter. She watched what I built and got inspired. Now she’s making her own game, asking Claude to help her code it. She doesn’t know what an AGENTS.md file is. She just asks Claude for code, plays what it makes, and asks for changes.
Maybe that’s the real story. The setup I built works because it’s predictable. But kids don’t care about predictability. They just care that the AI can help them build something cool.
How to Start Today
If you’re a programmer and you want to try this:
- Set up tests first. Get them running fast. 10 seconds or less for your domain.
- Create AGENTS.md. Write it like you’re explaining your codebase to an intern. Include architecture, naming conventions, gotchas, how to run the project.
- Add skill files for knowledge that won’t change often. Lore, design language, calculation formulas.
- Use plan mode before big changes. Ask the AI to write a plan in English before it touches code.
- Merge to main only after CI/CD passes. Use that as your safety net.
- For debugging, sit down and look at the code. The AI is good at execution, not at mysterious bugs.
- Use multiple AIs. Claude for code, ChatGPT for ideation. Document with one, invent with the other.
The workflow works because you’ve done the thinking up front. The AI handles execution. You handle review and steering.
You can play the game here: Inselnova.
This is part of the Inselnova dev log series. Posts cover the build, the game design, and the weird corners of a multiplayer strategy game.
