Some people measure progress in benchmarks. A programmer who goes by Priyan measures it in a small pixelated man hanging from a ledge. He first played Prince of Persia in 1995 on an IBM PC XT, and the game never left him — the rotoscoped animation, the clank of a gate slamming shut. So when Jordan Mechner published the original Apple II 6502 assembly source in 2012 — recovered from 3.5-inch floppies that had spent more than 20 years in a box — a natural experiment presented itself. Hand the source to every new frontier AI model, ask for a port to C#, and never touch the code. His only job: play the result and report what was wrong.
Round one, February 2026, was Claude Opus 4.6. The opening prompt set the tone for readability: “in this original code there 6502 assembly code for prince of persia, use the save level files and try to do it in c# console.” (On Hacker News, commenter smokel marveled that anything emerged at all: “Do what in the what now in the console?”) Over two days, Opus 4.6 produced a console game, a level editor and a Raylib graphics version, correctly parsing rooms, tiles, gates and guard positions. It looked like Prince of Persia and played like a falling filing cabinet. The prompt log from those days tells the story: “its bad not able to play its running graphics is scrambled”; “now char coming but movement everything wrong ... prince is not in floor”; “now it dropped below floor and arrow keys doesnt move.” The root cause, only understood later: the prince hopped tile to tile, while the real game plays hand-drawn animation frames with small per-frame movement. The architecture was wrong, and the model couldn’t tell.
Round two, March 2026, was OpenAI’s Codex, asked to repair Claude’s work: “this is prince of persia original assembly code to c# port done by claude still graphics not good can you fix it.” It delivered sensible surface fixes — sharp pixel filtering, transparent sprite backgrounds, gates you could actually walk through — but the prince still materialized in wrong places and the engine underneath stayed wrong. It had polished the paint on a house with no foundation.
Round three, September 2026, is where the experiment changed shape. Priyan wrote two Claude Code skills — one driving DOSBox with keystrokes and screenshots, one controlling Windows programs — and pointed Opus 5 at his original DOS copy with orders to compare against the real thing and run until success or 6am. Overnight, the model did what its predecessors hadn’t: it diagnosed the architecture problem itself, rebuilt the engine around the original’s frame-driven design, worked out the DOS file formats, and dug the real data out of them — every animation frame, the dungeon art, all 15 levels. It located animation tables inside PRINCE.EXE by searching for byte patterns it recognized from the Apple II source, confirming each against a second known value before trusting it. No copyrighted data entered the repository; the C# program reads everything live from Priyan’s own DOS install.
By morning it was playable. In a follow-up session the model watched his screenshots, caught its own ledge-detection bug, and fixed it by returning to the original assembly. But the levels were still off — every brick and gate placed by eyeballing screenshots, with guesswork filling the gaps.
Round four was Claude Opus 5.5 and a single prompt: “the character moves runs jumps but gate positions bricks all different, you are new model let see anything u can improve.” Instead of tuning by eye, it went to the library. It found the original’s own room-drawing routine as documented by SDLPoP — the open-source reconstruction of the DOS game by Dávid Nagy and the princed.org community — and produced DosRoomDrawer.cs, a straight port of SDLPoP’s seg008.c, labeled as such in its header. It also discovered that PRINCE.EXE is compressed with Microsoft EXEPACK (the earlier tables had worked only because they happened to sit in an untouched stretch), wrote an unpacker, caught an off-by-one-pixel screenshot crop, and checked its work pixel by pixel against DOSBox. On the first screen of level 1, mismatched pixels fell from 8,429 to 2 — the two being a torch flame caught at a different moment.
It wasn’t flawless: a sprite-position change, verified only with the prince facing one way, left him sinking into walls when facing the other — but given a backup, it proved the movement identical, isolated its mistake and reverted just that part. Asked later whether it could have managed without SDLPoP, the model itself answered, “Honestly, probably not in one prompt,” explaining it had read and ported an existing reconstruction rather than reverse-engineering the drawing code — and that what it genuinely contributed was knowing where to look, spotting the compression, and proving the result pixel by pixel.
To be clear, this wasn’t a controlled bake-off: as commenter jablongo noted, “This isn’t really comparing the models; he’s using successive models to improve his rebuild of Prince of Persia.” But Priyan’s takeaway stands on its own. The biggest leap came not from raw intelligence but from instrumentation — from Opus 5 onward the model could see the original and test itself, and he stopped being the only tester in the loop. Guards, sword fights and palace levels remain; the next model gets the same assignment.
And buried in SDLPoP’s documentation was the story’s best prize, a fact hiding in plain sight for three decades. The gate at the start of level 1 is actually open in the level data. The original game presses a hidden button as the prince drops in, which is why you hear it slam shut behind you. The drama of 1995 was stage machinery — and it took a machine working through the night to find the lever.