How to engineer an AI harness for game development

This piece argues that large language models work well for web stacks because those projects expose nearly everything as code, but they routinely fail on traditional games because games contain large amounts of opaque, non-code content (assets, data, state, and bespoke systems) that LLMs can’t easily reason about. It explains how model sessions are composed of system, assistant, and user prompts and how repeated re-submission of prior messages builds a context that can become polluted; managing that context is central to getting useful results. Practical observations include that Three.js projects succeed with LLMs because “everything is code,” while conventional game projects lack standardized tooling and training data, making generated game code brittle or irrelevant.

The proposed remedy is to engineer a harness: a set of patterns, interfaces, and tooling that make a game legible to agents. A harness extracts and normalizes game state, assets, telemetry, profiling, and SDLC artifacts into forms an LLM can consume and act on, reduces context pollution by supplying targeted context, and provides repeatable agent workflows for iteration. Building such harnesses - customizing Claude Code-style workflows, exposing internal representations, and scripting clear agent actions - enables faster, more reliable agentic game development.