Snowboard Kids N64 decompilation finished in 84 days with AI agents

The author of a decompilation blog has announced that Snowboard Kids, a Nintendo 64 snowboarding game, is now 100% decompiled. Every function in the game has a matching C implementation that compiles to machine code identical to the original. One footnote qualifies that figure: a small amount of handwritten assembly from system libraries remains, because assembly, not C, was the original source form for those specific pieces. The author credits three contributors by name, inspectredc, Bl00D4NGEL and queueRAM, for significant help, writing that 'no amount of AI would have been able to replace them,' and separately thanks three more people, iFuzzle, JamesBLewis and douglasjv, for lending their AI usage credits, described as 'tokens,' to the project.

The stated goal is to help the Snowboard Kids community, especially speedrunners, who have long focused on this first game. Working source code can explain phenomena speedrunners had only observed from outside the game, such as CPU pathing and the exact factors behind player speed. It is also expected to support static recompilation and more ambitious modding.

The headline number is speed. Snowboard Kids took 84 days to decompile, against 596 days for Snowboard Kids 2, the author's earlier project: about one-seventh of the time. The author is explicit that crediting AI entirely for that gap 'would be a gross oversimplification.' By the time this project started, the author already had roughly two years of decompilation experience from the sequel project, an advantage that is hard to quantify and was partly offset by new challenges, including a different compiler. About 4.8% of matching commits on Snowboard Kids still involved direct expert, meaning human, intervention, credited again mainly to inspectredc, Bl00D4NGEL and queueRAM.

Most of the difficulty was not figuring out what a function did, but reproducing exactly how its logic compiled. Snowboard Kids was built with IDO 5.3, a proprietary compiler from SGI, instead of the open-source GCC 2.7.2 used for Snowboard Kids 2. IDO's source was never released, and its original toolchain depended on obsolete SGI hardware, so the decompilation community has had to reverse-engineer parts of the compiler itself and statically recompile the IDO 5.3 and 7.1 suites to run on modern machines. IDO splits optimization and code generation across several passes and transforms code aggressively: a tiny change to the C can produce a completely different register allocation. The author states plainly that 'LLMs and I are not particularly good at reproducing its output.' The usual approach, for the author and for AI agents alike, was to write C that approximated a function's purpose and then use a tool called the permuter to make small tweaks toward an exact match, which does not always work if the underlying structure is wrong.

For scale, Snowboard Kids has 2,145 functions against 2,995 for its sequel. The author also points to a separate, unrelated project, the Pilotwings 64 decompilation, finished in 74 days, faster in absolute terms, though Pilotwings 64 had 16% fewer functions but more compiled code overall, which the author calls 'not a clean comparison.' The broader claim drawn from this: a motivated human team with the right expertise and intuition can match or even exceed the pace achieved here with AI agents.

Agents helped most with matching standard-library code. Snowboard Kids contains more than a hundred source segments from Nintendo's own libultra SDK library, plus code from the libmus audio library, and tools such as N64Sym can flag probable library functions inside the ROM. Getting agents to actually reuse that known source, rather than re-decompiling the same functions from scratch, took deliberate prompting: agents were instructed to treat a likely library match as a starting point and exhaust plausible SDK versions, compiler options and conditional-compilation paths before writing their own version. A separate automated step ran the m2c decompiler against every unmatched function and auto-integrated exact hits. It matched only 17 of 1,830 functions, a 0.93% success rate, but was cheap enough to be worth running anyway.

The author also had agents record newly discovered IDO compiler quirks in a shared file, DECOMPILATION_LEARNINGS.md, so a pattern found while matching one function could help with others later, on top of Codex's own 'local memories' feature for carrying lessons between tasks. The single most useful tool, per the author, was N64 Decomp Workbench, which can classify late-stage mismatches, account for relocations, replay individual compiler passes, and help tell a structural problem from a register-allocation one.

The author ran the agent harness across four parallel Git worktrees, each an independent copy of the repository, splitting candidate functions between them with what the text calls Nigel's --shard option, a basic hashing partition. Giving every agent task an explicit deadline, instead of letting the permuter run until it found a match or was stopped by hand, let agents budget their own time and judge when to give up on a hard function; the author could then raise the time allowance as easy functions ran out. Keeping the four worktrees in sync was a separate problem. A function matched in one worktree could be a near-perfect reference for a function being attempted in another, but that reference stayed invisible until the branches were merged, and merging and resyncing all four could take more than an hour. The fix was to make the similarity search check every worktree directly, so a newly matched function became available as a reference immediately, without waiting for a merge.

On model choice, the author tried five: GPT-5.5, GPT-5.6, Claude 4.5, Fable and GLM 5.2, tested against a changing set of hard functions, and calls the comparison 'completely unscientific.' The broader pattern, in the author's telling, was that Codex kept outperforming Claude, continuing a trend from the end of the earlier Snowboard Kids 2 project, and that a configuration the author calls 'Sol xhigh' was particularly effective once it became available. GLM 5.2, served by z.ai, was 'very disappointing.' The author had previously liked GLM for being effective enough with generous usage limits, but as those limits shrank while latency stayed slow, the author stopped assigning it work and cancelled the subscription.

