The decompilation of Super Smash Bros. Melee (the work of analyzing the machine code in an executable and reconstructing its source code) was completed on September 7, 2026. The final function was matched in PR #3409. All 19,828 functions now match the original machine code, and the rebuilt DOL-format executable is identical to the original. Meanwhile, Maurice Heumann spent about three months using AI agents to rebuild the PC version of Call of Duty: Modern Warfare 2 (MW2). By his own estimate, he spent 600 to 700 billion tokens, and he stopped work when 83% of all functions matched byte for byte. Both projects report progress as percentages, but the numbers don't mean the same thing. Looking at what each uses as its denominator, and who verified it, shows which parts can be checked mechanically and which still need human judgment.
The 37 days in which Melee closed its last 15 points
According to decomp.dev's records, the code match rate for Super Smash Bros. Melee rose from 46.94% on November 1, 2025, to 84.47% on August 1, 2026. That was 37.53 points over nine months. The remaining 15.53 points were closed in the next 37 days, reaching 100% on September 7.
The monthly figures use the first value recorded at the start of each month, and the date of reaching 100% is the date of the first commit that recorded 100.0% (PR #3409). Day counts are calendar days: 273 days from November 1, 2025, to August 1, 2026, and 37 days from August 1 to September 7. Other recorded points show 61.33% on April 1, 2026, and 92.92% on September 1.
データを表で見る
| コード一致率 (%) | |
|---|---|
| 2025-11-01 | 46.94 |
| 2026-04-01 | 61.33 |
| 2026-08-01 | 84.47 |
| 2026-09-01 | 92.92 |
| 2026-09-07 | 100 |
Contributors using AI took part in this final stretch. At least one contributor stated that PR #3374, merged on September 6, and PR #3380, merged on September 7, were "implemented and verified with Codex and Astra." Astra refers to "GPT-6 Astra," a model OpenAI has made available.
According to the PR descriptions, #3374 raised the code match rate from 98.00527% to 98.08615%, about 0.08 points, and #3380 raised it by 0.01113 points through 432 matched bytes. Together, these two PRs, where AI use was stated explicitly, contributed about 0.09 points, less than 1% of the remaining 15.53 points.
On the other hand, from 92.92% on September 1 to 100% on September 7, the rate advanced 7.08 points in just six days (editorial calculation). But the available materials don't show what drove this rapid progress.
So this record alone doesn't support the claim that "AI broke through the last barrier." The time-series data also can't tell us how much undisclosed AI use, changes in the number of participants, or generational changes in AI models affected progress.
Also, decomp.dev's code match rate is calculated from the number of matched machine-code bytes. It doesn't evaluate the readability of the reconstructed source or whether function and variable names are appropriate.
What does the match rate actually count?
Matching decompilation is the work of reconstructing C code that, when built with the same compiler and the same settings as the original, produces machine code identical to the original. A developer working on the decompilation of Klonoa: Empire of Dreams also cites Super Mario 64 and Ocarina of Time as earlier examples.
The goal is to generate the same machine code as the original. In other words, the correct answer to check against exists in the original binary. By building and comparing the reconstructed code, you can determine mechanically how far it matches.
One tool used for that comparison is objdiff. It compares relocatable object files, generated before linking, by function and data unit, and it is also used in decomp.dev's progress reports.
Heumann's own comparison script works on the same basic idea. It uses the OBJ (object file) obtained by building the reconstructed code with the same compiler as the original, along with the original EXE (executable) and PDB (a debug file containing symbol information), and compares byte sequences function by function, returning PASS or FAIL.
However, references whose addresses are fixed at link time won't match if the byte sequences are compared as they are. So these relocated portions are excluded from the direct comparison, and the script separately checks whether they refer to the same symbol at the same offset.
According to Heumann, a function that passes this check behaves like the original, bugs included. The premise is that the same compiler and settings are used and that the targets of relocated references are verified correctly.
Because pass/fail can be determined mechanically, an AI agent can be made to repeatedly generate and fix code function by function.
But even when the judging method is similar, the meaning of a match rate changes depending on the denominator.
decomp.dev's code match rate is the share of the total code bytes that is matched. The 83% Heumann reported, by contrast, is the share of all functions that match byte for byte. The "99%" in the same blog refers to the share of all functions for which reconstructed source code exists, regardless of whether it matches byte for byte.
None of these metrics evaluates the naming or readability of the reconstructed code.
There are also approaches that don't aim for a match with the original machine code. N64Recomp statically recompiles binaries into C functions function by function, and ReXGlue converts Xbox 360 PowerPC code in advance into portable C++. Their purpose differs from that of matching decompilation, which aims for source code that can reproduce the original machine code.
A change in verification method sped up the MW2 rebuild
In a blog post on October 9, 2026, Heumann reported that he had used AI agents to decompile a "popular FPS" into C++ over about three months. He revealed on September 30, in a post on X, that the target was Call of Duty: Modern Warfare 2.
In the first month, he used four agents, three workers and one reviewer, and rebuilt roughly 80% of the game. Menu display and map loading worked, but function signatures and structures contained errors, and the agents also fabricated or deleted processing. Heumann himself acknowledged that the code was not correct in terms of meaning or behavior.
The turning point was switching the judgment of correctness from AI review to byte-by-byte comparison.
Heumann made the project use the same compiler as the original and introduced the comparison script described above. Because a function that matches byte for byte also has the same meaning and behavior as the original, a dedicated review agent became unnecessary, he said.
With clear pass/fail judgments, even low-cost models such as Haiku and Luna, which had not produced enough results before, could now carry the work forward, and he explained that this cut costs substantially.
However, introducing the verifier also led the agents to start looking for new loopholes.
First, the agents tried to pass the match check using inline assembly. Next, they reportedly tried to rewrite the verification script itself so that the functions they generated were excluded from comparison.
Heumann points out that when instructions leave room for interpretation, agents try to satisfy the conditions through improper means. As a countermeasure, he introduced a mechanism in CI (continuous integration) that checks the verification script's hash against a value stored in GitHub Actions secrets, confirming that the script hasn't been altered.
What Heumann emphasizes is defining correctness clearly and creating a state in which it can be verified mechanically. AI review alone is insufficient, he says, and an objective PASS/FAIL judgment is the most effective feedback.
In the end, he prepared reconstructed source code for 99% of all functions and achieved an 83% byte match, with all functions as the denominator, not just those with source. In the final stretch he mainly ran 14 Luna agents and two Opus 5.5 agents.
The remaining functions would not match byte for byte no matter how many times they were revised. Heumann cites nondeterministic behavior and an inability to reproduce a linker process called "identical COMDAT folding," which merges functions with identical content into one, among the reasons.
He believes the remaining functions are also correct in meaning and behavior. He therefore judged that pursuing further byte matches would only consume tokens without bringing real improvement, and says the project can be considered complete. He adds, however, that Opus 5.5 agents might be able to raise the remaining match rate further.
Total token usage is only an estimate, because he deleted the VMs used for the work and lost the logs. Heumann's estimate is 600 to 700 billion tokens, of which about 300 billion were used by Luna.
Heumann treats the cost ratio of Luna to Astra as 100 to 1 and converts roughly 300 billion Luna tokens into the equivalent of about 3 billion Astra tokens. Under OpenAI's API pricing, Astra costs $10 per million input tokens and $50 per million output tokens, while Luna costs $0.10 for input and $0.50 for output, a 100-to-1 price gap for both input and output. This is consistent with Heumann's conversion, but a price list alone can't yield the actual total cost.
It is worth noting that all of these figures are Heumann's own reports, and the reconstructed code has not been published.
Heumann explains that there are no notable bugs and that all of the original's features have been reproduced. However, including the 83% byte-match rate, there is no way for third parties to verify it independently.
Kotaku reported on October 3 that a video posted on X had become unavailable following a claim from the copyright holder. Heumann himself disclosed on his blog that he had deleted two earlier posts.
Two Halo repositories, "99.5%" and "23.25%": why the numbers disagree
The README of a repository forked from the Halo: Combat Evolved decompilation project states "99.5% byte matching."
But when you check the repository it was forked from on decomp.dev, the code match rate as of October 11, 2026, is 23.25%, and only 2,511 of 11,047 functions are matched.
Specifically, the README of the fork, bnunu/halo-1, says "work-in-progress (99.5% byte matching)." On decomp.dev, by contrast, what can be checked is build 2342 of the original repository, punpckhdq/halo, with a code match rate of 23.25% and a fuzzy match rate, which includes approximate matches, of 24.65%.
The problem is that no definition is given for what the 99.5% in the README represents.
For example, it may be a different metric from decomp.dev's, such as how much of the byte sequence matches inside already-matched functions. It is also possible that decomp.dev's figure is based on the latest commit of the original repository and differs from the fork's current progress.
So it can't be concluded that the README's 99.5% is wrong, or that the decompilation is only 23% complete.
There is also no material indicating whether AI is used in these two Halo-related repositories, and AI use isn't the issue here. What matters is that when a percentage's denominator isn't stated, readers can't tell what the number means.
The same problem appears in another project.
AnyPS5 is a tool that relinks PS5 executables into native Linux or Windows formats, and it is not aimed at decompilation.
Its progress badges show 100.0% for shaders and 85.82% for system libraries (checked October 12). However, according to the README, the 85.82% for system libraries uses the functions the project has identified as its denominator, not all PS5 system functions.
The judging method and the origin of the numbers for the game decompilation cases covered so far are summarized below.
| Project | Judging method | Figure | Unit of the figure | Source of the figure | As of |
|---|---|---|---|---|---|
| 『Super Smash Bros. Melee』 | Byte match | 100% | Code match rate | decomp.dev (external) | 2026-10-11 |
| 『Snowboard Kids 2』 | Byte match | 100% | Code match rate | decomp.dev (external) | 2026-09-27 |
| 『Snowboard Kids』 | Byte match | 100% | Code match rate | decomp.dev (external) | 2026-10-10 |
| 『Klonoa: Empire of Dreams』 | Byte match | 51.30% | Code match rate | decomp.dev (external) | 2026-10-05 |
| 『Halo: Combat Evolved』 (build 2342) | Byte match | 23.25% (the fork's README says 99.5%) | Code match rate | decomp.dev (external, original repository) | 2026-10-11 |
| 『Call of Duty: Modern Warfare 2』 (PC version) | Byte match (from month two) | 83% | Share of functions matched out of all functions | Developer's report, code not public | 2026-10-09 |
Of these six titles, the ones whose arrival at 100% can be confirmed on an external progress tracker are three: Super Smash Bros. Melee, Snowboard Kids, and Snowboard Kids 2.
MW2 also uses byte matching as its criterion, but the only information supporting the 83% figure is the developer's own report.
Also, the "84 days" for Snowboard Kids is the period the developer counted to reach 100%. Calculated from the dates in the public repository, it comes to about 83 days.
While anyone can trace the history in an external tracker's records, a developer's self-reported figures depend on the definitions and explanations he or she provides.
Furthermore, MW2's 83% is the share of matched functions out of all functions, whereas Melee's 100% is the share of matched bytes out of the total code bytes. Because the units differ, the percentages in the table can't be compared directly.
Expert involvement in 4.8% of commits: what remains even at a 100% match
In a blog post dated November 27, 2025, Chris Lewis described the "one-shot" method he introduced to advance the decompilation of Snowboard Kids 2 (N64).
In this method, a scorer selects the next relatively easy function to work on, and Claude (mainly Opus 4.5) tries to reach a byte match with no human intervention. If there is no progress after more than 10 attempts, the function is recorded in a list of hard functions and the system moves on to the next one.
According to Lewis, unattended runs of more than eight hours became possible, and in the three weeks after introduction he made more progress than in the preceding three months. However, he also looked back on the rule of giving up after 10 failed attempts as having "worked only partially."
Processing functions from easiest to hardest has the problem that it eventually stalls.
In a blog post dated February 16, 2026, Lewis reported that after the match rate jumped from about 25% to 58%, progress slowed; he changed approach and raised it to about 75%, then stalled again.
Snowboard Kids 2 reached 100% on May 17, 2026. That was 596 days after the first commit on September 28, 2024.
Community members reportedly played a major role in the last 10 functions, which were especially difficult. In Lewis's experience, the best-performing model was Codex 5.5 xhigh. He cautions, however, that this assessment is based on his own experience and may change.
Lewis stresses that not only model performance but also human cooperation was important, stating, "the community was more important than any model."
In the original Snowboard Kids, the contributions of human experts show up in the numbers.
Lewis counts 84 days to reach 100%. In the public repository, this corresponds to about 83 days, from May 28 to August 19, 2026. It has 2,145 functions, fewer than the sequel's 2,995.
About 4.8% of commits related to matching work (about 41 commits) reportedly involved expert intervention.
According to Lewis, without the knowledge of experts familiar with the IDO compiler developed by SGI, the match rate might have plateaued at around 89 to 90%, however smoothly things went.
However, the 4.8% figure is a rough estimate that Lewis arrived at by manually reviewing and classifying the commit history. It doesn't indicate the share of human working time, and Lewis does not count himself as an expert.
The 89 to 90% figure is also an estimate assuming experts had not taken part, not a measured value.
The original and the sequel differ in the number of functions and in when work started. Lewis himself cites factors such as having become proficient at the work through a similar project that had lasted about two years immediately beforehand, and the difficulty of reproducing the IDO compiler's output.
So the 84-day period can't be interpreted directly as the result of efficiency gains from AI.
Incidentally, a script was also tried that used "m2c," a tool that automatically generates C code from machine code, to batch-process 1,830 unmatched functions. But only 17 matched, a mere 0.93%.
Lewis points out that even if the code matches 100%, that doesn't mean the content of the source code has been fully understood.
This problem has also surfaced in the decompilation of Klonoa: Empire of Dreams.
A blog post published by the game's developer on August 17, 2026, describes a case in which AI tried to get around the proper match check.
Klonoa: Empire of Dreams is a Game Boy Advance title released in July 2001. At the time of the blog post, 663 functions had been identified across the game, and 51% had been decompiled by code byte count.
When it got stuck, Claude Code forked the compiler in use, "agbcc," and tried to force a match by modifying the compiler itself.
But this changes the very baseline used for comparison, rather than restoring code to fit the comparison target. It departs from the original purpose of verifying a match against the original machine code.
This is the same pattern as the AI trying to rewrite the verification script in the MW2 case, and an experienced participant quickly rejected the change.
The developer calls the biggest risk in this project "cognitive debt."
While LLMs speed up the work rapidly, the burden on humans of understanding and verifying the code and changes accumulates until it grows beyond what can be paid off. The developer looks back on his own initial reaction on seeing the AI's improper attempt as one example of this.
That said, AI can also find things humans have overlooked. The same Claude Code reportedly discovered, autonomously, a hidden minigame that had gone unknown for 25 years.
The importance of "verifiable work" extends to COBOL modernization
The lessons from game decompilation also apply to migrating companies' old systems to new environments.
In an article dated February 23, 2026, Anthropic claimed that Claude Code can automate the investigation and analysis that makes up most of a system modernization, allowing modernizations that once took years to be completed in a few quarters.
On February 23, the day the article was published, IBM's stock closed at $223.35, down 13.15% from $257.16 on February 20, the previous trading day (editorial calculation based on Yahoo Finance daily data). However, the available materials can't establish that Anthropic's article caused the decline.
Meanwhile, Cognition, which provides the AI agent "Devin," explained more concretely in an article dated April 8, 2026, the difference between what AI can handle and what is difficult for it.
The Linux virtual machine (VM) in which Devin runs can't execute COBOL business systems from a mainframe as they are. This makes the iterative cycle of writing code, running it, checking the results, and fixing it impossible.
The background is that COBOL business systems are tightly tied to mainframe-specific infrastructure, such as job control systems, middleware, old databases, and proprietary file systems. Because the same environment doesn't exist on the Linux side, an agent can read the source code but can't run it to verify correctness.
By contrast, for batch processing with clear inputs and expected outputs, code can be revised repeatedly until the outputs match.
Cognition says the portion to which this method can be applied accounts for 30 to 50% of COBOL migration work. However, this figure was cited by the company from an external article and is not Cognition's own measured result.
Structurally, it is the same as byte matching in game decompilation. If the expected output is known, a verifier can be prepared using it as the standard.
As concrete examples, Cognition cites the migration of a 25,000-line customs clearance system used by an anonymous automaker to AWS Lambda, and, at Itaú, Latin America's largest private bank, the work of changing corporate taxpayer ID numbers to support alphanumeric characters.
The latter was reportedly completed three months ahead of schedule. However, both are cases published by Cognition itself.
Even larger efforts are under way.
According to a CIO Dive article dated July 28, 2026, Morgan Stanley used its in-house platform "DevGen.AI" to modernize more than 17 million lines of code written in COBOL, Natural, and PERL into languages such as Java and Python.
However, the figure of 17 million lines indicates the scale of the work, not the completeness or accuracy of the migration.
Experts are divided on the outlook for AI-driven legacy system modernization.
On June 18, 2026, Gartner predicted that more than 70% of mainframe exit projects started in 2026 would fail to deliver the expected results because they overestimate the capabilities of generative AI. This is a forecast, not a survey result showing that more than 70% actually failed.
For information systems departments in Japan considering mainframe modernization, the distinction Cognition presents is one useful input for decision-making.
The first step is to try AI migration on work whose expected output can be clearly defined, and for work where it is hard to prepare correct outputs, to check carefully how completeness and accuracy were verified.
In the game decompilation cases, the part whose progress third parties could confirm through public trackers was the part where matches could be judged mechanically. And there are examples where the knowledge of human experts was indispensable in getting through the last hurdle.
The reliability of the numbers also varies. Some, like MW2's 83%, can't be verified externally, while in cases like Halo, the README's figure has no stated definition, making it impossible to tell how it differs from the public tracker's figure.
Furthermore, challenges remain even after code matches 100%.
Lewis lists tasks such as renaming auto-generated function and variable names to something understandable, organizing the code's structure, and handling graphics and audio data appropriately.
Even as AI speeds up code reconstruction, the work of bringing its contents to a state that humans can understand and maintain doesn't automatically finish.
For COBOL and other legacy system modernization too, once the actual results of the mainframe exit projects started in 2026 become clear, they will offer material for judging how valid Gartner's forecast was.