Claude Code transforms digital archaeology with AI

A Transputer walked into a museum at Bletchley Park, and Claude Code got it programmed in occam. That is Phil Pemberton's story from his guest talk at The National Museum of Computing — told in his own words, in person, with none of the corroborating video or write-up you would want before treating it as established fact. Take it as one practitioner's account, then: he built an accelerator linking an Acorn Archimedes to Inmos Transputers, the 1980s parallel-processing chips programmed in occam, and he said openly that the language gave him trouble. Running the problem through Claude Code produced working code where he had been stuck.

One anecdote does not make a benchmark. But it points at something real about where LLMs are structurally advantaged — and that part holds up whether or not you were in the room for the talk.

What digital archaeology means, and why TNMoC is its capital

The UK's National Museum of Computing sits on the Bletchley Park site, home of the wartime codebreakers, and its remit stretches from cipher machines through British mainframes into the dawn of the microprocessor age. The collection attracts a subspecies of retro engineer who reverse-engineers long-abandoned systems, chips, and backwaters of digital history. TNMoC calls them digital archaeologists, and the moniker fits.

Their talks follow the same discipline as DEF CON and Black Hat reverse-engineering presentations — peel back layer after layer, document what you find, rebuild the system in software so the next generation can study it. The work is not nostalgia; it is preservation of intent. When the last person who understood occam retires, the Transputers become inert silicon.

That is the gap LLMs fill.

The Pemberton Transputer case, in concrete terms

Transputers were a 1980s effort to commercialize low-cost parallel processing. They were programmed in occam, a language designed to make parallel code read like a network of communicating processes. Programmed well, Transputers were excellent hardware. Almost nobody programmed them well, the surrounding ecosystem withered, and the technology was swept away by the commodity-processor era.

Three decades later, the documentation is sparse. Per Pemberton's account, the occam references are scattered across dead FTP servers, scanned PDFs, and one or two surviving mailing-list archives. He doubted many users could have managed the work without high-level support from the original vendor — support that no longer exists to give.

Then he ran the problem through Claude Code, and it worked. Working occam, for real Transputer hardware, from a practitioner who had publicly admitted the language beat him. If you want a one-line summary of why this matters: when the human expert hits the wall on an obscure language, the LLM finishes the job — at least this once, by this account.

Skepticism is warranted about the generality. A single talk anecdote is not a controlled result, and obscure-language output is exactly where confident-sounding hallucinations hide. The responsible reading is narrower: the model produced code the expert accepted as working, against hardware with fixed, checkable semantics. Transputer code either runs on the chip or it does not. That checkability is doing load-bearing work in this story, and it generalizes better than the anecdote itself.

Why LLMs are weirdly good at dead languages

LLMs have one structural advantage no prior tool had: training data scraped from three decades of the public internet, including the obscure mailing lists, code archives, and forum answers that constitute the entire surviving corpus of a language like occam.

Three properties follow:

• Pattern density. Even rare languages have enough public code that a large model can hold the grammar in weights. Occam is a small language. The corpus fits.
• Cross-domain transfer. The model does not need to "know" occam the way a compiler does. It needs enough examples to generate plausible code, and the Transputer's hardware semantics are fixed enough that the loop closes against something checkable.
• Intent preservation. The museum does not need the model to invent — it needs the model to recover what the original engineers would plausibly have written. That is a translation task, and translation is the thing these models do best.

This is not unique to Transputers. The same pattern shows up whenever an engineer maintains COBOL on a mainframe, ports FORTRAN to a modern cluster, or recovers the assembly listings of a 1980s BIOS. The bottleneck is rarely the grammar. The bottleneck is finding someone who still thinks in it. LLMs short-circuit that bottleneck — with the same caveat every time: the output is a draft to be checked against the datasheet, never ground truth.

How to use Claude Code for legacy work today

The tooling side of the story is the least controversial part. 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 mirrors the discipline of agent-readable repository structure — read, document, identify load-bearing assumptions, then act — and the session-continuity habits in agent sessions that survive context resets. The model is fast enough that the documentation step stops being the bottleneck. If you are formalizing how agents behave across sessions, the rules-file conventions are the natural place to pin the protocol down.

The part that survives the model swap

Every few 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 — or a team — on.

The part that does not 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 the next model ships — or when a team switches to a smaller local model for privacy — the protocol carries over. The model is interchangeable. The discipline is not.

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

That is also the honest summary of the Pemberton story. Strip away the color and what remains is a practitioner with an explicit protocol — sources gathered, semantics fixed, output checked against hardware — who used the model as a translator inside that protocol. The protocol did the epistemic work. The model did the typing. Build the protocol first, and the next model only makes it faster.

If you are building the durable layer your own agents render on — components that survive every model swap and platform reorg — start from OTF's templates: one component library, same props and behavior across web and native, so the substrate holds still while everything above it churns.

Sources

• The National Museum of Computing — museum homepage and Bletchley Park context: https://www.tnmoc.org/
• TNMoC events page (checked 2026-09-06; no Pemberton talk listing found — the account is reported as told, not independently corroborated): https://www.tnmoc.org/events
• Claude Code documentation — CLI install, surfaces, and usage: https://code.claude.com/docs