Galaxy Devlog #09 · Read the Galaxy build log
I do not write code and I cannot read it. Call the Cat: Galaxy, the Unity sequel to a game I already shipped, is written line by line by AI agents. My job is to say what I want, set the rules they work under, and check whether what comes back is actually right.
This one is not about a bug. It is about the fact that AI conversations end, and mine kept ending in the middle of something.
A conversation ends, and so does the work
Development with an AI runs across days, and every so often the conversation ends. Opening a new session means explaining, again, what the bug was, what got changed, and what is still left.
So starting with documentation work on August 25, 2026, I began numbering everything. The first entry is `D-20260825-01`. Gameplay work gets `G-date-number`, work on the mini-game mode gets `L-date-number`, and documentation work gets `D-date-number` — area, date, and sequence number, together in one ID.
Nine checks that all have to pass before a task counts as closed.
One number, tracked in four different places
Making a number and writing it in one daily log does not do much by itself. The same ID needs to show up in four places.
What one work ID connects: the plan doc, the fix checklist, the daily log, and the devlog raw material.
For example, a bug where an enemy that should not appear in the night stage showed up anyway got the ID `G-20260825-02`. That one number let me follow the repro screenshot, the fix path, 24 rounds of static checking, and the actual playtest that was still outstanding — all under the same tag. The ID does not fix the bug. It cuts down how long the next session spends rediscovering the same problem.
Putting evidence in front of the word “done”
Every task log has to include:
ID / Symptom / Cause (confirmed or hypothesis) / Fix path / Files changed Verification evidence / What was NOT changed / Failed attempts / Next check Status / Devlog link / Committed or not
If Unity was not actually run, “Play Mode complete” does not get written. Passing a static compile or `git diff –check` is kept separate from an actual play-test pass. Without that separation, a new AI session can misread a static-check result as proof the game itself was checked.
A beginner-friendly work ID and exit gate
A work ID can be built like this:
`AREA-YYYYMMDD-SEQUENCE`
Gameplay work might be `G-20260828-01`, documentation work `D-20260828-01`. A task only flips to “done” once every line below is checked:
[ ] The plan doc has this ID and its done condition [ ] If it is a bug or requirement, it is in the checklist too [ ] Symptom and cause are marked as confirmed or hypothesis, not blurred together [ ] The changed path and the deliberately untouched boundary are both written down [ ] The verification method and result are recorded [ ] Failed attempts and why they were reverted are recorded [ ] Whether an actual playtest is still required is marked [ ] Whether this is devlog material or on hold is written down [ ] If committed, the hash is recorded; if not, it says so [ ] The next concrete action for whoever picks this up next is written
Why this matters for automated work too
This system does not fix bugs on its own. What it does is keep “fixed” and “checked” as two separate claims. When the AI changes, searching the ID still shows the task’s current state and what verification is still outstanding.
The point of this post is not a productivity brag — it is the boundary that disappears the moment nothing gets written down. This applies past games too: automation scripts, content pipelines, and deploys all benefit from recording what changed alongside what a human still needs to confirm.
Next post
Even with an ID on everything, using the wrong coordinate system or unit still means tracking down the wrong code. The next post is about why aiming with screen coordinates missed on a spherical planet.
Solo dev of Call the Cat, shipped after 178 days
on Google Play
and Steam.
Now building the sequel, Call the Cat: Galaxy, in public.