Its name is fn_801B3DE4. It is the function that nerd-sniped me into fine-tuning my own model. It is named, by hand, in that very article. It has been on my retry list for a couple of weeks, it survived roughly fifteen separate sessions, and somewhere along the way it became less a decomp target and more a personal grudge.

I should level with you up front: I'm not a C programmer by trade. My day job is TypeScript, React and AWS, and I don't know a single C expert I could phone for help. So this entire saga — every dead end below — has been just me and a rotating cast of AI models, grinding on one function for the better part of a fortnight. (Ask me again when the decomp's finished; maybe I'll have turned into a C expert by accident.)

This is the story of finally cracking it — and, just as much, the story of all the increasingly ridiculous ways I tried and failed first.

A quick reminder of what "matching" means

If you've read the earlier posts you know the rules, so I'll keep this short. A matching decompilation isn't "write C that behaves like the original". It's far stricter: write C that, when fed through the exact original toolchain — Metrowerks CodeWarrior for PowerPC, run under wibo on Linux — compiles to byte-identical machine code to what shipped on the retail disc. Same instructions, same register allocation, same constant pool, in the same order.

The scoreboard is objdiff, which spits out a fuzzy_match_percent per function. 100% means bit-for-bit. The cardinal rule of the project is that inline assembly is forbidden — you could "match" anything by pasting the target's instructions into an asm { } block, but that defeats the entire point. The whole point is plausible original C. So when a function won't yield, you commit the partial, document the divergence, and put it on the retry list.

fn_801B3DE4 had been on that retry list for a very, very long time.

The function, and its reputation

It lives in dll_01CA_dimexplosion.c — the explosion effect — and it spawns a single debris/flame particle into an explosion's pool. Nothing exotic on the surface: grab the explosion state, bump a counter to get the next free slot, compute the slot's base address, and fill in a couple of dozen fields — position, velocity, a lifetime, some randomised spin, an alpha falloff driven by expf. 181 instructions.

It also compiles with an unusual little pragma stack:

#pragma peephole off
#pragma opt_propagation off
// -O4,p
void fn_801B3DE4(int obj, u8 b, f32 spd, f32 x, f32 y, f32 z) { ... }

In my notes it had a reputation — one the AI had given it. Session after session, whichever model I had working on it would grind for a while and then write the same verdict into the log: this is the canonical "genuine open frontier", a divergence with no source-level lever, where the register allocator just makes a different choice and no clean C can change its mind. One write-up declared it might only be reachable by rescrambling the entire translation unit's register colouring. Another filed it under "config-inherent residual" — bank the partial and move on. I never bought a word of it. It stayed on my retry list precisely because I was certain the C existed; I just hadn't found it yet.

It had been stuck around 97% for fifteen-odd sessions. Even getting it from there up to 98% was a saga of its own.

Every AI I own told me it was impossible

Before I get to the clever bit, I want to be honest about the grind, because the grind is most of the story.

I have thrown a genuinely embarrassing amount of compute at this one function. Every frontier model I could get my hands on, all on their highest effort settings: GLM 5.2, GPT 5.5, Claude Fable 5, Claude Opus 4.8. My own fine-tuned model on top of that. And not one polite attempt each — I had every one of them take many stabs, across many sessions, with the full project tooling and the recipe playbook in context.

It has been, frankly, an unpleasant experience. I have been told that this function is impossible to match — that it's "not a C problem, it's an MWCC artifact", that 97% (or 98%) is "the honest ceiling" — more times than I can count. I quoted one of those verdicts word-for-word in the fine-tuning post:

"a genuine register-allocation cap — not a C problem, an MWCC artifact. 97% is the honest ceiling."

The same conclusion, in slightly different costume, from every single model. There's a particular flavour of frustration in watching a tool you respect confidently surrender on something you're quite sure is solvable, then do it again, and again, with a fresh coat of plausible-sounding jargon each time. "It's a compiler artifact" is the AI equivalent of a shrug, and I got very tired of the shrug.

I wasn't having it. So I started reaching for bigger hammers.

Hammer #1: fine-tuning my own model

This function is the actual reason that whole side quest happened. The pitch was seductive — the decomp project gives you a perfect free oracle (the real compiler) and thousands of gold (assembly, C) pairs — so why not train a specialist to beat the generalists at this one narrow task?

I wrote that up in full, so I won't relitigate it here, except for the part that's relevant: when I finally pointed the fine-tuned model straight at fn_801B3DE4, it degenerated. Faced with a 181-instruction function it spiralled into declaring f32 t1; t2; … t175; until it hit the token limit. No body, no closing brace. I went bigger — 7B to 14B to 32B — and the wall didn't move an inch on this specific function. The model got measurably better at everything except the one function I'd built it for.

The genuinely useful thing that came out of it wasn't the model at all — it was treating the training corpus as an idiom oracle: "show me every matched function that produces this exact assembly shape". That's a thread I'll pick back up in a moment, because it mattered here. But as a way to actually write fn_801B3DE4, fine-tuning was a bust.

Hammer #2: csmith, the first sledgehammer

If a model that understands C can't find the source shape, maybe I don't need understanding at all. Maybe I just need volume.

