The first substantial software project I ever undertook (at least it seemed substantial at the time) was porting the famous text-based Star Trek game from an old newspaper I found to an IBM 5100 “luggable” computer in the mid-1970s. My father, who was a cardiologist, was an early advocate for computing in medicine, and he used an IBM 5100 at work. He would bring this beast home on the weekends and I would code on it.
I have no idea where I got the newspaper with the code printed in it, but I was enthralled when I saw it. It was written in some BASIC variant — with line numbers and everything — that wasn’t quite what ran on the IBM 5100, so I had to learn the nuances between the two languages by trial and error. I distinctly remember having to figure out the differences in the way GOSUB worked.
It took me many months to type it in, tweak it, and get it running. But I did it. It’s corny, but getting that game running was one of the great thrills of my life. It was so cool.
Recently, Claude Code converted that BASIC program to WebAssembly via Go in less than a minute. Now, it’s a fairly simple game, but still. Sigh.
That got me thinking. How long before we can do this with our big balls of mud? I’m going to go out on a limb and say — not long.
Busting the mud
I’m sure most of you write lovely code that is easy to maintain. But some of you — like me — spend your day working on a legacy application that was written by a dozen different people over the course of 30 years. You probably understand the system and how it is supposed to work, but you almost certainly don’t comprehend every line of code out of the millions that you are responsible for. You have a pretty high “WTFs per minute” ratio going when you read through it.
If you don’t deal with a big ball of mud on a daily basis, you almost certainly at least understand the whole notion.
But the amazing thing that is happening is that coding agents can understand those big balls of mud. They can quickly and easily trace through the convoluted mess of a 3,000-line procedure that no one wants to touch. They fix bugs in code that makes your head spin. That’s true for me — in my day job I maintain five million lines of code with one other guy. Coding agents have sped us up dramatically, probably by a factor of five or more. It’s been mind-bending.
All of this makes me wonder. What would happen if we asked Claude Code to convert our application to, say, Go and Wails?
We could tell Claude to use modern coding techniques, to write neat, modular code, and to re-architect the codebase using clean coding methods that are easy to maintain and expand. We could have Claude make the code look modern and consistent across the entire application. We could have the app run on Windows, the Mac, and Linux as well as in the browser. We could create our dream codebase if we were thorough enough in our specification and diligent enough in our monitoring of the process.
A legacy taboo
I bet the whole thing could be done in weeks (days?) instead of the years that it would take to do by hand. And why not? What do we have to lose?
Now, rewriting code from scratch is exactly what Joel Spolsky told us we should never do. But that was 26 years ago, and I’m going to say that Spolsky didn’t foresee coding agents. Spolsky’s first point is that the old, legacy code holds years of corporate knowledge and edge-case solutions that can’t possibly be recaptured in a new version. But these are precisely the kinds of things a coding agent can see and can capture. Spolsky’s second point — that a wholesale rewrite means years of not shipping anything new — is made moot by the speed with which it could be done.
Let’s face it. The time is coming soon — if it isn’t already here — when it would be irresponsible not to rewrite our big balls of mud. If you can modernize a legacy application with a coding agent doing 98% of the work, and get it done in a person-month or two, then the business case for such a project seems blatantly obvious to me. It would certainly mean a lot of testing, but we could get agents to do that as well.
Spolsky was right at the time — you should never rewrite your application with a software development team. But now? It’s something that will have to happen.
Read the original article: