Every software system exists twice: once as the thing the team believes it built, and once as the thing that actually shows up after it ships. This blog lives in the gap between those two, which is also where I have spent most of my career, around production incidents, architecture decisions, and deployment pipelines.

I'm a software engineer by trade, but code as an isolated artifact interests me less than the system around it, meaning who owns it, how it gets deployed, and the places where teams quietly make up for missing structure with heroics. When something looks "simple," it often means someone else is holding all the complexity out of view.

Plenty of technical problems turn out to be something else. Most architecture problems are ownership problems, and a rollback plan nobody has ever practiced is mostly a wish. That layer under the code is what I want to write about here.

Some of these articles will be about software architecture, production operations, or engineering leadership, and others will be about AI, agents, local tools, and MCP servers, including why I care more about boring, useful work than clever demos. Every so often I will probably go off the rails, and that is part of the point.

The older I get, the less patience I have for shallow takes about technology. The best engineering conversations are rarely about frameworks, cloud services, or whatever architectural fashion is making the rounds this year. The interesting questions tend to be messier than that.

Who owns this after it ships? When the happy path breaks, can someone other than the original builder recover it, or does everything depend on a few people remembering the magic steps? And did we automate the work, or did we accidentally automate judgment?

This blog will be opinionated.

I don't think I have all the answers, but soft, careful, over-qualified writing tends to bury the lesson, and engineering is full of expensive lessons, so when I have learned one the hard way I would rather just say it.

I also expect my views to change. Systems, teams, and tools keep moving, and AI is reshaping software work faster than any of them, but clear ownership and practiced recovery have held up through all of it, because no amount of tooling can make up for a confused organization. You'll see some themes come back again and again, like boring production being a feature, fixing a problem once instead of many times, and the fact that you cannot scale heroics. I also believe leaders own failure while teams own success, and that the work isn't done until someone else can carry it.

One theme matters more now than it used to, which is that the future belongs to engineers who can specify work clearly. AI amplifies whatever you bring to it. It makes a strong engineer faster and clearer, and it makes vague thinking more confidently wrong just as easily, and what separates the two is usually specification, judgment, and taste far more than raw intelligence.

So this is my corner of the internet for thinking out loud about software, leadership, and the people underneath all of it. You can read without an account, and you'll need to log in to comment. I'm happy to host disagreement, but I have no interest in drive-by noise, because the point here is the discussion.

Welcome to the blog. Let's talk about the system after the code ships.