AI-assisted decomps and recomps: what changes, and how to judge a project
XDA's coverage of the native Halo: Combat Evolved port this month included a line many readers were thinking: like most recent retro ports, it was "almost certainly developed with significant AI help". Some projects say so themselves. Others don't. Either way, the number of new ports has jumped this year, and AI coding tools are part of the reason.
The projects that say it out loud
Two examples from our list are open about it. psxrecomp, the PlayStation static recompiler behind ports like Tomba! and Ape Escape, started as an experiment written up by its author, Matthew Stanley, under the title "I Built a PS1 Static Recompiler With No Prior Experience (and Claude Code)". He describes his day job as backend APIs and data warehousing, not compilers.
The Wave Race 64 recomp goes further. Its README says the original project was written by Claude, working in Claude Code under a human director who set goals and played the builds, and that a later fork added macOS support with OpenAI's Codex.
What AI changes
Mostly speed, and who can take part. Reverse engineering a game used to need years of a small group's spare time. Ship of Harkinian and the Super Mario 64 port were built on decompilations done largely by hand. A motivated hobbyist with an AI assistant can now get a game booting in weeks. It's one reason a single batch of our additions this month included nine new Xbox 360 and thirteen new PS1 projects.
What it doesn't change
Some kinds of project can be checked objectively, whoever wrote them.
- Matching decompilations rebuild the original program exactly: compile the reconstructed source and the result must be byte-for-byte identical to the original game. If it matches, it's correct, whether a person or a model wrote the C.
- Static recompilations were always machine output. Tools like N64Recomp and XenonRecomp translate the game's machine code into C or C++ automatically. The human work is everything around it: graphics, audio, input, and the places where the translator gets confused.
Non-matching ports, the ones that rewrite or patch code until the game seems to work, have no such test. That's where the worries are real: code nobody fully understands, fixes that hide a problem instead of solving it, and projects that stall once the original author moves on. None of that is unique to AI-written code, but it gets more common when code is cheap to produce.
Six checks for any project
- Does it say what works? "Fully playable" should come with detail: which levels or modes were played through, and what's known to be broken. Good projects keep a list.
- Is there a release? A build you can download beats a video of one.
- Does the issue tracker get answers? Open bug reports with replies from the developer are a better sign than a high star count.
- Is the source public, and does it build? If only the binary is public, you're trusting whoever compiled it.
- Does it credit what it's built on? OpenCE, for example, names the decompilations it started from. A project that hides its foundations deserves caution.
- Does it ask for your own copy? A port that bundles the game's data is a legal risk to its users and likely to disappear. More on that in our browser ports piece.
How FanGamesDB handles it
We don't exclude projects for using AI, and we don't mark them down for it. Each entry's status reflects what the project delivers: fully playable, playable or in development. If a project describes itself as AI-written, the notes say so, as they do for Wave Race 64. Every entry links to the project's own page, so you can run the six checks yourself.
Sources: XDA, 1379.tech, Wave Race 64 recomp README.