Bringing a 27-year-old programming project back to life with Claude Code

A big chunk of my final year at university, studying for my Computer Science degree, was spent working on a project. That last year counted for 60% of my overall grade, and the project contributed half of that. So the mark that I obtained could make a significant difference to my overall result for my degree.

Every student on my undergraduate course had to pick a project and find a supervisor amongst the teaching staff who would be willing to support them. I had the idea of building a BBC Micro emulator, getting into the weeds of the computer that kickstarted my love of technology. But for specific reasons that are lost to me now, my tutor nudged me away from this and instead encouraged me to look at the work of Donald Knuth.

Knuth is a well-known computer scientist and mathematician. One of his major life works is a series of books called The Art of Computer Programming (TAOCP). Originally conceived as a single book of 12 chapters when he started it in 1962, four volumes (with Volume 4 split into sub-volumes) have now been published, with more planned. In the books, Knuth wanted to illustrate computing concepts on paper but did not want to tie the text to any specific real-world machine. From my final project report:

Algorithms and programs presented by Knuth in TAOCP are written in the language MIXAL and intended for execution on MIX, a hypothetical machine. MIX was formulated specifically for use with this work for a number of good reasons. The use of an existing language and machine would have given readers the impression that the books were just for users of those particular systems. Also, the rapid advancements in technology would mean that the system would very likely become obsolete over a relatively short period of time. Furthermore, idiosyncrasies of a chosen machine and language would have to be explained to the reader, confusing the issues at hand. All of these problems are avoided by the formulation of a near-‘ideal’ machine (Knuth, 1997, page ix).

Knuth’s approach was understandable, but it had the drawback that the reader would not be able to use an actual computer to experiment with the concepts outlined in the book. This was something that he recognised. Again, from my report:

The advantages gained from using a hypothetical machine are clear. However, since the machine does not exist, it is not possible for a user to ‘run’ the algorithm and view its performance in real-time. Knuth states himself that “[u]nder favorable [sic] circumstances the reader will have access to a MIX assembler and a MIX simulator, on which various exercises in this book can be worked out” (Knuth, 1997, page 153). MIX simulators are already available in various forms, the most recent being MIX Builder 98 by Bill Menees, and vary in their degree of usability and performance (see section 7). All of them are currently platform-dependent. It is the intent of this project to provide a working MIX machine upon which programs from the book can be viewed, run and analyzed by users, in a (relatively) platform-independent environment. This platform independence will give maximum access to potential readers of TAOCP (see section 2.1.1).

My idea was to create a MIX emulator that would be as widely accessible as possible.¹ Back in my university days, Java was considered to be the cutting edge of programming languages. Small Java applications, known as applets, could be delivered by embedding a ‘half-compiled’ version of the program (known at the time as ‘Java bytecode’) into a web page. When downloaded via a web browser, the program would then finish compilation and run on a Java Virtual Machine (JVM) specific to the computer that accessed it. The web had already brought a quiet revolution of interoperability between different types of computer, allowing you to access web pages from PCs, UNIX workstations or anything else that had implemented a web browser. But the functionality of the web in the 1990s was limited. Java applets took the capabilities of the browser to another level.

I’d never done any object-oriented programming before, so I bought a paperback copy of Bruce Eckel’s Thinking In Java and started to work my way through the text. The book was a brilliant introduction, both to the programming language as well as thinking in an object-oriented way. At some point, something clicked in my brain and I understood how I would tackle the architecture of the system. I felt I’d read enough and started coding.

Knuth’s text is super dense. I found myself poring over the few pages that outlined the specification of the system, reading the same sentences and paragraphs over and over again to try to understand the design. It’s hard to remember all the details of that final year in 1998–1999, but it feels as though I spent every significant chunk of my free time, including evenings and weekends, working on the Sun SPARCstations in the Computer Science block on campus. The code was written by hand in a text editor, and the accompanying report was written up in Adobe FrameMaker.

Coding in an object-oriented fashion was so much better than using a procedural language. Breaking down the problem into smaller and smaller components seemed natural once I had got the hang of it. I am sure that this contributed to the quality of my code. I distinctly remember the first time I attempted to run one of the example programs from the book on my emulator, which calculated and ‘printed out’ the first 500 prime numbers, and it working on the first go. I couldn’t believe it. I went to the vending machine in the common room and bought something for everyone who was in the computer lab that night.

