Introducing kairos-lab
I want to introduce kairos-lab, a small CLI built to remove friction from first-time Kairos experiments on macOS and Linux.
I want to introduce kairos-lab, a small CLI built to remove friction from first-time Kairos experiments on macOS and Linux.
I've been working on ARM images lately. They are not application containers, but a distro-style image built from ubuntu:22.04 that installs large package sets, runs post-install scripts, enables services, and pulls NVIDIA repositories. It's much closer to OS assembly than a typical app container.
I wasn't surprised that building these images natively on ARM would be faster than doing it from an x86 machine using emulation. That part was expected.
What surprised me was how much faster it was.
Seeing a Raspberry Pi 5 consistently outperform a 3-year-old high-end Intel laptop by almost 2x forced me to re-evaluate some assumptions I had about build performance, hardware specs, and what "powerful enough" actually means when you're building ARM software.
Ten years ago I gave my first talk at FOSDEM. Back then I was pushing for better tooling to inspect systems, to avoid configuration drift, and for universal system descriptions (USD) — a way to consistently define Linux systems (see this talk).
2025 felt like a continuation of the momentum I built last year with Kairos—more code, more people, and more proof that collaboration beats any solo sprint. I spent the year balancing hands-on engineering with developer relations, and I kept learning that the best outcomes happen when we build with others, not just for them.
Ever since I started working on Kairos, I've wanted to test out Fedora Silverblue on the desktop. Not sure why I postponed this so much, but I finally pulled the trigger. Installation was fairly simple, though it got stuck every single time when trying to enable the third-party repositories. When this happened I was a bit scared that the whole experience was going to be the same. Fortunately, this hasn't been the case—quite the opposite.
We are the lessons we've learned along the way, and we try to apply them at different levels of our experience.
Last week, the open-source team at Spectro Cloud held a Hackweek. If you haven’t heard of the format, it’s basically a week where we don’t focus on the highest-priority tickets. Instead, we work on things we want to work on—whether it’s for fun, exploration, or finally giving some love to that neglected project in the corner. I find Hackweeks incredibly valuable. In fact, I’ve written about them before—once in 2020 and even earlier back in 2015. They spark ideas, rekindle curiosity, and sometimes result in something genuinely useful.
This post documents what it felt like to build software with AI—from a clean slate, minimal tooling, and a curious mindset. The goal isn’t to teach, because I’m not an expert on the topic of Coding with AI. I’ve been coding professionally for years, but working with AI like this is still new territory. These notes capture my experiments, prompts, roadblocks, and small wins along the way.
As we approach the end of 2024, I find it important to reflect on the milestones achieved this year and how they've shaped my journey as a software developer, technologist, and contributor to the Cloud Native ecosystem. This post is as much about sharing insights as it is about expressing gratitude for the opportunities and support I've received.