Persuading and encouraging Claude to build occam2go, an occam to golang transpiler.
David Boreham, February 24, 2026
The first part of why is that since Go the language was unveiled 16 years ago I'd been curious about the similarity between its concurrency features and those of the much older language Occam. The two share a common ancestry in Tony Hoare's CSP, although there may be a more direct relationship through Go contributors that had some prior exposure to Occam. It occurred to me that perhaps Occam could be translated into Go since Occam's PAR construct looks quite similar to goroutines. And of course they both have channels. The program that translated Occam into Go, if it existed, would be called a transpiler. A compiler that generates code in another high level language rather than machine code.
The other half of why came much more recently. A few weeks ago a team from Anthropic published the results of a project where they had used LLMs (specifically, Opus 4.6) to write a C compiler, in Rust. Not a toy compiler: one that could build the Linux kernel into a bootable image. That was obviously an impressive achievement but for me it was more interesting to read the varying reactions from other developers. In particular I saw many comments saying something to the effect that this wasn't such a big deal because LLMs essentially just regurgitate elements of their training data. The theory went like this: because there's the source code for many C compilers in LLM training data, an LLM can just somehow spit all that out when asked. This of course ignores the fact that most C compilers are written in C whereas Anthropic had generated a compiler written in Rust. But it set me to thinking: if I could get an LLM to write a compiler for a language that almost nobody has heard of, that doesn't appear in training data, then I could do that thing all of us yearn to do above all else: prove someone wrong on the internet.
Mix into all that my new year pledge to myself that I was going to post all my LLM sessions online (because people say all kinds of things about what they do with LLMs while providing no hard evidence), at least the ones that didn't contain sensitive material, and here we are. So let's dive into what happened:
Initially I had no idea whether a February 2026 LLM could write a transpiler for a language nobody had heard of so I began by engaging it in conversation about the topic in general. It seemed enthusiastic (LLMs are great at that) and asked if it could fetch some PDFs of books about Occam, so we agreed on a simple plan of attack and it got down to cutting code. Surprisingly it also seemed to have some ideas and understanding of the semantic similarities and differences between Occam concurrency constructs and Go's. Perhaps somewhere there's a Subreddit I don't know about... I used Simon Willison's invaluable claude-code-transcripts utility to extract each LLM chat session, beginning with that initial discussion, linked below:
The "that was easy" moment. At this point Claude had created a transpiler that at least ran, and processed a set of test programs it had created. As the designated human I did point out that none of the tests actually executed a transpiled program. After Claude told me that I was absolutely right, it fixed that by generating a set of "end to end" tests. Claude continued the remainder of the project adding more and more e2e tests without being asked again.
It occurred to me that simply leaving Claude to write tests for its own tool would never prove that we truly had a working transpiler. To do that we'd need to process at least one real Occam program from the past. Initially I hoped I could track down the source code for the iconic Mandelbrot set program used to demo the Transputer and Occam in the 1980s. That has so far proved elusive, although it's probably on a dusty 1600BPI tape in someone's garage. In the meantime I did find that UKC had continued work on the Occam language through the turn of the century and their code was available on GitHub: kroc. It contained various example Occam programs. The next phase of the project consisted of asking Claude to make those examples build and run. But before that, it turned out that kroc had a language extension to support modules (libraries). How that #INCLUDE mechanism worked wasn't obvious, so I fired up Claude in the kroc project and asked it to figure that out:
Armed with the analysis from "kroc Claude", I asked "occam2go Claude" to use that analysis to implement a simple version of the feature. This would allow the kroc example programs to be consumed. Also around this time Anthropic released Opus 4.6 (at least my Claude had it -- general availability would follow a few weeks later).
Now Claude had made a transpiler that in theory supported all the language features required to process the kroc example programs. In theory. Problem #1: the transpiler crashed both Claude and the host machine. Impressive! Obviously there was some sort of infinite loop/memory leak in play. Initially Claude wasn't too savvy. It continually tried to re-start the previous session (ended when it crashed). That just crashed again. It, I suppose understandably, didn't realize it was in the LLM equivalent of Groundhog Day. Once I gave it a hint that the command it was about to run would hang/crash, it was impressive to see Claude grind away at the problem. It wrote many test programs on the fly, working through pieces of the problematic source program, running with a timeout guard, until it had isolated the cause of the infinite loop. On this one particular problem it sure looked like AGI to me!
After grinding through fixing the parser hangs and other issues with the example Occam programs, I realized that Claude was capable of writing many more test cases than it had committed to the repository (I saw it generate countless test programs on-the-fly to diagnose problems). A human developer, at least this one, would have preserved those test programs and added them to the project. More tests, better, right? So I asked the LLM if it could generate more test cases:
More grinding, after which most of the example programs built and ran, leaving some unsupported "difficult" features:
At this point things were looking good, but all the example programs the transpiler had been able to run were quite simple and not exactly visually impressive as the Mandelbrot set would have been. A random Google search pulled up the online version of the original book: Programming in occam®2. I'd glanced at this site before, but hadn't realized it included source code for the book's example programs. One of those examples was an implementation of Conway's game of life. I had also found a kind of Mandelbrot program (not the original) in kroc. Claude was therefore asked to make either of those build. The Mandelbrot program proved too difficult because it used Occam-pi features that were beyond our scope. But the Conway life program did build, run, and made the "glider" fly across the screen (eventually):
The last part of the "debug into existence" slog in getting the life program to work was done by asking Claude to run it itself, rather than attempting to describe the problems explicitly:
I wanted to remove the life program's source from the project repository (since it's copyright protected), yet allow users to try running it. Because there were a few modifications to get the source code to be compatible with the transpiler's version of Occam, they wouldn't be able to just download it from the book web site. Working around this is a good example of a task so tedious that a human is unlikely to tackle it, but the LLM didn't complain or roll its eyes: it just got to work making a sed script that modifies the downloaded file in-place:
Et voilà! an Occam to Go transpiler that can handle some historical nontrivial Occam programs, entirely LLM-generated.