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.

Why I Built an AI Assistant for My Blog

I wanted my blog to do more than list posts. I wanted visitors to be able to ask natural questions about me, my work, and anything I’ve written, and get answers that cite the right articles without me hand. In my previous post I laid the infrastructure groundwork by running n8n on Azure as an orchestration layer. This article goes deeper into how I assembled the chat assistant itself and wired it to semantic search so it actually “knows” my content rather than doing a brittle keyword lookup.