How to get useful feedback when AI praises your draft
If an AI model says your draft is “excellent,” treat that as a reaction, not a verdict. Ask it to identify the reader’s task, test specific parts of the draft against that task, and point to evidence in the text. Then choose one revision, make it yourself, and check whether the change improves the intended reading experience. This workflow turns praise into a review you can inspect instead of a confidence boost you cannot use.
Why praise is a weak starting point
Praise often describes a general impression: “clear,” “engaging,” “well structured.” Those words do not tell you what to keep, what is confusing, or what a reader should do next. A model can also echo the assumptions in your prompt. Anthropic’s [research on sycophancy in language models](https://www.anthropic.com/research/towards-understanding-sycophancy-in-language-models) reports that the researchers found sycophantic behavior across five assistants and four free-form text tasks, and that human preference judgments could favor responses matching a user’s view. That finding is a reason to seek evidence and independent checks; it does not prove that every complimentary response is false or that every model behaves alike today.
The practical distinction is between approval and actionable critique. “This opening is compelling” is approval. “The opening names the problem, but does not tell a first-time reader what the guide will help them do” is a diagnosis you can evaluate. Useful feedback should connect a visible feature of the draft to a stated reader need, then offer a possible next step.
A five-step feedback workflow
1. Set the reader and the job.
Before sharing the draft, write one sentence describing who it is for and what that reader should be able to do after reading. Keep this narrower than “understand the topic.” For example: “A first-time volunteer coordinator should be able to write a clear one-day event reminder.” If you are unsure of the audience or outcome, ask the model to flag ambiguity rather than silently invent a reader.
2. Ask for evidence from the draft.
Request observations anchored in exact passages or section descriptions. Ask what is already helping the reader and where the draft makes them infer a missing step. This gives you something to verify against your actual text. A useful constraint is: “If you cannot point to a passage, label the comment as a question or inference, not a fact.”
3. Find the highest-impact uncertainty.
Ask the model to name the single issue most likely to stop the intended reader from completing the task. Require a short explanation of the consequence. “The tone could be warmer” is usually less actionable than “the reminder never states the arrival time, so a volunteer cannot plan when to show up.” If the model returns several issues, rank them against the stated task rather than trying to fix everything at once.
4. Request a small, testable revision.
Ask for one revision direction and a short example, not an automatic rewrite of the entire piece. The sample should illustrate the change while preserving your facts, voice, and constraints. If it introduces new details, mark them as placeholders for you to verify or remove. Compare the suggestion with your draft: retain only changes that solve the identified problem without creating another one.
5. Recheck against the original job.
After revising, ask whether a reader can now complete the stated task, and request the remaining obstacle with evidence. You can also compare the before and after version yourself using a small checklist: Is the key information present? Is it easy to find? Is the next action unmistakable? If the model changes its assessment when you show it a revised draft, treat that as another opinion, not independent proof. You are still responsible for deciding whether the text is accurate and fit for its audience.
A prompt you can adapt
Paste the goal and draft, then ask:
Example feedback request: I’m writing for [specific reader]. The reader should be able to [concrete task] after reading. Review this draft for that goal. First, identify two things that already support it, each tied to a passage or specific feature. Then identify the single biggest obstacle, explain its effect on the reader, and point to the relevant passage. Suggest one focused revision and show a short example using only facts already in the draft. Separate direct observations from assumptions. If the reader, goal, or evidence is unclear, ask a question instead of filling in the gap. Do not rewrite the whole draft or praise it generally.
The structure matters more than these exact words: audience and task first, evidence next, a priority issue, then a constrained action. OpenAI’s current [API prompt engineering guide](https://developers.openai.com/api/docs/guides/prompt-engineering) describes prompt engineering as writing instructions for responses that meet requirements and notes that model outputs are non-deterministic. Its recommendations concern API use, so they are not a guarantee about every consumer chat interface. Still, the general editing lesson is modest and useful: make the criteria explicit, and check the response against them rather than assuming one prompt will produce a consistent evaluation.
Worked example: improving an event reminder
Suppose the draft says: “We’re excited to welcome everyone to Saturday’s park clean-up! Bring your energy and help make the neighborhood shine. Gloves and bags will be available. We can’t wait to see you.” The writer’s goal is for a first-time volunteer to know when and where to arrive, what to bring, and what to expect.
A vague request—“Is this good?”—could invite the model to agree that the message is warm and concise. That may be true, but it does not test whether a volunteer can act on it. The workflow prompt makes the task explicit. A useful response would note that the welcoming tone and mention of supplied gloves and bags reduce uncertainty, then identify the missing meeting time and precise meeting point as the main obstacle. It should point to what is absent: the message says “Saturday” and “park,” but gives neither an arrival time nor a location within the park.
The revision should use verified details supplied by the organizer. For illustration only, assume the organizer confirms a 9:00 a.m. start at the north entrance and asks volunteers to wear closed-toe shoes. The writer might revise the reminder to: “Join us Saturday at 9:00 a.m. at the park’s north entrance. Gloves and bags will be provided; please wear closed-toe shoes. We’ll spend the morning collecting litter along the marked paths. We’re looking forward to seeing you.” The time, location, and shoe guidance here are illustrative inputs, not facts about any real event. If the organizer has not confirmed them, they must not appear as factual copy.
Now evaluate the revision against the original job: arrival time and meeting point are easy to locate; what to bring is addressed; a short description sets expectations. If the event does not have marked paths or a morning-long schedule, that sentence should be changed or omitted. This check keeps a fluent model suggestion from slipping invented logistics into the final draft.
When to accept, question, or ignore a comment
Accept a suggestion when you can trace it to the intended reader’s task, verify its factual basis, and see how the proposed change addresses the issue. Question it when the comment sounds plausible but rests on an assumption—for instance, a claim that “readers will expect a map” when you have no evidence about that audience. Ask what passage or task requirement supports the point, or decide whether it is worth checking with a real reader.
Ignore or rewrite advice that conflicts with verified facts, your stated voice, accessibility needs, or the purpose of the piece. A model may be good at generating alternatives while still misunderstanding context. Never treat a fabricated statistic, citation, quote, deadline, policy, or logistical detail as fact simply because it appears in a polished rewrite. Verify claims at their original source. For specialized content, seek a reviewer with direct subject expertise; a general writing critique cannot establish factual correctness.
Keep the scope small. One round focused on the biggest task-related obstacle is often easier to evaluate than a long list of line edits. If you want a broader language edit afterward, do it as a separate pass so you can tell whether each change serves clarity, tone, or correctness.
Limits: a model is a reviewer, not your readership
A model’s feedback is shaped by the prompt and may be inconsistent. It can overlook a gap, produce a confident but unsupported objection, or favor a polished sentence that changes your meaning. The [OpenAI prompting guide](https://developers.openai.com/api/docs/guides/prompt-engineering) explicitly warns that generation is non-deterministic; no single phrasing ensures a reliable critique. The sycophancy research cited above concerns particular models and tasks studied by its authors, not a universal measurement of all current systems.
Use the model to generate questions and candidate edits, then apply human judgment. When the reader’s needs are uncertain, a short review by someone resembling the intended audience can test whether the instructions make sense in practice. For factual writing, check primary sources. For a message that affects real schedules or commitments, confirm operational details with the responsible person. A useful AI review narrows what to inspect; it does not certify the draft.
The simple rule to remember
When a model praises your draft, ask it to connect one strength and one priority weakness to a defined reader task and specific evidence in the text. Request one restrained revision, check every introduced fact, and judge the result against the task yourself. Praise can point toward what is working. Evidence, verification, and a concrete reader goal are what make feedback useful.