Launch offer: the first 1,000 users get Settl free for a year*Claim your spot
settlbuilding in public

The writer/reviewer agent loop: prompts + when it pays off

The short version

Every piece of AI-written work is read by a second AI that has not seen the conversation that produced it, with a single instruction: find what is wrong. It caught a displayed value that was correct when first calculated and then went stale after a related action, which both the original agent and the human reviewer missed.

The value is not intelligence, it is detachment. The agent that wrote the code is invested in it working. A fresh reader is not, and that is exactly why it sees what you cannot.

Copy these prompts

Paste them into Claude Code (or any AI that can see your project), in this order. Each one answers a different question, and the first is usually the one that matters.

1. Do not show it the first one's reasoning

Set up a review step where a second AI reads the change with no access to the conversation that produced it. Show me how to hand it only the change and the requirement, nothing else.

2. Tell it to assume something is wrong

Write me the reviewer prompt. It should assume there is a defect and go looking for it, rather than asking whether the code looks fine. Tell me the categories of bug this catches that a single agent reliably misses.

3. Ask about things that were right once

Have the reviewer specifically look for values that are calculated correctly at first and then go stale after some later action, because nothing invalidates them. That is the class of bug both I and the first agent missed.

A second AI caught the bug the first AI and I both shipped. My writer/reviewer loop: one agent implements, a fresh agent reviews. The reviewer flagged a balance that looked right but went stale after settle-up: a cached number that was never invalidated. I missed it. The author agent missed it. Fresh eyes (even artificial ones) see what invested eyes can't. Cost: one extra prompt. Cheaper than one refund.

Why it works

The author (human or AI) reviews its own work against its own mental model, the same model that produced the bug. A reviewer with no context of the writing session rebuilds understanding from the artifacts alone, which is exactly where stale assumptions get caught. You don't need a smarter model. You need an uninvested one.

The loop

  1. Writer agent implements from the spec/plan as usual.
  2. Reviewer agent starts with a CLEAN context. New session/subagent: it must not see the writer's reasoning, only the diff, the spec, and the codebase. Shared context = shared blind spots.
  3. Reviewer prompt shape (mine):
You are reviewing a diff you did not write. Spec: <link/paste>.
Hunt specifically for:
- state that can go STALE (caches, derived values, invalidation paths)
- lifecycle gaps: what happens AFTER the happy path (undo, delete, settle, retry)
- claims in the diff that the spec doesn't support
For each finding: severity, file:line, and the sequence of events that breaks it.
Do NOT restyle code. Correctness only.
  1. Make it walk the timeline. The stale-balance bug was invisible in the diff and obvious in the sequence "create expense → balance caches → settle up → balance still shows old number." Ask the reviewer to simulate event sequences, not just read lines.
  2. Triage like human review: accept, reject-with-reason, or investigate. Reviewer agents are also confidently wrong sometimes. The loop includes your judgment, it doesn't replace it.
  3. Feed accepted findings back as tests. The settle-up staleness became a regression test. Review findings that don't become tests get re-shipped eventually.

When it pays off (and when it doesn't)

Steal this for your app

Run this on your codebase

Paste this into Claude Code in your repo:

Review this repo the way a fresh reviewer agent would.
Hunt for state that can go stale: caches, derived values, denormalized totals, and their invalidation paths.
For each cached or derived value, walk the timeline past the happy path (undo, delete, settle, retry) and flag any sequence that leaves it stale.
Flag money math, auth, and sync code that has no second-context review or matching regression test.
List past bug fixes with no test covering the sequence that broke.
Give each finding a severity, file:line, and the event sequence that breaks it.
Report findings as a checklist before changing anything.

CACHE: make stale data mechanically impossible

A reviewer should not stop at "this cache has a TTL." A TTL is cleanup, not correctness. Ask it to trace every mutation of the source record and verify that the cache key includes a version counter or that the mutation advances the version before any reader can reuse the old entry. That turns invalidation from a hopeful side effect into part of the write contract.

Review these five things together:

  1. The source mutation and version increment happen in a safe order.
  2. Cache keys include the version or generation, not only the record ID.
  3. Concurrent misses use a lock or single-flight path to prevent a stampede.
  4. TTLs bound storage and recovery time, but are never the only correctness mechanism.
  5. A regression test walks read -> mutate -> read again and proves the second read cannot return the old value.

That sequence is the useful reviewer-agent prompt. It makes the agent reason about time, not just spot a cache.set() call in a diff.

Download the runnable pack

This pack runs the review as a deterministic dry-run, exposes an n8n webhook for automation, and includes Docker and GitHub Actions checks. Start with the sample payload, then replace it with your repository-specific evidence.

Get the next one in your inbox