The Recomp Scene Split Three Ways Over AI. Here Is How to Tell Which Port to Trust.

2026-09-18 · Explainer

Affiliate disclosure: This guide contains affiliate links. As an Amazon Associate, we earn from qualifying purchases at no extra cost to you. Learn more.

If you have been reading about decompiled and recompiled console ports this year, you have probably noticed something odd creeping into the headlines. Projects are advertising what they did not use.

"Zero AI code" is now a selling point. That is a strange thing for a hobby port to brag about, and it tells you something real about the state of this scene.

The recompilation community has split three ways over AI tooling. Understanding that split is genuinely useful, because it is currently the fastest way to judge whether a port is worth installing before you spend an evening on setup.

Why This Blew Up Around Donkey Kong 64

The argument had been simmering. Donkey Kong 64 brought it into the open.

In late June 2026, the team behind the DK64 Randomizer announced their own recompilation project earlier than they otherwise would have. Their reason was unusually direct. A competing DK64 recompilation was already underway, and it was being generated largely with AI tools.

Developer theballaam96 put it on Reddit: "We have a competitor who is vibe coding their way through, and doing a very poor job of it."

The team's own statement went further, saying they took on development because of the poor development direction of another concurrent DK64 recompilation that was heavily leaning on AI vibe code. Their pitch was that they had spent over a decade inside DK64's code and did not rely on vibe coding to make changes.

Their port, DK64 Rekongpiled, shipped on 29 August 2026. We covered what it actually delivers, including the ARM64 build almost nobody mentioned.

The Three Positions

Once you know to look, every project in this scene has picked one of three stances.

Position	What it looks like	Example
Refuse	Advertises that no AI tooling was used at all	DK64 Rekongpiled
Disclose	Says AI was used, explains what verifies the output	Mario Kart Wiicompiled
Hide	Uses AI without saying so, gets delisted when spotted	Unnamed, by design

Refuse

This is the DK64 position, and it is becoming the prestige stance. The argument is that recompilation and decompilation demand exactness. Output has to match original hardware behaviour, and a tool that produces plausible looking code is actively dangerous when plausible is not the bar.

The projects taking this line tend to be the ones with deep prior expertise in the specific game. They already know the codebase, so AI assistance offers them less and risks more.

Disclose

Mario Kart Wiicompiled took the opposite route and was upfront about it. Its README states that AI coding tools were used during development, and immediately pairs that with the control: all translated output is verified against real hardware behaviour.

That pairing is the whole argument. The claim is not that AI wrote correct code. It is that correctness is established by testing against the original console, so the tool that produced the code matters less than the verification that follows it. We covered the project itself here.

Whether you find that convincing probably depends on how much you trust the verification. But it is an honest position, and it lets you make your own call.

Hide

The third group is the reason the other two are shouting.

Community trackers have started policing this directly. The most widely used decompilation and recompilation list now has a formal policy: projects believed to be vibe coded get no card and no link, and are dropped to a plain reference list at the bottom of the page. That is delisting in everything but name.

It is a meaningful sanction in a scene where discovery runs almost entirely through a handful of community lists.

This Is Not a New Fight for Emulation

The recomp scene is arriving late to an argument that emulator developers already had.

We wrote earlier this year about emulator projects banning AI generated code outright. mGBA, SDL and QEMU all landed on restrictive policies, for reasons that were mostly practical rather than ideological. Their maintainers were spending review time on contributions that looked correct and were not, submitted by people who could not explain their own patches.

And the counterweight arrived in the same month, from the other direction. The Super Smash Bros. Melee decompilation hit 100% with AI assistance closing the final stretch, after six years of human work. That is the strongest available argument that these tools can do real work in this specific domain.

So the honest summary is that both things are true. AI tooling finished a six year decompilation, and AI tooling is producing ports the community is actively rejecting. The difference is not the tool.

What Actually Separates Them

The difference is verification, and this is the part worth internalising.

Decompilation has a built in correctness test. You compile your reconstructed source and check whether it produces a byte for byte match with the original binary. It either matches or it does not. There is no room for code that looks right.

That is why the Melee project could use AI on its final stretch without much controversy. Every suggestion was checked against an objective standard, automatically, and wrong answers were rejected by the process itself.

