In this interview, Julius Hartmann discusses how he and the team at InnoGames are integrating AI into the development of Heroes of History, what agentic tools mean for Unity developers, and why the developer’s role could increasingly shift from writing every line of code to directing agents, maintaining architecture, and safeguarding quality.
AI has rapidly become part of many developers’ daily workflow. When did it become an essential tool for you, and how has it changed the way you write, review, and maintain code?
For me, the move into AI-assisted work came relatively early, because InnoGames encouraged and supported developers from the very beginning in trying out new AI tools. It started with simple intelligent code completion in Rider or Visual Studio Code with Copilot. From there, it went on to tools like Cursor and eventually Roo Code and Cline – the first workflows in which AI no longer just makes suggestions but works in a far more agentic way.
At the moment, I mainly work with Claude Code and try to stay up to date on new models and refined workflows. The biggest shift for me is that AI has long since stopped being just a help when writing code. In the beginning, it was mostly about producing implementations faster. Today, AI code review is often the first step before my code even goes to a real colleague for review.
A lot has changed on the maintenance side as well. It is no longer only about maintaining game and tooling code, but also about AI-specific artefacts such as shared Claude skills, agent rules and AI-focused architecture documentation. In Heroes of History, we are currently pursuing an approach similar to agents.md and use Markdown files – among other things in combination with Obsidian – as structured documentation for AI agents.
Since we work in a mono-repository, context management is particularly important. An agent should not simply load the entire project knowledge, but only the context that is relevant to the task at hand. Otherwise, the risk of context rot increases.
That is why we use directory-based Claude rule files. If the agent is working in the backend, for example, it gets backend-specific rules and architecture information loaded into its context. If it is working in the Unity client or the frontend area, the conventions, constraints and documentation relevant there are loaded instead. In some cases, we structure this right down to individual features.
This adds a new technical maintenance layer: alongside product code, tests and classic documentation, we now also must maintain AI metadata such as agent instructions, skills, context rules and architecture notes. These artefacts must be versioned, kept up to date and reviewed, because they directly influence how AI tools work within the project.
Unity development involves everything from gameplay systems and editor tooling to debugging and optimization. Which areas have benefited the most from AI, and are there any tasks where AI still falls short?
Almost all areas of Unity development benefit from AI, but in different ways.
In our case, you can see it especially clearly with internal tools. We now have more than 140 internal Unity editor tools, which is partly because our game designers, artists from UI, 2D and 3D, and other disciplines work very closely with the Unity engine. In the past, such tools still mostly had to be built by developers and only got implemented after a request had been made and the ticket prioritised.
That has changed considerably with tools like Claude. Especially for editor code, our policies are now more relaxed, because code quality has increased so much thanks to good documentation and internally shared skills that artists or game designers can now prompt their own tools. That is a win-win situation for everyone involved. Developers can focus more on new features in the game code, and the tools help other disciplines work more productively.
We are also currently investing a lot of energy in integration and play mode tests. However, we are not yet where we want to be here. The goal is to significantly improve both our skills and our test coverage. For example, I have just written a skill that automatically generates and runs integration tests for new features without modifying production code. That is important, because it is the only way to get meaningful play mode tests. Claude used to be quite fond of cheating here to get to green tests faster.
Your master’s research explored using machine learning to detect bugs and game design flaws. Looking at today’s AI tools, what progress has surprised you the most?
My master’s thesis was still based on locally trained models (reinforcement learning) and of course had only a fraction of the resources available that today’s LLMs are trained with. During my research phase, models were usually heavily specialised for one particular purpose, for example object or image recognition – the classic cat-versus-dog example.
What surprises me most today is how general the models are. In the past, most systems were tailored to a very specific use case. Today the models are so broadly applicable that individual users often only tap into a small part of what they can actually do.
I still find this development towards general AI remarkable. At the same time, I can well imagine that specialised models will continue to have their place in certain application areas.
To give my favorite example, Studio Atelico has shown that generative content in games is possible at low cost! That is an impressive step for the use of generative AI and LLMs in games. They solved the problem by heavily optimising a smaller model and adapting it to the specific tasks of their game. As a result, the AI can even run locally on mobile devices.
How is AI helping you and your team manage bug reports, Jira tickets, and other development workflows more efficiently?
We are still experimenting a lot in this area, but there are already several tools and workflows that noticeably help us in our day-to-day work. One example is a QA bot that automatically familiarises itself with bug tickets, researches the relevant code and leaves its findings as a comment in the ticket. That saves a lot of time, especially for the initial triage.
On top of that there are PR reviews with inline comments that point out possible problems or ambiguities early on. We also use MCPs, for example to create Jira tickets from Slack conversations or to support certain processes. A lot of this is still at the experimental stage, but you can already clearly see that AI has enormous potential, particularly for recurring process steps and for preparing information.
As AI takes over more routine programming tasks, what skills are becoming more valuable for Unity developers?
The obvious one is of course prompting. But what I consider even more important is the ability to handle a lot of context and to switch quickly between different tasks. Once you have got used to working with agents, you often no longer work with just one, but with two or three in parallel. To do that, you must be able to keep several problems in your head at the same time and still stay structured. Some colleagues are already into double digits, but that is too much for me to keep track of.
I have cloned our project with several Git checkouts on my machine so that I can open Unity multiple times in parallel while my coding agent works simultaneously in a dev container, in its own isolated and secure environment. On the security side, we at InnoGames are supported by a dedicated team, which allows us to concentrate more on the actual game code in our projects.
Overall, I believe that skills such as context management, review competence, architectural understanding and the sensible use of agentic workflows will become increasingly important for Unity developers.
Do you think AI will fundamentally change how game development teams are organized, or will it primarily make existing workflows more efficient?
I am convinced that AI will continue to change team structures. Game designers, UI artists and other disciplines will increasingly program themselves, or rather have code generated for them. This automatically shifts the role of classic developers as well.
Developers must pay more attention to how they can meaningfully support this process. That applies, for example, to tooling, shared Claude skills, PR reviews, validation tools or automated testing. Developers should make it possible for a game designer to prompt a new tool without creating a lot of additional work for the development team later on. This requires easy-to-use skills whose output meets our coding standards, as well as mechanisms that catch errors early.
An important part of that is quality assurance. At Heroes of History, many tests run via Jenkins when pull requests are created, so that faulty code cannot be merged. But this process, too, can be supported by AI.
AI can not only generate code, but also help create suitable tests, update existing tests or suggest validation logic. What matters is that these quality assurance processes are deliberately built into the skills and workflows. Then a developer does not have to write or maintain every test manually but instead makes sure that the agent also takes the appropriate tests and checks into account when generating code.
I believe that developers in the classic sense will invest less time in pure implementation in the long run. Instead, they will increasingly have to keep an overview of software architecture, quality standards and the entire development process. In doing so, they become something more like a supervisor for coding agents. The job therefore shifts towards steering agents, quality assurance and empowering colleagues.
Looking ahead, which parts of the software development lifecycle do you expect AI to transform the most over the next three to five years?
As mentioned, classic implementation work in particular will decrease significantly. I used to like describing my job to friends and family by saying that once the game designers and artists had finished dreaming up the game, I was the one who made sure the buttons actually worked when you pressed them. That is only partly true today. In many cases, what I now check is whether Claude, Copilot or some other model has programmed the right button correctly.
For me, the biggest change lies precisely in that shift. The focus moves away from manually writing every single solution and more towards review, validation, steering and setting the right guardrails. I believe AI will transform this part of the development lifecycle most in the near future: less “I write every line myself”, more “I describe the goal, check the solution, test the edge cases and decide whether it really fits into our system”.
However, I do not think that in the longer term there will simply be one large model that does everything equally well. At the moment, many models come across as generalists. They can cover UI design, game design, programming, storytelling, documentation and technical planning all at once, and surprisingly well. But I suspect that the truly professional applications will become more and more specialised.
By that I do not necessarily mean that a completely new foundation model will be trained for every use case. What seems more likely to me is that specialised AI systems will prevail: a strong base model combined with domain-specific knowledge, project context, tool integration, tests, documentation, style guides and clear quality rules.
For software development, you can already see this direction in models such as Code Llama or StarCoder, which were specifically trained or evaluated for code. The Code Llama paper by Roziere et al., for example, presents a model family based on Llama 2 that was optimised specifically for programming tasks and includes variants for general code generation, Python and instruction following. The results on benchmarks such as HumanEval, MBPP and MultiPL-E show that such specialisation in code can bring clear advantages in certain scenarios. (Source: Roziere et al., Code Llama: Open Foundation Models for Code, arXiv:2308.12950, https://doi.org/10.48550/arXiv.2308.12950)
For the software development lifecycle, this means that pure implementation becomes less central. What becomes more important are skills such as describing tasks well, guiding models correctly, critically reviewing results and selecting the right specialised tools. Developers will therefore not become superfluous, but their role will change. They will become more like actors who understand systems, safeguard quality and use AI in such a way that what comes out at the end is not just any code, but the right code for the specific product.
That is why I believe that over the next three to five years AI will above all change implementation, prototyping, refactoring, testing and technical documentation. In the long term, though, the bigger shift will be that we no longer work with just one general AI assistant, but with specialised AI systems for particular phases and use cases: a coding agent for implementation, a QA agent for tests, a build agent for CI/CD, or a game design agent for balancing and gameplay prototypes.
In game development in particular this matters, because a feature does not just have to be technically correct. It has to feel good, fit the vision, be maintainable, run performantly and work with the designers’ and artists’ tools. AI can help enormously with that, but the assessment remains product-related and needs clear guardrails.
In the end, it probably will not be “the one best model” that prevails, but the best system for the particular use case.
Developer at InnoGames GmbH
