Galaxy Devlog #08 · 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 about a change that fixed the thing I asked for and quietly removed a thing I did not ask about. Not a crash, not a bad commit — a working rule that disappeared because it looked like part of the problem. The AI did what the words said. The words were the issue.
The boss had two rules, and I only named one
Our fire fox boss does two things. It breathes fire from its mouth as a ranged attack, and it deals damage if you touch its body. Two separate rules, running at the same time.
The bug I reported was about the first one: the fox kept closing the distance and shoving the player with its body instead of keeping its range and using fire. So I asked for that to be fixed.
What I did not do is say the second rule out loud. “Touching the body hurts” was already working, so it never occurred to me to list it. To the AI, reading only my request, the body was the source of the problem — so the body hitbox went away with the fix.
Removed under G-20260826-10, restored one ID later the same day. Both the cut and the restore stayed in the log.
Fixing where the fire starts also cut where the body hurts
The first fix was about the fire’s origin. To stop the fox from crowding the player, the fire hitbox was moved off the boss body and onto the mouth — the point the fire actually comes out of. That part was correct and I still want it.
But the body-contact damage came off in the same edit. That behavior was original, not something I was changing, so it was put back through its own separate path. In the internal log it is the step from G-20260826-10, where it dropped out, to G-20260826-11, where it came back — same day, one ID apart.
“Restored” there means the code and the log now have it. It does not mean I have watched the fight in Play Mode and confirmed both the fire and the body contact land the way they should. That check is still mine to do.
To catch a regression you have to write down the before, not just the after
“Fix the fire attack” was carrying two instructions that I had not separated. One: keep working — touching the body hurts, including while the fox is breathing fire. Two: change — the fire starts at the mouth, not from the center of the body.
If the scope of the task is written only as “the fox gets too close,” then a working rule — body contact — reads as part of that problem. So the work log for this change does not just say what moved. It has a column for what was deliberately left alone, and a column for attempts that were tried and reverted.
The “unchanged / failed attempts” column. Kept on purpose, so the next session does not undo the restore or retry a dead end.
A checklist you can fill in before you ask
Before handing a code fix to an AI, fill this in for yourself first. It is the same information the AI needs, so the request writes itself from it.
Symptom what looks wrong right now? Keep working what is correct today and must not disappear? Change scope how far does this fix reach: which files, which paths? Do not touch which files, branches, or behaviors stay untouched? Tried and reverted what did you attempt that did not work? Verified static check done? actual play check done? (two things)
Then the request to the AI is built from the same rows — naming what to preserve, not only what to fix:
Body-contact damage stays as it is. This change is only about the fire: where it launches from and the ranged hitbox. Before editing, list the code path that handles body contact and the path that handles the fire separately, so I can see they are different. Do not touch files outside that scope. Do not tell me it works if you have not run it.
Putting this in front of a task does not remove the risk. At the end you still look at what changed and confirm nothing that was working went with it.
Where this leaves things
The fix I asked for is in. The rule I did not ask about is back. Both are in the log, one ID apart, and the failed first attempt is written down next to them so the next session does not repeat it.
What I checked here is the code and the work log. I have not confirmed in Play Mode that the fire and the body contact both deal damage as intended — that is a separate job and it is not done yet.
Next post: a regression is cheaper to undo if you can still find the change that caused it a week later. It is about giving every bug its own work ID and linking that number through the planning notes, the daily log, and the review record.
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.