Recompilation output has no equivalent single test. A static recompiler produces working code by construction, but everything built on top of it, the graphics layer, the input handling, the platform glue, is ordinary software with ordinary bugs. There is no oracle telling you it is correct.

So the useful question about any project is not "did they use AI." It is "what checks their output, and is that check automatic." A project that can answer that has a defensible process regardless of tooling. A project that cannot is asking you to trust vibes, and that is true whether a human or a model wrote the code.

How to Judge a Port Before You Install It

Practical checklist, in rough order of usefulness.

Look for a stated AI policy either way. A project that addresses it directly, in either direction, has thought about it. Silence is not proof of anything, but the projects doing careful work have generally noticed this is a question.

Check who the developers are. The strongest recomp projects come from people with a long history in that specific game. DK64 Rekongpiled came from the Randomizer team. That history is public and easy to verify.

Look at the commit and release pattern. A steady stream of small fixes over months looks like maintenance. A large drop of code followed by silence looks like something else.

Read the issue tracker, not the trailer. Whether the developers can explain their own bugs is the single most telling signal available to you, and it costs five minutes.

Check whether it is in a curated list. If a project is missing from the community trackers while similar projects are on them, that absence is usually deliberate.

Does Any of This Affect You?

For most people, mildly. A badly built port is a bad evening, not a disaster. You uninstall it.

It matters more if you are on a handheld, for one specific reason. Poorly built ports tend to be inefficient ports, and inefficiency is invisible on a desktop with headroom to spare. On battery powered ARM hardware with a mobile GPU, the same sloppiness turns into stutter, heat and a dead battery.

The projects doing careful work are also usually the ones bothering to ship ARM builds at all, which is why the ten decomp ports properly packaged for cheap handhelds skew heavily toward the established, long running projects.

If you want to explore this scene on a handheld, the safest hardware advice is the boring kind. A

runs almost everything in it, and gives you enough headroom that an inefficient port is merely inefficient rather than unplayable. On the ARM side, a covers the PortMaster catalogue comfortably.

Questions People Ask

Is AI generated code actually worse for these projects?

It depends entirely on what verifies the output. Decompilation has an automatic byte for byte matching test, which catches wrong answers regardless of who wrote them. The layers built on top of a recompilation have no such test, and that is where quality problems concentrate.

Which projects have banned AI code?

Among emulators, mGBA, SDL and QEMU have restrictive policies. In the recomp scene it is less formal, with individual projects like DK64 Rekongpiled stating a no AI position rather than any scene-wide rule existing.

Did AI really finish the Melee decompilation?

It closed the final stretch of a six year project, with every suggestion checked against the byte for byte matching standard. It did not do the bulk of the work, and the matching requirement meant incorrect output could not slip through.

Should I avoid ports that disclose using AI?

Not automatically. Disclosure plus a described verification process is more trustworthy than silence. Mario Kart Wiicompiled discloses AI use and states that output is verified against real hardware, which is a more informative position than most projects offer.

How do I find out if a port used AI?

Read the project's README and its issue tracker. Check whether it appears in the main community decompilation trackers, since the largest one now formally delists projects it believes were vibe coded.

Is this argument going to be resolved?

Not soon. The scene currently contains both the strongest argument for these tools, a finished Melee decompilation, and the strongest argument against, ports the community is rejecting on quality grounds. Both keep being true at once.

Related Reading

• AI Finished the Melee Decomp. The Emulators on Your Handheld Ban It.
• Melee Is 100% Decompiled, and AI Finished the Last Stretch
• Donkey Kong 64's Recomp Ships an ARM64 Build
• Mario Kart Wiicompiled: The First Wii Recomp
• Decomp vs Recomp: How Old Games Become PC Ports
• Every Decomp Port You Can Play on a Cheap ARM Handheld
• Recompiled Games List: Every Native PC Port by System

Quotes are as reported by Kotaku and verified against the projects' own public statements where those were readable, retrieved 18 September 2026. The competing DK64 project was not named in that coverage, and we are not naming or linking it. Some coverage of this story sits behind paywalls we could not read, so nothing from those outlets is quoted here.