The prompting playbook built for engineers works for writers too

You have rewritten the same headline five times this morning. Each version feels a little different from the last. None of them feels obviously better. You are not testing anything. You are moving words around until something feels right, then moving on because the deadline is closer than the certainty ever was.

The same thing happens with the prompts you write for AI. A description runs too long, so you add a line telling it to be concise. A draft keeps missing your tone, so you add another rule. Six months later the prompt is twice as long and you still cannot say whether any single addition helped.

A support bot got the same treatment

On 19 May 2026, at Anthropic's Code with Claude conference in London, applied AI engineer Margot van Laar spent her session live-fixing a broken customer support prompt, one failure at a time. The bot withheld information a customer was entitled to. It miscalculated bills. It refused to escalate problems that should have reached a human.

Each failure had a specific, fixable cause. None of them was fixed by writing a more careful sentence.

A prompt problem is rarely a wording problem. It is a systems problem wearing a wording problem's clothes.

Before changing a single instruction, van Laar's first move was to define what better actually looks like: run the prompt against cases that matter, change one thing, check whether it helped. Guessing is not a method. That is not really a coding insight. It is an editorial one, and it applies just as directly to the workflow behind an article as it does to the workflow behind a support bot.

Put your rules in a document, not in every prompt

Van Laar's first fix was structural: separate role, rules, data, and task into clearly labelled sections, so the model, and the person reading the prompt, can tell them apart. For a one-off support bot, that structure lives inside the prompt itself.

For a content practice that runs for years, it should not. If you are re-explaining your voice, your audience, and your formatting rules inside every single prompt, you are retyping something you already wrote down once. Anything that stays true across every article belongs in a reference document, written once, pointed to whenever it is needed.

A single prompt should only carry what actually changes for that task: this article, this constraint, this specific thing you need right now. Everything permanent belongs somewhere else.

The outdated rule is rarely in the prompt, it is in the document

Van Laar's second fix was to delete instructions that no longer help. In her example, an old defensive rule, written for a weaker model, made a newer model withhold information it actually had access to. The instruction had quietly become a liability nobody thought to remove.

For a single prompt, catching that is a five-minute fix. For a style guide or a content-DNA document that governs every article you produce, it is a slower kind of damage. A rule written to correct a problem an older model had can become a straitjacket for a newer, more capable one, and the document has no way of knowing the model has moved on. Only you know that, and only if you go back and check.

This is the harder version of the same fix. It means reviewing the reference documents on a set rhythm, not just the prompts, and not waiting for something to visibly break first.

Give it a way to count, not a reason to try harder

AI models get word count wrong more often than almost anything else you ask of them. Told to write exactly 150 words, or to keep something short, they land wide of the mark and stay confident about it. Telling a model to be careful does not make it better at counting, because an instruction cannot hand it a skill it does not have. Van Laar's version of this problem was a billing calculation. For most content work, it is length.

Her fix works the same way either way: give the model something to check its own work against, instead of trusting it to estimate. Count the words after a draft comes back and ask for a specific trim, rather than hoping a length instruction lands close enough on its own. This matters most exactly where a hard limit exists, an SEO description capped at a fixed number of characters, a subtitle with a maximum length. That is precisely where an estimate quietly fails.

State the argument on both sides of a tradeoff

Van Laar's fourth fix addressed a bot that refused to escalate a billing error, because the prompt only told it what escalating would cost. Nothing in the prompt said what escalating would gain. State one side of a tradeoff and the model optimises for that side, every time, without knowing there was another side to weigh.

The same failure shows up in editorial instructions. Tell a model only "always use claim-based headers" and it will follow that rule past the point where it still serves the article. Give it both sides instead: why a claim-based header earns a reader's trust and reads well for AI search, and why a topic label sometimes still carries a search term the reader is actually typing. Then let it weigh the specific case, rather than applying the rule blind.

Split the task, not just the sentence

Van Laar's fifth fix split one large, failing prompt into three simple ones, draft, check, repair, running independently instead of trying to do everything in a single pass. That structure is close to how careful editorial work already happens, with or without AI involved.

Draft in one place. Review against specific criteria in a second pass. Apply only what the review found, in a state that has no memory of the reasoning behind it, only the concrete instructions that came out of it.

That separation matters more than it looks like it should. A repair step that can still see the review's full reasoning tends to drift, weighing arguments and doubts that were never turned into instructions. A repair step that only sees the specific findings has nothing to drift toward. It fixes what was flagged, and nothing else.

Test the workflow the way you would test a prompt

None of these five fixes is really about AI. They describe the gap between a system and a collection of good intentions: a style guide nobody prunes, a prompt that repeats what a reference document should already hold, an instruction that states the cost and forgets the benefit. Van Laar never touched a sentence until she had a way to tell whether a change helped.

The next time you rewrite that headline a sixth time, that is the question worth asking. Not which words. What you are testing them against.

Next week another lesson from Anthropics' Code with Claude: Claude only works like a colleague once you onboard it like one