Making it a habit

Making it a habit is closing the gap between knowing how something works and using it, which is where most people who read a course like this quietly stop. Nine lessons of mechanics. This one is about that gap.

What does a good task look like?

After a while you stop thinking about it and just know. Until then, here is the test, and it has two halves that both have to be true.

Could you describe what a good answer looks like? If yes, it is a candidate. If you cannot say what finished means, you will accept whatever arrives.

Would you notice if it were wrong? Either because the mistake would be obvious, or because you can check in under a minute.

Both true: hand it over. Only the first: hand it over and check properly. Only the second: you need to think about what you want before you ask. Neither: do it yourself, or work out what you want first, which is the real task anyway.

Where it earns its keep, concretely

Not a list of capabilities. A list of the moments in a week when reaching for it is obviously right.

• You are staring at a blank page. A bad first draft in twenty seconds beats a blank page for an hour, and you were going to rewrite it anyway.
• Somebody sent you something long. A summary aimed at a decision, as in lesson 3.
• You have to say the same thing to three audiences. One version, then rewritten for each.
• You know what you want and not what it is called. Describing the thing until it names it is a good use of five minutes.
• Something is in the wrong shape. Notes into a table. A transcript into actions. Ten emails into a list of what everyone wants.
• You need the argument against your plan. Ask for it directly. It is better at this than at agreeing with you, and you have to remember to ask.

Where it does not

• Anything where being subtly wrong is expensive and hard to check. Lesson 9, and the whole reason lesson 9 is in this course.
• Anything you would need to check line by line. Checking is slower than writing.
• Anything requiring what happened in the room. It was not in the meeting. It does not know that the finance director hates the word “streamline”.
• Deciding. It will help you think and it will produce something that sounds like a decision. The decision is yours and it is worth noticing at the moment you hand it over.

Two weeks, and a note

The only way to find your own version of the two lists above is to keep score for a bit, because memory is unreliable in a specific direction: you remember the impressive answers and forget the twenty minutes you lost to a task that was never going to work.

For two weeks, one line whenever you use it. Anywhere, a notebook is fine:

Mon  Rewrote the supplier email          worked, 2 min, would do again
Mon  Asked it to explain the VAT rule    wrong, checked, 10 min wasted
Tue  Summarised the 40-page report       worked, saved an hour
Tue  Tried to get it to plan the count   6 messages, gave up, did it myself
Wed  Drafted the stock take procedure    good first draft, heavily edited

Two weeks of that and the pattern is obvious. Everyone’s is different, and everyone’s surprises them in one direction or the other.

The specific thing you are looking for is the repeated entry. A task that appears three times in a fortnight with “worked” next to it is a project, from lesson 5. A task that appears three times with “gave up” is a task to stop attempting.

Knowing when to stop asking

The one habit worth building deliberately, because it goes against how a conversation feels.

Two corrections about the same thing, and you stop. Not three, not six. It came out wrong twice for the same reason, which means the problem is in what you asked rather than in what it did. Start a new chat with a better request, or do it yourself.

The reason this is hard: each correction feels like progress. You are closer than you were. And you may well get there on the sixth message, having spent longer than doing it by hand. Nobody notices this happening, which is why it is worth having a number.

Where to go from here

You have the mechanics: what it can see, how to ask, where to put standing context, what a document hides, and what goes wrong. Everything else is practice.

If you write code, part 2 of this course is the same material for Claude Code, which is a version of this that lives in your terminal and can edit your files and run your commands. It assumes a paid plan and eighteen lessons of your time, and it starts from scratch, so you can go straight to lesson 11.

If you do not write code, you are finished, and you have not missed anything. Part 2 is not part 1 continued; it is a different tool for a different job.

Your turn

Two weeks. There is no shortcut for this one.

Keep the log described above. One line per use, and be honest about the failures, because a log with only successes in it is a log that teaches you nothing.

At the end of two weeks, read it and answer three questions:

1. Which task appears most often with “worked” next to it?
2. Which task appears more than once with “gave up” or “wasted” next to it?
3. How many entries are things you would not have done at all otherwise?

Check: you can name one task to turn into a project from lesson 5, and one task to stop attempting. If you cannot name the second one, you have not been honest in the log, because everybody has one. Set up the project this week and write the stop-doing one somewhere you will see it.

That third question is the interesting one and it has no right answer. A high number means you are doing more, which may be good and may be busywork. A low number means you are doing the same work faster, which is the boring answer and usually the valuable one.

Recap

A task is a good candidate if you can describe a good answer and would notice a wrong one. Both halves matter.

It is good at first drafts, summaries aimed at a decision, reshaping things, naming things you can describe, and arguing against your plan. It is bad at anything subtly wrong and hard to check, anything needing what happened in the room, and deciding.

Keep a log for two weeks. The repeated success becomes a project; the repeated failure becomes a thing you stop attempting.

Two corrections about the same thing and you stop and rewrite the request.

That is part 1. If you write code, lesson 11 starts the other half. If you do not, this was the whole course, and it was meant to be.