Five teardowns: from bad to good

The last lesson gave you the theory: five parts and the rule about gaps. This lesson is the gym. Five tasks from different fields, each in two versions. One teardown pattern throughout: what it was → what's wrong → what we added → what changed in the answer.

How to work through it. Every prompt has a Run button — press it and read for yourself, don't take my word for it. But free sandbox runs are limited per day, so be thrifty: pick the two or three pairs closest to your own work and run those in full — the bad one and the good one. Read the rest. One pair you actually ran teaches more than five you read.

Teardown 1. An email: there's a topic, but no job

Write an email to colleagues about the office move.

What's wrong. There's a topic but no task. "About the move" is a subject, not a verb. The model doesn't know what to do with the move: celebrate it? warn people? ask them to pack? No role, no context, no format, no constraints. Five gaps out of five.

You are a department head writing to your team of 12.
Task: warn them about the office move and tell them what we need from them.
Context: we move on 3 March, two blocks further out but closer to the station. People have already heard rumours and are anxious about the commute. Personal belongings must be packed by 1 March; the office manager hands out boxes.
Format: a short email under 150 words, ending with 3 bullets titled "what to do before 1 March".
Constraints: don't apologise, don't be defensive, and don't invent an address or any detail I haven't given you.

What changed. A verb appeared — and the text started doing work instead of musing about a topic. The context about rumours and anxiety reshaped the tone: the email now answers the question people actually have ("how will I get there?") rather than the formal one. And the constraint "don't invent an address" cuts off the most expensive error: in the weak version the model almost always inserts a plausible, non-existent address.

Teardown 2. A table: the format that saves you an hour

Compare three internet plans and tell me which to pick.

What's wrong. You never said which three plans. The model will invent them — and the comparison will be beautifully formatted and entirely fictional. No context (who uses it? how many devices?), no format.

You are a consultant who helps people choose internet plans.
Task: compare three plans and recommend one.
Context: a family of four; in the evening two TVs stream while someone takes work calls. Here are the plans:
A — 100 Mbps, 25 EUR/month, no TV.
B — 300 Mbps, 35 EUR/month, TV included.
C — 1 Gbps, 60 EUR/month, TV plus router rental.
Format: a table (plan, speed, price, who it suits), and below it 2 sentences with your recommendation and one reason.
Constraints: use only the data I gave you. Invent nothing. If something is missing for a proper conclusion, say plainly what's missing.

What changed. Two moves do all the work. First, the data lives inside the prompt: the model now reasons over your numbers, not over the internet's memory. Second, the constraint "if data is missing, say so": you're giving it permission to admit ignorance instead of filling the gap with invention. And the table format turns the answer into something you can show your family straight away, rather than an essay you have to mine by hand.

Teardown 3. Text: where tone lives

Write a post about our new bakery.

What's wrong. A classic: you'll get "We are thrilled to introduce!", three emoji and exclamation marks — the average of every promotional post on the internet. You recognise that style instantly, and so does your reader.

You are the owner of a small family bakery, writing yourself, in the first person.
Task: write a social media post about the opening.
Context: we opened on Tuesday in a courtyard of a residential block; we bake rye sourdough and cinnamon buns. It's just me and my wife, and we start the dough at 4 in the morning. Our readers are the neighbours from the surrounding buildings.
Format: 4-5 short paragraphs, living human speech, as if telling a neighbour over the fence.
Constraints: no "thrilled to introduce", "innovative" or "unique", no exclamation marks, one emoji maximum, don't promise discounts.

What changed. Notice what the constraints did here: a banned-word list. This is the most underrated trick for writing tasks. You can't tell a model "don't sound like an advert" — too abstract. But "no exclamation marks and never the word unique" is a concrete fence it understands literally. Add the detail from the context — dough at 4 in the morning: details like that are what turn an average text into yours. The model couldn't have invented them; you supplied them.

Teardown 4. Tearing apart a document: the most underrated task

What's important in a rental contract?

What's wrong. That's a question for an encyclopedia, not a task about a document. The model will tell you what rental contracts contain in general. It has nothing to do with your contract.

You are a careful legal consultant.
Task: find the clauses in the text below that could hurt me as the tenant.
Context: I'm renting a flat to live in, for the first time; the landlord sent the contract. Contract text:
[paste the contract text here]
Format: a list of the clauses you found. For each: the exact quote from the contract → what it means for me in plain words → what to ask the landlord.
Constraints: quote only what is literally in the text, word for word. Don't recite general rental rules. If a clause is ambiguous, say so rather than deciding for me. Your answer is not legal advice.

What changed. Everything. Remember the technique from the hallucinations lesson — "give it the material"? Here it is at work: a model with the document answers from the document, not from memory. Demanding a word-for-word quote is also a built-in check: you can find a quote in the text with your own eyes in two seconds. No quote in the contract means the clause was invented, and you'll see it immediately. The format "quote → what it means → what to ask" turns the answer into an action plan.

And this, by the way, is the task beginners almost never hand to an AI. Everyone asks it to "write"; almost nobody asks it to "take apart what I already have". Yet this is exactly where hallucination risk is lowest and the payoff is highest.

Teardown 5. Ideas: quantity versus quality

Come up with ideas for a team party.

What's wrong. You'll get five ideas you could have named yourself: bowling, an escape room, outdoor team-building. The internet's average is, well, average.

You are an events organiser experienced with small teams.
Task: suggest 12 ideas for a team party.
Context: a team of 15 software engineers, half of them introverts who hate anything labelled "team-building". Budget 600 EUR, it's November, the city is cold. Last year we did bowling and it landed so-so.
Format: group them into three columns — quiet / active / unusual. Each idea: one line, plus one line on why it suits this team.
Constraints: no bowling and no rope courses. Don't invent prices for specific venues — if you give a cost, mark it as a rough estimate. Ideas must fit the budget.

What changed. Three things. The number 12 instead of "ideas" forces the model past the obvious: the first five are always the clichés, the interesting ones start around six. The context about introverts and the flat bowling night narrows the field to your actual team. Grouping into columns forces genuinely different kinds of ideas rather than twelve versions of one. And the constraint about prices inoculates against the most common hallucination in this task: plausible invented price lists.

What the five fixes have in common

Scroll back and look for the repeats. Three things got fixed almost every time:

• We added our own material — the plan prices, the contract text, the 4am dough, the bowling that flopped. The model cannot know any of it. Whatever you supply, it doesn't have to invent.
• We built a fence — don't invent the address, never say "unique", no bowling, word-for-word quotes only.
• We allowed "I don't know" — "if data is missing, say so", "if a clause is ambiguous, say so". You legalise the honest answer; otherwise the model is obliged to fill the gap.

A pause to think

No trick here: in which of the five teardowns is the cost of an error highest? Think before reading on.

The fourth — the contract. A bad post can be rewritten, a dull party survived, but a missed early-termination penalty costs real money. And notice the pattern: the higher the cost of error, the more constraints the good brief carries, and the more it matters that you can check the answer — which is why the word-for-word quote requirement showed up there. That's the bridge to the next lesson: a good brief doesn't just produce a good answer, it makes the answer checkable.

Do this now

Take the teardown closest to your own work and swap the context in the good prompt for yours: your numbers, your text, your team. Leave the structure alone — it's already right. Run it. That's your first working template, and it stays with you after the course.