When I first started trying to build games with LLMs I did what almost everyone does at the beginning. I went straight for a one-shot prompt to make a complete game. Just like many others, I expected the model to almost read my mind. I imagined it would somehow capture all the little connections and decisions happening in my head in a fraction of a second just from a few lines of text. Of course, that is not how they work.
After some time I began to understand the mechanics of how LLMs operate on a deeper level. That naturally led to the now fading term “prompt engineering”. These days people talk more about “context engineering” but the core idea is the same. We have to teach our own brain how the LLM works so we can structure the context in a way that lets it deliver maximum value.
With my current work on GameByte, where AI builds studio-quality mobile games from prompts, this understanding has become crucial. When you explain the problem in a way that matches how the model processes information, even something as short as “3D platformer game” in the system prompt can be enough. The model will then ask the right follow-up questions and move you toward your goal without constant manual steering.
Another lesson is that all the old pain points developers faced before AI are still pain points for LLMs. Spaghetti code, excessively long files, poor documentation, lack of comments and missing test cases all reduce their effectiveness. This is why Amazon’s recent “Kiro” and the spec-driven development approach resonate so well. They are basically formalizing best practices that those of us building with LLMs have learned over time.
And finally, LLMs do not particularly enjoy editing someone else’s messy code. Just like human developers, they perform much better when writing from scratch. If you clearly define the boundaries of the task and ask them to start fresh, the results are often significantly better.
After some time I began to understand the mechanics of how LLMs operate on a deeper level. That naturally led to the now fading term “prompt engineering”. These days people talk more about “context engineering” but the core idea is the same. We have to teach our own brain how the LLM works so we can structure the context in a way that lets it deliver maximum value.
With my current work on GameByte, where AI builds studio-quality mobile games from prompts, this understanding has become crucial. When you explain the problem in a way that matches how the model processes information, even something as short as “3D platformer game” in the system prompt can be enough. The model will then ask the right follow-up questions and move you toward your goal without constant manual steering.
Another lesson is that all the old pain points developers faced before AI are still pain points for LLMs. Spaghetti code, excessively long files, poor documentation, lack of comments and missing test cases all reduce their effectiveness. This is why Amazon’s recent “Kiro” and the spec-driven development approach resonate so well. They are basically formalizing best practices that those of us building with LLMs have learned over time.
And finally, LLMs do not particularly enjoy editing someone else’s messy code. Just like human developers, they perform much better when writing from scratch. If you clearly define the boundaries of the task and ask them to start fresh, the results are often significantly better.