The author stresses that a 100% functional match is not the end of the work. It means C code exists for every function, not that the team understands what each one does. Remaining tasks include replacing auto-generated names, identifying unknown structure fields, cleaning up awkward matches and describing large amounts of game data. Next steps mentioned include a Snowboard Kids recompilation project, helped by the fact the first game shares many quirks already addressed by patches from the separate Snowboard Kids 2: Recompiled project; an open-ended look at porting the first game's levels and content into the second game's engine; and interest in eventually decompiling Snowboard Kids Plus, a Japan-exclusive PlayStation release of the first game with extra levels and characters. The author closes by pointing readers to the Snowboard Kids decompilation project itself and inviting contributions to the remaining cleanup and documentation work.

Key facts

Snowboard Kids, a Nintendo 64 game, reached 100% decompilation (every function matches the original machine code) in 84 days, versus 596 days for the same author's earlier Snowboard Kids 2 project, about one-seventh the time; about 4.8% of matching commits still needed direct human expert intervention.
Snowboard Kids was built with the proprietary SGI compiler IDO 5.3 rather than the open-source GCC 2.7.2 used for its sequel, and IDO's aggressive, multi-pass optimization made its output hard for both the author and AI agents to reproduce reliably.
AI agents worked best reusing known Nintendo SDK library code (Snowboard Kids contains over a hundred segments from the libultra library), while a fully automated matching script using the m2c decompiler matched only 17 of 1,830 unmatched functions, a 0.93% success rate.
In an admittedly unscientific comparison of five models, GPT-5.5, GPT-5.6, Claude 4.5, Fable and GLM 5.2, the author found Codex continued to outperform Claude, favored a configuration called 'Sol xhigh,' and dropped GLM 5.2 after its usage limits shrank while latency stayed slow.
The project ran across four parallel Git worktrees with a shared DECOMPILATION_LEARNINGS.md file logging IDO compiler quirks for later agent runs, though fully synchronizing all four worktrees could take more than an hour.

Why it matters

The author treats the headline figure, 84 days to decompile Snowboard Kids against 596 days for the author's earlier Snowboard Kids 2 project, as only partial evidence of what AI contributed, warning explicitly that crediting language models alone 'would be a gross oversimplification' since two extra years of personal decompilation experience and a harder, different compiler both factor into the gap. The piece is specific about where agents were reliable, reusing known Nintendo SDK library code and tracking recurring compiler quirks across runs, and where they were not: about 4.8% of matching commits still needed direct intervention from named human experts, and the compiler itself remained something 'LLMs and I are not particularly good at reproducing.'

Who it affects

The direct beneficiaries are the Snowboard Kids decompilation and speedrunning community: working source code helps explain phenomena speedrunners had only observed from outside the game, such as CPU pathing and the exact factors behind player speed, and it opens the door to static recompilation and deeper modding. More broadly, the writeup is aimed at people running or considering agent-assisted reverse-engineering and decompilation projects, since it documents concrete harness choices, parallel Git worktrees, per-task deadlines, a shared compiler-quirks file, that could apply to other proprietary-compiler decompilation efforts too.

How to use it

There is no product or price here. The practical takeaways are workflow patterns: pointing agents at known SDK source (Nintendo's libultra and libmus libraries) before letting them reinvent matching code from scratch, running an automated script that tries the m2c decompiler against every unmatched function to catch cheap wins, keeping a shared markdown file where agents log compiler quirks they discover so later runs benefit, giving each agent task an explicit deadline instead of letting a matching tool run indefinitely, and syncing partial results across parallel worktrees so a match in one branch becomes an immediate reference for agents working in another. The Snowboard Kids decompilation project itself is open, and the author says cleanup and documentation contributions are welcome.

How solid is it

This is a first-person blog post by the project's own author, not an independent evaluation. The author flags the model comparison, GPT-5.5, GPT-5.6, Claude 4.5, Fable and GLM 5.2 tested against a changing set of difficult functions, as 'completely unscientific,' and separately calls the 74-day Pilotwings 64 decompilation cited for comparison 'not a clean comparison either,' since that game had 16% fewer functions but more compiled code overall. The core numbers, 84 versus 596 days, 2,145 versus 2,995 functions, about 4.8% of commits needing expert intervention, 17 of 1,830 functions auto-matched, are the author's own project statistics rather than externally audited figures, though they are precise rather than rounded estimates.

Risks and caveats

The author is explicit that attributing the full speedup to AI would be a 'gross oversimplification,' since prior experience and a different, harder compiler both complicate the comparison. Even after the 100% functional match, neither the author nor the AI agents fully understand what every function does: identifiers are still auto-generated placeholder names that need to be replaced, some structure fields are unidentified, and large amounts of data remain undescribed. IDO, the compiler Snowboard Kids was built with, is described as something the community understands as 'more of an art than a science,' and the author says plainly that 'LLMs and I are not particularly good at reproducing its output,' so small C changes can still require manual tuning through the permuter tool rather than a clean agent-only fix. The GLM 5.2 experience is also a caution that a model's cost-effectiveness can flip: the author had previously been 'a big fan of GLM,' but its usage limits tightened while its latency stayed slow, to the point of cancelling the subscription.

“Well, it's 2026, so the answer is at least partially AI. But it would be a gross oversimplification to attribute the difference entirely to LLMs.”

— the author of the Snowboard Kids decompilation writeup