I Let My AI Assistant Do the Heavy Lifting on Two Godot Games. My Job Changed.

Kfir Adut — Fri, 18 Sep 2026 14:35:54 +0000

The usual way people talk about AI-assisted development is too small.

They describe a faster autocomplete, a better search box or a tool that can turn a clear instruction into a block of code. Those things are useful, but they still leave the developer carrying the whole project in their head: what needs to happen next, what broke, what to test, what to ship and when to stop polishing one part and move to another.

I have been testing a different model while building two Android games in Godot.

My AI assistant, Instinct, does the heavy lifting. It researches approaches, works through implementation, inspects existing assets, maintains the repositories, runs tests, diagnoses failures, prepares builds and keeps the work moving across many steps. I set the product direction, challenge weak decisions, test the result on a real device and decide what is good enough to keep.

That division of labor is more demanding than "AI writes code." It changes what the human needs to be good at.

The projects

The first game is Glimmerbook Solitaire, a portrait Android game built around classic storybook worlds. The second is Ithaca Rising, an Android-first game inspired by the journey of Odysseus.

Both use Godot 4 and GDScript. Both live in GitHub repositories with automated build work around them.

Glimmerbook Solitaire in portrait: the Basket at Dawn higher-or-lower board, with the draw pile, current card and eight-card layout visible.

They are still works in progress, which makes them useful tests: the assistant is not being asked to reproduce a finished specification. It has to operate while the product is still changing.

That is where the real work begins.

A prototype can look productive because many files changed. A product only moves forward when the right thing changed.

Heavy lifting does not mean final authority

Instinct can take a goal such as "make this feel closer to a polished casual game" and turn it into a long chain of work. It can study references, inspect the asset library, compare implementation options, update scenes and scripts, run checks, prepare an Android build and report what remains weak.

That is heavy lifting because I do not need to direct every file edit or remember every dependency between steps.

But the assistant does not get the final word.

One early version of Ithaca Rising was built as a web prototype. It was a coherent technical path, but it was the wrong product decision. I was building an Android game with combat, animation, touch input, audio, particles and room to grow. I pushed back and asked why we were not using Godot.

The project was moved to Godot 4.

Earlier Ithaca Rising stage: Odysseus and the layered environment were in place, while the Lotus Wraith was not visible and the interface still crowded the scene.

That moment taught me more than a smooth success would have. An assistant can execute a reasonable plan very quickly. If the plan is wrong, speed only gets you to the wrong place sooner. My most valuable contribution was not writing the replacement code. It was recognizing that the implementation did not match the product.

A better loop: direction, execution, evidence, correction

The working loop now looks like this:

I define the experience and the standard.
Instinct researches and implements the next meaningful slice.
The project is built and checked through the repository and CI workflow.
I test the result, usually on the target Android device rather than judging only from code or screenshots.
We compare the result with the intended experience, find the gap and repeat.

The evidence step matters.

A build existing is not evidence that it launches. A scene loading is not evidence that the game feels good. A screenshot looking polished is not evidence that touch input, pacing or progression works.

We hit a launch problem in one Android build. The useful response was not to keep adding code. It was to compare the broken build with the previous game and release path that already worked. That narrowed the problem and got the project back onto a known-good path.

Later Ithaca Rising combat: Odysseus and the Lotus Wraith are both visible, with an enemy health bar and hit particles making the action easier to read.

This is one of the strongest uses of an agent: it can hold the mechanical history of the work and investigate the difference, while I stay focused on the outcome.

The human bottleneck moves upward

When implementation becomes cheaper, judgment becomes more important.

I spend less time asking, "Can this be built?" and more time asking:

Is this the right mechanic for the audience?
Does the current build feel like a real game or a prototype wearing polished art?
Are we reusing the best assets and open-source work available, or rebuilding something weaker?
Is the next feature actually improving the experience?
What does the real device show that the development environment hides?

A landscape Glimmerbook crop makes the hierarchy easy to inspect: title and rule first, then the burgundy card backs and cream face-up cards.

These questions are not separate from engineering. They determine which engineering work is worth doing.

There is also a management lesson. An AI assistant can continue across research, implementation, QA and release preparation without waiting for a new prompt after every small step. That creates leverage, but only if the project has clear constraints and a way to verify reality. Otherwise, autonomy becomes motion without progress.

What I would do differently now

First, I would lock the target platform and quality reference before the first implementation. The web-to-Godot correction was useful, but avoidable.

Second, I would define "done" as an observable result. For an Android game, that means a build that installs, launches and behaves correctly on the target device. Repository activity is not the finish line.

Third, I would make comparison part of the debugging process from the start. When one project works and another does not, diff the working path before inventing a new one.

Finally, I would keep the roles explicit. Instinct does the heavy lifting. I own the direction, the standards and the decision to ship.

That is not a smaller role for the human. It is a more concentrated one.

A note on how this article was made

The same division of labor applies here. Instinct prepared this draft from our real project history and did the heavy lifting in turning it into a clear technical narrative. I reviewed the facts, chose what should be public and remain responsible for every claim published under my name.