Suzanne: When I write with AI, I typically go through many, many revisions before a document is done: proposals, briefs, customer emails, internal guides, whatever it is. One proposal didn’t finalize until version fifty-six. The tool has genuinely changed how fast a first draft comes together. What it hasn’t changed is how much judgment a document still needs before it goes out the door.
Adeline: The same is true on the research side, though the failure mode is different. The risk isn’t only that a model invents a capability or repeats itself. Research writing has its own register, careful hedging, explicit acknowledgment of what a study does and doesn’t show, and a model trained to sound fluent will often smooth away exactly the qualification that made a claim honest. A sentence that should read “the evidence suggests” becomes “the evidence shows.” Before I call something finished, I’m also checking whether the argument’s structure survived the editing, not just its prose, since a model asked to tighten a paragraph will happily keep the topic sentence and quietly drop the conditional it depended on.
After enough rounds of this, between the two of us, a set of habits has settled in, the difference between a document we can send and one that quietly embarrasses us later.
This list itself came out of mining that history. We asked the AI to search back through our own chat threads and pull out the patterns in what we kept correcting, then added our own thinking on top and tested it against what follows. It’s worth trying with your own threads. Whatever you’ve been drafting with AI, the record is already sitting there, and the patterns in your own corrections tend to be sharper than any generic list, including this one.
Here’s what we check.
1. Verify Before You Share
A model writes to sound complete and confident. When a detail is missing, it doesn’t flag the gap, it fills it with something plausible, and a fluently written claim reads exactly as convincing whether or not it’s true. Three places this shows up most:
• Capability and feasibility claims. In a proposal or capability document, this often looks like asserting that a feature, integration, or workflow works a certain way, or that something is possible, when it hasn’t actually been confirmed. It’s easy to catch an invented statistic. It’s much harder to catch a confidently written sentence about what something “can do.” Read those sentences as claims to verify, not just prose to smooth.
• Borrowed or unverified figures. A generic benchmark used as a stand-in number, or a stat that’s actually someone else’s claim being repeated back as your own. Ask for the source behind any figure so you can go check it yourself rather than take the model’s word for it.
• Options flattened into one. A draft that presents a single method or example as though it’s the only path may have quietly dropped exceptions or alternatives that also apply. It reads fine on its own, right up until someone downstream assumes the flattened version is the whole picture.
• A second reader, when you can get one. This isn’t unique to AI drafting, a fresh set of eyes catches things the writer can’t, on any document. But it matters more here: after enough rounds of revision, you’ve read the draft too many times to see it clearly, and the model checking its own output has the same blind spot toward its own smoothing. Optional, but worth it when the stakes justify the time.
Most LLMs default to this. Filling a gap with a plausible guess, rather than flagging it, is the base behavior you get out of the box. It doesn’t have to stay that way, though. We wrote about this at more length in Who Owns the Output?: with the right tooling and guardrails, you can get a system that tells you what it doesn’t know and exactly what it would need to answer, instead of quietly guessing. That reduces the problem significantly. It doesn’t eliminate it, and it doesn’t remove the need for someone to actually read the output, but it changes the default from a confident guess to an honest gap.
This isn’t a check you can outsource by skimming or forwarding on trust. A confidently written sentence about a capability reads exactly like a true one until someone who actually knows the details reads it line by line. Read the document before it goes out. Don’t just scan the shape of it.
2. Set the Request Up Right
The best fixes happen before a draft exists at all. What you hand the model at the start shapes the draft more than any amount of revision after.
• Ground drafts in real source material, not a blank page. When a prior draft, a related document, or relevant history exists, hand it over instead of describing the ask from scratch. A model working from real material produces something anchored in fact. A model working from a description of what should exist is guessing at the details.
• State exclusions explicitly, not just inclusions. Say what a document should not contain, not just what it should include. Left to its own judgment, a model defaults toward including everything plausible.
• For high-stakes or ambiguous messages, ask for a few distinct approaches, not one draft. Two or three genuinely different strategies surface trade-offs immediately, instead of discovering them three rounds of iteration in.
• Know your purpose/argument and explain it explicitly. AI is a tool for drafting prose, not for generating the argument itself. What AI does is help you say it faster and often more clearly. My process starts with a “messy draft”: I write out what I want to say in a raw, word-vomit way, with no concern for polish. Then I use AI to iterate on the language until it captures exactly what I meant; It’s my own point, written in the clearest possible way.
3. Pick the Format That Gives You Control
• Use HTML instead of native Word or PowerPoint when spacing and layout actually matter, then convert it to PDF. Word and PPT formatting is fiddly for a model to control precisely, paragraph spacing, table alignment, and layout collisions are common problems. Styled HTML gives much finer control and is easier to iterate on visually. That combination, styled HTML converted to PDF, is what actually produces a genuinely polished, shareable document.
• For .docx or .pptx deliverables, ask for a visual check before calling it done. Have the file rendered to PDF or image and actually look at the page. That rendered preview is a sanity check, not a guarantee: it’s usually produced by a different engine than Word or PowerPoint itself, so the actual file still needs to open in the real application before it goes anywhere.
• State the format and destination up front. Who’s reading it, how formal it needs to be, whether it’s a document or a chat message. Models calibrate density and tone far better when told this than left to infer it.
4. Say Each Idea Once
A model reliably restates the same point in slightly different words across a document. The risk grows with length: the more a document runs on, the more likely the model loses track of what it already said earlier and restates it further down, so long documents deserve a redundancy pass more, not less.
• Near-duplicate bullets: two points that are really one idea in different clothing, and can usually be merged into one, sharper bullet.
• A concept restated across sections: the same claim showing up in an intro, a feature list, and a summary. If it’s said three times, it only needed to be said once.
• A full section that’s really just one example: a walkthrough dressed up as its own heading when it could be a few tight bullets folded into a nearby section.
The fix isn’t “make it shorter everywhere.” It’s finding the actual repeats and cutting those, which recovers length without losing substance.
5. Watch for These Phrasing Patterns
• AI-sounding phrasing: certain constructions are just obviously AI-written, easy to spot on sight, not necessarily because they read like marketing copy, but because the rhythm and word choice don’t match how a person would actually say it.
• Mismatched voice: a document written for one purpose can drift into the wrong register for another, a pitch’s language leaking into an internal memo or a handover note.
• Overly pointed or blunt phrasing: a tradeoff or cost stated more starkly than intended once you imagine it landing in a real inbox. Worth a dedicated look before anything goes external or up-chain.
• House style rules, like no em-dashes: restate standing style preferences per document, since they tend to drift back in on longer builds even when set once.
Even this piece isn’t exempt. We have a standing instruction telling the AI never to use em-dashes, set a long time ago. When we had it run this very document’s own checklist against itself, the draft still turned up fifteen of them, including inside the bullet that says, word for word, “no em-dashes.” Here’s how it put it when it found them:
Good catch to push for — running the doc’s own checklist against itself turned up a real issue: it had 15 em-dashes throughout, including in the bullet that literally says “House style rules (e.g., no em-dashes).” That’s the tip #3 phrasing check failing on its own document.
Read that quote closely and you’ll notice it has one too.
6. Calibrate to the Actual Audience
• Name the seniority and role explicitly. It changes bullet density and how much a term needs explaining, since a quick internal note and a leadership-facing brief shouldn’t share a template.
• If a document serves a specific function, say so explicitly. A handover, an internal record, a pitch, that framing decision determines what content belongs in it at all, not just how it’s worded.
• For papers, calibrate to who’s actually reading it. A policy audience wants the implications stated plainly, up front. A peer-review audience expects the methodology and caveats spelled out in full before the conclusion. Writing for one when you actually mean the other is its own kind of miscalibration.
7. Iterate with Precision, Not “Make It Better”
The fastest and the best revisions come from pointing to the exact phrase or bullet to cut or change, rather than open-ended rewrite requests. A vague “make it better” invites the model to guess at what’s wrong and often trades one problem for another. Naming the exact issue gets it fixed without new ones introduced elsewhere.
Revision also has to check backward, not just forward. Past a certain number of rounds, a correction you made early can quietly get overwritten by a later “make this tighter” or “make this more formal.” The model isn’t tracking which fixes were deliberate; it’s optimizing the version in front of it. Before calling a document done, check that earlier corrections, especially factual fixes and standing style rules, actually survived the later rounds.
The Prompt We Paste at the End
None of this replaces judgment. It just tells you where to point it. The last thing we do, every time, is paste this before we call a document finished:
Do a final pass on this: cut anything said more than once, tighten any phrasing that sounds AI-generated or overly polished, flag pointed language that could read wrong to a senior audience, check for em-dashes, and flag anything stated as fact that I should verify, including capability claims and any number or statistic that might not be confirmed.
It only works because of everything above it. A final pass won’t rescue a document that skipped the right format, the right audience, or the right framing from the start. It catches what’s left once those calls have already been made.
That’s really the larger point. The technology didn’t remove the need for a careful reader. It just moved where that reader’s attention needs to go.
This is true beyond our own process. It mirrors a common claim about AI and labor more broadly: that it won’t replace workers so much as free them from mundane tasks, redirecting their effort toward more intellectual work. We’d argue the same is true for writing. AI saves time, but it doesn’t erase the need for a careful reader, a personal style, or plain artistry. Instead, it changes how we interact with our own texts, and often, that interaction produces a better result.