Analysis, plan, code, checks: our rhythm for developing with AI 🤖

We have never hidden that we use AI a lot on Blocks Beyond The Stars — without it, a game this size simply would not be doable as an after-work project. But for us, "developing with AI" does not mean: type a wish, take the result, hope. Over the months a fixed pattern has emerged that sounds surprisingly old-fashioned — and works precisely because of that. Today we lay it out in full.

It always starts with a human and an idea. Before any AI does anything, someone wanted or noticed something: a player using the feedback key to report that animals appear inside their walls — or we ourselves, when Justus says mid-game what he is missing. The AI does not invent tasks around here. It is given them.

Then the AI works in phases. Four of them, always in the same order: analysis, planning, implementation, verification. (The fifth step, manual testing, comes afterwards — but that is a human's job again, more on that in a moment.) The most important trick is what the AI is not allowed to do: write code right away. An AI that starts typing immediately solves the wrong problem at impressive speed. So every larger task begins with an analysis — what is already there, where does the cause really lie, what else is attached to it? The result is text, not code.

Then comes the plan — and it gets read. The analysis is followed by planning: which files will be touched, in what order, which traps are known, which decisions are still open? This is exactly where the questions surface that are better answered before programming ("Should this work in the browser too?", "What happens to old save games?"). Only once the plan stands does the implementation follow — and that is often the most boring part of the whole thing. Which is exactly how it should be.

Related things go in one batch. A second rule that saves us a lot of time: when several problems are similar or connected — five gamepad menus that all share the same focus problem, or fifteen findings from the same test round — the AI gets them bundled as one job, not as fifteen separate ones. It then has to work through the affected code only once, the solutions fit together instead of contradicting each other, and nothing falls on the floor between two jobs.

Before every release: two separate inspection rounds. After every larger work step — and always before a new version goes out to you — we set the AI on the result once more. But with two deliberately separate investigations. First: are the targeted features and bug fixes really completely done — or is a half-finished remnant still sitting somewhere, a forgotten edge case, a missing translation? Second, in a pass of its own: did the changes cause new problems elsewhere? Mixing both into one question does not work — whoever hunts for gaps and for collateral damage at the same time finds half of each. Asked separately, these two questions spare us an enormous amount of rework; a good share of the things that show up in the release notes as "fixed along the way" comes exactly from these inspection rounds.

And at the very end, a human tests again. The fifth step is not an AI phase but ours: manual testing means actually playing. Freshly built version, a real gamepad, a real kid playing. Plenty of things that survive every analysis die within the first five minutes on the sofa. Because whether something feels right is a question no analysis in the world can answer.

Look closely and you will find no AI magic in this pattern, just age-old engineering craft: first understand, then plan, then build, then check. And for us the bracket around it is always the same: a human has the idea, a human does the final test — the AI works in between. The only new thing is how fast that loop has become. 🔍