# Your first useful hour with AI
Three small tasks to try before you decide whether any of this is worth your time.
**Time:** 15 minutes

**What you'll have when you're done:** Three finished pieces of real work, and a clear sense of which parts of your job this is reliable for.

**Before you start:**
- Any AI chat tool you're allowed to use at work. A free tier is enough for all three tasks
- Something you wrote yourself in the last month: a document, a long email, meeting notes
- A task you've been putting off because it's tedious rather than hard
---You've probably tried this already. You asked it something. What came back sounded fine but wasn't much use. You filed the whole subject under overhyped.

That's a fair read of the evidence. It's also what happens when you ask for the one thing it's worst at.

Here's the split that makes the rest of this make sense:

| Strong | Weak |
|---|---|
| Working on material you gave it | Supplying material from memory |
| Reshaping, sorting, restating | Recalling a fact, a figure, a date |
| Drafting a first version | Telling you it doesn't know |
| Arguing against a plan you describe | Anything about last month |

Most disappointing first sessions are a right-column question. All three tasks below come from the left column. They're ordered by how much judgment you hand over.

Reading this takes about fifteen minutes. Doing all three takes about an hour. Stop after the first one and you'll still have the part that matters.

---

## Before you start: the one rule

**Describe structure. Don't paste data.**

Field names, process steps, and the shape of a problem are fine. Customer names, real figures, anything from a live record, exported reports: not fine.

Read your company's AI policy first. If there isn't one, assume the stricter version. "There was no policy" has never gone well for the person who said it.

Every task below uses material you wrote yourself.

---

## Task 1: summarize something you already understand

**About ten minutes.** Take that document you wrote. Paste it in. Ask for a summary in five bullets.

You're not doing this for the summary. You already know what the document says. That's the point. You can grade this answer instantly, which makes it the safest place to learn what its output is worth.

What will happen: five bullets come back in a few seconds, in a confident and slightly flat register. Read them against what you know.

Look for three things.

- **What it got right.** Usually the explicit structure. Your headings, your stated conclusions, anything you said outright.
- **What it flattened.** You made a point carefully, with a qualifier attached. Watch for the qualifier going missing.
- **What it added.** Sometimes a bullet appears that reads sensibly and isn't in your document. This is the important one. Find it here, where you'd notice. Not later, on a document where you wouldn't.

**What you've learned:** it sounds the same whether it's right or wrong. There's no tell. Nothing in the tone shifts when it starts inventing. You can't train yourself around that, which is why every task after this one needs a way to check the output.

---

## Task 2: do the tedious thing you've been avoiding

**About fifteen minutes.** This is where it earns its place.

Pick something mechanical. Messy notes into a table. Twelve bullets regrouped by theme. A rambling email cut to five lines. One update rewritten for three audiences who each need a different level of detail.

They have one thing in common. Everything needed to do the job is in what you paste. Nothing has to be recalled or looked up.

Be specific about what you want. Vague request, vague result.

```
Turn these notes into a table.

Columns: what was decided, who owns it, what date was mentioned.
One row per decision.
If a date wasn't mentioned, write "not stated". Don't guess one.
Leave the wording as close to mine as you can.

[paste your notes]
```

That fourth line does a lot of work. Without it, gaps get filled with something plausible. Tell it to mark a gap as a gap and it usually will.

What will happen: you get a table. Check the "not stated" rows against your notes. Those are the spots where it would otherwise have invented something.

**What you've learned:** the more of the answer is already in what you paste, the more you can trust what comes back. Build the habit here.

---

## Task 3: have it argue with you

**About twenty minutes.** The first two were about output. This one is about thinking. It's where people who stick with this get most of the value.

Take a decision you're actually weighing. Describe it. Say what you're inclined to do. Then don't ask for a recommendation.

```
Here's the situation: [describe it. Constraints, who's involved,
what has to stay true]

I'm inclined to: [your plan, stated plainly enough to be argued with]

Don't tell me whether I'm right. Instead:
1. List every question someone experienced would ask before
   committing to this, that I haven't answered above
2. Give me the strongest case for the opposite approach
3. Tell me what would have to be true for my plan to fail
```

Asking it to argue is the whole trick. Ask "is this a good idea?" and you'll mostly get agreement. It's accommodating by default, and a confident bad plan gets confident help. Telling it to take the other side is what breaks that.

What will happen: a list of questions. Several you can't answer. Those are the deliverable.

Not because it found something you couldn't have. Because you found them today instead of in week three.

**What you've learned:** it's more useful pointed at your reasoning than at your writing. You're still the one deciding. It's harder to skip a question once it's written down in front of you.

---

## When it breaks

**It makes things up, in the same tone as everything else.** Names, figures, citations, features, quotes. Not rarely, and not only on obscure questions. Task 1 exists so you meet this on safe ground. Treat any specific fact you didn't supply as unverified until you check it.

**It agrees with you.** Describe a bad plan with confidence and you'll get help executing it. That's why task 3 makes it argue instead of asking its opinion.

**It's worst on anything recent.** Renamed products, this year's features, current pricing, what a tool does now. Old and stable is safer ground.

**Long conversations drift.** Constraints you set early get dropped forty messages later. On anything that runs long, restate the constraints when you ask for the final version.

**It refused, and your request was reasonable.** Describe the task instead of leading with the words that tripped it. If it still won't, take that as the answer. Don't work around a refusal on anything involving real data or real people.

**Nothing landed and you're unimpressed.** Usually the prompt was two sentences. Or it was a right-column task from the table up top. Check which one you asked before you conclude it can't help.

---

## What this doesn't tell you

An hour tells you how the tool behaves. It doesn't tell you whether it's worth using for your job. That takes a few weeks of noticing which of your tasks land in the left column.

Some jobs have a lot of them. Some have very few. That's a real finding, not a sign you didn't try hard enough.

It also can't reach your actual systems. Everything above works on what you paste in. Connecting it to the places your work really lives is a separate problem, with its own walls.

<div class="cta">
<h2>Next</h2>
<ul>
  <li><a href="/guides/working-within-limits/one-sentence-ticket-to-testable-spec/">When security says no</a> <span>The work you can still do without a connection</span></li>
  <li><a href="/guides/">Browse the other guides</a> <span>Same format, different task</span></li>
  <li><a href="/rss.xml">Subscribe by RSS</a> <span>New guides as they publish</span></li>
</ul>
</div>