How We Ported 900,000 Lines of Code in 4 Days Using the Ralph Wiggum Loop

Ralph Wiggum Loop

How We Ported 900,000 Lines of Code in 4 Days Using the Ralph Wiggum Loop

In four days, our Rōnin co-founder, Byron McClain, ported a 900,000-line video game from Windows to macOS, without writing a single line of code himself.

The game? Command & Conquer: Red Alert, the 1996 real-time strategy classic from Westwood Studios.

The experiment? Take an open-source game engine built exclusively for Windows, completely rebuild it to run natively on macOS, and do so entirely using Claude Code, an AI coding agent, paired with the Ralph Wiggum Loop methodology.

When we asked our co-founder, Byron McClain, why he chose to test AI coding agents on a 28-year-old video game, his answer was simple: “I’m not a game developer. I know Jack about how to develop a game.”

And that was exactly the point.

“I wanted to find the edges of Claude Code,” Byron explains. “I needed something gigantic and pre-existing that I could try this on, but it would need to have very clearly defined goals. I don’t know how to do any gaming, anything. So I thought, here’s a perfect test: take something I’ve never done before and see what Claude Code paired with the Ralph Wiggum Loop could actually handle.”

Turns out, it can handle quite a bit.

Using Claude: greenfield vs. brownfield

When testing new AI coding tools, most people start with greenfield projects, or building something new from scratch. It’s easier. There’s no existing code to untangle, no legacy dependencies, or any architectural decisions made 30 years ago that you have to work around.

At Rōnin, we have already tested Claude Code on greenfield work. It performs well. You can take a product requirements document, feed it into Claude, and watch Claude generate a functioning piece of software phase by phase.

But brownfield projects? That’s where things get interesting. With a preexisting codebase, you need some prior knowledge of what you’re looking at. A developer must understand context and navigate and update code they didn’t write. This is exactly the challenge Byron was looking for.

The Red Alert engine was the perfect stress test. At over 900,000 lines of code, it represented decades of Windows-specific development. Every system dependency would need to be identified, isolated, and replaced with macOS equivalents. The windowing system, graphics rendering, audio processing, file system access, network multiplayer protocols, all of it had to be rebuilt.

And Byron wanted to try it in Rust, a modern systems programming language, to prove Claude could handle not just porting but modernization.

Enter the Ralph Wiggum Loop

Claude Code has a feature called “plan mode” where it scans your entire codebase, asks clarifying questions, and generates a structured approach to whatever you’re trying to accomplish. “Having Claude in plan mode to plan out all the phases is extremely helpful when tackling something this massive,” Byron explains.

But plan mode alone wasn’t enough for a project this size, because even with these planned steps, someone still had to babysit Claude through execution. A human needed to answer questions, approve each step, and tell it when it was okay to move to the next phase. For a 900,000-line project? That would mean constant human intervention.

But Byron found another way, by means of the Ralph Wiggum Loop. Which is essentially “danger mode” for Claude Code and a way to run the AI agent autonomously without constant human approval.

ralph wiggum loop

Here’s how it Ralph Wiggum works: You break your project into phases, then break each phase into discrete tasks with clear acceptance criteria. Claude runs through each task, checking whether the criteria are met. If the criteria are met, it moves to the next task. If not, it keeps iterating until it gets it right or until it hits a predefined escape hatch and stops.

The human’s role is now to check in every 30 minutes or so, see where things stand, and kick off the next phase when one is complete.

Planning the port 

Byron cloned the Red Alert repository, initialized Claude Code on it, and watched it scan through the project structure. Claude immediately recognized what it was looking at. It cataloged the file structure, identified Windows dependencies, and asked for guidance. 

“There was no coding. I just told Claude what I wanted it to do. I said that my mission was to remove all the Windows-dependent code in the system and replace it with Mac OS specific code so that this game will run on Mac OS,” Byron explained. 

And after that, Claude asked the right questions: 

  • What graphics framework should we use?  
  • What about audio?  
  • File system access patterns?  
  • Network protocols?  

“Claude was making all these recommendations for the different audio, graphics, and access to the file system,” Byron recalls. “It was just a conversation we had together, with Claude making recommendations, and me weighing options based on 30 years of development experience, even though I had never built a game before.”  

