Platform Engineer.

I'm a tinkerer at heart — the kind of engineer who wants to know what's actually happening under the abstraction, not just that it works. That instinct is what pulled me toward platform engineering: the layer between code and production, where infrastructure decisions either quietly hold everything together or quietly break it.

Most of my work sits on two fronts. The first is CI/CD: I design pipelines that scale under load and forget everything once a job ends, so nothing lingers between runs and nothing breaks quietly from leftover state. I think about this the way an architect thinks about load — where the bottlenecks will form, what happens when ten jobs land at once, what should be stateless versus what actually needs to persist. That thinking is what I bring, regardless of which platform ends up running it.

The second is Kubernetes security. I work at the kernel level — capturing what a process actually does, not what it claims to do, and turning that stream of behavior into something queryable: a graph where you can ask "has anything ever talked to this service before" and get a real answer. That's the core of kubelock, a project of mine that models cluster behavior this way. The interesting part isn't the capture itself, it's the modeling — deciding what "normal" behavior even looks like for a cluster, so that a deviation means something instead of just being noise.

That same instinct extends to networks — I don't just configure them, I can reason about how a network should be built from first principles: what needs to talk to what, where the trust boundaries sit, what happens when a link fails. It's part of why I write low-level code for the same reason people do crosswords — a DNS resolver from raw packets, an MQTT stack, aCHIP-8 emulator, a reflection library inZig. None of it ships to production. All of it teaches me something the frameworks hide.