Chapter 11: Better Conversations and Better Results ⚡

September 2, 2026

This entry is in the series Get on board with Artificial Intelligence

⚡ FAST TRACK

What’s left after the basics

You now have the mechanics of a single conversation and a way to build the request. Together those cover the great majority of everyday use, and if you stopped here you would already be more effective than most people using these tools.

This chapter is the layer above: the techniques that separate someone who gets good answers from someone who gets work done. Most of them involve giving up the idea that a conversation is a place where you ask for things.

Two modes, and the mistake of confusing them

Almost every AI session is one of two fundamentally different activities, and people run into trouble when they use the technique for one while intending the other.

Production mode. You know what you want and you need it made. A draft, a summary, a table, a rewrite, a plan in a known format. Success is a finished artifact. Here you should specify heavily up front (full CLEAR) and iterate toward a target you already hold in your head.

Thinking mode. You do not know what you want. You are working out what the problem is, what the options are, what you actually believe. Success is a better-formed idea, and the artifact may be nothing at all. Here heavy specification is counterproductive, because specifying requires knowing, and knowing is the thing you lack.

In thinking mode, the moves are different:

I’m trying to decide something and I haven’t worked out what the actual question is. Let me talk through it and interrupt me when something doesn’t follow.

Don’t give me advice yet. Just tell me what you think I’m actually worried about, based on what I’ve said.

What are the three ways of framing this problem, and what does each one make invisible?

Many people use AI only to produce something they have already imagined. Give yourself permission to use it in exploration mode as well; that is where unexpected options and new connections often appear.

Decompose the work

The largest single improvement available to an intermediate user is breaking big tasks into stages instead of asking for the finished thing.

A request for “a marketing plan for my new service” produces a document with the right headings and no substance. The reason is structural: every section is generated in one pass, each getting a fraction of the attention, none informed by the thinking that should have preceded it.

Do it in sequence instead, in a single conversation:

1. Here’s my service and my situation. Before anything else, what questions would you need answered to build a real plan? Answer them.

2. Given that, who are the three most plausible customer segments and which is most reachable for me? Decide.

3. For that segment, what are five channels, ranked by fit with my budget and time? Decide.

4. Build the plan around what we’ve settled on.

Four exchanges. Each stage constrains the next, and each contains a decision you made. The final document is specific because the conversation that produced it was specific.

This is also how you keep control of work you are delegating. A plan assembled from four choices you made is yours. A plan produced in one shot is the model’s, and you will discover its assumptions only after acting on them.

Set the standard before you see the output

Ask for something and you will judge what comes back against a vague internal sense of good. Ask the model to define good first, and you get a rubric you can apply.

Before you write it: what distinguishes an excellent version of this from an adequate one? Give me five criteria.

Read the criteria. Correct them; this is where you discover what you actually care about. Then:

Now write it, and afterward score it against those five criteria, with the weakest one first.

Two things happen. The output improves, because the model is generating against explicit targets. And you get a self-assessment that, while not authoritative, reliably points at the section you should look at hardest.

Separate the maker from the critic

Preference training rewards agreeableness, which helps explain why a model flatters. Framing the work as someone else’s provides a useful workaround.

The stronger version is structural. Use two conversations.

In the first, produce the draft. Then open a fresh conversation, paste the draft with no history and no indication of where it came from, and ask for a hard critique against specific criteria.

The second conversation has no investment in the first. It did not write it, it has not been agreeing with you for twenty messages, and it does not know you want it to be good. The critiques are noticeably sharper.

Then take the critique back to the first conversation and work through it. This maker–critic loop is the closest thing to a professional editorial process you can run alone, and it costs about three minutes.

Give it more of your material than feels natural

People paste a sentence and expect the model to infer a world. Then they conclude the output is generic.

Paste the whole email thread, not your summary of it. The full document, not the paragraph you think is relevant. Three previous examples of your writing, not a description of your style. The actual data, not your characterization of the pattern.

Two reasons this works. Models are far better at extracting what matters from material than at inventing material that is missing. And your summary has already discarded the detail you did not know was important, which is frequently the detail that determines the right answer.

The caution is Chapter 25’s: everything you paste goes somewhere. Know your settings before you make this a habit with work material.

Make it show the reasoning before the conclusion

For anything analytical, ask for the working before the answer:

Work through this step by step before giving me a conclusion.

