Sixty-one percent of professional developers say AI often produces code that "looks correct but isn't reliable", and 96% do not fully trust it (Sonar, 2026). The same is true of AI-written copy, generated logos and generated video. A review is where "almost" becomes "right", and most reviews are too shallow to do that job. Here is a method that is not.
A review is not a read-through
Reading AI output is dangerous because it is fluent. Fluent code compiles. Fluent prose scans. Fluent design looks finished at thumbnail size. Your brain fills gaps and forgives errors it would catch in a colleague's rough draft, because the surface is smooth.
So the first rule: never review by reading top to bottom. Review by asking specific questions of the output, one at a time, and writing down the answer. Each "no" or "not sure" becomes a task with a name on it. That is the whole method. The rest of this guide is the questions.
The seven checks
1. Does it do what was actually asked?
Go back to the prompt or the brief, not to your memory of it. Models frequently answer a nearby, easier question: a function that handles the example input but not the general case, a paragraph that explains the topic instead of arguing the point, a logo that matches the mood words but ignores the constraint about working in one colour. List each requirement in the brief and mark it met, partly met or missing.
2. Is every fact, number and name true?
Assume every specific claim is invented until you find the primary source. Statistics, dates, quotes, API method names, package versions, legal wording, a person's title. This is the slowest check and the one most often skipped. If you cannot source it, cut it or mark it as unverified. Do not publish a number you found only in the model's answer.
3. What happens at the edges?
Generated work is optimised for the typical case. Ask what happens when the input is empty, huge, malformed, in another language, on a slow connection, on a 360 px screen, for a user with a screen reader, at 16 px, in one colour, at minute nine of a three-minute song. For code, write the edge case as a test. For design, render it at the extreme. For copy, imagine the least charitable reader.
4. Would the person whose name is on it say this?
Copy, in particular, has an author. Read each paragraph as that person. Is this a claim they would make? A tone they would use? A promise they can keep? Delete hedges they would not hedge and confidence they do not have. For code, the equivalent is: would the engineer who will be paged for this accept it into their system?
5. What is missing that only a person would know?
The model does not know your customer's history, the constraint from last week's meeting, the reason the old version failed, the thing legal said never to claim again. Every piece of AI output has a hole shaped like your context. Find it and fill it. This is usually where the real value of the human work sits.
6. Is anything here that should not be?
Hallucinated dependencies. A licence-incompatible snippet. A stock phrase that appears in ten thousand other posts. A generated face that resembles a real person. A hand with six fingers. Copyrighted lyrics. Security anti-patterns like string-built SQL or secrets in code. Look for what should be removed, not only for what should be fixed.
7. Can you explain it?
If you cannot explain how the code works, why the design decision was made or why the paragraph is structured that way, you do not own it yet. Thoughtworks calls the accumulated version of this "cognitive debt": solutions adopted without the mental model to maintain them. Either learn it well enough to explain it or rebuild it in a form you understand.
Turn every finding into an owned task
A review that produces a list of concerns is half a review. Finish it: each finding becomes a task with a single owner and a clear done state. "Verify the three statistics in paragraph 2 against primary sources. Owner: Anita. Done when each has a link or is removed." Vague findings ("tighten this up") are how work stalls.
| Finding as written | Finding as a task |
|---|---|
| "The error handling seems thin" | Add tests for empty input, network timeout and malformed JSON; handle each explicitly. Owner: Dev. Done: tests pass. |
| "Not sure about these numbers" | Source the 3 statistics in section 2 or remove them. Owner: Editor. Done: each has a primary link. |
| "Logo feels off small" | Redraw the mark at 16 px and 32 px; thicken strokes to a minimum of 1.5 px at 16. Owner: Designer. Done: legible in favicon test. |
| "Chorus is weak" | Rewrite the chorus lyric to state the hook once, in plain words; re-record. Owner: Writer. Done: sings cleanly in one take. |
Record the review
Write down what was checked, by whom, and what changed as a result. This is not bureaucracy. It is the answer to three questions you will be asked later: "How was AI used in this?", "Who approved it?" and "Why did we decide that?" It is also how the next review gets faster: the checks that found nothing three times can be lighter next time; the ones that always find something become the template.
A short version to keep
- Asked? Check against the brief, not memory.
- True? Source every specific claim.
- Edges? Empty, huge, wrong, small, slow, assisted.
- Yours? Would the named person say it?
- Missing? Add the context only you have.
- Shouldn't be there? Remove hallucinations, risks, clichés.
- Explainable? If not, you do not own it yet.
How this was made: written by the After AI Work team from our own review practice. Statistics are from Sonar's 2026 State of Code Developer Survey (sonarsource.com, January 2026). "Cognitive debt" from Thoughtworks Technology Radar vol. 34 (April 2026). AI tools were used to draft an outline; every sentence was rewritten and every claim checked by a person.