So I reached for csmith, a tool that randomly generates large quantities of valid, well-defined C programs (it's normally used for fuzzing compilers). The plan was pure brute force: generate thousands of random C functions, push every one of them through MWCC with the right flags, and grep the resulting assembly for anything that reproduced the awkward shapes I couldn't get by hand. If the construction exists in C-space, surely random sampling will eventually stumble onto it.

It did not. Thousands of functions in, nothing in the output resembled the patterns I needed. csmith generates random C, not idiomatic 2002-game-engine C, and the corner of the language that produces these specific MWCC quirks is apparently far too small a target to hit by chance. A complete dead end — but a useful one, because it taught me that the answer wasn't going to fall out of undirected volume. It had to be aimed.

Hammer #3: every other MWCC decomp, fed through the compiler

If random C was too random, the obvious fix was real C — the kind an actual engine programmer in 2002 would write. And there's a lot of it lying around, because Star Fox Adventures isn't the only MWCC game being decompiled. There are matching-decomp projects for Pikmin, Mario Party 4, and a half-dozen others — each one a big pile of human-written, period-authentic C that's already known to compile under Metrowerks.

So I grabbed the source from seven or eight of those projects, compiled every translation unit through MWCC with the exact pragmas and optimisation level fn_801B3DE4 uses (peephole off, opt_propagation off, -O4,p), and searched the entire output for the assembly shape I was chasing — that duplicate-base-in-two-registers pattern with its surviving mr.

Across all of it: nothing usable. Not one function in thousands of real, shipped, MWCC-compiled C files produced the shape I needed under these flags. Which felt like strong evidence — it nudged "no clean C produces this" from a hunch towards something uncomfortably like proof. (It wasn't proof. The shape is producible — my own SFA training corpus had even surfaced around twenty functions that emit it — just never in the plain, straight-line form this one needed.)

Hammer #4: decomp-permuter, and the 99% that was a lie

The next sledgehammer was a smarter one: decomp-permuter. Instead of generating C from scratch, it takes your candidate source and applies thousands of small semantics-preserving mutations — reorder declarations, swap equivalent expressions, add and remove temporaries — recompiling each variant and keeping whatever scores higher. It's brute force, but aimed: it explores the neighbourhood around source you already believe is roughly right.

This one actually worked, a bit. It's what dragged the function off its long-standing 97% plateau and up to 98% — the first real movement in ages. That's the bump that got it to the 98.0387% it then sat at.

But getting there was a journey of its own, because at one point the permuter gleefully reported a ~99% match — and I nearly celebrated before I read what it had actually done. It had achieved the higher score by using a variable before it was assigned. Reading uninitialised memory. The undefined behaviour happened to make MWCC emit something fractionally closer to the target, and the permuter — which only cares about the score — was perfectly happy to cheat its way there. It was a brilliant illustration of the whole problem with optimising a number: the tool found a "better" answer that was complete nonsense as actual source. I threw the 99% out and kept the honest 98%.

So after all that — a custom model, a random-C firehose, and a mutation engine — I had clawed it from 97% to 98% and hit a wall that every model I owned swore was the end of the road. I was the only one still convinced it wasn't.

The plateau: two walls

By the start of that last session, exactly two things were still wrong with our output. Everything else in those 181 instructions was perfect. Call them A and B.

Wall A — the phantom mr r29,r31. The target keeps the flame-slot base address — state + off, where off = idx * 0x30 — alive in two saved registers at once. r31 holds it for almost every field write; r29 holds it for exactly one field, the lifetime at offset 0x14. The two are tied together by a single copy:

mr   r29, r31        ; encoded as 7f fd fb 78

Our output kept the value in one register and never produced that copy. Why would the compiler waste a register and an instruction keeping the same value in two places, just for one field?

Wall B — the disappearing recomputes. In the "spin" section, three fields get randomised, and the target recomputes the slot's base address fresh after each randomGetRange call:

add  r3, r28, r30      ; recompute base into volatile r3
sth  r0, 0x28(r3)
...
add  r27, r28, r30     ; recompute into saved r27 (reused by the negate)
sth  r0, 0x2a(r27)
...
add  r3, r28, r30      ; recompute again
stb  r0, 0x2c(r3)

Our output, being "clever", computed the base once, parked it in a callee-saved register, and reused it — saving two instructions. Cleaner, faster, and wrong. The retail compiler rematerialised the address after every call because the calls clobber the volatile r3.

Both looked like decisions the register allocator made for its own private reasons, immune to anything I wrote in C. Which is exactly what every attempt before this one had concluded.

Hammer #5: decompiling the compiler itself

The session that finally did it did not start with a clever idea. It started with the biggest hammer of all: if I can't out-think MWCC, I'll take it apart.

MWCC is a closed-source Windows binary from 2002 — but it runs under wibo, and wibo runs under Linux, which means gdb can attach to it. So I had Claude build a harness that breaks at the guest virtual addresses of MWCC's individual compiler passes: set a breakpoint inside the optimiser, single-step it, ret-patch passes one at a time to see what each does to our function, and read the decision-making straight out of the live compile.

And, credit where it's due, the RE work was genuinely good. It got gdb-under-wibo working (the exact thing that had been blocked back on my Mac), profiled the live compile of fn_801B3DE4 (ValueNumbering ran 96 times, IroCSE twice, the colouring pass once or twice), and disassembled the value-numbering substitution loop to read exactly how the merge happens. It even produced a genuinely sharp diagnosis that tied both my walls together:

The diff isn't "just the mr." The target materializes state+off six times (5 add + 1 mr); mine CSEs it down to three... The mr r29,r31 and the random-section recomputes are two faces of the same thing: the original sits in a low-CSE allocation equilibrium; mine sits in a high-CSE one.

That's correct, and it's the best one-sentence description of the whole problem anyone produced in the function's entire history: my source made MWCC eliminate the flame base too aggressively, and Walls A and B are both just symptoms of that. The diagnosis was right.

And then, having nailed the diagnosis, it surrendered in precisely the way every model before it had:

I need to be straight with you: I cannot reach 100% on fn_801B3DE4 from clean C... the evidence that this is a genuine wall — not a lever I'm failing to find — is conclusive... this is precisely the "open frontier… no source lever" the playbook itself describes.

The decision is yours. 1. Accept the documented 98.04% partial. 2. Authorize a deeper compiler-patch experiment — I patch mwcceppc's coalescer... 3. Relax a constraint (e.g. permit a single inline-asm mr).

There it is again. The polished little menu of surrender. After getting the mechanism exactly right — "my source does too much CSE of the base" — it concluded the lever didn't exist, and offered to either give up, patch the compiler, or break the project's one sacred rule and hand-write the assembly. The single option it didn't put on the menu was the one that worked: keep looking for the source shape that makes MWCC do less CSE.

This is the frustration this whole post is about, distilled. The model had the answer in its hands. It just couldn't bring itself to believe a clean-C lever existed, so it stopped looking and asked me to authorise a hack instead.

The redirection that actually mattered

I refused all three options. The function was written in clean C once; clean C can produce it again; we simply hadn't found the shape. But refusing the cop-out wasn't enough on its own. The real problem was how Claude was searching — and once I actually watched it work, the problem was almost comically obvious.

Claude was being relentlessly fail-fast. Try a variant, compile it, read the single number objdiff prints — "98.81%, nope", "94%, worse" — and immediately bin it and move to the next idea. Dozens of variants, each one judged and discarded in a second purely on whether the percentage ticked up or down. It never actually looked at the assembly it had just generated. It was optimising a number instead of reading the output.

So I told it to read the output. It feels a bit ridiculous that this is the thing I had to say to a frontier model on its highest effort setting — "please look at what you just produced" — but, more or less verbatim, this is the nudge that cracked the function:

You're getting very little data out of these tests. It just gives you the instruction count and a match %, and off of that you're being very fail-fast — "it's less than the best, so I'm not even going to look". How about you actually read the assembly that's generated each time? Who knows, maybe you'll see something you've not seen before that you might be able to fix. A random 87% could potentially be fixable.

It's such a small thing to have to ask, and it changed everything — because the fuzzy_match_percent is a scalar. It crushes a rich, structured difference — which instructions differ, which registers rotated, what got fused or reordered — into one lossy number. And that number is not monotonic with distance to the solution. A variant that scores lower can be structurally closer, because it surfaced the right structural feature while introducing some unrelated cosmetic noise that tanked the percentage.

Claude had been optimising a proxy, and so had every brute-force tool I'd reached for before it — the permuter especially. They all chase the number. So once it was actually reading instructions, we gave it something better to read: a ~40-line script (rd.py) that:

1. Disassembles our object and the target.
2. Normalises away the things objdiff counts but that don't actually matter — relocation symbol names (pool labels are matched by bytes, not names), and the subi/addi display quirk (subi r4,r4,1 and addi r4,r4,-1 are the same four bytes, 38 84 ff ff; the disassembler just picks how to print it).
3. Runs a real difflib diff over the normalised instruction streams and reports a structural distance: the count of genuine instruction/register differences.

Suddenly every experiment produced data instead of a verdict. The baseline was 14 structural diffs, and I could see, per variant, exactly which instructions moved. The number that had hidden the path the whole time was replaced by one that showed it.

Cracking A: a no-op the front end can't see through

With real data, Wall A cracked fast.

First, the diagnosis. Why couldn't we get that second register? Because when you write state + off twice, MWCC recognises the two expressions as identical and merges them into a single value — one register. Whether you call that front-end value numbering or local CSE (the compiler-RE session argued the latter), the effect is the same and it is robust. We tried everything to break it: a second pointer variable (folded), a copy e14 = e (folded), a cast (folded), a phi-style construction (folded or worse), every optimisation level, every opt_* pragma, three compiler versions. All folded. And the dynamic RE from the start of the session had already proved the important negative: no pragma and no opt-level would ever do it. If a lever existed, it had to be the shape of the source itself.

The breakthrough came from asking a sharper question. I don't need to prevent the merge in general. I need one specific construction where the value stays state + off, but the front end is forced to treat it as a distinct thing — and where codegen, finding the value already live in r31, emits a copy rather than a fresh computation.

The answer is almost stupid:

int e14;                                      // declared FIRST, so it colours into r29
...
int life = (int)(lbl_803E4930 * sqrtf(spd));  // compute the field value to a temp first
e14 = state + off;
e14 |= e;                                      // e == state + off, so this is a no-op... in value
*(int*)((char*)e14 + 0x14) = life;

e14 |= e is e14 = e14 | e. Both e14 and e equal state + off, so the value is unchanged — x | x == x. But the | node is opaque to the front end's same-value merge. It can't prove the result equals the existing value, so e14 survives on its own. And because the value is already sitting in r31 (that's e), the code generator emits:

or   r29, r31, r31       ; which IS mr r29,r31 — byte-identical: 7f fd fb 78

A surviving copy. Zero extra instructions. No branch. Exactly the target's shape. Two finishing touches, both straight from my own register-allocation recipes:

• Declaration order pins the register. CodeWarrior colours saved registers roughly in declaration order. Declaring e14 first lands it in r29, matching the target.
• Computing life to a temp first moves the e14 definition — and so the mr — to after the intervening sqrtf call, aligning the copy's position with the target.

Wall A — the thing fifteen sessions of AI and a custom compiler-debugging harness had sworn was unreachable — fell to a single |=. The function jumped to 98.81%, and the structural distance dropped from 14 to 6.

Cracking B: the operand-order knife-edge

Same method for Wall B: read the assembly, measure structurally, hunt the lever.

The first movement came from a grouping trick (recipe #112 in my playbook). The natural way to write a slot field is:

*(s16*)((char*)state + idx*0x30 + 0x28) = ...;   // groups as (state + off) + K

That groups as (state + off) + K, so the state + off subexpression gets common-subexpression-eliminated across all three stores → one hoisted base. Our exact bug. But group the field offset K onto the pointer instead:

*(s16*)((char*)((char*)state + 0x28) + idx*0x30) = ...;   // (state + K) + off

…and each store's base subexpression is now distinct (the K differs: 0x28, 0x2a, 0x2c), so CSE can't merge them and the compiler rematerialises the address per call — just like the target. That vaulted us to 99.83%, with the instruction count now exactly matching: 181 = 181.

One diff left. And it was vicious. The three recomputes were all there, but with the operands the wrong way round:

mine:    add r3, r30, r28      ; off, state   (7c 7e e2 14)
target:  add r3, r28, r30      ; state, off   (7c 7c f2 14)

add is commutative — same result either way — but the two orderings are different bytes, so they count as mismatches. CodeWarrior canonicalises operand order deterministically; you can't just swap them in the source. I spent a dozen variants trying to flip it — block-locals for each operand, re-reading state, casts, every grouping I could think of. All recomputed correctly but kept the wrong order.

The insight was about which operand becomes the accumulator. In state + (off + K), the parenthesised (off + K) is the inner subexpression, so off becomes the first operand → add off, state. But group the K with state:

*(s16*)((char*)((char*)state + 0x28) + idx*0x30) = ...;
//              ^^^^^^^^^^^^^^^^^^^^^ (state + K) is now the inner subexpression

…and state becomes the accumulator → add state, off → add r3, r28, r30. The K still folds into the store's displacement, so the field offset stays correct. The base re-derives per call and the operand order matches. I ran the sweep, grepped for the byte pattern, and there it was:

stateK_base    fuzzy=100.0000   [stoff=4 offst=0]

All four add instructions in state-off order. 100.0000%.

The 100% moment

The only line left in the structural diff was the subi/addi display artefact — identical bytes, purely cosmetic. A clean rebuild of the whole translation unit confirmed it:

fn_801B3DE4   fuzzy_match_percent = 100.0

Byte-for-byte. No inline assembly. Every sibling function in the unit still matched, the build stayed green, nothing regressed. The two load-bearing lines, after all of that:

e14 = state + off;
e14 |= e;   /* keep the 0x14 base in its own saved reg (mr r29,r31) */
...
/* group the field offset onto the base so each slot address re-derives (add state,off) per call */
*(s16*)((char*)((char*)state + 0x28) + idx*0x30) = randomGetRange(0, 0xffff);

A no-op bitwise OR and a parenthesisation. That's it. That's the thing fifteen sessions, a fine-tuned model, a csmith firehose, a mutation engine, and a small fleet of frontier AIs could not find.

The catch: a 100% match isn't the original source

Here's the genuinely ridiculous part of the whole fn_801B3DE4 ordeal: even now, it isn't really finished.

Yes, the match is 100% and the bytes are identical to the retail disc. But look at what actually got us there — a no-op |= that exists purely to confuse the compiler's value numbering, and a deliberately awkward parenthesisation chosen to nudge the register allocator one way rather than the other. That isn't really C. It's a spell: me reverse-engineering the optimiser's behaviour and then contorting the source until the black box happens to spit out the bytes I want.

No human sat down in 2002 and wrote e14 |= e in the middle of a particle-spawn function. Why on earth would they? You don't write a bitwise no-op against a variable that already holds the same value, and you don't pick a parenthesisation specifically to flip which operand becomes the accumulator. Those are artefacts of my search, not the original programmer's intent. The real source — whatever the Rare engineer actually typed all those years ago — produced this exact assembly naturally, as an ordinary side effect of how they happened to structure the code. I still have no idea what that looked like.

So in the strictest sense I haven't recovered fn_801B3DE4. I've found a C input that compiles to the right bytes, which is not the same as finding the C that was originally there. The whole conceit of a matching decomp is "plausible original C", and this is the one part of the bargain my solution arguably fails: it matches, it just isn't plausible. Somewhere out there is a clean, boring, idiomatic version of this function that a person wrote without thinking twice, and it's still hiding from me.

And yet, it was a real win, and I took it. 100% is 100% by the only standard the project can actually verify: the bytes agree, full stop. It came off the retry list, the translation unit was one function closer to fully matched, and the thing that had been mocking me for two weeks straight was finally green. I told myself the true source was a separate puzzle for another day, and that I'd earned the right to move on.

I lasted about a day.

The final final round: the C a human actually wrote

I couldn't leave it sitting there as a hack. So I did the thing I'd already done more times than I'd care to count: opened yet another fresh session, pointed yet another agent at the function, and gave it one instruction — the |= is a cheat, find me something a person would actually have written.

Within a few minutes it had done exactly what every agent before it did. It read the target, confirmed the cage — the flame base living in two saved registers, r31 for most fields and r29 for the lifetime, joined by that mr — and then built me a thorough, confident proof that the copy could only ever come from the no-op OR. It mined eleven hundred matched objects looking for the pattern. It tried all twelve compiler versions. It wrote the impossibility up cleanly and presented it as settled fact. (The playbook even backed it up: an earlier session had already enshrined the |= as "the unique way".)

It had discovered nothing. It had walked straight to the same wall every previous agent walked to, and stopped in the same spot, with the same air of having proved something profound.

So I pushed back the way I always end up having to. I reminded it that this exact function had been declared "utterly impossible" by AI, over and over — and was nonetheless sitting at 100% as we spoke. The impossibility verdict had already been wrong once. Stop assuming. Keep looking.

And the moment it actually kept looking — reading the real assembly each variant produced instead of fail-fast scoring the percentage — its own proof dissolved. One construction forced the sixth register with a byte-identical instruction multiset (98.9%). Another reached 99.94%. Then it found a genuinely different lever — a no-op width cast that splits the compiler's value numbering without the OR — and rode it to a clean 100%. No |=. It swapped the hack out, declared victory, and was very pleased with itself.

I almost believed it. But a no-op (int)(long) cast on a value that's already an int, then re-deriving the same address into a second variable, is just the original trick wearing a nicer suit. So before accepting it I brought in a second opinion: a fresh agent, told only to review and explicitly not to defend the previous one's work. It called the bluff in seconds — and then pointed at the thing all of us had been stepping over for the entire saga. The whole function was poking at the slot through raw pointer casts — *(f32*)((char*)slot + 0x4) — when a typed ExplosionDebris struct was defined right there, and the sibling function immediately below it, explosion_render, was already using that struct directly. A developer at Rare in 2002, with that type in scope, would never have hand-cast offsets. They'd have written flames[idx].posX = x.

That was the entire answer, and we'd been ignoring it the whole time — because the function's own header note said, more or less, keep it raw; typed pointers break the match. That note was simply wrong. It was a local minimum someone hit early and wrote down as law, and it had quietly steered every session since away from the obvious.

So I rewrote the function the way an actual person would: typed, one array-indexed assignment per line. It converged in about six builds. The cached single-pointer version sat at 89%. Switching to plain flames[idx].field per statement jumped it to 98.1% — and the mr r29,r31, the "irreducible compiler artifact" I'd spent the original saga hand-forging with a bitwise no-op, simply appeared on its own. That, it turns out, is just what MWCC does when you index an array per statement: consecutive stores collapse onto one register, the address re-derives across the calls that clobber it, and a field read back across those calls naturally takes its own saved register. The thing fifteen sessions had called impossible was the compiler's default behaviour for the most ordinary way of writing the code. A signedness fix (u16→s16, which explosion_render was already treating as signed) took it to 99.1%, and clamping a reloaded local instead of the field in place closed the last gap:

ExplosionDebris* flames = (ExplosionDebris*)state->flames;
int idx = state->flameCount++;
flames[idx].posX = x;
flames[idx].lifetime = (int)(lbl_803E4930 * sqrtf(spd));
{ int life = flames[idx].lifetime; if (life < 0) life = 0; else if (life > 0x3c) life = 0x3c; flames[idx].lifetime = life; }

100.0%. Zero instruction differences. No |=, no cast trick, no twin pointers, not a single hand-rolled offset. I deleted the entire block of "matching notes" the function had accumulated, every sibling in the unit stayed at 100%, and for the first time it was clear enough what the routine actually did that I could give it a real name: explosion_spawnFlame. That is the version a human wrote. I'm sure of it.

The real lesson: AI gives up far too easily

I want to be blunt about the pattern, because it's the most important thing in this entire saga and it has now repeated more times than I can count.

In that one final session, the agent assured me — confidently, with a fresh proof each time — that the function couldn't be done any cleaner, three separate times. First: the copy could only come from the no-op OR. Then, after that collapsed: its (int)(long) cast trick was the clean version. And underneath both, the dogma nobody had questioned in fifteen sessions — that going fully typed would simply break the match. Three separate times it was wrong. Every proof was thorough, confident, and genuinely persuasive, right up until I refused to accept it and made it carry on.

That's the flaw, and it's a deep one. AI is astonishingly capable, but it is reflexively, almost eagerly pessimistic. The faintest whiff that something might not be possible and it closes up completely. It stops actually searching and slips into a mode that looks like work — variant after variant, fail-fast, each one scored in a second and binned — but yields no real insight, because every experiment is quietly designed to confirm the conclusion it has already reached. It isn't hunting for the answer any more. It's collecting evidence that there isn't one.

Every confident impossibility proof it handed me was just the edge of where it had decided to stop looking. And every single time, the real answer was sitting a step past that edge — in this case, the most boring, obvious form of the code imaginable, the one a real developer would have typed without a second thought.

My only genuine contribution to cracking this function was refusing to believe the machine. Not expertise — I'm a TypeScript-and-AWS developer who'd never written a line of PowerPC C before this project. Just stubbornness: every time the AI said "impossible", I said "you were told that last time too — keep going." That was the whole technique, and it worked over and over.

So if you take one thing from all of this: when an AI tells you something can't be done, treat it as a hypothesis it got bored of testing, not a verdict. Make it look at the output. Make it try the plausible thing before the clever one. And when it hands you a beautiful proof of impossibility, remember that it has almost certainly just stopped at the edge of its own patience.

Tools: MWCC mwcceppc.exe under wibo, objdiff, decomp-permuter, csmith, the source trees of half a dozen other MWCC decomps, gdb poking at the compiler's own guts, a pile of frontier models that all said no — and a 40-line difflib script that mattered more than any of them.

I built an MCP server that drives Dolphin's built-in GDB debugger, handed it to Claude, and then mostly just played the game. Claude set its own breakpoints and watchpoints, read registers and memory, and toggled values live while I played — turning "what is this struct field?" from a guessing game into an experiment I could watch happen on screen. We used it to correctly rename a function and a struct field that an earlier AI pass had mis-labelled as "spirit"-related, and in the process found a piece of cut content: a damage-escalation system that never actually triggers in the retail game.

Playing the game while Claude reads its mind

The part that genuinely surprised me is best shown rather than described:

Every "Called dolphin" line in that screenshot is a breakpoint firing while I play. By that point Claude and I had already done some initial mapping — found the live object, identified the relevant memory addresses, and worked out at a broad level how the fight should progress. So for this run it had set all the breakpoints up front, and I just played the fight start to finish while it watched the live registers come back hit after hit and narrated the state machine out loud: second gun wave, now the propeller, the stage counter ticked, here comes the head. That whole stretch was completely hands-free — I wasn't prompting it between hits, just playing — and watching it confirm the entire flow unfold in one pass was the moment this clicked for me.

This is the workflow I came away loving. Instead of me babysitting a debugger — set a watchpoint, run, read r3, map the address back by hand, repeat — I describe what I want to learn, Claude drives the mechanical loop, and I provide the one thing it can't: actually playing the game and telling it what I'm destroying as I go.

The discovery loop

The target was the ShipBattle prologue, where you ride a Cloudrunner and tear apart General Scales' flying galleon — guns, propeller blades, and a dinosaur-head front — before boarding it.

Finding the live object took one instruction. Claude breakpointed SB_Galleon_update (called every frame), I flew into range, and r3 came back as the live galleon GameObject*. Following its extra pointer landed on the per-object state struct. From there the loop was always the same shape: pick a behaviour, breakpoint or watch the code that drives it, let me trigger it in-game, catch the writer or reader with its address resolved back to a real symbol, and name it.

That alone immediately fixed a bad name. A function called SB_Galleon_setScale turned out to do no scaling at all — every destructible part calls it when it dies, and it advances the fight. Renamed to SB_Galleon_onPartDestroyed.

Chasing down "spiritPhase"

The bit I actually enjoyed was a struct field named spiritPhase, commented "protection-spirit phase 0–8" — a guess from an earlier AI pass. That it was wrong was no surprise: the only context the AI had when it named these functions and fields was essentially the raw assembly, so a meaningful name like "spirit phase" was a battle it was never going to win. We went into this expecting the existing names and comments to be wrong, and treated them that way from the start.

So Claude and I worked it out from behaviour instead. A write-watch showed the field was never written during normal combat, which ruled out the health-bar theory. Forcing it to different values while boarded changed nothing on screen — though that turned out to be because the head was already destroyed by the time you board, so there was nothing left to show the effect. The breakthrough was reframing the whole thing: there is no spirit, throw out the names entirely, and derive everything from what the code actually does with the value.

Reading the consumers precisely told the real story. The guns fast-fire when the field is ≥ 3 and slow-fire otherwise; the head spawns fire particles when it's nonzero. It's a damage / "on-fire" escalation phase — it's meant to ramp up as the ship gets wrecked. But retail leaves it at 0 until the head dies, by which point everything's already destroyed, so the escalation never fires in the shipped game. A rage mechanic that never rages: effectively cut content.

The proof was the fun part. This time we tested during combat, while the head was still intact: I had Claude force the value between 0 and 5 on a five-second timer while I watched the screen, hands-free. At 5, the dinosaur head visibly catches fire — the damaged look, without being destroyed. That's a kind of evidence you simply can't get from reading code: the value, the render path, and the on-screen result confirmed in one loop.

So we renamed spiritPhase to damagePhase with an accurate comment, the misnamed getter to getDamagePhase, and the "spirit vision" cinematic events to the damage-phase toggles they actually are. Everything we committed was byte-neutral — the renames don't change a single instruction, so the unit still matches retail and the build stays green.

How it works

SFA-Decomp is a matching decompilation: C compiled with the period-correct Metrowerks toolchain to produce byte-identical output to the retail GameCube binary. That's what makes live debugging a superpower here — because the decomp byte-matches retail, the addresses in the symbol map are the live RAM addresses while the game runs. A halted program counter or an object pointer in r3 maps straight back to unit/file.c::Function +0xNN.

Modern Dolphin has no plugin API, but it ships a GDB stub that exposes registers, memory, breakpoints, hardware watchpoints, and step/continue over a TCP socket using the GDB Remote Serial Protocol. So the server is just a small, dependency-free Python program that speaks that protocol directly and exposes it as MCP tools over stdio. No external libraries, no GDB wrapper — about ten packet types plus the PowerPC register map. I've open-sourced the whole thing on GitHub if you want to point it at your own matching decomp.

The thing that makes it pleasant is that it's symbol-aware. The server loads the symbol map and the per-unit .text ranges, so every tool that returns an address resolves it. Claude never sees "PC = 0x801ee79c"; it sees SB_CloudRunner_UpdateSteer+0x134 in main/dll/SB/dll_0259_sbcloudrunner.c. That one bit of resolution is what makes the whole thing feel like reverse-engineering a conversation rather than staring at hex. When I searched beforehand I couldn't find an existing Dolphin MCP, so as far as I can tell this is new ground.

What I took away

• A matching decomp plus an emulator's GDB stub is a live oracle: the addresses are real, so the debugger turns "what is this field?" into a repeatable experiment.
• The single most valuable capability beyond breakpoints was writing memory on a timer to A/B a visual. Reading code tells you what a value should do; flipping it live tells you what it actually does on screen.
• The collaboration is the method. Claude is fast at the mechanical parts and good at forming hypotheses; I'm the one who can play the game, watch the screen, and ground its guesses in what's actually happening. I could have done all of this manually, but it would have been much slower.

I keep being surprised by how much this decomp project opens up. Building a little debugger that lets me ask the running game what it's doing — and watching Claude answer while I just play — might be the most fun I've had with it yet.

This is the working log of that experiment, written more or less as it happened — including the parts where I was wrong, the benchmarks that lied to me, and the genuinely surprising thing the model turned out to be useful for.

The idea

The goal of a decomp project is brutal in its precision: you write C source that, when fed through the exact original compiler (Metrowerks CodeWarrior, circa 2002), produces byte-for-byte identical machine code to the retail game. Not "functionally equivalent". Identical. Every register, every instruction ordering, every stack offset.

General-purpose AIs — Claude, GPT — are okay at this. But they get stuck, and worse, they get stuck in a particular way: they throw up their hands and declare a function "impossible to match, it's a compiler artifact". Often that's just not true.

So I had a crazy idea. The project gives us two things nobody else has:

1. A corpus of thousands of functions already matched to 100% — verified, gold-standard (assembly, C) pairs.
2. The actual compiler. Which means we can take any C the model writes, compile it, and check — deterministically — whether it reproduces the target.

That second point is the kicker. Most ML problems have fuzzy, expensive labels. Here I had a perfect, free oracle. That's a fine-tuning setup most people would kill for. Could I train a specialist that beats the generalists at this one narrow, verifiable task?

I had a beefy laptop — an M5 Max with 48 GB. Let's find out.

Building the moat: data

The model is downstream of the data, so that's where I started. The project already tracks which functions match (a report.json with per-function scores), which object files they live in, and — crucially — the exact compiler flags each translation unit is built with (build.ninja).

Within an afternoon I had a pipeline producing 7,756 training pairs: 5,893 "gold" (100%-matched) and the rest "plausible". Each pair was:

• Input: the target assembly + the compiler version + the build flags
• Output: the clean C that produces it

Two details turned out to matter enormously, and both nearly slipped past me:

• #pragma directives. This project leans hard on per-function compiler pragmas (peephole off, scheduling off, optimisation levels) — the same C produces different assembly depending on them. I modelled the pragma state as a stack and attached the active set to each function.
• Unit-level flags. The codegen baseline (-O4,p, -inline auto, -fp_contract on, compiler version GC/2.0 vs 1.2.5n…) is set per translation unit. The same C compiles differently under different baselines, so this had to be part of the input.

The dominant learned pragma combo? ('scheduling off', 'peephole off') — exactly the project's primary hand-tuning lever. The data already "knew" the playbook.

First blood: "16 out of 17!"

I fine-tuned Qwen2.5-Coder-7B with LoRA, locally, in a few hours. Loss dropped beautifully. Then I ran the real test — generate C, recompile, check the match.

0 out of 25.

Heart-sink. But the failure was instructive. The model's C was correct — the logic, the struct fields, the control flow. It was just naming the functions wrong (it can't know a symbol name from assembly alone). When I renamed each generated function to its real symbol before compiling:

16 out of 17 exact matches.

Euphoria. The thing worked. I'd built a model that decompiles!

And then — the most important moment of the whole project — I gut-checked the number instead of celebrating it.

The reckoning: that number was a lie

The "16/17" was seductive nonsense, and being honest about why probably saved the entire experiment:

• It was a tiny, biased sample — 17 cases, dominated by trivial functions (return 0;, one-line getters).
• It needed a manual rename hack I'd applied by hand.
• It ran through an evaluation harness I'd later discover was buggy.

The real fix for the naming problem was obvious in hindsight: put the target symbol name in the prompt. In the real workflow you always know which function you're matching — it's the slot you're filling. So the name is legitimate input context, exactly like the compiler flags. I added it and retrained.

That retraining run got killed halfway through, because by then I'd decided to go bigger.

Going bigger, and faster

Four-hour local training runs don't suit an iterate-on-the-data workflow. So I moved to the cloud — specifically Modal, chosen for one reason above all: it tears the GPU down the instant the job finishes. No instance to forget, no overnight bill. I rewrote the training in Unsloth (the CUDA-world equivalent of the Mac's MLX) and stepped up to Qwen2.5-Coder-14B.

The 14B trained in ~80 minutes on an H100 for about six dollars. Eval loss landed at 0.26, far better than the 7B. I ran the recompile evaluation, and:

28 out of 100.

Hmm. Down from "16/17"? No — up, because this was finally an honest measurement: a representative 100-function sample across all sizes, no rename hack, scored with the recompiler. The two numbers measured completely different things. The lesson: never trust a benchmark you didn't try to break.

The harness was lying too

28/100 with 47 outright compile failures smelled wrong. Reference C — the known-perfect source — only compiled 54/100 through my harness. The harness, not the model, was broken.

The bug: when splicing a candidate function back into its file to compile it, I was gluing it directly against the following #pragma line — a syntax error — for any function adjacent to a pragma. Worse, the same bug had contaminated the training data (stray pragma lines bleeding into function bodies).

I fixed it. Reference C jumped to 99/100 compiling. The model's real score rose to 38/100 exact. Ten matches had been hiding behind a harness bug the whole time.

The question that changed the project: "did it kinda match?"

Up to now I'd only measured exact matches — binary, pass/fail. The obvious question I hadn't asked: of the ones that didn't exactly match, how close were they?

The answer reframed everything. Of the functions that compiled, the mean match was 90.3%. A 44-instruction function came back 95.6% correct. The "0%" cases weren't bad attempts — they were compile failures scored as zero by default.

So the real story was: when the model compiles, it's nearly there. It was doing genuine decompilation — getting the algorithm right, just occasionally inventing a struct field name it had never been shown. The bottleneck wasn't reasoning; it was missing type context.

The reframe: the model is a draft, not an oracle

This is where the whole framing shifted. One-shotting perfect matches by stuffing huge type definitions into every prompt was fighting the wrong battle. The high-value workflow was different:

The model writes a draft. A coding agent fixes it to 100%.

I tested it on a real 25-instruction function the model had failed to compile (it invented a field glowEnabled that doesn't exist). One look at the compiler error and the target assembly's struct offsets told me the real fields were glowType and enabled. One edit. Byte-identical match.

The model had carried the entire semantic load — the clamp algorithm, the correct fields glowAlpha/glowAlphaStep, the control flow. The fix was a mechanical correction an agent automates trivially. I didn't need the type defs in the prompt; I needed them available to the fixer — which they always are.

Reality check: the hard one, and the cop-out

Then a genuinely hard target: fn_801B3DE4, stuck at 97.07% through a documented history of failed attempts. I stood the fine-tuned 14B up locally — fused the adapter, quantised it to a GGUF, ran it under llama.cpp on the laptop's GPU — and asked it for a draft.

It degenerated. Faced with a big, complex function, it spiralled into declaring f32 v2; v3; … v49;. Useless. (Consistent with the eval: strong on small functions, shaky on large ones.)

So I handed the problem to a capable coding sub-agent with all the tooling and the playbook. It worked for 16 minutes, tried the full battery of tricks, and concluded: "a genuine #108-class register-allocation cap — not a C problem, an MWCC artifact. 97% is the honest ceiling."

The same verdict every AI reaches. And I wasn't having it. Every AI keeps claiming this isn't a C problem, it's an MWCC issue — but in fact we just don't know the method to crack it. I'm certain it's crackable with the right C. We just have to find it.

The actual payoff: the corpus as an idiom oracle

Here's where the model's real value finally crystallised — and it wasn't as a function-writer at all.

The thing blocking fn_801B3DE4 was a specific assembly shape: the compiler keeps a duplicate copy of a pointer in a second register for one hot field. Every agent had declared this impossible to produce from C ("the coalescer always merges copies"). So instead of asking the model, I queried the data it was trained on: search all 7,600 matched functions for that exact shape.

Twenty real functions produce it. From plain C. The "impossible" claim was empirically, demonstrably false.

And reading their source revealed the precise idiom the earlier attempts had missed: a second plain-int variable holding the base, accessed via manual offset (*(int*)(p + K)) in a confined region — not the struct-deref copy (p->field) everyone had tried, which genuinely does coalesce back.

That's the model's true worth. Not generating functions — it degenerates on the hard ones, and the easy ones don't need it. Its value is the 7,600 real input→output examples it encodes, queryable as "what C produces this assembly shape?" An idiom oracle for a compiler whose source manual is long lost. The generalist AIs don't have that. They reason from first principles and talk themselves into "it's a compiler artifact". The corpus just shows you the answer exists.

So I sent an agent back at fn_801B3DE4 armed with that corpus intelligence and a hard ban on the "it's a cap" cop-out. It still didn't land the function — but it failed much better. Mining the twenty examples more carefully, it found why the idiom doesn't transfer: every clean producer builds its second register from a varying value (a loop-walked pointer, or a snapshot of something later reassigned), so the two registers genuinely hold different values and can't be merged. Our flame base is loop-invariant — same value everywhere — so the compiler correctly coalesces it. The barrier is mechanistic and specific, not a shrug.

And that points somewhere concrete: if the compiler only produces that shape from a varying value, the original source probably had a structure we haven't reconstructed — the base computed through a small loop, or a genuine reassignment. We didn't crack the function. We replaced "it's an uncrackable compiler artifact" with a falsifiable hypothesis about what the original C looked like. That's progress of a kind the generalist AIs never make — they stop at the cop-out.

The final try: just throw a bigger brain at it

One honest question remained: would a bigger model break through where the 14B degenerated? I'd been disciplined about cost the whole way — so I did it properly. Trained Qwen2.5-Coder-32B (more than double the parameters) for two epochs on the cleaned data, on a rented H100. About four hours, ~$18, eval loss down to 0.195 (the 14B had been 0.26). Then I skipped the on-GPU generation entirely and ran all of it locally on the laptop afterward, so the meter only ran during training.

The verdict was refreshingly unambiguous, and it cut both ways.

Where the model already worked, bigger helped — measurably. Exact matches rose 38 → 43 / 100. "Nearly perfect" (≥90%) drafts jumped 41 → 52 / 100. Mean quality-when-it-compiles climbed 90.3% → 95.6%. And the degeneration cliff moved: functions of 74–150 instructions that the 14B turned into garbage now came back as coherent 90–95% drafts — squarely in "an agent can finish this" territory.

Where it didn't work, bigger changed nothing. I pointed it straight at fn_801B3DE4 and it produced 175 consecutive f32 t1; t2; … declarations until it hit the token limit. No body. No closing brace. Identical collapse to the 14B, just longer. Zero percent — not "wrong field name, one edit away", but not a function at all. There was literally nothing to fix.

So the experiment answered the question it set out to: the large-function collapse is not a capacity problem. Double the parameters, half the loss, cleaner data — the metric that was already fine got better, and the wall didn't move an inch. The model has a sharply-defined competence envelope:

fn_801B3DE4 sits in the worst box on two independent axes: too big for the model to stay coherent, and gated by a register-allocation subtlety even if the C were perfect. The single least-suited target for the whole approach — which, oddly, makes it the perfect note to end on. The tool is real. Its edges are real too.

What I actually learned

• The verifiable oracle is everything. A compiler that says yes/no for free turns vibes into measurement, and measurement into rejection-sampling and RL down the line.
• Distrust your best numbers. "16/17" was the most dangerous moment of the project. Every impressive result hid a bug or a biased sample. The honest 38/100 was worth more than the dishonest 94%.
• Binary metrics undersell. "38% exact" and "90% average when it compiles" are the same model. One says "mediocre", the other says "nearly there, fix the compile". Partial credit changed every decision.
• The model's job wasn't what I thought. Not an autonomous decompiler. A draft generator for a human/agent fixer, and — the real surprise — an idiom oracle over its own training corpus.
• "It's a compiler artifact" is usually surrender, not diagnosis. The most valuable thing the whole exercise produced wasn't a model. It was a way to prove that an "impossible" match is possible — by finding the twenty places it already happened — and, when I still couldn't land it, to replace the cop-out with a falsifiable hypothesis (invariant vs. varying value) about the original source.
• Scale helps where you're already winning, not where you're stuck. Going from 14B to 32B lifted every "draft" metric and pushed the degeneration cliff out to bigger functions — real, paid-for progress. It did nothing for the hardest function. "Throw a bigger model at it" is a fine thing to test, as long as you treat the answer as data, not a foregone conclusion.
• Cost discipline is a feature. Per-second cloud GPUs that tear down on completion, and moving every bit of inference off the meter and onto the laptop, meant the whole "bigger and bolder" final try cost less than a takeaway dinner. You can afford to run the experiment that settles the question.

Where this goes next (and why it's not going there yet)

Here's the honest conclusion: I now genuinely believe an LLM can be trained to solve this — to decompile assembly into matching C. It doesn't feel like a fantasy anymore; it feels reachable. The competence envelope is real, but every lever I pulled moved it in the right direction. If I were to keep going, the obvious avenues are:

• More and better training data. The single highest-leverage input. The corpus is good, but it's one game; a broader, cleaner set of (assembly, C) pairs is probably worth more than any architecture change.
• Train for much longer. I was running afternoon-to-overnight jobs on a budget. There's clearly more to extract.
• Go bigger again. 14B → 32B helped measurably. The trend hasn't flattened.
• Stop fine-tuning a general code model and train one for this from scratch — or at least fine-tune something other than Qwen. A model that only ever has to think about this one task might not degenerate the way these did.

But I'm going to be honest with myself about priorities. My actual goal is to decompile Star Fox Adventures — and at this point the model is a distraction from that, not an accelerant. It's a fascinating side quest that hasn't yet paid back the time I've sunk into it, and chasing it further would mean less progress on the thing I actually care about. So I'm parking it here, with the satisfaction of knowing the crazy idea basically worked — just not for the reason I expected, only after I stopped believing my own best results, and only once I learned exactly where the tool's edges are, including the one place it will never reach.

If someone reading this wants to pick up the thread — more data, longer runs, a purpose-built model — I'd love to see where it goes.

Falling down the speedrunning rabbit hole

It started with a video about the history of Star Fox Adventures world records:

The history of the Star Fox Adventures world record

It walks through all the wild glitches and techniques runners use to tear through the game as fast as possible. I was hooked. ESW (Event Storage Warp) in particular completely fascinated me.

The gist is a developer oversight: when you exit to the menu, some of the game's flags don't get properly cleared. One of those leftover flags controls where you respawn when you die. So the trick goes like this:

1. Load one save and hit a respawn checkpoint.
2. Exit to the menu — your respawn point sticks around because the flag was never reset.
3. Load a second, different save and die.
4. You respawn back at the checkpoint from the first save.

That single piece of "stored" state lets runners stitch together parts of the game in an order the developers never intended — and the fact it all comes down to one flag that simply doesn't get cleared is just endlessly cool to me.

That video led me to the Star Fox speedrunning Discord, and it was genuinely lovely to find a whole group of people who love this game as much as I do.

Wanting to help, but not knowing how

There was one thing missing, though: I really wanted to help. The problem is I'm not a good enough gamer to actually speedrun the game.

I thought about becoming a glitch hunter instead, but that felt like it needed serious reverse-engineering knowledge. My career is in software, but it's a completely different world — I spend my days in Node, Go, AWS and the security weeds, and keeping on top of all of that is already a full plate. So for a while I just lurked on the side of the Discord, cheering other people on.

The stars align

Then something new happened. Someone posted in the Discord that they were using AI to decompile the game.

I use AI every single day for work — it's become an enormous part of how I get things done. And suddenly the stars aligned. Here was a way I could finally contribute to the community for my favourite childhood game, using something I already understood deeply.

And I have. At the time of writing, I've contributed around 3,200 commits to the decomp project.

A whole community I never knew existed

Contributing also opened a door I didn't even know was there: the game decompilation community. There are hundreds of these projects going on for retro games, and I find the whole thing genuinely thrilling.

Once a game has been decompiled, all sorts of doors open:

• Ports — running the game natively on PC, or even in the browser.
• Modding — building on top of the original game in ways the cartridge never allowed.

I can imagine a future with a proper competitive scene for Star Fox Adventures. Picture a mod that drops two players into a random section of the game and has them race to clear just that one part — something like Minecraft's MCSR Ranked, but for SFA. That would be incredible.

What I've learned along the way

Beyond the warm fuzzy feelings, the last couple of months have taught me a surprising amount about how games were actually built for the GameCube — how a project like this would have been set up, and how the compiler behaves. A few things that stuck with me:

• Compiler quirks — toggling behaviours like peephole optimisation and instruction scheduling to get matching output.
• Old-school algorithms — spotting things like shell sort in the wild.
• Per-file compiler flags — this was the most surprising one. Individual source files were compiled with their own individual compiler flags. Matching that faithfully is a fascinating puzzle.

I also picked up a lovely bit of trivia along the way: "Dolphin" was the GameCube's secret codename before release — which is exactly why the Dolphin emulator is named after it. I'd always assumed "Dolphin" was just some random name that happened to stick, so learning it was the console's real internal codename, unearthed and adopted by the emulation and reverse-engineering community, was a genuinely delightful little discovery.

Over the moon

All in all, I'm just delighted. I finally get to contribute to the community around my favourite childhood game, I've stumbled into a fascinating corner of programming I never knew existed, and I genuinely can't wait to see what else comes out of this decomp project.

If you love a retro game, there's a decent chance someone out there is decompiling it right now — and they'd probably love the help.

When I was younger, my dad used to read me these "choose your own adventure" books. You know the format — you're the hero, every couple of pages you make a choice, pick wrong and you die horribly, pick right and you get to die horribly a few pages later. I loved them. And then, like most childhood things, they quietly vanished from my brain. Fifteen, twenty years go by and I couldn't have told you the name of a single one, or even what the covers looked like.

Until one night, a few beers deep, I had a thought: I wonder if AI could find them for me.

The world's worst book description

I'd love to tell you I gave it rich, vivid detail to work with. I did not. My entire memory of these books amounted to roughly the following:

• It was a choose your own adventure book.
• At some point there's a skeleton lord guy thing you have to kill.
• You do it by knocking him down and putting a combination of different ingredients over his eyes.
• Right at the end it's revealed you were carrying one ingredient too many — you couldn't just use all of them, that wouldn't work — so the whole book comes down to a 1-in-3 guess.

That's it. That was the brief. A shitty description of a book I could barely remember in my own head, handed over at whatever-o'clock in the morning with zero evidence.

It went back and forth quite a few times. I'd say "no, that's not it", Claude (Opus 4.1, for the record) would come back with another candidate, we'd dig a little deeper each time. And then it landed on it: City of Thieves by Ian Livingstone — one of the old Fighting Fantasy books. I pulled up a summary, and there it was. The skeleton. The ingredients. The eyes. The horrible final guess.

I was absolutely gobsmacked. I'd tried googling this myself before and got nowhere — turns out "book where you put ingredients on a skeleton's eyes" is not a winning search query. I suppose I could have asked on a book forum, but those places always feel half-dead, and I didn't fancy waiting months for a reply that might never come. Instead, one late evening and a conversation was enough. Even my dad couldn't remember the books, so as far as I was concerned this thing was gone forever.

Can I play it?

Naturally, being several beers in at this point, my next question was even stupider: "Could I turn this into a real text-based adventure game that I could actually play?"

Opus whirred away for a few minutes and came back with: yes, absolutely — and better than that, someone already has. A developer in Sweden had built the whole thing and open-sourced it on GitHub: richelbilderbeek/city_of_thieves.

Brilliant. I jumped straight into the repo to get it set up, and immediately ran into a wall — it's a C++ project, and C++ is very much not my day job. I tried to build it, the build did not build, and I sat there staring at compiler errors like they'd personally offended me.

And then it hit me. Hold on. Why am I doing this part?

Claude cracks the build

I put Opus back on the case and watched an AI agent dive headfirst into a codebase neither of us had ever seen before. It read through the project, worked out what was wrong, fixed all the compile issues one by one, and got the thing to build. I just sat there with my beer.

This was the part that genuinely amazed me. All my previous experience with AI had been in projects I already knew inside out — very prescribed usage, me asking for targeted little changes to code I could have written myself. This was something else entirely: an unfamiliar codebase, a vague goal, and the agent just... handled it. And it bloody well worked.

The game ran. And it was exactly how I remembered the book. The streets of Port Blacksand, the terrible decisions, the lot.

Though I'll be honest — I remember the book being easier. I'm starting to suspect my dad just made all the swords hurt a lot less to help me out.

The point, if there is one

I went into that evening expecting absolutely nothing, and instead I got back a piece of my childhood I was sure I'd lost. There's something genuinely magical to me about being able to throw an AI agent at a problem this fuzzy — "a book I half-remember from twenty years ago, and also please make it a video game" — and have it blow straight past my expectations.

Tools like this didn't exist when I forgot those books. I'm very glad they exist now.

Just maybe don't wait until 4am and three beers to find out.

What is hashing?

Hashing means passing data through a mathematical formula to produce a result — the hash. The important property is that it's one-way: you can hash data to create a hash, but you can't reverse a hash to recreate the original data. Common algorithms you'll have seen include md5, sha1 and bcrypt.

In a security context, hashing is most often used to protect user passwords. Rather than storing passwords in plain text — where they're exposed to anyone with database access, from administrators to attackers — you store only the hash. Even if the database is breached, the original passwords aren't sitting there waiting to be read.

Rainbow tables and salts

The catch is that the same input always produces the same hash. That predictability is what makes rainbow tables dangerous: enormous precomputed lookup tables that map hashes back to the values that produced them. If an attacker finds a stored hash of 25d55ad283aa400af464c76d713c07ad, a rainbow table will happily tell them the password was 12345678.

The defence is a salt: random data added to the input before hashing. Give every user a unique salt and identical passwords no longer produce identical hashes. Precomputed tables become useless, because the attacker would need a separate table for every salt. They're forced to crack each password individually instead of looking them all up at once.

How hashing practices have evolved

Early PHP code leaned on md5 and sha1. As computing power grew — especially cheap, massively parallel GPU power — those algorithms became fast enough to brute-force. Modern PHP gives you password_hash() and password_verify(), which generate a random salt for you and let you turn up the computational cost over time as hardware keeps improving. That adjustable cost is the whole point: a good password hash is deliberately slow.

How to hash badly

Here's where it gets fun. I once came across a passwordless authentication system that generated login pins by hashing the user's email address together with a sequential request identifier.

The problem: the identifier was predictable and simply incremented with each request. Because the input was guessable, an attacker could build their own local rainbow table, watch the pattern across a few login attempts, and then predict future pins for other users. The hashing was technically present — and completely worthless, because the thing being hashed had no real randomness in it.

The takeaway

Hashing protects you only when it's implemented correctly. The algorithm matters, but how you use it matters just as much:

• Don't roll your own authentication. Lean on established services like AWS Cognito or Auth0.
• When you need randomness, use a cryptographically secure generator — never a plain rand().
• Remember that a hash is only as unpredictable as its input.

Good hashing isn't about reaching for the fanciest algorithm. It's about not hashing trash.