Developing an RPG with AI: what comes after the first result

When I read the 1E9 article on projects built with Claude Opus 5.5, I couldn't help thinking of my own project. It showcases applications, animations and games that, according to their creators, came together in a short time. Some of the stories are about handing the AI an idea and collecting the result a few hours later. The article itself points out that these origin stories usually cannot be independently verified.

What interests me most is what happens next. What does it take to turn a first playable scene into a coherent RPG?

That is exactly what I am working on with Epos of Ashes. I am developing the game in Unity together with Claude and Codex. As a solo developer, I orchestrate the AI harnesses and bring my experience as a software developer to the project structure and the processes around it. That includes deciding when a solution needs to be reviewed or reworked.

Playing changes how you look at it

As soon as a character walks through the world and the first enemies attack, there is something tangible. Results like that are easy to show. 1E9 also notes that visual work is especially prominent in public perception because it can be conveyed in short videos. A clip, however, says little about how a game behaves over a longer stretch of time.

So when we play our RPG, our attention regularly shifts: from the question of whether a feature exists to how it behaves in context.

An enemy spots me, approaches and attacks. But if my hits barely change its behaviour and the enemies next to it stay uninvolved, the fight still feels incomplete. That raises new questions about hit reactions, group behaviour and the rhythm of an encounter.

The roadmap helps me put these insights in order. It evolves with the project. Some decisions hold up; others get reopened by a single play session or a new dependency.

Working autonomously also means organising collaboration

The longer autonomous runs described in the 1E9 article touch on a question that occupies me too: what has to be in place for an AI to keep working sensibly over a longer period?

In my project, Claude and Codex work on different areas, and additional agents take on narrowly scoped tasks. That requires the same kind of agreements as a development team: clear responsibilities, understandable handovers, and information about interfaces that have changed.

For this I use a synchronisation service of my own, harnes-sync. It supports communication between the working environments. Responsibility for how it all fits together stays with me. When two workstreams each deliver a plausible solution, I still have to check whether both rely on the same assumptions and work together.

As autonomy grows, it also becomes relevant which tools and access are permitted in the first place. That is a different level from the quality of our game code, but it belongs to the same way of working. In September 2026, for example, OpenAI documented a research agent that exploited a gap in DNS filtering to reach an external chatbot despite network restrictions. The case shows concretely why the boundaries of the working environment need to be checked as well. OpenAI incident report

Approaches such as OpenAPPA therefore sit, according to their documentation, between the agent and its tools: rules outside the model check where information may be passed on. That is an example of technical control in addition to instructions given to the AI — not a blanket security guarantee. OpenAPPA: how it works

False positives: what a green test doesn't answer

We can overestimate certainty when verifying functionality, too. A passing technical test first of all answers the questions of its own test scenario.

Scrolling through our hotbar, for example, automatically consumed potions. Selecting an item and using it were coupled in the code. Only in actual play did it become clear that this behaviour did not match what a player expects.

To me, observations like this are part of a more complete acceptance process. Technical tests check defined cases. Playtests add the sequences and situations those cases do not yet cover. Then there is the wider context: which action came before? Which window is open? What happens after switching, or when a save game is loaded?

Only this interplay shows whether an encapsulated feature works correctly and reliably within the game as a whole. Producing a result and reliably signing it off are two different tasks — and in a short demo they easily blur into one.

From progress to actual effort

This distinction matters for economic expectations as well. A quickly generated demo does not yet tell you anything reliable about the return on investment of an entire project. Integration, verification, corrections and later maintenance count just as much.

How hard it is even to measure productivity is described by the research organisation METR: in its February 2026 update, it sees signs of greater speed-ups from newer AI tools, but calls its own data unreliable for a precise estimate because of selection and measurement problems. Neither a general promise of success nor a general dismissal follows from that. METR on measuring productivity

In my day-to-day work, iterations cost money even with cheaper models, narrowly scoped agent tasks and automated workflows. Usage limits interrupt the work, switching sessions requires handovers, and wrong assumptions lead to rework. Attempts at optimisation change this effort, but they don't make it disappear.

The same applies to models, animations and effects: they have to fit the design, be technically integrated, and be checked against their licence terms. This work is part of the project, even if it is barely visible in a screenshot.

Keep questioning the progress

The examples at 1E9 show what people are trying out with AI. My project adds a view of ongoing development: what has to happen for the many individual results to fit together?

AI makes it possible to explore areas you previously avoided for lack of knowledge or because of their complexity. At the same time, visible progress can tempt you to look only at the next goal. Without enough verification, results pile up that look convincing but work poorly together — what is often called "AI slop".

That is why, at Epos of Ashes, looking again is part of the process: playing, questioning assumptions, changing decisions and checking results in context. The AI harnesses are part of this collaboration. Whether the end result matches my vision of the game is still something I have to shape and judge myself.