When not to use AI for this

Everyone writes about what these tools can do. Almost nobody writes about the times when reaching for one makes the work slower, or worse, or both. Which is odd, because if you use them every day you have hit all three.

This isn't me being sceptical. I use these things constantly and I sell a few. It's just the shorter and more useful list: the situations where I've learned to put the model down.

The first is when you can't tell whether the output is right.

Every time you use a model there are two costs, not one. There's the cost of producing the thing, which is the part that gets advertised, and the cost of checking it, which doesn't. When you know the subject, checking is cheap. You read it, you spot the two places it went wrong, you fix them, and you're ahead. When you don't know the subject, checking is the entire job. Now you're sitting in front of something fluent and confident about a topic you can't evaluate, which is a worse place to be than the blank page you started with. At least the blank page was honest about what you didn't know.

There's an easy test for this. Before you ask, try to describe what a wrong answer would look like. If you can't, you're not ready to use a tool that sometimes gives you one.

It's why "write me a contract" and "explain this contract" feel like the same request and aren't close. In the second one you're checking a summary against a document sitting right in front of you. In the first one you're signing something you can't audit.

The second is when the task is the thinking.

Some writing exists to hand someone a conclusion you already reached. Some writing is how you reach it. The two look identical on the page and they're completely different jobs, and only one of them can be handed off.

If you've ever written a long message to someone, worked out halfway down that you were wrong, and deleted the whole thing, that was the writing doing its job. A model won't do that for you. It'll give you a clean, well-organised version of whatever argument you asked for, including when the argument is bad. It has no stake in whether you're right and no way of noticing that you aren't.

Strategy documents, difficult emails, post-mortems, anything where you're still working out what you actually think: write those yourself, badly, and then use the tool to tighten up whatever survived. The order matters more than the effort does.

The third is when the input is the hard part.

A lot of work that looks like writing is really deciding. The reason a page is hard to write usually isn't the sentences. It's that nobody has settled who it's for, or what it's supposed to make happen, or which of the four things it currently claims is the real one.

Give a model an unclear brief and it'll produce something anyway. It'll be well-formed and about nothing in particular, and the vagueness that was sitting in your brief is now spread thinly across nine hundred words where it's much harder to see. You haven't solved the problem. You've made it longer.

You can tell you're here when you keep regenerating. Once is a bad roll. Three times means the instruction is the problem, and no amount of rewording the prompt will fix a decision you haven't made yet. Stop, write one sentence saying what the thing is for, and most of the time you'll find you can write it yourself now.

There's a fourth, and it's the one I get wrong most often. Small tasks that are just faster by hand.

Opening a chat, explaining the context, waiting, reading it, correcting it, pasting it back. Call it ninety seconds of overhead. A surprising amount of work is under ninety seconds. Renaming a few variables. Writing one email. Checking one number. The tool isn't slower at the task. It's slower at the whole loop, and the loop is the bit you actually pay for.

The reason this one sticks is that it never feels like a loss. It feels productive. You were doing something the entire time.

What connects all four

In every one of these the model is doing the part that was never the bottleneck. The words were never the hard bit. Knowing what to say was. Or being able to tell whether it came out any good. Or the fact that asking took longer than just doing it.

So there's a question worth asking before you reach for it, and it takes about five seconds. What's actually hard about this? If the answer is producing the words, or the code, or the first draft, these tools are genuinely brilliant and you should use them without feeling bad about it. If the answer is knowing what should be produced, or being able to judge whether it's any good, you haven't found a use for the tool. You've found a way to look busy while the real work waits.

I'd rather sell you something with that written on the box.

← All notes