Does using AI language models (LLMs) really accelerate game development, or do they just create hidden technical debt that can hurt us later? We’re going to approach this as a hypothesis: LLMs can dramatically speed up development, but also risk amplifying technical debt. Let’s test this claim together by looking at real examples from our workflow.

I spent the last couple of months observing the impact of AI on No Rest for the Wicked. In this article, we're gonna take a deeper look at what type of tool LLM really is and how to use it properly.

* Any time I mention AI-tool or LLM in this article I don’t mean any specific tool. On a daily basis, I usually use Gemini and Cursor. The article doesn’t consider which model is better.

In this article, the first part of The Aware Game Engineer series, I'm gonna share my thoughts on:

• What does experience mean for a game developer?

• What does the architectural decision-making process look like?

• What key code qualities should we consider during the architectural decision-making process?

• I will share the story of one of the cases of technological debt incurred in No Rest for the Wicked.

Throughout my career, I've seen many early prototype architectures being pushed far beyond their intended scale, leading to compounding technical debt and burning production budgets.

I can't count the hours I've wasted on building useless internal tools, endless refactors, and micro-optimizing code that was already 'good enough'. At first glance, these tasks feel like 'Must-Haves', but in reality, they lead to burning budgets, delayed releases, and crunch. "The Aware Game Engineer" is a deep-dive series on how to stop wasting budget on things players don't care about. I'm gonna share the mistakes I made and explain where they came from, so you can save time and your production budget. Each article is a tool you can use to increase the production speed of your game.