The Craftsman's Case for AI

“A blacksmith forges their own hammer before forging a sword. The tool shapes the craft as much as the hand that wields it.”

Software is no different.

I stumbled onto the idea of software craftsmanship very early on in my career. Probably something I picked from the Agile dinosaurs back when I started coding. Whatever you think of the figures behind it, the concept stuck with me. A clear north star: get good at your craft. Treat code like a trade worth mastering. That felt compelling then. It still does.

The Toolbox

One piece of this puzzle was getting good at the tools you use. Historically, this meant mastering the Unix philosophy. It meant preferring the terminal and the CLIs, for direct manipulation of the file system, the actual state of the computer, rather than a proxied UI layer. It meant knowing IDE shortcuts and some obscure settings.

Also, craftsmanship involves ownership. You shouldn’t rely just on the tools your OS or your company provides. You need a personal toolbox which can travel with you from job to job and computer to computer. It’s the accumulation of your specific workflow optimizations over years.

Opportunity Cost

Until recently, there was a hard limit to this toolbox. We collected aliases and configurations, but we rarely built full-fledged software to solve our own minor inconveniences. The opportunity cost was simply too high.

I’ve already written about how AI coding unlocks us for building tools that can automate tedious workflows at our workplaces, improving internal tooling and what not. But another point where I think there’s massive leverage is in improving our personal workflows.

You can script complex automations for your specific development environment that maybe no one else needs, but which make you significantly more effective. Because ideally, software should fit you like a craftsman’s tool fits their hands. Now that code is relatively cheaper, we can finally do more of that.

Compounding

I’ve been curating my dotfiles for many years now. Aliases, neovim setup, zsh tweaks, tmux keybindings and much much more. Everything looks and feels very familiar to me. You spend enough time somewhere, you make it yours.

But that used to evolve really slowly. It would take months for me to even attempt to adopt some tool or to try and customize a workflow. Now, it takes me minutes. I can spin up an agent and set things up in no time. Undo, change, integrate with other tools, anything is possible. And it’s fast.

Besides, I can now create small tools or scripts, and build experiments like Shadow Claude.

Another thing I built recently was a window/workspace manager for macOS, which I was never happy with (having tried many alternatives over the years). I spent an afternoon with an agent and built exactly what I needed: iurysza/ultra. Just portable, simple, mine.

These are not that impressive, I know. But these things compound nicely. Over time what you get is a system that’s familiar, which can massively augment your capacity to investigate a bug, to analyze some state, to have a clear grip of what’s going on.

To seamlessly jump between different parts of a system in a smooth and natural way. Tasks that require multiple steps can be reduced to a single command. This composition is the real unlock.

Nerd Sniping

There is one major caveat. With the barrier to entry lowered, the risk of nerd sniping yourself increases.

Just because you can build a tool for everything doesn’t mean you should. It’s now even easier to fall into the trap of spending hours building things just because.

Conclusion

You are no longer limited to the tools you can buy or the scripts you have time to painstakingly write. If you treat your development environment as a product you own, AI allows you to forge exactly the tools you need to be a master of your craft.

That’s honestly one of the most compelling use cases of AI-coding to me. The meta layer. Improving your ability to do your work. This also helps to approach another major point now: developer grief in the face of these changes. But that’s the topic for another article.