The hardest thing to find in language learning is a patient French speaker at 7:15 on a Tuesday morning, when I have twenty minutes and feel like talking about my weekend. Years of courses, grammar, vocabulary, and audio lessons never fixed that scarcity. Conversational GPTs have not solved language learning, but they gave me the one thing I could never manufacture on my own, which is volume: hundreds of ordinary conversations, available whenever I want one.
I have always thought of my brain as fixed storage: long-term memory like a hard drive, short-term memory like RAM, both finite. That is why context switching hurts. It is not just that you stopped one thing and started another, it is that you had a whole working set loaded in your head and something flushed it. We talk about AI context windows now, but people have them too: limited working space, long-term storage with strange indexing, facts we keep, facts we ignore, and a childhood TV theme song that apparently holds a lifetime lease.
Who designed this mess? Every engineer has asked it over a strange workaround, an awkward abstraction, or a manual deploy step. Hiding inside the question is one of the easiest mistakes in engineering, the assumption that the person before you should have known better. Sometimes the work is careless, but a lot of the time you are looking at context you don't have. Before criticizing a design, learn what its author was up against, then fix what is still broken.
Ctrl+Z may be the most trusted keystroke in software, but production systems aren't text editors. Every conversation about AI agents eventually turns into a conversation about trust, and the useful kind of trust comes from knowing what happens when the agent gets something wrong. Undo is an operational discipline that runs from design and validation through rollback, compensation, and learning, and the more we let agents act instead of advise, the more that discipline has to exist before we hand them the keys.
'I am the only one who knows how to do this' sounds like a flex, but most of the time it means part of the system only works because you are standing next to it. Working yourself out of a job means removing the broken, fragile, one-person-dependent parts of your work so the system no longer needs babysitting. The engineers worth keeping make their hardest problems boring, hand them off, and earn their way into bigger ones.
The demo worked, the team hit the date, and everyone felt good for about thirty minutes. Then the support tickets started. Boring software can be as clever as you like to build. The part that should be boring is running it in production, with practiced rollbacks, clear ownership, and nobody relying on heroics to get through the week.
Every software system exists twice: once as what the team believes it built, and once as what shows up after it ships. This blog lives in the gap between the two, writing about ownership, deployment, operations, and the people underneath, starting from the idea that most architecture problems are ownership problems.
