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.
Suzanne : Lorsque j’écris avec l’IA, je passe généralement par de très nombreuses révisions avant qu’un document ne soit finalisé : propositions, notes de synthèse, courriels clients, guides internes, etc. Une proposition n’a été finalisée qu’à la cinquante-sixième version. L’outil a véritablement accéléré la rédaction d’une première ébauche. Ce qu’il n’a pas changé, c’est le niveau de jugement nécessaire avant la diffusion du document.
Adeline : C’est la même chose du côté de la recherche, même si le mode de défaillance est différent. Le risque ne se limite pas à ce qu’un modèle invente une fonctionnalité ou se répète. La rédaction scientifique possède son propre registre, des précautions d’orthographe et de grammaire, et une reconnaissance explicite des résultats et des limites d’une étude. Or, un modèle entraîné à paraître fluide aura souvent tendance à gommer précisément la nuance qui rendait une affirmation crédible. Une phrase qui devrait se lire « les preuves suggèrent » devient « les preuves montrent ». Avant de considérer un travail comme terminé, je vérifie également si la structure de l’argumentation a résisté à la révision, et pas seulement le style, car un modèle à qui l’on demande de condenser un paragraphe conservera sans problème la phrase thématique et supprimera discrètement la proposition subordonnée dont elle dépendait.
Après plusieurs échanges de ce genre, entre nous deux, un certain nombre d'habitudes se sont installées, faisant la différence entre un document que nous pouvons envoyer et un autre qui nous embarrasse discrètement plus tard.
Cette liste est le fruit de l'analyse de notre historique. Nous avons demandé à l'IA de parcourir nos conversations et d'en extraire les corrections récurrentes, puis nous y avons ajouté nos propres réflexions et comparé le résultat à ce qui suit. N'hésitez pas à essayer avec vos propres discussions. Tout ce que vous avez rédigé avec l'IA est déjà enregistré, et les schémas de vos corrections sont généralement plus précis que dans n'importe quelle liste générique, y compris celle-ci.
Voici ce que nous vérifions.
1. Vérifiez avant de partager
Un modèle écrit de manière à paraître complet et sûr de lui. Lorsqu'un détail manque, il ne le signale pas, il le comble par une explication plausible, et une affirmation rédigée avec fluidité paraît tout aussi convaincante, qu'elle soit vraie ou non. Ce phénomène se manifeste principalement dans trois situations :
• Affirmations relatives aux capacités et à la faisabilité. Dans une proposition ou un document de spécifications, cela se traduit souvent par l'affirmation qu'une fonctionnalité, une intégration ou un flux de travail fonctionne d'une certaine manière, ou qu'une chose est possible, sans que cela ait été réellement confirmé. Il est facile de repérer une statistique inventée. Il est beaucoup plus difficile de déceler une phrase rédigée avec assurance sur ce qu'une chose « peut faire ». Considérez ces phrases comme des affirmations à vérifier, et non comme de simples formules à embellir.
• Chiffres empruntés ou non vérifiés. Une valeur de référence générique utilisée comme chiffre de substitution, ou une statistique qui n'est en réalité qu'une affirmation d'autrui présentée comme la vôtre. Demandez la source de chaque chiffre afin de pouvoir le vérifier vous-même plutôt que de vous fier aveuglément au modèle.
• Options simplifiées. Un brouillon présentant une seule méthode ou un seul exemple comme s'il s'agissait de l'unique solution peut avoir omis discrètement des exceptions ou des alternatives pourtant pertinentes. Le document paraît correct en soi, jusqu'à ce qu'un utilisateur ultérieur suppose que cette version simplifiée représente l'ensemble des possibilités.
• Un second lecteur, si possible. Ce n'est pas propre à la rédaction assistée par IA : un regard neuf repère les erreurs que l'auteur ne voit pas, quel que soit le document. Mais c'est d'autant plus important ici : après plusieurs révisions, on a tellement lu le brouillon qu'on en perd le sens critique, et le modèle qui vérifie ses propres résultats a le même angle mort face à ses propres imperfections. C'est optionnel, mais ça vaut le coup si l'enjeu justifie le temps investi.
La plupart des LLM fonctionnent par défaut de cette manière. Combler une lacune par une estimation plausible, plutôt que de la signaler, est le comportement de base. Cependant, il n'est pas nécessaire qu'il en reste ainsi. Nous avons abordé ce sujet plus en détail dans l'article « À qui appartient la sortie ? » : avec les outils et les garde-fous appropriés, il est possible d'obtenir un système qui indique clairement ce qu'il ignore et la réponse exacte nécessaire, au lieu de deviner discrètement. Cela réduit considérablement le problème. Cela ne l'élimine pas complètement, et cela ne dispense pas de la lecture effective de la sortie, mais cela remplace le comportement par défaut d'une estimation assurée par une simple indication de la lacune.
Il ne s'agit pas d'une vérification que l'on peut déléguer en la survolant ou en la transmettant sans réfléchir. Une phrase bien rédigée décrivant une capacité peut sembler authentique jusqu'à ce qu'une personne connaissant les détails la lise attentivement. Lisez le document avant de l'envoyer. Ne vous contentez pas d'en survoler la forme.
2. Configurez correctement la demande
Les meilleures corrections s'effectuent avant même l'élaboration d'une ébauche. Ce que vous fournissez au modèle au départ influence davantage l'ébauche que n'importe quelle révision ultérieure.
• Fondez vos ébauches sur des documents sources réels, et non sur une page blanche. S'il existe une ébauche, un document connexe ou un historique pertinent, fournissez-le plutôt que de décrire la demande à partir de zéro. Un modèle basé sur des éléments concrets produit un résultat ancré dans la réalité. Un modèle basé sur une description de ce qui devrait exister se contente de conjecturer les détails.
• Indiquez clairement les exclusions, et pas seulement les inclusions. Précisez ce qu'un document ne doit pas contenir, et pas seulement ce qu'il doit inclure. Livré à lui-même, un modèle tend par défaut à inclure tout ce qui est plausible.
• Pour les messages à fort enjeu ou ambigus, demandez plusieurs approches distinctes plutôt qu'une seule ébauche. Deux ou trois stratégies véritablement différentes permettent de faire immédiatement ressortir les compromis, au lieu de les découvrir après trois itérations.
• Définissez clairement votre objectif/argument et exposez-le explicitement. L'IA est un outil de rédaction, non un générateur d'arguments. Elle vous aide à vous exprimer plus rapidement et souvent plus clairement. Ma méthode commence par un brouillon : j'écris ce que je veux dire de manière spontanée et spontanée, sans me soucier de la finition. J'utilise ensuite l'IA pour affiner le texte jusqu'à ce qu'il retranscrive exactement ma pensée ; c'est mon idée , exprimée avec la plus grande clarté possible.
3. Choisissez le format qui vous donne le contrôle
Utilisez HTML plutôt que Word ou PowerPoint lorsque l'espacement et la mise en page sont importants, puis convertissez le document en PDF. La mise en forme dans Word et PowerPoint est complexe à maîtriser pour un mannequin : espacement des paragraphes, alignement des tableaux et conflits de mise en page sont des problèmes fréquents. Le HTML stylisé offre un contrôle bien plus précis et facilite les modifications visuelles. C'est cette combinaison (HTML stylisé converti en PDF) qui permet d'obtenir un document soigné et partageable.
Pour les fichiers .docx ou .pptx, demandez une vérification visuelle avant de les valider. Faites convertir le fichier en PDF ou en image et examinez-le attentivement. Cet aperçu est une vérification de base, mais pas une garantie : il est généralement généré par un moteur différent de celui de Word ou PowerPoint, le fichier final doit donc être ouvert dans l’application prévue avant toute utilisation.
• Indiquez clairement le format et la destination dès le départ : qui est le destinataire, le niveau de formalité requis, s’il s’agit d’un document ou d’un message instantané. Les modèles adaptent bien mieux la densité et le ton lorsqu’on leur fournit ces informations que lorsqu’ils doivent les déduire.
4. Énoncez chaque idée une seule fois.
Un modèle reformule de manière fiable la même idée, avec de légères variations, au sein d'un document. Le risque augmente avec la longueur du document : plus un document est long, plus le modèle risque de perdre le fil de ce qu'il a déjà dit et de le répéter plus loin. Par conséquent, les documents longs nécessitent une redondance accrue, et non moindre.
• Points quasi identiques : deux idées qui ne forment en réalité qu’une seule et même idée sous une forme différente, et qui peuvent généralement être fusionnées en un seul point plus précis.
• Un concept répété à l'infini : la même affirmation apparaît dans l'introduction, la liste des fonctionnalités et le résumé. Si elle est répétée trois fois, une seule aurait suffi.
• Une section entière qui n'est en réalité qu'un exemple : une procédure pas à pas déguisée en titre à part entière alors qu'il suffirait de quelques points concis intégrés à une section voisine.
La solution n'est pas de « raccourcir partout ». Il s'agit de trouver les répétitions exactes et de les supprimer, ce qui permet de gagner en longueur sans perdre en substance.
5. Faites attention à ces schémas de formulation
• Un style d'écriture typique de l'IA : certaines constructions sont manifestement écrites par une IA, faciles à repérer au premier coup d'œil, pas forcément parce qu'elles ressemblent à un texte marketing, mais parce que le rythme et le choix des mots ne correspondent pas à la façon dont une personne le dirait réellement.
• Ton inadapté : un document rédigé dans un but précis peut adopter un registre inapproprié pour un autre, le langage d’un argumentaire commercial se retrouvant parfois dans une note interne ou une note de passation de consignes.
• Formulation trop directe ou abrupte : un compromis ou un coût est présenté de manière plus tranchée que prévu lorsqu’on imagine le message atterrir dans une boîte de réception. Il est important d’y jeter un œil avant toute transmission externe ou à la hiérarchie.
• Règles de style internes, comme l'interdiction des tirets cadratins : réaffirmer les préférences de style permanentes pour chaque document, car elles ont tendance à réapparaître dans les versions plus longues, même lorsqu'elles sont définies une seule fois.
Même ce document n'y échappe pas. Nous avons une consigne permanente, établie il y a longtemps, interdisant à l'IA d'utiliser des tirets cadratins. Pourtant, lorsque nous l'avons soumise à sa propre vérification, le brouillon en a tout de même détecté quinze, y compris à l'intérieur de la puce qui stipule pourtant « pas de tirets cadratins ». Voici comment elle les a signalés :
Bonne remarque à souligner : en comparant la liste de contrôle du document à elle-même, un problème réel s’est révélé : elle contenait 15 tirets cadratins, y compris dans la puce qui indique littéralement « Règles de style internes (ex. : pas de tirets cadratins) ». C’est le contrôle de formulation n° 3 qui échoue sur son propre document.
Lisez attentivement cette citation et vous remarquerez qu'elle en contient une aussi.
6. Adaptation au public cible
• Indiquez clairement le niveau hiérarchique et la fonction. Cela modifie la densité des puces et le niveau d'explication nécessaire pour chaque terme, car une note interne rapide et un exposé destiné à la direction ne doivent pas utiliser le même modèle.
• Si un document remplit une fonction spécifique, indiquez-le clairement. Qu'il s'agisse d'une passation de consignes, d'un compte rendu interne ou d'une présentation, ce choix de formulation détermine le contenu du document, et pas seulement sa formulation.
• Pour les articles, il est essentiel d'adapter son style au public visé. Un lectorat en charge des politiques publiques souhaite que les implications soient clairement énoncées d'emblée. Un lectorat évalué par les pairs, quant à lui, attend une description détaillée de la méthodologie et des limites du texte avant la conclusion. Écrire pour l'un alors qu'on vise l'autre constitue une erreur d'adaptation.
7. Itérez avec précision, et non pas « améliorez-le ».
Les corrections les plus rapides et les plus efficaces s'obtiennent en ciblant précisément la phrase ou le point à modifier, plutôt qu'en formulant des demandes de réécriture vagues. Un simple « améliorez-le » incite le modèle à deviner le problème et risque souvent de le remplacer par un autre. Nommer le problème exact permet de le corriger sans en créer de nouveaux.
La révision doit également prendre en compte les versions précédentes, et pas seulement les suivantes. Après un certain nombre de cycles, une correction apportée en début de document peut être discrètement écrasée par une modification ultérieure visant à « renforcer » ou à « formaliser ». Le modèle ne tient pas compte des corrections intentionnelles ; il optimise la version en cours. Avant de considérer un document comme terminé, vérifiez que les corrections précédentes, notamment les corrections factuelles et les règles de style établies, ont bien été conservées lors des cycles de révision suivants.
Le texte que nous collons à la fin
Rien de tout cela ne remplace le jugement. Cela indique simplement où l'orienter. La dernière chose que nous faisons systématiquement, c'est de coller ceci avant de considérer un document comme terminé :
Une dernière relecture : supprimez les répétitions, resserrez les formulations trop artificielles ou trop soignées, signalez les formulations trop appuyées qui pourraient être mal interprétées par un public de haut niveau, vérifiez la présence de tirets cadratins et signalez tout ce qui est présenté comme un fait avéré et que je devrais vérifier, y compris les affirmations concernant les capacités et tout chiffre ou statistique qui pourrait ne pas être confirmé.
Cela ne fonctionne que grâce à tout ce qui précède. Une relecture finale ne peut pas rattraper un document qui, dès le départ, n'a pas respecté le format, le public cible ou la formulation appropriés. Elle permet de corriger les problèmes restants une fois ces choix effectués.
C'est là le point essentiel. La technologie n'a pas supprimé la nécessité d'un lecteur attentif ; elle a simplement déplacé l'attention du lecteur là où elle doit se porter.
Cela se vérifie bien au-delà de notre propre processus. Cela rejoint une affirmation courante concernant l'IA et le travail en général : elle ne remplacera pas tant les travailleurs que ne les libérera des tâches répétitives, réorientant ainsi leurs efforts vers un travail plus intellectuel. Nous pensons que c'est également vrai pour l'écriture. L'IA permet de gagner du temps, mais elle ne supprime pas la nécessité d'un lecteur attentif, d'un style personnel ou d'un talent artistique. Elle modifie plutôt notre rapport à nos propres textes et, bien souvent, ce rapport aboutit à un meilleur résultat.