About

I didn’t fall in love with coding right away.

My first job placed me at a software company before I’d made a deliberate choice about what I wanted to build. For a while, it felt like a relationship of convenience. Then something shifted. It wasn’t a single moment, but a slow accumulation of watching code turn into something tangible the instant you hit run. That literal magic, an idea becoming a system, a system becoming something someone else can use, is what eventually pulled me in completely.

I’ve been building backend systems and distributed infrastructure for over five years now, across cloud platforms, hypervisor environments, and SDK design. I work with Python, Java, and C#/.NET, and I’ve spent enough time debugging silent failures at scale that I’ve developed strong opinions about what good infrastructure actually looks like under pressure.

How I think about systems

Most systems I’ve inherited were built for the moment they were needed. Convenient for the team that wrote them, but brittle for everyone who came after. I build differently.

I think about code the way a civil engineer thinks about a bridge: not just “does it hold today” but “what happens in ten years when the load changes and the original team is gone.” That means reusable abstractions, clear separation of concerns, and architectures you can extend from rather than fork around. It’s harder and sometimes exhausting, but it’s the only kind of building that compounds.

When I’m debugging something unfamiliar, the first thing I do is map the architecture. I don’t fully trust logs until I understand the system that generated them, because logs reflect the intent of whoever designed the logging, and not everyone thought carefully about intent. When I do understand the system, I can work fast: narrow to a component, form a hypothesis, assess it against what the data actually says. What I’m always looking for is the thing that only becomes visible when you put multiple sources together. The bug that looks like nothing in isolation but screams when you line it up against three other signals.

That instinct is what eventually led me to build LogIQ, an AI-powered investigation tool born out of a particularly painful on-call incident involving a silent VM creation failure that only revealed itself when I correlated Splunk streams, Jira tickets, customer logs, and a developer reproduction environment simultaneously.

What I’m chasing

The AI space is loud right now, and most of the noise sounds the same.

I’m not interested in being another engineer who wires together LLM APIs and calls it a product. I’m interested in finding the places where AI genuinely changes what’s possible for backend systems and infrastructure, where the architectural decisions around agents and tools and permissions actually matter, and where someone with a deep systems background can bring something the typical AI-first engineer can’t.

I want to bring a fresh perspective to how AI gets built into production systems, not as a feature sprinkled on top, but as something designed from the ground up with blast radius, observability, and long-term maintainability in mind. The same principles I apply to any system.

What I care about beyond the terminal

I play tennis, and the sport has shaped how I approach technical work more than I’d initially admit. Tennis is a game of pattern recognition, rapid hypothesis testing, and adjusting mid-rally when what you expected doesn’t happen. Debugging distributed systems under pressure turns out to work the same way.

I was also a Zumba instructor for a while. Teaching a room full of people with different skill levels how to move together, keeping energy high, reading who needs encouragement and who needs space, that experience made me a better collaborator and a more thoughtful technical lead than any engineering course did. When you’ve had to hold a room’s attention while keeping 30 people moving in sync, running a post-mortem or onboarding a new team member feels manageable.

What I’m writing about here

This blog is where I think out loud about infrastructure, AI agents, and building systems that hold up. Not tutorials. Not hot takes for engagement. Just the kind of writing I wish I’d found earlier in my career, honest about where things break, specific about why, and genuinely trying to leave the reader with something useful.

If something here resonates, my X (Twitter) is where the shorter version of these thoughts lives.

I’m always open to a conversation with engineers who care about the same things.