justin․searls․co

Is the tool bad or is it a skill issue?

Mitchell Hashimoto, founder of Hashicorp and, more recently, Ghostty in a post on his relationship with AI coding:

Instead of giving up, I forced myself to reproduce all my manual commits with agentic ones. I literally did the work twice. I'd do the work manually, and then I'd fight an agent to produce identical results in terms of quality and function (without it being able to see my manual solution, of course).

This was excruciating, because it got in the way of simply getting things done. But I've been around the block with non-AI tools enough to know that friction is natural, and I can't come to a firm, defensible conclusion without exhausting my efforts.

But, expertise formed. I quickly discovered for myself from first principles what others were already saying, but discovering it myself resulted in a stronger fundamental understanding.

  1. Break down sessions into separate clear, actionable tasks. Don't try to "draw the owl" in one mega session.
  2. For vague requests, split the work into separate planning vs. execution sessions.
  3. If you give an agent a way to verify its work, it more often than not fixes its own mistakes and prevents regressions.

More generally, I also found the edges of what agents -- at the time -- were good at, what they weren't good at, and for the tasks they were good at how to achieve the results I wanted.

I recorded an interview on the freeCodeCamp podcast a few days ago saying the same thing. Namely, that this reminds me of every other time programmers have needed to learn a new way to do something they already know how to do some other way. When I was teaching teams test-driven development, I always had to encourage them to force themselves to test-drive 100% of their code without exceptions so they're forced to actually learn the difference between, "this is hard because it's a bad tool for the job," and, "this is hard because I've not mastered this tool yet."

Over-application of a tool is an important part of learning it. And it applies just about every time we're forced to change our ways, whether switching from Windows to Linux, a graphical IDE to terminal Vim, or from Google Drive to a real filesystem.

Either you're the type who can stomach the discomfort of slowing down to adopt change, or you're not. And many (most?) programmers are not. They're the ones who should be worried right now.


Got a taste for hot, fresh takes?

Then you're in luck, because you'll pay $0 for my 2¢ when you subscribe to my work, whether via RSS or your favorite social network.

I also have a monthly newsletter where I write high-tempo, thought-provoking essays about life, in case that's more your speed:

And if you'd rather give your eyes a rest and your ears a workout, might I suggest my long-form solo podcast, Breaking Change? Odds are, you haven't heard anything quite like it.