Many years later, Java applets were deprecated in web browsers. As a result, my emulator, which I’d hosted on my website for the past dozen years, stopped working. My career took me into technical analysis work, project and programme management and now a general manager of a technology team. I haven’t done any ‘proper’ programming in decades. After leaving university, I never did finish the work on the emulator.

This past Christmas, I was reading Simon Willison’s summary of 2025 in the world of large language models, and pondering what this all means for the remainder of my career as a technology manager. From Willison’s summary:

The most impactful event of 2025 happened in February, with the quiet release of Claude Code.

I’d been reading about Claude Code for a few months and had planned to try and find the time to explore it. Given my lack of knowledge of modern software development using GitHub and the command line, I knew it might take some time to get up to speed. But then I read on. From Willison’s summary again:

In October they repurposed that container sandbox infrastructure to launch Claude Code for web, which I’ve been using on an almost daily basis ever since.

Now I had no excuse.

I signed up to an £18/month Claude Pro plan, the minimum required to get access to Claude Code. I’d been thinking about a small change I wanted to make to the WB-40 Album Club website. Because of some missing data on the original Album Club site, the code was just using the year in its date calculations instead of the full date. Using the Claude Code web interface, I connected it to my GitHub account, ‘installed’ Claude Code and gave it access to my code repository for the WB-40 Album Club project.

The first thing I did was to use one of the built-in canned prompts to create a CLAUDE.md file, a Markdown text file written as an explanation of the code. My understanding is that this file is then used by Claude Code in subsequent sessions so that it knows what’s what without having to spend time (and tokens) analysing everything again. It finished writing the file, and then let me send it as a pull request (i.e. a request from the developer, in this case Claude, to add this file) to the code repository:

I then started a new ‘session’, in the context of the same GitHub repository, and stated in English exactly what I was trying to achieve:

I sat there fascinated, watching it post messages about the progress of the work. Suddenly, it finished and told me the code was ready. The ‘+9 -14’ indicator shows that it had added nine lines of code and removed 14, which I could review if I wanted to. I created a pull request, merged it into the project and the site rebuilt itself with the changes.

It all worked. From opening Claude Code for the first time to updating the website had taken all of 45 minutes.

I went to bed that night, as I am sure many other people have who have used tools like this, thinking about the possibilities. I’m not a programmer and don’t have lots of existing codebases, but then I remembered that I did have my MIX project. I wondered what Claude Code could do with that? The next day was Monday, so I’d have to wait until work was over for the day before I could try it out.

For years the raw code for my MIX emulator had been available in a ZIP file on my website. The first step was to create a new GitHub repository and upload all of the files to it. From there, I could then connect Claude Code and get to work.

It was fascinating to read the CLAUDE.md file that Claude Code generated after it analysed this new repository. It outlines the project’s architecture, explains the known limitations (particularly that it is old and no longer works) and leaves instructions for how developers should approach updating the codebase.

My idea was to recreate the application using a modern technology stack. So, starting a new session, this is exactly what I asked it to do. My prompt was:

I’d like to bring this project back to life. This code used to run in a webpage as a Java Applet, but it will no longer work in modern browsers. Can you please suggest how this can be rewritten in a modern codebase/tech stack where it will be functionally identical to how it was written originally?

Claude responded:

Here’s my analysis and recommendation based on a thorough review of the codebase.

Current State

The simulator has two distinct layers:

1. Simulation engine (~2,500 lines): MIX word/byte/sign data model, full instruction executor (64 opcodes), assembler (incomplete), clock timing, comparison/overflow state
2. GUI layer (~3,600 lines): AWT Canvas-based custom rendering of registers, memory cells, indicators; Frame-based windows for the editor, line printer, control console, clock; GridBagLayout positioning; menu bars with keyboard shortcuts
   

The original runs as a Java Applet embedded in an HTML page. Applets were removed from browsers years ago and from the JDK itself in Java 17.

Recommended Approach: TypeScript + React Web Application

