A week of solo game development with Claude Code, around a full-time job

TL;DR: I build Inselnova on my own, around a full-time job. In the week of 24 to 30 September that meant 66 AI coding sessions, 154 new tickets, and 159 tickets shipped in two releases. A lot of my own time goes on reading what the AI writes for me and answering its questions, 247 of them that week. This is the development lifecycle I’ve ended up with, from a one-line ticket to a release, with the numbers from that week.

Where the tickets come from

Every piece of work is a ticket on one board. 44 of that week’s 154 were a single line from me with no description. Something happens while I’m playing or reading chat, and I copy and paste it in. “Monad - coin storage too small?” is a whole ticket. I’m the only person working on this, so often the title says everything. I use the description when I want a notepad for several ideas at once.

Players file tickets too. 18 came straight from players that week, and over the last four weeks Turtle Blues filed 25 and Florentia 11. Those land in a list called Incoming and I read every one. They aren’t written the way I write mine, so it takes a while to understand what the person means, and sometimes one card becomes three tasks. I don’t look at who reported it, only at what they reported. If it’s a bug, I try to get it into the release I’m already working on.

357 open tickets doesn’t bother me

An Incoming card goes one of two ways. It goes into the next release, or it goes into the Icebox because I’ve already thought about that idea and the game isn’t ready for it. I want people to feel heard, but I won’t build everything that’s asked for. Some ideas need a lot of thinking first.

The Icebox holds 147 tickets and half of them are more than three months old. When a ticket has been there a while, it means I want to sit on it and I’m not ready to build it. I read through it about once a week, sometimes for fun over a coffee, and old ideas come back with new ideas attached. About once a month I groom the whole list. Duplicates get archived, and so does the odd idea that isn’t what I want the game to be. I enjoy reading through it.

What ships is mostly fresh. The two releases that week carried 159 tickets, and the median ticket shipped three to four days after it was created.

A small ticket, start to finish

Picking a ticket takes about five minutes, because they’ve usually been organised in an earlier session. I run /ticket with its number. That loads it into a new Claude Code session and tells me roughly where the code lives. It doesn’t start work, because I want to kick that off myself. Then I give it my ideas, often by voice, because you can get a lot of context across quickly by talking. I usually ask it to check and find the problem itself first, so it builds up its own picture of the code.

If the fix is simple I tell it to go ahead. If it’s something I need to see, I look at it on my local copy of the game. A small ticket skips the heavier checks. I run /commit, and about a minute later it’s committed with a decent log and added to the release’s changelog. I close the session and move on.

I commit small and often. 148 commits landed between 24 and 28 September. It suits how my mind works, and each one is probably a small dopamine hit for reaching a milestone.

A five-minute ticket can turn into half a day

When I open a ticket I decide whether that area of the game needs more than the ticket asks for. One from the week before said the attack messages in alliance chat were grouping up a bit ugly. I looked at it and ended up refreshing all of the world news: one family of news cards and one news service behind them, with four other tickets pulled into the same piece of work.

I think that’s fine. You’ve got to keep things clean as you go.

A big ticket gets about a day of planning before any code

A big feature starts with a brief from me and a /spec, which writes a plan pack: a folder of numbered task files and the questions it needs answered. I check the backlog and the Icebox for older tickets that should be swept up at the same time. For the feature I planned that week, that turned up a bounty idea from 23 August, which went into the plan as something for later.

Then I answer questions. That one feature has four question files with 44 numbered questions, each with a recommendation I can accept or overrule. /grill walks me through the rest one decision at a time. Across the week the AI asked me 109 questions in chat and wrote another 138 into question files. Planning that feature took about a day of waiting for it to think, reading, and throwing other ideas in.

Research is the other big one. For a larger feature it’s spread over several days in ten-minute sessions, and it often means looking at how other games handle the same thing. Most of it happens in ChatGPT, sometimes Gemini, and not much in Claude. I copy files over, get a second opinion and paste the feedback back in, and I get design mockups made before anything is built. Reviewing the finished work is quick because the AI does that job for me, and committing costs me nothing. I fire it and walk away.

I still decide the architecture

I don’t write the code, but I’ve been a developer for 30 years and I read the plan like one. These are from my own prompts that week:

• “I don’t really want hooks all over the game. I can see here we’re going to have to add lots of hooks throughout the whole system, which can make things fragile.” The plan changed to one hook and an hourly sweep.
• “I saw you designed a bounty table… Do we need that?”
• “I’m more about designing the architecture to start with. The ideas could be just having a bool on the report, or a general bookmarking mechanism, new table, like a polymorphic association. But is that too much?” It was too much. Reports got a single column.
• “I like small files, in directories, clean up after yourself.”

For the big feature I asked for a file showing the directory structure of the new engine, and nothing gets built until I’ve approved it.

One worktree, three to five sessions

Each release is one git worktree, and all my sessions work in it together. I know worktrees are designed for one agent each. I can’t keep track of more than one copy of the game, and running several local versions to test on is more than I want to deal with. Hotfixes and the NPC service have their own worktrees, so I can get a fix live without leaving the release.

With heavy tasks I have about three sessions open. With small ones I’ll load five, work through them and commit them. It depends on how much I can take in at once. I try not to let two sessions touch the same files, so usually one is in planning, asking me questions, while another is building. They still collide occasionally, and the commit skill has picked up a lock and a few recovery steps because of it.

Fresh reviewers, then me

When a big piece of work is built I run /shakedown. It sends out reviewers in parallel, each checking one thing: how the screen is built, the numbers, the copy, the tests, the backend, the player’s route through it, and whether the handbook still matches. They are new agents that haven’t seen the session that wrote the code. That gives the AI a fresh memory, and nothing from a long build session can poison what it thinks it knows. The news work had ten reviewers go over 329 files. It came back yellow with 43 major findings, and a fix pass cleared 41 of them. /reconcile does a similar job for the wiki, checking the game against the handbook in both directions. Subagent runs went from 62 to 181 that week, and shakedown reviewers were the biggest single group.

Then I test everything myself on the screen. The /playtest skill has more than 30 recipes for setting a scene up: it spawns an enemy next to my island, lowers their defence, or has them attack me. The AI doesn’t have to work out how to do those things each time. Sometimes there’s twice as much work to do once I see a feature on the screen.

The process gets a fix most weeks too

40 of the week’s tickets start with CHORE:. They’re small jobs that aren’t for players: a skill that needed a new rule, a doc that moved. Every commit on a release needs a ticket, so the /chore skill makes one for itself.

Every week something about the process annoys me. Committing takes too long, or a grill leaves me with too many questions, or I can’t get my head around a balance change. I tell the AI what’s bothering me and ask it to help. I also have an /improve skill with a hook: after a session that committed real work, it asks whether anything went wrong that the next agent shouldn’t have to learn again. It’s allowed to answer that nothing did.

The newest piece is a folder of standing checks that I re-run and compare with the last run: server health once a release, the first-session numbers every Monday, the Black Tide after it changes. They help me look at the whole game, not only the ticket in front of me.

Around the job

I work from home. In the morning, if there’s a batch of small tickets, I throw them all in, let the AI work them out and propose a fix for each, and come back to them at lunchtime. The rest happens in the evening, once my daughter is in bed and if there isn’t a show to watch with my wife. My brain is a bit more tired by then.

My day job is technical and full of data. This is whatever I want it to be. I’m making a world that other people are part of.

The week used 4.3 billion tokens across Claude Code and Codex, and 98% of that was the AI re-reading context it already had. My usage limit resets on a Monday and I normally start running low by Friday. That doesn’t change how I plan the week, but I like ending Friday with little left, because I’m more likely to rest at the weekend. Using AI this much tires your head out quickly. That week I got an extra reset, so 29 September alone was 1.4 billion tokens, most of it planning.

I aim for a release a week. Lately it’s less regular, because more of the work is bigger and trickier.

If you build on your own around a job, what does your week look like?