Tasks It Is Bad At

Six months ago Tessa was the person at Waymark who used the chat box. Now she is the person the office asks before using it, which is a different job and a harder one.

Two requests reached her desk this week. The bookings clerk wants the model to add up four rows of supplier expenses, because retyping them into a spreadsheet is annoying. The brochure writer wants it to confirm that a partner hotel still runs its airport shuttle, because the partner's website is out of date and the model answers instantly.

She said no to both. What makes her useful is not the no — anyone can be cautious — it is that she can give the reason in one sentence each, and that the two reasons are different.

This page is that ground mapped. Not a list of surprising exceptions to memorize, because such a list goes stale and nobody carries one around anyway. Three patterns, and every one of them falls straight out of machinery you already own.

Pattern One: Exactness

Chapter 4 left you with a sentence about tables: the model may talk about the numbers, but the spreadsheet owns them. That was a rule for one afternoon's task. It is time to promote it into a category, because arithmetic is only the most obvious member of a family.

The family is exactness — every task where one wrong digit, one miscount, or one mishandled condition ruins the whole result. Adding four expense rows. Counting how many of 2,300 reviews mention a refund. Working out which tours satisfy two conditions at once — over four nights and under a price cap. Converting a currency for a quote that a client will hold you to.

The mechanism is the one from Chapter 1 and it has not changed since. Given the text so far, the model continues with what fits. A number of the right size and shape fits. There is no step inside it that computes, and no step that checks, so what comes back is a plausible result rather than a calculated one. Chapter 4's wrinkle still stands beside that: some products run real code for the arithmetic, and those figures are as good as a calculator's, because a calculator did them. If you cannot tell which of the two you got, treat it as predicted.

Which produces the specific danger worth naming: the failure mode here is close. A total that was absurd would be harmless — you would see it and laugh. A total that is wrong by four percent looks exactly like a total that is right, and goes out in a quote.

So the test is not "is this hard arithmetic?" It is: if this is slightly wrong, is the work ruined? If the answer is yes, a tool that computes should compute it. That tool is usually the spreadsheet already open on the other screen.

Pattern Two: Facts That Must Be True

The second pattern belongs to a hotel.

Back in Chapter 3, Tessa asked for small lakeside hotels with a quiet terrace, and the Harbourview Annex came back third: a restored boathouse, twelve rooms, a terrace out over the water. It sounded exactly right. It does not exist. In Chapter 5 it turned up again, this time as a value in a spreadsheet cell, in a file of 2,300 rows that was almost sent to an operations meeting.

It appears here for the last time, in the same costume it has worn twice already, because it is the whole of the second pattern and it needs no new story. Anything that must be true — a name, a date, a price, a clause, a shuttle that still runs — is weak ground when nothing verifies it. Fitting and existing are two different tests, and the machine only ever runs the first.

Notice the shape of the rule, though, because "bad at facts" stated flatly would contradict most of this book. The model has been answering questions for nine chapters. What it is bad at is being a source of record — the place a fact comes from and stops. As a drafting tool for facts it is excellent: it produces the claim, names where you might confirm it, and hands you a two-minute job instead of an afternoon of research.

The distinction is a workflow, not an opinion. Draft-then-check was the arrangement from Chapter 3 onward. Remove the check and the weakness becomes load-bearing, which is precisely what the brochure writer was proposing to do about the shuttle. Where no verification step fits into the work, no model output ships.

Pattern Three: the Same Answer Every Time

The third pattern is the one nobody expects, and it is the reason Chapter 1 spent a page on variability.

Some work must fire identically every time it runs. Does this booking qualify for the group discount. Does this supplier invoice need a second signature. Is this guest's cancellation inside the refund window. Run those a thousand times on the same input and you must get the same answer a thousand times, not because consistency is tidy but because a rule that sometimes decides differently is not a rule.

The model cannot promise that, and the reason is not a defect. Chapter 1 showed the chance built deliberately into how each token is picked, and explained why: without it, the writing reads stiff and dead. That designed variation is what makes it a good drafting partner and a poor law-book. Turning the dial down narrows the spread; it does not turn assembly into lookup.

There is a second half to this that matters more in an office than the first. A written rule in ordinary software is auditable. Somebody can open it, read the condition, and say exactly why a booking was refused in March — and say it again next year when the question is asked by a regulator rather than a colleague. The model's answer has no such record inside it. It arrived, it was plausible, and there is nothing to open.

So: rules that must fire the same way forever belong in software that fires the same way forever. This one is cheap to get wrong slowly, which is what makes it dangerous — the discount worked for eight months.

The Pattern Behind the Patterns

Read the three back and they are not three facts. They are one sentence from Chapter 1, read honestly.

The model produces plausible text. And plausible is not exact, plausible is not verified, and plausible is not repeatable.

Exactness fails on the first. Facts fail on the second. Consistency fails on the third. That is the entire map, and it fits on a sticky note, which is what Tessa's actually is.

The everyday version is a colleague you have probably met. Brilliant generalist: fast, articulate, good on any subject, the first person you go to when something needs drafting, explaining or sorting into piles. You would not make that person the accountant. You would not make them the notary. You would not make them the compliance officer. Not because they are unreliable in some general way, but for three specific reasons that all reduce to the same one — the qualities those three jobs are built on are precisely the qualities that fluency does not supply.

Drop the colleague there; the model is not a person and this book is not going to pretend otherwise. Keep the three jobs. They are the map, and the next page starts using it.