The plain-words pass

Day 15: The Plain-Words Pass, a Check You Run Before You Send

Your AI draft sounds sure of itself, and that's the problem. Every draft does. The confidence comes free with the tone, so it tells you nothing about what's actually true. One extra prompt strips the tone off. Then you can see which parts of the draft carry real information and which parts were only there to sound good.

Start here: two versions of the same status update

Here's a status update written the way an AI usually writes one. Nine lines, and none of them is false.

Hi team,
Quick update on the payment retry issue.
We've made significant progress this week investigating the intermittent failures.
After a thorough deep-dive, we identified a potential root cause in the retry logic.
We've implemented a robust fix that leverages exponential backoff.
The change is deployed to staging and is undergoing validation.
Early signals look promising.
Overall, this positions us well to close out the issue before the release.
Let me know if you have any questions!

Here's the same update after one plain-words pass. Four lines.

Payment retries failed because the client retried instantly and hit the provider's rate limit.
We changed it to wait 1s, 2s, then 4s between retries. It's on staging.
I don't know yet if the fix works. Staging hasn't failed since Tuesday, but staging rarely failed before either.
I'll know after one day in production.

Read the third line again: “I don't know yet if the fix works.” That's the most important sentence in the whole update, and you only get it in the rewrite. The first draft papered over the same fact with “early signals look promising” and “positions us well”. Nobody lied. The model aims for confident and helpful, and most of us let that tone through because it reads nicely. Take the tone away and you're left with what you actually know.

The prompt (copy this)

Rewrite in the plainest words that keep the meaning.
No adjectives you can't defend.
If a sentence says nothing concrete, delete it and tell me you deleted it.

Where this sits in the series: the earlier days were about getting a good draft. This step comes after the draft and before you hit send. It's a check on the content, not a style pass, so don't judge it by whether the result sounds nicer. Judge it by which way each section moved.

What usually gets shorter: padding

Most of the shrinking happens in three spots: the opening that sets the scene, the closing that sums up, and the sentences in the middle that say the same thing twice. LLMs turn these out easily because that's what a finished document is supposed to look like.

• ▹Before: “In today's fast-paced environment, teams increasingly rely on AI tools to accelerate delivery. This proposal outlines how we can do the same.” → After: “This proposal is about using Claude to draft our test plans.”
• ▹Before: “Overall, these changes position us well for future growth and set a strong foundation for upcoming initiatives.” → After: (deleted, because it says nothing concrete)

Rule: if a section shrinks, it was padding. Keep the cut. Don't sneak it back in.

What usually disappears: hedging and claims nobody checked

Once you ban adjectives you can't defend, the model has to swap each one for a fact or drop it. Sometimes a fact turns up. Sometimes there's nothing there.

• ▹“Robust, scalable retry logic” → “retries 3 times, then fails.” Now a reader can judge it.
• ▹“Robust, scalable retry logic” → (nothing). This is the case that matters. The draft had an adjective and no fact behind it.
• ▹“There are several trade-offs worth considering” → has to become “pick A” or “I don't know which.” Either answer helps. The original sentence didn't.

Rule: if a claim vanishes, treat it as unverified. That includes unverified by you. The draft had no fact behind it. The model often can't tell what you checked apart from what it made sound plausible, and your reader can't either. So a vanished claim becomes a to-do: go and check it, or send the document without it.

The surprise: some sections get longer

People expect a plainness pass to shrink everything. It won't. Abstract wording can squeeze a lot of mechanism into a few words, and plain wording has to spell that mechanism out.

• ▹Before: “Leverages an event-driven architecture for resilience.”
• ▹After: “Puts each order on a queue. Three workers read from it. If one worker dies, the other two keep going, and its unfinished orders go back on the queue after 30 seconds.”

The longer version is better. Now a reviewer can ask the questions that matter, like “what if all three die?” or “can an order get processed twice?”. Nobody could ask either one about “event-driven architecture”. Rule: if a section grows, the draft was hiding how the thing works. Keep the longer explanation.

How to read the result in 30 seconds

Put the two versions side by side and go section by section. You're not rereading for flow. You're sorting each section into one of three buckets:

• ▹Shrank → keep the cut.
• ▹Vanished → go and check the claim. If you can't, leave it out or say you don't know.
• ▹Grew → keep the longer explanation and read it closely. This is where reviewers will find the real problems.

The "vanished" bucket is where most of the value is. If nothing vanished, the draft was probably fine. If several claims vanished, hold off on sending.

What happened when we ran it on agent-written PRs at PhoenixDX

At PhoenixDX, coding agents write the first draft of a lot of our PR descriptions. They read well, and they're confident every single time. We added the plain-words pass as a step before a PR goes up for review. I thought the main win would be shorter descriptions. They did get shorter, but that's not what people talked about.

What reviewers said was that “seamless” couldn't hide anything any more. One description said a change “integrates seamlessly with the billing service.” After the pass it said: “calls billing's /charge endpoint; if the call times out, the order stays pending and nothing retries it.” That sentence kicked off a real review discussion. The original would have been approved without anyone stopping on it. Authors felt it too. When the pass deleted a claim, the engineer who opened the PR had to decide whether they actually knew it was true. I didn't measure any of this. It's what came up in reviews and retros, and it's why we kept the step.

Two mistakes to avoid

• ▹Accepting the rewrite without reading what it deleted. The deletions are the useful part, which is why the prompt asks the model to report them. Paste the clean version over your draft and you lose the record of what nobody checked.
• ▹Letting the rewrite strip out real precision. Plain doesn't mean vague. Models sometimes round “p95 went from 820ms to 310ms on 14 Oct” down to “latency improved”. Tell the model to protect the details.

Here's the improved prompt:

Rewrite in the plainest words that keep the meaning.
No adjectives you can't defend.
Keep every number, name, date and link exactly as written.
If a sentence says nothing concrete, delete it and list what you deleted at the end.

Homework

Pick the last AI-assisted draft you actually sent: an email, a report, a PR description. Run the prompt on it and count what vanished. For each vanished claim, ask yourself honestly whether you'd checked it before you hit send. That count is your baseline.

Tomorrow: what to do with the claims that vanished, and a quick way to check one before it goes out with your name on it.

Extend your knowledge

• ▹Read George Orwell's 'Politics and the English Language' (1946). He argued that vague language covers for vague thinking, which is the idea this pass rests on, decades before anyone had an LLM.
• ▹Read the UK Government Digital Service guidance on plain English, including its list of words to avoid. It works as a ready-made checklist to paste into the prompt.
• ▹This week, run the pass on one AI-written PR description and one email, and see which one loses more claims.
• ▹If you review other people's AI-written docs, ask them to attach the model's 'deleted' list alongside the final version.