Becoming an AI Power User

On Monday you ask an assistant to summarize a long email thread for your manager. The summary comes back almost right, except that it retells the thread in order and buries the one decision your manager has to make. You move the decision to the top and send it. Two weeks later you ask for another thread summary and move the decision to the top again, because the first fix lived only in your head. Good surprises disappear the same way. A throwaway question once turned your scattered trip notes into a packing list sorted by which bag each item goes in, and now you cannot remember what you asked. Both times the conversation taught you something and nothing carried it forward, so the next attempt cost as much attention as the first.

The loop has four steps, and they are the labels in the picture below: try an approach, inspect the result, test a change, and save what helps. The notebook in the picture holds the example this section follows. A morning brief is the short rundown of your day that an assistant writes from your calendar, and the two saved pages compare a day with an all-day event and a day without one.

Ask why a weak AI answer fell short

A weak answer becomes useful once you ask why it fell short. The assistant may have lacked context, misread the goal, ignored a requirement, failed to find a source, or hit the limit of what it can do. Ask it to list possible explanations with the evidence for each, then test the likeliest one first. An explanation that sounds convincing is where the testing starts.

Suppose your morning brief looks fine for weeks, and then one Tuesday it says nothing about the conference that fills your whole day. The calendar shows the conference as an all-day event, a banner across the top of the day with no start or end time. You ask the assistant which entries it read. If the conference is missing from that list, look at retrieval first: the calendar connection or the dates it reads. If the conference is on the list and absent from the brief, the summarizing step is the likely place it dropped out, so add an instruction: "Open with any all-day event, then list the timed ones."

Once Tuesday's brief mentions the conference, save copies of two days as test cases: that Tuesday, and an ordinary Wednesday with no all-day event. On Tuesday the brief should open with the conference. On Wednesday it should go straight to the meetings without inventing a banner event. Those are the two pages in the notebook.

Saved test cases recheck old failures whenever you change an AI instruction

A month later you want the brief to flag scheduling conflicts, so you add a second instruction. Before you trust it, rerun the two saved days. If the conference has dropped out of Tuesday's brief, the old failure is back and the new instruction is the first suspect; run Tuesday with and without it to confirm. Either way, you find out today instead of on the morning you miss the conference. Once both days pass, add a third saved day with two meetings that overlap, because that is the failure the new instruction exists to catch.

Each repair leaves a saved case behind, so every later change is rechecked against every failure you have already fixed. After a few repairs the set might hold the conference day, the quiet Wednesday, the day with overlapping meetings, and a day with a call in another time zone. One request reruns all of them: "Write the brief for each saved day and compare it with what each day should show." You stop having to remember which fixes a new instruction might break, because the set checks them for you.

AI performance can vary sharply between tasks that look alike, so success on one task tells you little about the next. A brief that handles meetings well can still fumble all-day events. Test the kind of work you intend to hand over, with the sources and tools that work will use. The assistant can run those comparisons and report what it found. Before you rely on its verdict, check that it catches the failures already in your saved set.^[1]

Store each AI lesson where the next similar task will load it

A correction you keep typing belongs in a standing instruction. An invented claim calls for a verification step, such as "Check every date against the calendar entry and cite it." Keep a result you loved whole, as an example of what good looks like. A failure you repaired goes into the test set, next to the fix. Keep each one where the next similar task will load it, such as a saved prompt, a project's instructions, or a file of examples.

The loop can start from delight as easily as from an error. Say you ask for a trivia game for a family reunion and discover the assistant can write each clue at three difficulty levels, so the kids and the grandparents can play together. Save the request that produced it, and the next game starts there. Play turns up uses you would never have put on a task list, and comparing the results with what you wanted shows which of them to develop.

Try, inspect, test, and save in whatever order the evidence suggests

The four steps in the picture follow no fixed order, though a repair still gets tested before you save it. A test may show that a repair made things worse and send you back to inspect. A playful attempt may produce something good on the first try, and then the thing to save is the attempt itself. On a one-off task, stop at whichever move gave you what you needed. A repair you mean to reuse gets tested before it is saved.

A project you care about shows which AI practices to build

Try these steps on a project you care about, and they start to combine. Say you are organizing that family reunion. The trivia game you made on a whim becomes the evening's main event. A check of the RSVP summary against the replies catches two cousins the summary left out. The reminder email you have now written three times becomes a saved routine. The project supplies the reason for each piece you save, so you build what the work needs and nothing for its own sake.