A benchmark reported yesterday by Alibaba researchers should be pinned above every content calendar. They collected 37,463 real requests from 26,314 coding sessions where people had struggled to get an AI assistant to finish a job, refined them into 273 tasks with 2,331 hidden acceptance criteria, and ran ten leading models through them. The best model, OpenAI’s GPT-6 Astra, met an average of 69.9% of the criteria per task. It fully solved 26.4% of the tasks. On multi-file repository edits, that figure fell to 17.9%.
Coding is not blogging. But the shape of the failure is the same: the draft looks finished, most of it is right, and the last quarter is where the damage lives. A wrong version number, an invented quote, a link that goes nowhere, a confident sentence about something the model cannot know.
So I do not publish an AI draft until it has been through a review pass that treats every factual sentence as a claim to be checked. Not a vibe check. A source check. Here is the exact pass I use.
The short version
- Assume every number, name, date and quote is wrong until you have opened a source.
- Check the link, not just the claim. A dead or mismatched link is a factual error with a URL attached.
- Delete any first-person experience the draft invented, and replace it with one you actually had.
- Soften what you cannot verify, and say so plainly instead of sounding certain.
- Read the finished piece aloud once. Confident nonsense survives silent reading and dies at speaking speed.
Why AI drafts fail in the same five places
After enough drafts, the errors stop being random. They cluster in five predictable places.
- Numbers without a source. A percentage appears with three decimal places and no origin. It may be real, remembered from somewhere, or invented to make the sentence sound researched. You cannot tell by looking, which is the point.
- Citations that do not exist. Titles, authors, journals and years that read plausibly. Ask for the URL and you get a 404, or a page that says something else entirely.
- Stale product facts. Pricing, limits, version numbers and feature lists change faster than training data. A sentence can be true in the model’s memory and false on the vendor’s site today.
- Borrowed experience. “When I tested this last month…” from a model that has never opened the tool. This is the most damaging one, because readers forgive a wrong number far more easily than a fake story.
- Confident predictions. “This will kill X” is an opinion wearing a fact’s clothes. It needs to be labelled as a bet, not delivered as a finding.
Google’s documentation update this month makes the same point from the other side: it now tells publishers to fact-check and review AI-generated content before publishing, and warns against manufactured authorship. The compliance bar is no longer “did a human touch it?” It is “can you stand behind what it says?”
The five-minute pass
Five minutes is not enough for a 3,000-word research piece. It is enough for a 1,200-word blog post if you work in the right order. I keep the draft on the left and a browser window on the right, and I do not edit prose until the facts are settled.
- Mark the claims. Read the draft once and highlight every proper noun, number, date, quote and superlative. Do not fix anything yet. You are making a list, not editing.
- Open the primary source. Not a blog quoting a blog. For a study, the paper. For a product claim, the vendor’s own documentation or changelog. For a quote, the transcript or the recording. If the best you can find is a summary of a summary, the claim is not verified, it is repeated.
- Click every link. Check that it loads, that the title matches what you said it says, and that the date is current. A link that resolves to the right domain but the wrong page is worse than no link, because it looks like evidence.
- Rewrite from the facts, not from the draft. Once a claim is confirmed, write the sentence yourself using the source in front of you. This one habit removes most accidental plagiarism and most of the model’s smug tone at the same time.
- Read it aloud. Slowly. The sentence you skated past silently is usually the one that says nothing, or says something you cannot defend.
A claims table you can keep
When a piece has more than a handful of facts, I keep a small table beside the draft. It turns “I think this is right” into a yes or no. Mine has four columns, and the last one is the only one that matters.
| Claim type | Looks like | Check against | If unverified |
|---|---|---|---|
| Number | “42% of sites…” | The original study or dataset | Cut the number or say “many” |
| Quote | “…” — named person | Transcript, video, original interview | Paraphrase the idea, not the words |
| Product fact | “Version 7.2 supports…” | Vendor changelog or docs | Say “check current docs” or cut it |
| Personal story | “When I tested this…” | Your own notes or screenshots | Cut it or run the test for real |
| Link | “Source: example.com” | Open it; read title and date | Delete the link and the claim |
The prompt I add before the first draft
Most cleanup can be avoided by asking the model to expose its uncertainty instead of smoothing it over. I paste this after the brief, before any drafting starts. It does not replace the check. It makes the check shorter.
Before you write, list the five factual claims this article will depend on. For each one, give the primary source you would use and mark it certain, uncertain, or unknown. Do not invent sources to fill the table.
Then write the draft, and put [VERIFY] after every number, name, date, quote or product detail you are not certain about. Do not round over gaps.
At the end, list the three sentences most likely to be wrong, and why.
Two things to note. First, the model will still miss claims, especially ones it believes are common knowledge. The [VERIFY] tags are a floor, not a ceiling. Second, a source URL from a model is a lead, not proof. Open it. Read it. If it does not say what the draft says it says, the draft is wrong.
What “verified” means before I press publish
My standard is one question: if a reader emailed “where did you get this?”, could I answer in one sentence with a link or a specific experience? If the answer is a shrug, the sentence is not ready.
That standard changes how the piece is written. A fuzzy number becomes “roughly” or disappears. A prediction becomes “I think” or gets cut. A product detail gets a date stamp: “as of November 2026” tells the reader when the fact was true, which is often more honest than pretending it is permanent.
It also keeps the publishing workflow boring, which is what you want. The 90-minute post workflow leaves a real slot for this pass instead of pretending the draft is the finish line. The monthly planning afternoon is where the topics come from, so the writing day starts with decisions already made. And repurposing happens only after the facts survive, because a wrong number copied into five formats is five times the problem.
Pre-publish checklist
- Every number has a source open in a tab, or it is gone.
- Every quote is verbatim from a primary source, with the speaker named correctly.
- Every link loads and matches the claim it supports.
- No first-person experience that I did not actually have.
- No prediction stated as a fact; bets are labelled as bets.
- Product names, versions and prices checked today, with a date stamp.
- The whole piece read aloud once, start to finish.
Next time you have a draft that feels finished, set a timer for five minutes and try to disprove it. Open the first number. Click the first link. Read the first quote. If everything survives, publish with confidence. If something does not, you just caught the 74% before your readers did.
