In May I wrote about building small websites with AI. Since then I’ve built more sites, simulations, tools, and a set of comics. Every project raised the same question: how do I know when the result is good enough? Here are the ten habits that answered it. Each takes minutes to set up and pays back the first time it catches something.
The short version
Use a different model as the reviewer.
Hide the source from the first reader.
Never trust a single review.
Run the boring checks before the clever ones.
Cap the review loop at three rounds.
Keep the mechanical parts free of LLMs.
Save intermediate results and inspect them before the expensive step.
Keep a handover file with the decisions that must not be undone.
Keep the task list in the repository.
Mine your histories for repeated fixes.
Each tip below is a few sentences: what to do, why, and where I saw it matter.
Where the tips come from
Most of the examples are from a comic pipeline. I’ve collected adaptations on a new AI Generated Comics site: Lovecraft’s The Shadow Over Innsmouth, Hoffmann’s Der Sandmann in German, Conan Doyle’s The Adventure of the Speckled Band, and five others. The pipeline is a private extension of Polyptych. It reads a story, picks characters and settings, allocates pages to the important sequences, writes panels and dialogue, and only then renders images.
The opening page of The Speckled Band. Click to read the adaptation.
Comics expose AI weaknesses fast. A detective story collapses if one clue goes missing. Image models have no idea of 3D geometry, so a character sits behind a desk on one page and in front of it on the next. That makes comics a cheap test bed for review techniques, and the techniques transfer to code and prose.
1. Use a different model as the reviewer
Do: When an agent reviews another agent’s output, pick a model from a different family for the reviewer.
Why: Models share blind spots with their own output. A fresh conversation resets the context, but not the preferences.
Seen: In my website pipeline, an editorial reviewer on the same model as the writer kept passing prose. A reviewer on a different model found concrete problems in the same pages.
2. Hide the source from the first reader
Do: Give the first reviewer only the artifact, not the original spec, story, or your intent. Let a second reviewer compare its findings against the source.
Why: A reviewer who has the source fills in what the artifact lost. You want to know what a reader can understand from what is actually in front of them.
Seen: My comprehension check gives a blind reader only panel descriptions and lettering. It reports where it got lost. A second pass sorts those findings into missing material, unclear presentation, deliberate omissions, and reader mistakes.
3. Never trust a single review
Do: Run several independent readings of the same unchanged draft before you call it done. Re-read after each fix to see whether the fix helped.
Why: One favourable review is not a certificate. Different readers find different gaps.
Seen: A Speckled Band script showed a burnt match twice without explaining it. The first critique missed it, a second reading found it. Of four more readers on the same unchanged script, only one caught the match.
4. Run the boring checks before the clever ones
Do: Build, lint, type checks, link checks, and browser tests must pass every round before any LLM judge looks at the result.
Why: A visual reviewer should not spend its attention on a broken link that a command catches in a second. Each check should have one specific job.
Seen: Mechanical checks flag crowded lettering and broken panel structure.
5. Cap the review loop at three rounds
Do: Let judges return ranked changes, let the maker apply them, rerun the checks. After three rounds, stop and review it yourself.
Why: Without a cap it is too easy to ask for one more improvement instead of deciding whether the thing is ready.
Seen: My site pipeline runs a visual judge on screenshots at several sizes in light and dark mode, plus an editorial judge on the text.
6. Keep the mechanical parts free of LLMs
Do: Split each tool into a plain program with no LLM and no credentials, and a thin agent skill around it that makes the judgement calls.
Why: The plain part is testable with ordinary inputs and expected outputs. When something breaks you have a text, a command, or a file to inspect instead of a conversation to reconstruct.
Seen: All projects converged on this shape.
7. Save intermediate results, inspect before the expensive step
Do: Persist every stage. Review the cheap stages before you start the slow or costly one, and resume from saved stages instead of regenerating.
Why: The expensive step should never be the first place you find out the plan was wrong.
Seen: In Polyptych the agent runs the text stages and critiques, saves them, and hands them to the rendering CLI. I check the script before paying for a whole comic’s worth of images.
8. Keep a handover file with the decisions that must not be undone
Do: Next to the stable AGENTS.md or CLAUDE.md, keep a handover.md. Record where the work stands, which checks passed, and the non-obvious decisions with their reasons.
Why: A new session cannot tell a deliberate choice from a mistake. Without the reason written down, it will helpfully restore the old value.
9. Keep the task list in the repository
Do: Put tasks, acceptance criteria, and decisions in the repo and let agents update them through a CLI. I use Backlog.md.
Why: The handover carries recent context. The board carries the commitments. Together they remove most of the re-explaining at the start of each session.
Seen: Agents and I now see the same answer to “what is next” and “what counts as finished”.
10. Mine your histories for repeated fixes
Do: Look at the commit histories of finished projects for corrections you made after the pipeline declared them done. Look at your session transcripts for the places you keep interrupting or correcting the agent. My claude-history tool extracts them from Claude Code.
Why: A fix that shows up after several finished runs is a missing rule in the template or the reviewer prompt. A correction you keep making by hand belongs in the tooling, or in how you explain the work.
Seen: Once I had a shelf of generated sites, the same post-run fixes appeared more than once. Fixing the pipeline helped every site after it.
Closing
Have a look at the comics and see where current LLMs and the pipeline is still struggling.
P.S. This article was written with the help of Codex GPT-6 Astra and Claude Fable 5.1.
I built my own slide and infographic generator because I couldn’t stop poking at Google’s NotebookLM. It’s called Polyptych, and it turns a single essay into the visuals you’d want...
For a while now I’ve been building small websites with AI; each is a focused site about a single topic, with its own voice. I’ve collected them on a new...
