What I Don't Automate

At some point in every build I do with Claude Code, I have to decide what stays manual and what gets automated. I’ve come to think that decision matters more than the automation itself.

I learned it the slow way. I once scripted a step that took about ten minutes a month, which saved me maybe five of them. Then an API changed underneath the script, and I spent an hour fixing it. That wasn’t a win. It was the same work moved somewhere I’d stop noticing it.

The trap of automating because you can

The easy trap is automating everything just because the tool makes it possible. When a model can write the script in a few minutes, it feels free, and that feeling hides the real cost, which arrives later as maintenance. Every automated step is something you now own: it can break, it can drift out of date, and it can quietly do the wrong thing while you aren’t looking.

So the cost of automation isn’t the writing. It’s the babysitting, and that stays hidden until the day an integration changes.

The bar I use now

Anything I automate has to clear three tests. It happens often enough to matter, the logic is stable enough that it doesn’t need constant attention, and getting it wrong is cheap to catch. A weekly data pull passes easily. A step I run twice a year doesn’t, no matter how annoying it is in the moment.

The third test is the one people skip. If an error would go unnoticed and cost real money before anyone caught it, I want a person in that loop, however boring the step is.

AI makes the automating part cheap. It doesn’t make the deciding part any easier.

What stays with me

Anything close to a judgment call stays on me. How to frame a number for a client is one, and whether a dip in traffic is noise or a real problem is another. Both look like things you could hand to a script, since there’s data involved, but the data doesn’t carry the context. A traffic dip in the week of a holiday and a traffic dip after a site change look identical on a chart, and only someone who knows what happened that week can tell them apart.

That’s also why I never let a script write the sentence that goes next to a number in a client report. The number can be assembled automatically. The explanation of what it means for that particular business is a judgment, and I want to be the one making it.

I don’t think that’s a permanent line, and I expect it to move. But right now the deciding-what-to-automate part is still the one that takes the most thought, and I’d rather spend my time there than on a script that saves five minutes.

That’s the same thinking I bring to the reporting systems I build for clients. The repeatable assembly gets automated, and a person stays on the interpretation.