What LLMs Can and Cannot Do

Iris now fields the same meeting every week: someone arrives with a proposal that begins "let's just have the AI do it". Answer support tickets. Write the quarterly forecast. Check the contracts. Some of these are excellent ideas and some are quiet disasters, and telling them apart by gut feel is how companies end up in the news. What she needs — what this page is — is the honest map: where these systems are genuinely strong, where they reliably fail, and how to tell the difference from the mechanism rather than from vibes.

Nothing new arrives on this page. Every line of the map derives from pages you have already read — the loop of Topic 40, the recipe of Topic 41, the hallucination mechanism of Topic 42. This is the harvest, and it is the book's most practical page: by the end you can scope any "AI feature" proposal, or your own daily use, with a defensible one-minute test.

Where It Is Reliably Strong

Start from the mechanism and the strong column writes itself. The loop produces fitting text from context. So wherever "produce fitting text from context" is the job description, the model is on home turf: drafting and rewriting, summarizing a long document, translating between languages, explaining a concept at a chosen level, brainstorming twenty options where you need three, transforming formats — meeting notes into action items, a spec into an email. These are not lucky side effects. They are the mechanism doing exactly what it was optimized for, which is why the strength is reliable.

One member of the strong column deserves its own sentence: code. Writing code is language work — a program is text with strict grammar — and it comes with something no other text enjoys: a compiler or test suite that mechanically catches a large class of mistakes. Text whose errors are cheap to detect is the best possible assignment for a fluent generator that sometimes errs.

Where It Is Reliably Shaky

The shaky column derives just as directly. Verified facts without provided sources: Topic 42's mechanism in one line — the loop generates the likely, not the verified, so unsourced factual claims are fluent guesses delivered with total confidence. Arithmetic and multi-step logic: predicting likely text is not computing — the model is a storyteller who can describe a calculator beautifully, not a calculator — and a plausible-looking number is the most dangerous kind of wrong. Current events past its training snapshot: Topic 41's frozen file recalls a compressed past, not today. And its own limits: it rarely knows when it doesn't know, so it cannot reliably flag its own shaky answers. Tools that bolt on calculators and live search exist and genuinely help — but they are patches on the mechanism, not changes to it.

The Two-Question Test

Sort Iris's weekly proposals and a pattern emerges behind the columns. The model shines where errors are cheap and fluency is the value — a draft a human reviews loses nothing to an occasional wrong sentence, because review catches it and the fluency did the heavy lifting. It is dangerous where errors are costly and truth is the value — a medical, legal, or financial answer sent out unchecked is exactly the case where a confident, fluent guess does the most harm.

That gives you the two-question test, and it takes one minute. Question one — stakes: what does a mistake cost here? Question two — verifiability: how quickly can a person check the output? Cheap mistakes, easy checking: use it freely. Costly mistakes with fast checks: use it, with the check made mandatory. Costly mistakes nobody will check: that is not an AI feature, that is an incident report with a delay on it. The proposal to draft support replies for agents to approve and the proposal to let the bot answer billing questions unsupervised differ by nothing but these two answers.

Neither Magic nor Trick

One promise remains from the start of the chapter: the stress test of the autocomplete analogy. As a mechanism, it has held every page — the fluency, the varied runs, the invented refund clause, the six-fingered hand all traced back to prediction-in-a-loop, and nothing on this page needed anything more. Where the analogy fails is as a measure of the results. Your phone's keyboard suggests one word; the scaled version drafts a usable contract, explains the code it just wrote, and translates a negotiation — and no one who studied the small machine predicted that the large one could. Scale did not just make autocomplete longer. It produced qualitatively new capabilities, and pretending otherwise is its own kind of dishonesty.

So hold both, because both are true: this is a genuinely new kind of tool, and it is a next-word predictor whose mechanism you now understand end to end. Neither magic — it does not know, verify, or understand, and its confidence is a learned style. Nor trick — the capabilities are real, the productivity is real, and reflexively dismissing it misjudges the decade as badly as worshipping it. Models will keep changing; the loop, the recipe, and the two-question test are the parts built to travel. That is why this page — and Iris — will still be right next year.