A 37-year-old video game has become an unlikely test of how far AI coding has come.
Claude Opus 5.5, Anthropic’s latest high-end coding model, helped turn a painstaking reconstruction of the original 1989 Prince of Persia into a much more faithful playable version. The breakthrough was not simply that the model could write C# code or make a game that looked vaguely right.
It figured out that some of the most stubborn visual problems should not be solved by guessing.
Instead, Claude found an existing reconstruction of the game’s room-drawing logic, ported that code into C#, connected it to data extracted from the original DOS game and then compared the result against the real game pixel by pixel.
On one test screen, the number of mismatched pixels reportedly fell from 8,429 to just two.
That makes this a useful little experiment in AI-assisted software engineering. It shows a model doing something much closer to reverse engineering and code archaeology than ordinary code generation.
There is also an important caveat: the project was conducted by an independent developer, not Anthropic, and Claude’s final breakthrough depended on the work of people who had already spent years reconstructing Prince of Persia’s DOS internals.
This was not a simple “build the game” prompt
The experiment began with Priyan R, a developer who wanted to see how different frontier AI models would handle the same programming challenge.
He supplied models with the original Apple II source code for Prince of Persia, written by creator Jordan Mechner in 6502 assembly language, and asked them to port the game to C#.
Mechner published the original Apple II source in 2012 after it was recovered from old floppy disks. The source covers code written between 1985 and 1989 and provides an unusually valuable window into how the game was built.
The experimenter deliberately did not manually rewrite the model-generated code. His role was largely to run the game, observe what was wrong and provide feedback.
The first model, Claude Opus 4.6, managed to parse significant portions of the old game but struggled with a fundamental problem.
It was building the wrong kind of engine.
The first AI attempts got the architecture wrong
The early C# version could display rooms and some game elements, but movement did not feel like Prince of Persia.
The reason was subtle and fundamental.
The recreated game treated the prince as though he were moving from tile to tile on a grid. The original game did something different. Its movement was driven by animation frames and small positional changes from frame to frame.
That distinction is the difference between a game that merely resembles Prince of Persia and one that actually behaves like it.
The experiment moved on to OpenAI’s Codex, which improved several surface-level issues such as sprite rendering and visual filtering. But the underlying architecture remained flawed.
The breakthrough arrived with Claude Opus 5, when the developer gave the model tools that allowed it to launch the original DOS game, send keyboard input and capture screenshots.
Now Claude could do something earlier versions could not: compare its reconstruction with the actual game while working.
It diagnosed the architecture problem, rebuilt the engine around frame-based behavior and extracted animation information from the DOS files.
That produced the first genuinely playable version of the reconstruction.
But another problem remained.
The game still did not look quite right.
The stubborn problem was the rooms
The prince could run, jump and fall correctly, but the rooms contained subtle visual errors.
Bricks were in the wrong places.
Gates did not line up.
Decorations were slightly misplaced.
The earlier model had effectively solved these problems one object at a time by comparing screenshots and estimating positions.
That approach can get surprisingly close.
It can also become a swamp of tiny assumptions.
Claude Opus 5.5 took a different route.
When the developer gave the new model a single follow-up instruction about the remaining visual differences, it searched for a deeper explanation of how the original game constructed its rooms.
That led it to SDLPoP, an open-source project that reconstructed the DOS version of Prince of Persia from disassembly and years of reverse-engineering work by its community.
Claude then ported SDLPoP’s room-drawing routine into C#. The resulting file in the project is explicitly identified as a C# port of SDLPoP’s src/seg008.c room-drawing code.
That distinction matters.
The headline “reusing the original game’s own code” is a little too neat. The model was not simply copying the original DOS source. It was taking a community reconstruction of the DOS game’s behavior and translating that into the new implementation.
The AI discovered why the bricks were not actually random
One of the most interesting details involved the game’s distinctive brick patterns.
What can look random to a player is not necessarily random inside the software.
SDLPoP’s documentation showed that the original game generated those patterns deterministically using information tied to the room, row and column. That meant the same environment could be recreated consistently rather than guessed from a screenshot.
That discovery changed the problem.
Instead of asking:
“Where should this brick go?”
the system could ask:
“How did the original program decide where this brick goes?”
That is a much more powerful question.
It replaces visual imitation with reconstruction of the underlying rule.
The same process helped explain another apparently strange detail: the gate at the beginning of the first level appears open in the underlying level data, while an in-game action causes it to close as the prince enters.
Those are exactly the kinds of quirks that are easy to reproduce badly and much easier to reproduce once the original logic is understood.
Even the DOS executable had another trick
The investigation did not stop at the room-drawing routine.
The experiment’s author says Claude Opus 5.5 also discovered that the DOS PRINCE.EXE file was compressed using Microsoft EXEPACK.
That mattered because some of the earlier attempts had managed to find data tables in the executable, but those discoveries worked partly by luck because the tables happened to sit in an uncompressed portion.
Opus 5.5 wrote an unpacker and was then able to read the relevant tile-drawing tables from the developer’s own copy of the game.
This is where the demonstration becomes more interesting from a programming perspective.
The model was not simply generating code from a description.
It was inspecting unfamiliar legacy software, forming hypotheses about its structure, testing them against evidence and changing course when those assumptions failed.
That is much closer to the sort of work engineers encounter when inheriting an old codebase.
Then came the pixel-by-pixel test
The most concrete result from the experiment came when Claude compared its recreation against the original running inside DOSBox.
On the first screen of level one, the developer reported that the number of different pixels dropped from 8,429 to two.
The remaining discrepancy was attributed to a torch flame being captured at a slightly different moment.
The second room and the exit door on level three also reportedly matched the original.
Those measurements are important because they turn an otherwise fuzzy claim such as “the AI recreated the game” into something much easier to evaluate.
A screenshot can be judged.
A pixel difference can be counted.
A game can be run side by side with the original.
That does not make the experiment a formal benchmark, but it gives outsiders a concrete result to inspect.
Claude still made mistakes
The experiment was not a clean demonstration of an infallible AI engineer.
Opus 5.5 changed how the prince’s sprite was positioned based on the original code and tested the change in one direction.
When the character faced the other way, the sprite sank slightly into walls.
The developer noticed the problem, supplied an earlier backup and asked Claude to investigate.
The model determined that movement itself remained consistent while the sprite rendering introduced the error, then reverted that specific change.
That episode may be more revealing than the near-perfect screenshot.
Real software work is full of cases where a seemingly sensible fix breaks something else.
The useful capability is not never making mistakes.
It is finding the mistake, isolating it and backing out the bad change without destroying everything around it.
The most important contribution was not the model alone
There is a temptation to describe this as a machine independently resurrecting a classic game from decades-old source code.
The actual story is more collaborative.
Jordan Mechner’s decision to publish the original Apple II source made the experiment possible in the first place. The SDLPoP community had already reconstructed important parts of the DOS version through disassembly and reverse engineering. The developer running the experiment supplied the original DOS copy, testing environment, screenshots and feedback.
Claude Opus 5.5 connected those pieces.
That is significant in its own right.
Modern AI coding tools are increasingly useful not because they magically understand an entire software system in isolation, but because they can search documentation, inspect files, run programs, compare outputs and revise their own work.
Anthropic says Opus 5.5 is designed for advanced coding and agentic tasks, and the company has highlighted its ability to work on long-running software projects.
The Prince of Persia experiment offers a small, unusually visible example of that broader trend.
Why this matters beyond a 1989 game
Prince of Persia is obviously not a modern enterprise application.
It is an old, constrained piece of software with extensive documentation and a community that has already spent years studying its internals.
That makes it a favorable environment for an AI model.
A messy proprietary codebase with millions of undocumented lines, missing dependencies and constantly changing requirements would be a much harder test.
So the experiment does not prove that AI can effortlessly understand any legacy software.
What it does show is a progression in what coding models can do when they have the right tools and enough context.
Earlier systems were largely asked to produce code.
The newer workflow is closer to:
Inspect the software.
Run it.
Observe what is wrong.
Search for clues.
Recover the underlying logic.
Reuse existing work.
Test the result.
Fix the failure.
Repeat.
That is a very different model of AI-assisted programming.
The real story is code archaeology
The nostalgic appeal of Prince of Persia makes the demonstration easy to understand, but the deeper story is not about reviving a classic game.
It is about what happens when an AI becomes capable of navigating the archaeology of software.
Old codebases often contain strange shortcuts, undocumented assumptions and behavior that makes no sense until someone reconstructs the original environment.
Understanding such systems requires more than syntax.
It requires connecting clues scattered across source files, binaries, documentation and observed behavior.
In this experiment, Claude did not invent the answer to every one of those puzzles. It benefited directly from previous reverse-engineering work.
But it was able to recognize useful prior work, adapt it to a new implementation and verify the result against reality.
That is the part worth watching.
The future of coding AI may depend less on generating brand-new code and more on understanding the enormous amount of code humans have already written.
Prince of Persia just happens to be a particularly charming 37-year-old laboratory for testing that idea.
