Claude Code Transforms Digital Archaeology with AI

A Transputer walked into a museum at Bletchley Park, programmed in occam, and Claude Code got it running. That's not a metaphor — it's Phil Pemberton's story from a guest talk at TNMoC. He designed an accelerator for the Acorn Archimedes (the first Arm-based computer) using Inmos Transputers, the 1980s UK parallel-processing chips programmed in occam. He admitted publicly he struggled to get his head around the language. Claude Code wrote working code where the human presenter couldn't.

This is the most interesting thing an LLM has done in 2026, and almost nobody is paying attention.

What digital archaeology means, and why TNMoC is its capital

The UK's National Museum of Computing sits on the Bletchley Park site where Colossus broke Lorenz in WWII. Its remit stretches from wartime cipher machines through '60s and '70s British mainframes into the dawn of the microprocessor age. The collection attracts a subspecies of retro geek who reverse-engineer long-abandoned systems, chips, and backwaters of digital history. TNMoC calls them digital archaeologists. The moniker fits.

Their talks are the real artifact. They sit alongside DEF CON and Black Hat reverse-engineering presentations in their discipline — peel back layer after layer, document what you find, rebuild the system in software so the next generation can study it. The work isn't nostalgia; it's preservation of intent. When the last person who understood occam retires, the Transputers become inert silicon.

That's the gap LLMs fill.

The Pemberton / Transputer case, in concrete terms

Transputers were a 1980s UK effort to commercialize low-cost parallel processing. They were programmed in occam, named after William of Ockham, designed to make parallel code read like a network of communicating processes. Programmed well, Transputers were unparalleled. Almost nobody programmed them well. The technology was swept away by the time of the Pentium.

Three decades later, the documentation is sparse. Phil Pemberton needed to write an accelerator that would let an Archimedes talk to Transputers. The occam references are scattered across dead FTP servers, scanned PDFs, and one or two surviving mailing-list archives. Pemberton said in his talk that he doubted many users could have managed without high-level support from Inmos themselves.

Then he ran the problem through Claude Code. It worked. The Register notes an "even more impressive Claude-powered reverse engineering effort" right after — the article is truncated mid-sentence at "if marginally less obs" — so I can only report what's visible. The Pemberton case alone is enough to make the point: when the human expert hits the wall on an obscure language, the LLM finishes the job.

Why LLMs are weirdly good at dead languages

The Register's piece notes that LLMs are "still in their metaphorical diapers." True. But they have one structural advantage no prior tool had: training data scraped from three decades of public internet, including the obscure mailing lists, GitHub gists, and Stack Overflow answers that constitute the entire occam corpus.

Three properties follow:

• Pattern density. Even rare languages have enough public code that an LLM can hold the grammar in weights. Occam is small. The corpus fits.
• Cross-domain transfer. The LLM doesn't need to "know" occam the way a compiler does. It needs enough examples to generate plausible code, and the Transputer's hardware is well-enough documented that the loop closes.
• Intent preservation. The museum doesn't need the LLM to invent — it needs the LLM to recover what the original Inmos engineers would have written. That's a translation task. LLMs translate well.

This isn't unique to Transputers. The same pattern shows up whenever an engineer tries to maintain COBOL on a mainframe, port FORTRAN to a modern cluster, or recover the assembly listings of a 1985 BIOS. The bottleneck is rarely the grammar. The bottleneck is finding someone who still thinks in it. LLMs short-circuit that bottleneck.

How to actually use Claude Code for legacy work today

The case study is good news. The implementation is better news. Claude Code is a CLI you run from a terminal, point at a directory, and ask questions of. For digital archaeology work, the pattern is:

# Install Anthropic's CLI
npm install -g @anthropic-ai/claude-code

# Authenticate (subscription or API key)
export ANTHROPIC_API_KEY="sk-ant-..."

# Point it at a legacy codebase — for example, a Transputer occam project
cd ~/projects/transputer-accelerator
claude "Read the occam sources in src/, identify any references to the
         Inmos T800 datasheet, and rewrite the channel-communication
         primitive in idiomatic modern occam. Preserve the comments."

For more structured work, define a custom slash command that captures your archaeology protocol so the workflow survives the next model swap:

<!-- .claude/commands/archaeology.md -->
# Archaeology protocol

You are reverse-engineering a legacy system. Before writing code:

1. Read every file in $ARGUMENTS and produce a one-paragraph
   module map (inputs, outputs, side effects).
2. List the assumptions baked into the code that are not
   documented anywhere.
3. Identify the smallest unit of behaviour that, if changed,
   would break the rest of the system.
4. Only then propose changes. Cite the file and line for every claim.

This is the same shape as a research note in a museum archive — read, document, identify load-bearing assumptions, then act. The LLM is fast enough that the documentation step stops being the bottleneck.

The part that survives the model swap

Every six months a new model arrives that does legacy work better than the last. The capability is real. It is also, structurally, the wrong layer to bet a museum on.

The part that doesn't change is the protocol around the model. The .claude/commands/archaeology.md above is a stable artifact. The module map is a stable artifact. The list of load-bearing assumptions is a stable artifact. When Anthropic ships the next model — or when a museum switches to a smaller local model for privacy — the protocol carries over. The model is interchangeable. The discipline is not.

This is the same shape as any durable software layer. Cross-platform UI work lives or dies by whether the component contract survives a framework migration. Digital archaeology lives or dies by whether the documentation protocol survives a model migration. The tools swap; the conventions hold.

Practical version: keep the archaeology protocol in version control, not in chat history. Treat the LLM's output as a draft to be checked against the datasheet, not as ground truth. When the model changes, the protocol doesn't.

The part I can't tell you yet

The Register's piece was truncated mid-sentence — "an even more impressive Claude-powered reverse engineering effort, if marginally less obs" — so the second case study isn't visible to me. What's on the page is enough: an LLM wrote working occam where the human presenter admitted he couldn't. If a museum can recover one Transputer from its obscure-language graveyard this way, the same approach recovers a thousand forgotten systems.

Build the protocol. Point the model. Document everything the model produces. The model will get better. The protocol is the part you keep.