There is something strangely satisfying about opening source code that is almost three decades old.

Not because it is beautiful. It isn’t. Not because you remember how everything works. You definitely don’t. But because every line tells a story about a younger version of yourself who somehow thought “future me will understand this.” Spoiler: future me did not.

Back in 1997 I wrote CaveRace, a small DOS arcade game about collecting treasure, avoiding monsters, blowing up rocks, and trying not to blow yourself up in the process. Nothing revolutionary, just a fun little game made with the tools we had at the time. Over the years it lived on different computers, went through a DirectX rewrite, eventually made its way to Windows Phone, and then quietly disappeared. I never really forgot about it, though, and this year I sat down to answer a simple question: could I rebuild CaveRace today as if starting from scratch, while keeping the original gameplay completely intact? The answer became CaveRace 1.5.

I recently started rewriting CaveRace, a game I originally built in C in 1997. The old version was written for MS-DOS using Borland C, VGA Mode 13h graphics, and a little x86 assembly. Rewriting it is a good excuse to revisit the game and experiment with a modern systems programming language.

For this version, I chose Odin together with Raylib. Odin feels familiar when coming from C, and its official vendor collection already includes Raylib bindings and native libraries. In theory, getting a window on the screen should be as simple as importing Raylib:

AI is not replacing software engineers. It is amplifying them. The question is whether it is amplifying good engineering practices or bad ones.

Artificial Intelligence has fundamentally changed software development. Today, a developer can generate APIs, database layers, tests, infrastructure templates, documentation, and even complete features in minutes. Tasks that previously required days of work can now be completed during a single coffee break.

The productivity gains are real. However, many engineering organizations are discovering a less visible side effect: they are shipping more code than they can actually understand.

The box arrived today, just in time before the holidays, sitting on my doorstep like a time capsule. The moment I saw the familiar Commodore logo on the packaging, I had to pause. It wasn’t just another retro gadget. It was the Commodore 64. Or at least, as close as we’re ever going to get in 2025.

I tore open the cardboard (carefully, because let’s be honest, I’ll probably keep the box) and there it was: the Commodore 64 Ultimate, in all its beige glory. The weight of it, the shape, even the slight texture of the plastic, it all felt right. Like holding a piece of my childhood again.

I’ve been watching Model Context Protocol (MCP) servers pop up everywhere as the glue between AI agents and the real world. The pitch is simple: expose tools and data through a standard protocol and suddenly your AI agents can plan trips, analyze documents, query databases, or in my case, work with maps. MCP clicked for me because it’s opinionated where it matters and unopinionated where it shouldn’t. It standardizes how clients and servers talk, but it doesn’t box you into a single stack. Think of it as the USB-C of AI integrations: one cable, many devices.  

A personal history in a few very nerdy chapters

Pac-Man

The first “computer” that really knocked on my brain wasn’t even called a computer. It was an Atari 2600 with those giant wood-paneled vibes, a plastic spaceship parked under a living-room TV. Somewhere far from home (friends of my parents), the kind of visit where adults drink coffee forever, I met Pac-Man and the notorious E.T. They weren’t just games, they were a portal. The graphics were blocky miracles, the sound was pure electricity, and my head did that little swivel where a new obsession clicks into place. I didn’t own one. I barely got to touch it. But the idea got in. That was enough.