Your existing code is an important part of any AI agent’s context. Consequently, poorly structured code and technical debt are considerable barriers to agentic coding.
In the past, uplifting a legacy codebase used to be a risky and expensive endeavour. Many are the technical debt backlogs that never got priority. Even more numerous are the failed infamous project re-writes.
This is where coding agents paired with modern code quality tools offer nothing short of a revolution. Let’s look at the proof from our recent case study.
300K lines of code refactored in three weeks
- Our case study demonstrates agentic refactoring at scale on a real-world, non-trivial codebase: Street Fighter III: 3rd Strike.
- The codebase consists of 300k lines of C code.
- We refactor the whole codebase to eradicate any technical debt, bringing the code to a level where new features could be added safely with AI.
- Functional correctness was verified via a replay-trace harness that compared the rollback state hash frame by frame. (And yes: we could still play the game as before).
- The CodeHealth MCP Server was used as the objective quality signal and agentic feedback loop.
- We designed a process where a refactoring playbook is built up iteratively. That way, agentic refactoring tasks become progressively more effective.
- In that process, we discovered novel domain-specific refactoring rules courtesy of the AI. These were remarkably useful, yet structurally different from the code transformations an expert human would consider.
The uplift was executed in three weeks at a token cost of roughly 4,000 USD.
That token cost corresponds to half of a monthly developer salary. For contrast, similar projects in the pre-AI era are likely to have required 12-18 months of expert developers.
Code Health visualizations before and after agentic refactoring. Visualized via CodeScene.
With that covered, we’re ready to look at the agentic process.
The agentic refactoring process in numbers
Refactoring the whole codebase to a perfect 10.0 took exactly three weeks. Those three weeks involved:
- 2,903 commits
- 252,055 lines of code modified
- 726 distinct source code files touched
- 22 refactoring recipes with 82 additional notes created
The refactoring process experimented with multiple elements initially before settling on Claude Opus for the bulk of the work. One main reason for this was thatClaude Code with Opus was significantly better than Codex with Sol at capturing and documenting the discovered refactoring patterns in the emerging playbook. We also noticed that files often plateaued in the uplift process when running agents with the smaller Sonnet and Terra models. They seemed to get stuck at a local optimum, and couldn’t progress on the remaining code smells.
Uplifting a 300k codebase to perfect Code Health would have been a massive task just a year ago.
I had my agentic coding wins in the past, but this is the first time I’m experiencing a true superhuman AI performance at scale. And I say that as someone with three decades of experience in large-scale system development.
An AI-designed playbook beyond human capacity
The resulting playbook contains some familiar refactorings for uplifting unhealthy code: Extract Function, Guard Clauses, Parameter Object, etc.
But what struck me the most was that the process caused agents to discover recurring transformation shapes and name them. The AI also specified the preconditions for each recipe, evaluated whether they worked, and added successful ones back into the playbook.
Some of these recipes are surprisingly specific:
- Shared Index Range captures repeated loops that differ only in their start and end ranges.
- Action Parameter handles duplicated control structures that differ mainly in which function they invoke.
- Uniform Step Table turns heterogeneous function calls into a uniform, table-driven dispatch.
These aren't generic refactorings pulled from Fowler's catalogue. They emerged from the patterns the agents encountered in this particular codebase as a response to the feedback from the CodeHealth MCP.
However, not all refactoring attempts were successful. Many didn’t move the quality needle at all, while some attempts even made it worse by degrading the code's health. That’s why it was crucial to let the agents accumulate knowledge about the transformations that worked on this particular codebase and which didn't. Those documented failures became part of the playbook, too.
For me, this points to a natural next step for tackling the technical debt problem: generic refactorings offer the foundation, domain-specific refactorings adapt to the specific problem at hand. It’s a natural insight, and surprisingly obvious in retrospect. That the process is possible to automate carries promise for companies looking to benefit from AI-coding.
Measuring engineering outcomes
As fascinating as all of this is, there’s an obvious elephant in the legacy room: the objective itself. Give an agent a metric and a generous supply of tokens, and it will happily optimize for any metric. So why did we trust Code Health as the target?
The reason is because the Code Health metric has been validated via previous research. That way, we can trust the metric to act as a reliable proxy for real engineering outcomes:
- Productivity: The Code Red papers show that low Code Health correlates with slower delivery and higher defect density. Healthy code is 10x faster to evolve and contains, on average, 15x fewer defects.
- AI correctness: Recent research extends these findings into the agentic world. Better Code Health improves AI correctness.
- Token efficiency: Healthy code reduces iteration churn, and cuts token usage.
All of those wins are highly relevant for this case study, too. This refactoring project started as preparation for a study with Lund University. We needed two functionally equivalent versions of the same codebase: one unhealthy, one at Code Health 10. The next stage will see students implement features in both using the latest frontier AI models, comparing the cost and quality of the work. The large-scale uplift laid the ground for those next steps.
Summary of the business value
To sum up the outcomes, the Streetfighter III uplift from an average Code Health 5.6 to a perfect 10.0 translates into:
A ~ 70% reduction in AI-induced defects making the code itself AI-ready.
A reduction of token waste with ~45% when implementing future features.
We can now compare those expected outcomes with the investment of 4,000 USD for tokens. That’s a very concrete business case.
Is technical debt now a solved problem?
No. Quite the opposite. Technical debt is a more urgent problem than ever. Any organization that “adopts AI” naively is likely to add to existing problems rather than seeing any productivity gains magically materialize.
However, this case study demonstrates that the economics for dealing with technical debt have changed. Dramatically. And the key component behind this shift is to use AI to make the code better suited for AI.
The key to making this work is ensuring that agents aren’t working blindly. This means deterministic quality feedback that tells them where to improve as well as acting as the objective judge. That quality signal is the Code Health metric.
In addition, automated tests and equivalence checks are absolutely essential as safeguards for preserving behaviour.
Our case study illustrates that large-scale technical debt remediation might finally become economically viable.
Ending credits
Daniel Webb & Dr. Markus Borg fighting unhealthy code.
The best thing about writing up a case study like this is that I receive part of the praise. However, the real credit belongs to Daniel Webb and Dr. Markus Borg who did all the heavy lifting. The execution and process are all theirs.
And if you want help driving and achieving these results in your company, then I highly recommend contacting Daniel and NeoSee.
I also want to thank the CodeScene team for providing the tools needed to turn coding agents into reliable engineering partners.
Finally, thanks to Capcom for making a great game back in the day, and thanks to the 3SX/3S decomp for making the code available as open-source code. That makes studies like this possible.
.png)