Own what you ship

There's a principle I keep coming back to, and lately it feels more load-bearing than ever: own what you ship. If you can stand behind every line of what you build — explain what it does, fix it when it breaks, support the people using it — you're doing it right. How you wrote it matters far less than whether you understand it.

That's always been true. What's changed is how easy it now is to ship something you don't understand. I use AI every day — boilerplate, debugging, the boring parts — and I'm not interested in pretending that's a problem. It isn't. The problem is publishing code you've never actually read, can't explain, and won't be able to maintain. AI didn't invent that; it just made it possible at scale.

So I keep coming back to the divide I think is coming. Not between people who use AI and people who don't — that line won't mean much for long. The one that lasts is between builders who understand what they ship and builders who don't. The tools are about to make both kinds far more productive, which means the gap between them gets wider, faster, and a lot more visible. Two people can hand you the same working code; six months later, only one of them can still tell you why it works.

I know which one I want to be, and it's the same answer it would have been ten years ago. The tooling got louder. The bar didn't move.