Evidence at a glance
One Capability Opens Two Doors
On October 14, 2026, Simon Willison’s blog pointed readers to indie game developer Popcar’s discussion of AI-assisted game decompilation. Popcar describes a wave of efforts that can turn older games into mashups, mods, or versions for new platforms, while raising a parallel concern: the same capabilities could be used to take apart software that is still being sold and reuse its code without authorization. The subject is not a new game, but a change in how people can reconstruct existing software.
The shift matters to technical leads not because AI can now automatically restore any game, but because it changes how the work is divided. Traditional decompilation has often depended on individuals or communities spending a long time analyzing machine code. Programming agents can take on some of the repetitive function analysis and code reconstruction. Lowering that barrier cuts both ways: preservation projects become easier to start, and so do attempts to copy software without permission.
The Speedup Comes from Task Decomposition, Not One-Click Understanding
Maurice Heumann has described a decompilation project involving a shooter, though he has not disclosed the game’s name. He said the project took about three months. Agents used IDA’s ida-mcp to read program-analysis results and help reconstruct functions in C++; people organized the work, assigned tasks, and checked progress. The project divided work by translation unit through GitHub issues, and used Discord and continuous integration to report errors.
So the phrase “AI decompiles a game” can suggest a misleading picture: a model looks at a game and produces its complete source code. The actual process is closer to a human-managed parallel pipeline. The program is broken into function-level tasks, reconstructed piece by piece, then sent through compilation and checks. Heumann’s post title cites more than 500 billion tokens, while a later estimate put the total at roughly 600 billion to 700 billion. These are different estimates from a project participant, not independently audited usage figures.
Proving the Reconstruction Is Correct Matters More Than Producing It
In Heumann’s project, verification was not a final acceptance step; it was part of what allowed parallel reconstruction to proceed. The team used the compiler from the original game to generate object files, then compared reconstructed functions with the original binary byte by byte. References involving relocations were checked separately for their target symbols and offsets. Successful matches could also be recorded in CI, so later changes would not silently break already verified work.
This provides stronger evidence than simply showing that a game appears to run, but the method cannot be applied unchanged to every title. Heumann notes that compiler settings, register allocation, inlining, and calling conventions all affect the result. Even code with the same semantics may fail a byte-for-byte comparison if its instructions are ordered differently. Agents can speed up the production of candidate code, but correctness still depends on a verification method suited to the particular binary and build environment.
Preserving an Old Game Does Not Mean Releasing the Whole Game
“Decompilation,” “recompilation,” and “porting” are not interchangeable. Decompilation reconstructs source code from a compiled program. A recompilation project may translate the original game logic into new code and build it again, while a porting tool may instead try to run the original program on a new platform. Popcar discusses these approaches as part of the same preservation wave, but projects do not all follow the same technical route. The fact that they use AI does not mean they reconstruct the same components in the same way.
The project associated with The Binding of Isaac offers a useful boundary case. Its README describes translating the original game code into C++ and running it on a newly written native engine. It also requires players to provide their own Steam game files and notes that AI assisted development. Reconstructed code or a new engine does not automatically include the original assets, nor does it eliminate the need for original files. For preservation, making a game run is only one link in the chain. File dependencies and distribution choices also determine who can actually access it.
Evaluate Runability, Verifiability, and Distribution Separately
Running a game in a browser is one way to lower the barrier to access. Popcar notes that older games can sometimes run in a browser through WebAssembly, offering another route to access when original platforms are unsupported or the hardware is no longer common. The material does not say that every project uses this approach, or that browser execution solves issues involving game assets, network services, or rights. WebAssembly changes the runtime environment; it does not automatically resolve how a preservation project handles original files and other dependencies.
Technical leads should assess three questions separately: can the code be reconstructed and verified to a suitable standard, does running it depend on users supplying original files, and how will the project obtain and distribute code and assets? AI agents can make more function-level work parallel, but they do not remove compiler differences or make rights decisions for a project. Including verification and file provenance in architecture and cost assessments helps prevent “it runs” from being mistaken for “it is fully preserved and can be freely distributed.”