Then Claude generated the plan. “It was right at 14 phases, and then each phase had anywhere from like 10 to 15 tasks,” Byron says. 

The phases broke down the port logically, windowing and event loops, graphics rendering, audio implementation, file system access, network protocol updates (converting the ancient IPX multiplayer protocol to modern standards), and finally packaging it all into a proper Mac application bundle.  

Some phases even had sub-phases for particularly challenging systems. 

When Claude got stuck 

It wasn’t a perfect experiment, but that’s expected.

There were only a handful of times where it would bailout,” Byron notes.

Most bailouts occurred during dependency installation because Rust requires certain low-level packages to interact with macOS frameworks. Even in “danger mode,” Claude couldn’t install them without explicit permission, so a few manual interventions got things back on track. 

However, the more interesting issues showed up during validation. 

“When I did get the game running, the audio was playing staticky and weird,” Byron recalls. Digging into the code, he found Claude had assumed about how to block concurrent audio streams in one part of the system. That assumption worked fine in isolation, but elsewhere in the codebase, Claude had implemented the same functionality differently and better. 

Because the codebase was so large, Claude’s context window couldn’t hold everything at once. It would handle one area, auto-compact its memory to make room for the next area, and occasionally lose track of decisions it had made earlier.  

This is where human validation mattered. 

The audio issue was caught during testing, as were a few other places where Claude forgot to use a specific value from another module, which caused the errors. These weren’t failures of the AI; they were reminders that large, complex systems still need a good software engineer to check.  

It took me about four days for everything – including bugs.”

But even though there were errors, these fixes took hours, not days. “Using the Ralph Wiggum loop, it took me about four days for everything – including bugs,” Byron says, “the vast majority of the 900,000-line port was solid. I was just doing cleanup, not rewriting an entire video game.” 

What the experiment using Ralph Wiggum Loop proves 

Byron and Claude completed the platform migration of a complex, legacy codebase in four days from start to finish. From Windows to macOS, from outdated protocols to modern implementations, from scattered executables to a signed Mac application bundle. 

And 95% of that work happened autonomously, with Claude identifying dependencies, rewriting systems, validating its own output against acceptance criteria, and moving methodically through each phase. Alone, with minimal input from Byron.  

 The 5% that required human intervention? Dependency permissions, cross-module validation, and final QA testing. 

This proves a few critical things about where AI coding agents are right now: 

Autonomous coding works for brownfield projects. This wasn’t a toy example or a greenfield demo. This was real legacy code with real complexity. 

Context window management is the constraint. Claude can handle massive codebases, but when it auto-compacts memory, it can lose track of earlier decisions. Humans still need to catch those consistency gaps. 

Task decomposition is the new core skill. The quality of Claude’s output directly correlated with how well we defined the tasks upfront. Garbage in, garbage out still applies, but now “garbage in” means poorly defined acceptance criteria, not poorly written code. 

Validation remains human work. The AI can check itself against defined criteria, but can it catch subtle issues like audio quality or performance bottlenecks? That still takes human judgment.  

We’re not replacing developers. We’re changing what developers do. 

What’s next 

The game works. It runs on multiple Macs. “I was able to get it ported, get it bundled into a Mac app, and I gave it to some of the other Rōnins to try it out on their Mac laptops, and it works,” Byron says. 

More importantly, we now know the boundaries of Claude. We know where AI agents excel (systematic conversion, pattern matching, implementation) and where humans still add value (architectural decisions, subtle validation, context consistency). 

The next step?  

Taking this methodology to client work, because if we can port a 900,000-line game in four days, what can we do with a legacy system? Or a modernization project? Or a technical debt backlog?  

As Byron put it: “We’re definitely moving towards fully automated coding. The future isn’t coming. It’s here, and it took four days to prove it.” 

 

Author:
Julie Simpson is the Marketing Manager at Rōnin Consulting. Before joining the team, her software development knowledge was practically non-existent. However, after countless internal meetings, soaking up information, and engaging in endless Teams chats with the Rōnin crew, Julie has transformed into a bona fide technology geek. Nowadays, she dreams about AI, laughs at dev jokes, and frequently messages the team with warnings about the eventual rise of Skynet.