iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Yes, but not autonomously or reliably in the general case. A 2026 project report says a coordinated team of coding agents reconstructed a commercial game’s behavior in readable C++, with 99% of functions represented and 83% matching the original machine-code bytes under a custom verifier. That result concerns decompiling a compiled game—not simply handing agents an existing source repository—and it depended on human planning, specialist reverse-engineering tools, a fixed compiler, and continuous machine checks.
What “recreate a game from its source code” actually means
The answer changes radically depending on what the agent receives. An agent modifying an existing, documented source tree is doing ordinary software maintenance. An agent given a compiled executable, disassembly, or screenshots must infer missing intent, data structures, rules, and edge cases. Those are different technical problems and should not share one accuracy percentage.
The most prominent 2026 example is often described as source-code recreation, but the primary account describes a decompilation project. Developer Maurice Heumann spent about three months producing readable C++ that compiled and reproduced the behavior of a commercial game. His October 9, 2026 account does not name the title; a contemporaneous Tom’s Hardware report identified it as Call of Duty: Modern Warfare 2 (2009). The workflow and measurements come from Heumann’s account, while the game identification comes from that secondary report.
Free tools Windows power users keep installed
One-click scans. No signup required.
That distinction matters. Having the original source, build files, assets, and design documents gives an agent far more information than recovering behavior from a binary. Conversely, a binary-reconstruction project can be a demanding test of reverse engineering even when no source repository is available.
#1 Best Overall
What the 2026 case study achieved
Heumann reports that the final reconstruction contained 99% of the game’s functions and that 83% were byte-exact when compiled and compared with the original. He also says the game ran with its original features present and that the remaining unmatched functions were believed to be semantically correct after repeated revision. These are the project author’s measurements and conclusions, not an independent audit or replication.
| Reported item | What it means | Qualification |
|---|---|---|
| 99% of functions present | Nearly all identified functions had a counterpart in the reconstruction. | Author-reported for this project; it is not a general agent success rate. |
| 83% byte-exact | Compiled function bytes matched the original in the checked comparison. | Applies to the selected compiler, build settings, and verifier; relocation handling was special-cased. |
| All original features present | The author says the resulting game launched and retained its feature set. | No outside group is shown reproducing the result. |
| 600–700 billion tokens | A rough estimate of agent usage during the project. | Heumann says lost session logs prevent an exact count; it is not an audited total or a price. |
Why the early “working” build was misleading
The first milestone looked successful: the game launched, showed a menu, and loaded maps. Heumann later found that readable code could still be wrong in ways a visual smoke test would miss. Function signatures, type declarations, and structure layouts could be inaccurate; logic could be invented, omitted, or subtly rearranged while the program continued to run.
An agent reviewer was not enough to catch those deviations because the team had not yet defined an objective meaning of “correct.” Heumann summarized that lesson with the statement, “We never properly defined ‘correctness.’” A human or another model can judge whether code looks plausible, but plausibility is not equivalence.
How the verification harness worked
The team changed course by compiling the reconstructed code with the compiler used for the original game and comparing the resulting object-code functions with the original executable. This made correctness a repeatable CI check rather than an opinion.
- Function-level comparison: each reconstructed function was matched against its counterpart in the original binary.
- Relocation-aware checking: bytes containing relocation addresses were not compared literally. Instead, the verifier checked the referenced symbol and offset, preventing different load addresses from creating false failures.
- Data and type checks: the account says the harness also checked data and types, not just instruction bytes.
- Continuous regression testing: recorded comparisons ran again in CI so a later agent change could not silently reduce the match rate.
Heumann’s stated project lesson is that “A reliable verification harness that delivers an objective PASS or FAIL signal is the best feedback an agent can get.” That is a conclusion from this workflow, not proof that byte comparison is the right acceptance test for every game project. A new game, for example, has no original executable whose bytes should be reproduced.
What the agents and humans actually did
The project was an orchestrated system, not a single prompt. It used Claude Code and Codex command-line agents, GitHub issues organized by translation unit, a shared communication channel, CI notifications, and Hex-Rays’ ida-mcp interface to inspect disassembly and decompilation output. The number and model mix changed over time: Heumann says the effort began with four agents and later expanded to a larger fleet.
Agents handled portions of translation, implementation, and revision. Humans designed the task boundaries, selected tools, interpreted failures, and changed the evaluation method when the initial approach produced convincing but semantically incorrect code. The issue structure and continuous integration were as important as the model calls because they preserved context and exposed regressions across a long-running effort.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →This explains why the case should not be summarized as “an AI recreated a game.” A more accurate description is: a human-directed team used coding agents as components in a heavily instrumented reverse-engineering pipeline.
How other evaluations compare—and why their scores cannot be ranked together
Several 2026 evaluations measure neighboring abilities. They use different inputs, scopes, and definitions of success, so their percentages are not interchangeable.
| Evaluation | Input and scope | Reported result | What it does not prove |
|---|---|---|---|
| GameCraft-Bench | Agents create 2D games in Godot from specifications. | Strongest displayed configuration: 68.44 overall, with separate mechanics, depth, visuals, and art scores. | It does not cover Unity, Unreal, 3D games, multiplayer, large-scale physics, long production workflows, or subjective fun. |
| GameEngineBench | Scoped native C++ changes inside Unreal Engine 5 projects from nine repositories; 110 tasks. | Strongest reported pass@1: 55.5%; 31 tasks were unsolved by every tested configuration. | It measures implementation of bounded tasks in existing projects, not recreation of a whole game. |
| GameReplica | Black-box replication from screenshots and action input, with no source or documentation; 125 tasks across 25 games and five difficulty levels. | Top model: 71.6%; other evaluated models: 4.0–42.9%. | Visual fidelity was stronger than implementation and rule consistency, so a similar-looking result could still behave incorrectly. |
| Retrobench | Agents receive raw MIPS assembly for Nintendo 64-era functions and write C that must match machine code when built with the original IDO compiler. | Designed around byte-for-byte matching rather than a single whole-game score. | It is a narrow function-level reverse-engineering benchmark, not a complete game reconstruction. |
The useful comparison axes are therefore: what information the agent can see (source, executable, assembly, specification, or screenshots); how much it must build (a function, a scoped change, a playable game, or an entire title); how correctness is measured (visual similarity, behavior tests, pass@1, or bytes); what human and tool support is supplied; and whether an outside party has validated the result.
What this means if you have source code
When a legitimate project already has source code, agents can accelerate porting, bug fixing, test generation, documentation, and subsystem rewrites. They still need a buildable baseline and tests that express the behavior you intend to preserve. The 83% figure from Heumann’s binary project should not be used as a forecast for your repository: source availability removes much of the inference problem, while an unfamiliar engine, missing assets, platform dependencies, or undocumented networking can create different obstacles.
For a lawful reconstruction or migration, obtain permission for every executable, asset, SDK, and dependency. Keep the work within licenses and local law; do not bypass access controls or distribute copyrighted game content without authorization. “Can an agent do it?” is separate from “Are you allowed to do it?”
Rank #4
A practical, testable workflow for an agent-assisted recreation
The following process generalizes the strongest parts of the case study without assuming that every project has a byte-level oracle.
- Define the target: decide whether you need source-compatible behavior, gameplay equivalence, visual similarity, a port, or merely a prototype. Write measurable acceptance tests before asking an agent to implement anything.
- Inventory the inputs: record which source files, binaries, symbols, assets, specifications, screenshots, and test accounts are available. Mark unknowns instead of letting an agent silently guess.
- Choose an oracle: use unit tests, replay files, network traces, frame captures, property tests, or—where legally and technically appropriate—compiler-produced byte comparisons. A launch screen alone is not an oracle.
- Partition the work: assign issues by translation unit, subsystem, or clearly bounded behavior. Keep interfaces and structure layouts documented so parallel agents do not invent incompatible types.
- Freeze the toolchain: pin compiler versions, flags, SDKs, generated-code settings, and platform targets. Reproducibility is essential when tiny build differences affect output.
- Inspect specialist evidence: for binary work, use a disassembler/decompiler and preserve symbol, address, and type decisions. For source work, capture call graphs, tests, and dependency constraints.
- Run checks on every change: require CI to report pass/fail results and retain failing artifacts. Have agents fix a specific failure rather than repeatedly rewriting code based on a subjective review.
- Review semantics and player behavior: tests can miss feel, pacing, accessibility, and emergent interactions. Human reviewers should examine the areas the oracle cannot measure, while avoiding claims that visual plausibility equals rule correctness.
- Document uncertainty: label inferred behavior, unverified functions, platform-specific differences, and missing assets. A clear uncertainty register is safer than presenting guesses as recovered design intent.
Common failure modes and fixes
The game launches, so the reconstruction is declared finished
Why it fails: startup exercises only a small path; incorrect types or rules may remain dormant. Fix: add replayable tests for menus, saves, combat or movement rules, error paths, and long sessions, then compare state and outputs rather than only process exit codes.
Agents produce locally plausible but globally incompatible code
Why it fails: parallel agents infer different names, calling conventions, or structure layouts. Fix: maintain a shared interface ledger, assign ownership of canonical definitions, and make CI reject ABI or schema drift.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Visual similarity hides rule errors
Why it fails: GameReplica’s results specifically show that visual-fidelity scores can exceed implementation and rule consistency. Fix: test action outcomes, timing, collisions, state transitions, and repeatability with scripted inputs.
Best Value
Byte matching is treated as universal
Why it fails: byte identity is meaningful for a decompilation target with a known compiler, but not for a new implementation whose behavior is correct despite different optimizations. Fix: select the oracle that matches the goal: behavioral equivalence for ports, visual and input metrics for black-box replication, and byte checks only when exact code generation is the requirement.
Token volume is mistaken for capability
Why it fails: Heumann’s 600–700 billion figure is approximate and reflects a long, multi-agent effort, not an efficiency benchmark. Fix: report task completion, regression rates, human hours, and reproducibility alongside any usage total.
So, can AI coding agents do it?
They can contribute to recreating a game, and one 2026 case reports unusually strong binary-level results. The evidence does not show that an agent alone can reliably recreate arbitrary games from source, binaries, or screenshots. The successful pattern combines humans who define scope and legality, agents that implement and investigate in parallel, specialist tooling that exposes hidden program structure, and an objective verifier that catches plausible mistakes.
The safest conclusion is conditional: if you have clear rights, a well-defined target, enough technical artifacts, and a test harness suited to that target, agents can reduce the labor of a substantial reconstruction. Without those conditions, a playable-looking build is evidence of a demo—not proof that the original game has been recovered.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
