Interpretability first showed up on my radar with Golden Gate Claude. Anthropic published a version of Claude that had been steered to be obsessed with the Golden Gate Bridge, so that it would contrive amusing excuses to bring it in to every conversation. At the time I didn’t really understand the technical details or even know what this kind of work was called. But it seemed interesting!

This year, I discovered that the field is called interpretability, and the strand of it I had read about is mechanistic interpretability: the project of understanding what a neural network is doing at the level of weights and neurons. Interpretability is interesting for its own sake (what are these things we call LLMs?) but it’s important within the broader field of AI safety: how can we make sure AI goes well?

Read more »

Bluedot recently published a fun technical AI safety puzzle. You get a frozen sentence encoder feeding a little classifier head that predicts eight features. The first and second tasks are to find and then describe a non-linear feature inside the model. The third asks you to train a model with an “even weirder representation”. I’ll write up my actual puzzle answers once the submission deadline has passed.

This post is about something I found while mucking about trying to make weird representations. Many of the things I was doing to change the representations were “signposted” by having to amend the model structure. I liked the idea of a model that appeared normal but had some sneaky secret. (This has obvious implications for AI alignment.) Playing around with the loss function did work a bit, but even better was “poisoning” the training data. That doesn’t give you a weird representation but it does give you a backdoor: secret behaviour that can be triggered by a passphrase.

Read more »

I was invited to speak at this year’s AI Engineer Europe conference on the topic of how to do AI-native engineering in big tech companies with a cool demo planned. Sadly, my extremely peculiar employer refused me permission to speak. So you’re reading this instead of watching a talk.

If you’re trying to do meaningful, novel AI work inside a big company (not just Big Tech, with capital letters), it’s difficult because you’re being squeezed from two sides simultaneously. I’ve seen teams respond in a way that makes things worse. Here’s what I think actually works.

Read more »

Sheffield has always been the doe-eyed ingenue compared to the oi-oi-oi brashness of Manchester and whatever it is that Leeds is. Many are attracted by the climbing and the trees. Fewer are attracted by the local tech industry.

I’ve worked remotely since moving to Sheffield four years ago, so I’ve never had much reason to care about the local scene. That changed when I was nearly made redundant and suddenly found myself asking: what software companies are actually based in Sheffield? Turns out the answer wasn’t easy to find. There’s no single page listing the IT and tech companies here, what they do, or what kind of developer jobs they offer. So I made this one.

Read more »

2026 note: this is an old build log, not current advice. I am leaving it up because it still captures the useful bits of trying to run Kubernetes cheaply on Hetzner Cloud, but I would reach for a managed cluster now unless I had a very specific reason not to.

This post is a guide to setting up a bare-metal Kubernetes cluster on Hetzner Cloud.

Why? Well, previously I had a couple of applications running on a Google Cloud virtual server. They were running on FreeBSD because my original plan had been to use it as an opportunity to learn a bit about FreeBSD. This failed because I’d forgotten that the end goal of setting up a server is to interact with it as little as possible. Once things were working I didn’t really want to dick around with it and so my main FreeBSD-specific experiences were limited to fiddling about getting things to build properly. Because I didn’t interact with the server very often I kept forgetting how to do things and had to rely on past me having thought to write copious notes. Doing per-application backups was a bit fiddly and generally I didn’t have good visibility on what was going on. Since I wanted to play with Kubernetes anyway I thought it would be a good opportunity to improve my deployments, backup strategy and general plumbing.

Read more »

I wrote a Game Boy emulator in Go called Goboy. This was not because the world was desperately crying out for another Game Boy emulator. It was because emulators are a lovely excuse to learn how real machines work without immediately drowning in modern hardware complexity.

The posts below are a build log rather than a pristine tutorial. That means there are wrong turns, mildly embarrassing bugs and a lot of “I thought this would be simple and then it was not simple”. I think that makes them more useful. Most emulator write-ups show the final clean architecture. Real emulator development is more like discovering that one bit in one register was supposed to be read-only and that your entire mental model has been quietly wrong for three days.

Read more »

This is part of the Writing a Game Boy emulator in Go series.

One of my aims with Goboy was always to deploy a web-based version using Webassembly. It actually turned out be remarkably straightforward (see here).

The first step is to build for the Webassembly architecture. Following the instructions in the Go repo, the build incantation was simple:

GO111MODULE=on GOOS=js GOARCH=wasm go build -o builds/wasm/goboy.wasm cmd/goboy/main.go

That ran in the browser using the helper JavaScript specified in the Go repo. Ebiten, the game runner library I’m using, supports Webassembly and so things were painless.

Read more »

This is part of the Writing a Game Boy emulator in Go series.

Goboy is nearly completion – well, as complete as a Gameboy emulator can ever be. My wife was volunteering in Phnom Penh for a few weeks and I had intended to use the time to implement the audio unit. As things turned out I ended up spending a few weeks chasing down various bugs. There is still some errant flickering sprites that I haven’t had time to debug yet and the audio remains unimplemented. Those two aside, though, Goboy is in much better shape.

Read more »

This is part of the Writing a Game Boy emulator in Go series.

Goboy has reached a major milestone – a working display!

Recently, my development process has been a bit unorthodox. My wife and I are spending this year travelling and so I only have bits of time between the many, many temple visits to program and blog. The display is the most complex single component of the Gameboy and, in my opinion, implementing it is pretty much an all or nothing job. You can’t really built it piece by piece as you can with the instruction set. Each time I worked on the display it took me a little while to rebuild my mental model of how the display works and all of its (sometimes obtuse) details. I had started work on the display while we had a solid block of time in one country. I was also working remotely at this time so progress had been pretty slow and I was worried I wouldn’t finish it before we started moving again. The thought of having to tackle this pile of half-finished, broken code on a series of night buses did not appeal.

Read more »

This is part of the Writing a Game Boy emulator in Go series.

Finally the opcodes are implemented. I took the approach of getting all of the opcodes implemented and unit-tested before moving on to other components. In retrospect I wouldn’t recommend this approach because you go through a long period with nothing really to show for it. On the other hand, once the opcodes were done all I had to do was implement basic ROM loading and all of the blargg test ROMs would pass straight away, right?

Read more »