This genuinely improves accuracy on multi-step problems, and with reasoning models much of it happens automatically. But the more important benefit is inspectability. A conclusion you cannot examine is a conclusion you must either accept or reject wholesale. A chain of steps lets you find the exact point where it went wrong, and it is usually one identifiable step, not the whole analysis.

Remember the earlier caution: a stated chain of reasoning is generated text, not a transcript of an internal process. It is useful for finding errors, not proof that no errors exist.

Ask what would change its mind

The most useful calibration question I know:

What evidence would change this conclusion? What would I need to find out for the opposite to be true?

An answer resting on solid ground produces a specific, checkable list. An answer resting on nothing produces vagueness. You learn something about the reliability of the response without leaving the tool, and you get your verification list as a byproduct.

Its companion:

How confident are you in each part of this, and which part would you check first if you were me?

Use confidence rankings to decide what to inspect first, while relying on evidence for the final judgment.

Carrying context across sessions

Good conversations accumulate context that is genuinely valuable and easily lost.

Hand off deliberately. Before abandoning a long conversation:

Write a briefing paragraph I can paste into a new conversation: the situation, the decisions we’ve made, the constraints, and what’s still open.

Use project features where available. Most major tools now offer a workspace that holds instructions and files across many conversations. If you have recurring work, this is worth setting up once rather than re-explaining weekly.

Keep your own file. A plain document with your situation, your preferences, your standing constraints. Paste it at the start of anything significant. This is tool-independent, survives every product change, and becomes the seed of a personal system.

Knowing when to stop

Three signals that a conversation has stopped paying.

Diminishing returns. Three consecutive exchanges that improve nothing. Take the best version and finish it yourself.

Circling. The same correction, given twice, not applied. Start fresh.

Outsourced judgment. This one is subtler and matters more. Stop when you notice yourself asking the model what you should think. Use it to generate considerations that help you think, then weigh those considerations in the context of your own life. Plausible advice can quietly displace a conclusion you needed to reach yourself.

The best users of these tools end sessions with a clearer view of their own reasoning. If yours end with less, that is worth noticing early.

Exercise 11.1: Run one conversation in thinking mode

Take a decision you have been circling. Open with: I don’t know what I actually want here. Don’t advise me yet. Just ask questions until we’ve found the real question.

Notice how different this feels from asking for a recommendation.

Exercise 11.2: Build the maker–critic loop

Produce a draft of something real. Open a new conversation, paste it with no context, and ask for a hard critique against five criteria you specify.

Compare that critique to what the original conversation says about the same draft. The gap is the flattery effect, measured.

Exercise 11.3: Decompose something you’d normally one-shot

Find a task where you would ordinarily ask for the finished product. Break it into four stages with a decision at each.

Compare the result to a one-shot attempt at the same task.

REAL-WORLD CASE STUDY

Using AI to Write a Book About AI

Writing Get on Board with AI became an unusually appropriate experiment: I used AI to help me write a book about using AI.

I began with the subject matter, experience, opinions, and stories I wanted to share. AI helped me organize them into a structure that would work for readers with little or no technical background. Together we developed the chapter outline, the Fast Track reading plan, the exercises and guided projects, the CLEAR Prompt Method, and the TRUST Verification Method.

The process was highly interactive. I would explain an idea, sometimes clearly and sometimes in the literary equivalent of a toolbox dumped onto the floor. AI helped sort the pieces, determine what belonged together, and turn rough thinking into readable prose. It simplified technical concepts, smoothed transitions, cut repetition, and helped maintain a warm tone.

It also served as researcher, proofreader, and occasionally a very persistent critic, comparing tools, checking product details that change monthly, reviewing the manuscript for readability, and moving time-sensitive material such as subscription prices into dated bonus content. It even helped reduce my supply of em dashes, which was generous of it, since apparently nobody had been supervising its own.

I did not accept every recommendation. We debated titles, chapter order, tone, and what belonged in the core book. Some passages were revised repeatedly; others were cut entirely. AI could propose language and structure, but deciding what was accurate, useful, and genuinely mine stayed with me.

That is the central message of this book. AI works best as a capable collaborator, not an unquestioned authority. It accelerates research, organizes complex material, and offers endless patience. It never asks for coffee, never sighs at another revision, and is always willing to reconsider a paragraph it called excellent five minutes earlier.

The book was finished faster and came out better because AI was involved, but the experience, judgment, and final decisions remained human.