Kyle Kukshtel argues that coding agents struggle with games partly because source code leaves so much invisible: assets, live state, and the effects of a change. His proposed remedy is a harness — the tools and feedback loop that let an agent operate the game and check its work, rather than just edit files.
The practical ingredients:
- Reproduce the same situation with controlled randomness and save/load support built early, not bolted on at the end.
- Record actions as replayable commands, so an agent can return to a bug without manually playing through to it.
- Compare cropped screenshots and image differences, rather than asking the model to interpret a whole busy screen after every edit.
- Keep adjustable game data outside compiled code, and separate the simulation from the graphics engine so tests can run without launching everything.
- Export performance measurements in a form the agent can read and use to check whether a change helped.
The useful shift is from asking for better code to building a better way to verify changes. But this is a proposed workflow, not proof that every project needs the architecture: Kukshtel’s postscript says he is shipping a small project using none of it, and sees the larger investment as more relevant to bigger games.
The 79-comment thread on Hacker News adds an alternative division of labor, reports from people trying similar loops, and objections to making everything reproducible.
What the thread adds
- drusepth — proposes keeping fine adjustments in human hands: “you shouldn’t be asking an LLM to make these tweaks for you; you should be asking an LLM to build the tools that let you make these tweaks by hand faster or more effectively.”
- vanyle — reports a testing-first route into agent tooling: “I wrote an automated testing system for my game engine to take screenshots and simulate input for automated testing and then I realized how good claude was at using it to make games”.
- TeMPOraL — describes a benefit beyond test speed from running without an interactive game window: “It did, and that gave it ability to run multiple instances in parallel, which it now uses autonomously whenever it needs to confirm assumptions or validate changes.” This is their account, not a result demonstrated by the essay.
- bob1029 — challenges the cost of reproducibility: “Ensuring you maintain determinism across many platforms is where things get super nasty.”
- pton_xd — pushes back on another commenter’s claim that game coding is solved: “Currently you still need to give them guidance on what type of architecture would best work for your game, or after many iterations on gameplay you’ll end up with terrible performance and a complete mess of a codebase.”
Handles are pseudonymous, and HN exposes no per-comment scores. Ordering is HN’s own ranking; these excerpts are a slice of the discussion, not a consensus.