The full specification exceeds the context window. Factor it.
Natural language to executable game simulation (arXiv:2603.20270): a player describes a game; the system generates runnable code. The challenge: game specifications involve interdependent systems (physics, rendering, game logic, input handling) that exceed what a single LLM call can process coherently.
FactorSmith decomposes the specification into a factored POMDP — each module handles a subset of state variables with its own transition dynamics. The physics module tracks positions and velocities. The rendering module tracks visual state. The game logic tracks scores and conditions. Each module's context is limited to its relevant state variables, keeping individual LLM calls within tractable context lengths.
A three-agent architecture (planner-designer-critic) iteratively refines the code. The planner decomposes the specification into modular steps. The designer implements each step. The critic evaluates the result through structured scoring and triggers checkpoint rollback when quality drops. The iteration continues until the critic approves or resources are exhausted.
Improved prompt alignment, fewer runtime errors, and better code quality compared to non-factored approaches on the PyGame Learning Environment benchmark.
The structural insight: decomposition is a context management strategy, not just a software engineering principle. The game's systems are coupled in reality but separable in implementation — you can write the physics before the rendering because the interface between them is narrow (positions and velocities). Factoring exploits narrow interfaces to keep each LLM call focused. The decomposition mirrors the game's modularity, and the game's modularity mirrors good software architecture. Factored POMDPs formalize what software engineers already know: separate concerns, define interfaces, compose modules.