AI made reverse engineering cheap. Checking it didn't get cheaper.

Things we used to only imagine are being built now, and in days rather than years: one game's mechanics inside another, console games running natively on a PC, security holes found in software whose source nobody outside the company has seen. A lot of that speed comes from AI. It also has a price, and the growing dependence on AI is making parts of the industry question how much of this work anyone actually understands. Games and hardware are where my interests lie, so I wanted to look at it closely, and then try it on my own code.

What's happening in games

• ArkWeb puts Spider-Man Remastered's web-swinging into Batman: Arkham Knight's Gotham. Viral posts said AI had "fused two games". What it actually does is run both games side by side and pass data between them through shared memory, with Arkham Knight as the visible host. Four of the project's six commits are co-authored by Claude, and its setup guide tells you to let an AI agent install it.
• Many of the other viral mashups, such as a block of Minecraft TNT sitting in Red Dead Redemption 2's Valentine, use the same trick: two games running at once, with AI writing the glue between them.
• AnyPS5 relinks PS5 executables into native Windows and Linux programs, without emulating the console. In October 2026 it reported translating every GPU shader instruction on its tracking list, and about 88% of the system library functions it has declared so far. News coverage lists only one game, a simple 2D platformer, as verified to run. You supply a game dumped from your own console; the project distributes none. Some of its commits are co-authored by Claude models too.
• Projects that turn old console games into native PC ports have accelerated with AI, and the community has split over it. A Smash Bros. PC port reportedly written entirely by AI in about 25 days turned out to have physics that were off in places, and some projects now state outright that they accept no AI-generated code.

What's happening in software and security

• Wiz used an AI-assisted reverse-engineering setup built on IDA to find a critical remote code execution bug in GitHub Enterprise Server's closed-source binaries. GitHub validated and patched it within about two hours.
• Google's Big Sleep agent has reported its first 20 vulnerabilities, in widely used open-source software such as FFmpeg and ImageMagick.
• The same speed is available to attackers. If reading a binary takes minutes instead of weeks, hiding things inside it buys much less time than it used to.

What actually got cheaper

Reverse engineering always had two halves. One is tedious: reading assembly or decompiled code, guessing what a variable means, giving functions names, writing the glue that connects two systems. The other is checking: is this reconstruction actually equivalent to the original? AI collapsed the cost of the first half. It did very little for the second.

That explains the split in the port community. Projects that rebuild a game's source byte by byte have a built-in check: the compiler either reproduces the original binary exactly or it doesn't, so a wrong answer is rejected without anyone needing to trust it. Ports and mods built on top have no such check, and that is exactly where the quality arguments start.

My experiment

I took two of my own early Java programs: a console Monopoly I wrote in my first year (291 lines) and a hardware scorer that rates a CPU and GPU pair and estimates FPS, which came before PerfHub (504 lines). Because the code is mine, there is no legal question. I compiled both without debug information, ran them through ProGuard so every class, field and method name became a, b, c, and decompiled the result with CFR. That is roughly what a released Java program looks like to someone who wants to understand it.

Then I had Claude, the assistant I build with, rewrite readable source from the decompiled code alone. The rule was that the original source stayed closed until the end. It had seen the file names when the repositories were cloned, so class names were not scored. Finally, both versions ran on the same inputs and their output was compared byte for byte. Monopoly rolls dice, so a small harness gave both versions the same random seed.

Results

• Behaviour: 300 of 300 input cases produced identical output for the hardware scorer, and 60 of 60 seeded Monopoly games were identical, move for move. A control run with different inputs showed the comparison could tell them apart.
• Names: of 64 fields and methods, only 3 came back with exactly the original identifier, but nearly all came back with the same meaning: watDegeri became powerWatts, isParcacigisayisi became threadCount, kiraBedeli became rent.
• Time: a few minutes of the assistant's working time per program, by the system clock. For a person reading obfuscated code by hand, this would be an afternoon at least.

What those numbers hide

• The meaning came from my own strings. Every field was printed next to a Turkish label, like "Bellek türü " followed by the value, so the program described itself. Commercial software often encrypts or strips those strings, and that would make this much harder.
• The decompiler's output for Monopoly did not even compile. CFR had mixed up variable types, so turning it into working code needed reasoning, not just renaming.
• The first comparison failed on every single case, and the reason is the most useful finding of the whole experiment. While retyping one line, the assistant had silently corrected a typo of mine, "sırasısyla" to "sırasıyla". A helpful change, and a wrong one, because the goal was the same program. Only the byte-for-byte comparison caught it. Without that test, the "fix" would have shipped.

It found bugs I hadn't noticed

Reading my own program from the outside showed problems I had missed, and running the original binary confirmed each one:

• None of the 22 Intel CPUs in the hardware scorer can be selected. The program converts the input to upper case, so "i7" becomes "I7", but the keys were stored with a lower-case "i". All 14 Ryzen models work, which is why I never saw it.
• Typing "RED DEAD REDEMPTION 2" with an ordinary I is rejected, because the key was saved with the Turkish İ.
• The RX 9070 XT is displayed as an RX 9700 XT, and Cities: Skylines II recommends -32 GB of RAM. I had meant "32-64", and Java read it as a subtraction.

All of these are fixed now (commit 1db52dd). Every listed CPU, GPU and game is accepted however it is typed, and on 150 inputs the old version already handled, only the lines I meant to change are different.

Where I land

The costs are real. There is a line between interoperability, preservation and security research on one side and piracy on the other, and faster tools make it easier to cross. I won't write about cracking. The other cost is quieter: when AI writes the glue and nobody checks it, you get a port with the wrong physics, or a "fix" that changes what a program does.

Understanding a binary is no longer the expensive part. Proving that your understanding is right still is.

Next I want to repeat the experiment with the strings encrypted, the way much commercial software ships, and see how much of the meaning survives.

Everything behind these numbers, including the rebuilt code, the comparison scripts and the checksum-pinned tools, is in the blog-experiments repository, so you can rerun it yourself. Part 2 is a blind test on a program I had never seen: Part 2: a blind test.