A single-page web app is the natural successor to the applet — it runs in the browser, requires no installation, and can be hosted as a static site (GitHub Pages, etc.).

It then gave a full account of the planned architecture, why it had chosen this technology stack, what alternatives had been considered etc. It was fascinating to read through. And then:

Want me to start implementing this?

For me, this was mind-blowing. Before it got started, I wanted to make sure that it wasn’t going to do something too off-piste. So I asked:

Will you preserve the look and feel of the original? I realise that it won’t look exactly the same, but the same in spirit (at least) would be good.

Would you also code tests to ensure that the logic is working correctly, such as the program counter, memory management etc.?

To which Claude Code responded “Yes to both.” I didn’t explicitly ask it to start, but it got going.

After chugging away, things ground to a halt with a note that “You’ve hit your limit · resets 3am (UTC)”. Argh. I wasn’t sure what to do next, but I knew I didn’t want to pay more than the £18 I’d signed up to. I found out that once your account has exited the usage limit limit sin-bin, you can just prompt Claude Code with a simple ‘Continue’ and it will wake up and continue from where it got to. As I clicked around the Claude website, I found the Billing and Usage pages, where I learned that you can buy API credits to continue your work even when you’ve hit the limit. Not only that, but there was an offer to add £38 to my account that day for free. Of course I clicked it, made sure that auto-top-up was turned off, flicked the switch to allow this extra usage, and started Claude Code running again.

It worked away for a long time, and I ended up going to bed. In the morning, I found that it had completed its first attempt. Not only that, it told me that it had implemented features such as the assembler which I had never got round to finishing back in 1999:

All done. Here’s a summary of what was accomplished:

Modernized MIX 1009 Simulator

Ported the original 1999 Java AWT MIX simulator to a modern web application in mix-sim/.

Technology Stack

• Vite 7 + React 19 + TypeScript for the frontend
• Vitest for testing (64 passing tests)
  

Architecture

Core Engine (src/core/):

• MIXWord.ts — Fundamental 5-byte + sign data unit
• MIXMachine.ts — Full simulation engine (~1,060 lines) with:
• All 63 MIX instruction opcodes (arithmetic, loads, stores, jumps, shifts, comparisons, I/O, conversions)
• MIXAL assembler with label resolution, directives (ORIG/CON/ALF/EQU/END), field specs, and expression evaluation
• Event system for UI reactivity
• MIXInstructions.ts — Complete instruction set definitions
• types.ts — Shared enums and the MIX character table
  

UI Components (src/components/):

• Register panel (A, X, I1-I6, J)
• Memory viewer with scrollbar and PC highlighting
• Comparison and overflow indicators
• MIXAL program editor with sample program loader
• Line printer output display
• Control console (Step/Go/Reset) with clock display
  

Tests (src/test/core.test.ts):

• 64 tests covering MIXWord operations, all instruction types, assembler, and integration scenarios
  

Committed and pushed to claude/modernize-java-applet-YrOmV.

A few more prompts helped me to understand how I could get the project to build and publish itself to GitHub Pages, a free hosting site. The first build attempt resulted in errors, which I copied and pasted back into Claude Code. It investigated and fixed them, explaining to me what the problems were. Pulling the code into the main branch got things up and running.

Loading and running the program to calculate the first 500 prime numbers was thrilling all over again. This time it wasn’t with the sense that I had brought something to life, like it had felt the first time back in 1999, but with the feeling of what it meant for the future of programming.

You can find the converted version of the emulator here. I used a few more prompts for some minor tweaks, cleaning up some of the formatting, adding a link to the original project report from the ‘Info’ pop-up box, and getting it to display the machine in a usable way on a phone screen. I’ve also added a speed slider which allows you to see the computer in action as it processes.

I’m completely blown away by how easy this was. The irony is not lost on me that this project originated in a series of books called The Art of Computer Programming. Does the invention of tools like this mean that it will soon be a lost art? I have mixed feelings — pun not intended — that something I spent nine months on can now be created at the drop of a hat. It’s simultaneously liberating, unsettling and fun.

1. These days there are many such MIX emulators available. Knuth’s own webpage for The Art of Computer Programming lists lots of examples. ↩