The prevailing narrative in game development circles goes something like this: LLMs are bad at games. They produce slop. They can't handle the non-code complexity of real game projects. A Calgary-based indie developer with 15 years of game programming experience is arguing this diagnosis is wrong — or at least badly incomplete. The real problem is legibility. The argument rests on a structural observation about how LLMs actually work. Every interaction with a model builds cumulative context — prior messages re-submitted with each new prompt, like a playground game where you recite everyone else's contribution before adding your own. Web applications are almost entirely code, which means an LLM can reason about every component. Games are not. They contain assets, state machines, physics systems, and behavioral layers that are effectively opaque to a text-based model. The LLM isn't stupid; it's blind. This reframing shifts the problem from "AI capability" to "context engineering" — the emerging discipline of curating what goes into a model's context window to minimize pollution and maximize signal. The author's experience building mood.site (a moodboarding tool built almost entirely via copy-pasting code into ChatGPT's web interface, roughly 20 hours over 2-3 weeks) convinced him that LLMs are genuinely productive for web stacks. The gap with games isn't about model quality but about the information architecture of what the model can see. The proposed solution is the "harness" — a structured intermediary that translates game state, assets, and systems into representations an LLM can reason about. This isn't a new concept; tools like Claude Code already function as harnesses for general software development. But the argument is that games need bespoke harnesses because every game manifests its own needs differently. There is effectively zero standardized tooling across game development, making each project a custom integration challenge. The author draws a sharp distinction between the Three.js one-shot demos proliferating on social media (where everything is code, making LLM integration trivial but producing work that "lacks any real authorial voice outside of whatever the LLM median is") and serious production use. The former is easy but artistically hollow. The latter requires solving the legibility problem first. The harness pattern sits in between: maintain creative authorship while making the project machine-readable enough to leverage LLM productivity. What's genuinely useful here is the diagnostic framework. Rather than the binary "AI good/bad for games" debate, this identifies the specific bottleneck: games are black boxes to models. Every asset, every non-code system, every behavioral layer that can't be serialized as text is a wall the LLM hits. The harness pattern is essentially a translation layer — not replacing the developer but making the developer's work legible to an automated collaborator. The piece is limited by being a talk-to-blog conversion that cuts off before fully demonstrating the harness pattern in practice. The conceptual framework is sound but the proof remains promissory. The real test will be whether harness-built games can exhibit the authorial specificity that distinguishes craft from slop — whether making games legible to LLMs helps developers ship distinctive work faster, or merely accelerates the production of more competent mediocrity.
