AI as Reviewer
Your design → AI critiques → you decide → you implement. The assistant is strongest as a second reader of something you made, because then its output is a list of objections you can judge, not a design you have to adopt.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
You have a design for a piece of the system and an assistant that will happily produce one of its own. How do you use it to make your design better without ending up with its design instead?
You have sketched the order lifecycle for the store: created, paid, shipped, cancelled, with a note about refunds you are not sure of. You could ask the assistant to "design an order state machine" and compare. You suspect that if you do, you will end up implementing whatever it produces, because it will be more complete than yours.
Ask for its design and take the better one. It will be thorough — it will remember refunds, partial shipments and disputes — and comparing two designs feels like rigour. Choosing the more complete one feels like humility.
The comparison is not between two designs; it is between a design you can defend and one you cannot. "More complete" means it contains states you did not ask for and cannot explain, and each of those is a decision made by nobody.
- The comparison is not between two designs; it is between a design you can defend and one you cannot. "More complete" means it contains states you did not ask for and cannot explain, and each of those is a decision made by nobody.
- Your design is abandoned before its errors were found. The point of a review is to learn where your thinking was wrong; replacing the design skips the review and keeps the thinking.
- The assistant's design carries its assumptions — partial shipments, disputes — as if they were requirements. They are not yours; nobody checked them against the founder, and they are now in the state machine (Assumption vs Requirement).
- Next time, you sketch less, because the sketch will be replaced anyway. The habit that produced a design to review erodes, and the review has nothing to work on.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Fix the order: your design first, then the critique, then your decision, then your implementation. The assistant reviews what exists; it does not produce the thing to be reviewed. This is the reviewer's position on any team, and it is the position where an assistant's breadth is most useful and its authority least dangerous.
- Give the reviewer the design and the constraints, and ask for objections, not alternatives. "Here is my order lifecycle and my invariants; what transitions are missing, what state is unreachable, what invariant does this allow to break?" produces a list you can check one item at a time. "What would you design?" produces a rival.
- Judge each objection as a claim about your system. Some are right and change the design; some are right about some other system and do not apply; some are wrong. Sorting them is the review, and only you can do it, because only you know which assumptions are requirements (What Must Be True?).
- Implement the decided design yourself. The review changed a state machine on paper; the code that follows is yours, and building it is where the remaining errors surface. A design you implemented is one you can debug (From Pseudocode to Code).
The review loop, in order
The pipeline is short and the order is the whole lesson. The assistant appears once, in the second position, and never in the first or last. Each step names what it produces and how the reflex hollows it out.
- 1Your design
States, transitions, invariants, and the holes labelled honestly.
fails by An empty page, or a paragraph of intent.
- 2AI critiques
Objections in a fixed form: missing, unreachable, breakable, assumed.
fails by "What would you design?" — a rival instead of a review.
- 3You decide
A written verdict per objection: accept, does not apply, wrong — with why.
fails by Accepting by count; the design absorbs every objection.
- 4You implement
The decided design, built by you, surfacing what paper could not.
fails by Pasting the reviewer's version of the design.
The loop repeats on the implementation. The second pass, on code, is where most of the value is, and it is only possible if the first pass left you with a design you understand.
Sorting the objections
Every objection arrives with the same confidence, so confidence cannot be the sorting key. The decision below is the one you make per objection, and its options are the three verdicts. The criteria are about your system, which is why only you can apply them.
The reviewer says the design is missing something. What is the verdict?
when The objection names an invariant of your system that the design lets break, or a transition your requirements need and the design lacks.
cost A redesign, and a check that the fix does not open a different hole.
when The objection is right about a system with different requirements — partial shipments, multiple warehouses — that yours does not have, and you can say so.
cost A written reason, and a note in the "later" list in case the requirement arrives.
when The objection misreads the design or asserts a constraint that is not true here.
cost The effort to be sure it is wrong rather than merely unwelcome; a second look at your own design.
How the review itself fails
The failures below are of the move, not of the assistant. Each is a way of appearing to review a design while actually replacing, ignoring or never finishing it.
| Trigger | Symptom | Cause | Response |
|---|---|---|---|
| Asked for a design instead of objections | The implemented state machine has states nobody on the team can explain. | The reviewer's design replaced yours; its assumptions became your requirements. | Return to your sketch; ask for objections to it; give each a verdict. |
| Objections accepted by count | The design grows a state for every objection; V1 has dispute handling and no customers. | No verdict step; every objection was treated as a requirement. | Sort with the three verdicts; move "does not apply" items to the later list. |
| Assumption objection answered by the assistant | "We have partial shipments" appears in the design; the founder has never heard of them. | A requirement question was asked of a tool that cannot know the answer. | Take it to whoever owns the requirement (Asking People). |
| No second pass on code | The paper design was fine; the refund call inside the transaction times out under load. | The review stopped at the design; the implementation was never reviewed. | Run the same review on the code, with the same invariants. |
How to do it
Most important first.
- Write the design before opening the assistant, badly if necessary. A design with a hole labelled "refunds?" is reviewable; an empty page is not.
- Send the design with its constraints and invariants, and ask for objections in a fixed form: missing transitions, unreachable states, invariants that can be broken, assumptions you have made silently.
- For each objection, write one of three verdicts and why: "accept — changes the design", "does not apply — because", "wrong — because". The written why is what you will re-read in six months (The Decision Journal).
- When an objection reveals an assumption, take it to whoever owns the requirement, not back to the assistant. "Do we have partial shipments?" is a founder question (Asking People).
- Re-run the review after implementation, on the code, with the same constraints. The second review is cheap and finds the errors the paper design could not show.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The order lifecycle, reviewed. Design sent: created → paid → shipped, with cancelled reachable from created and paid; refunds unknown. Objections received: no state between paid and shipped for a partial pick; cancelled-from-paid needs a refund and the design has no refund state; shipped orders can be disputed; nothing says what happens if payment confirmation arrives after cancellation. Verdicts: partial pick — does not apply, one warehouse, one shipment in V1; refund state — accept; disputes — does not apply yet, written down as later; late confirmation — accept, and it is the most valuable item on the list, because it is the one the sketch could not have shown.
- The decision, then the implementation. The state machine gains refund-pending and refunded, and a rule that a late confirmation on a cancelled order triggers a refund rather than a paid state. You implement it, and the implementation surfaces a question the review did not: who initiates the refund with the provider, and what if that fails? That question goes into the notebook and the next review, and the cycle continues on your design, not a replacement.
- The URL shortener, where the reviewer was right and it hurt. Design: a random six-character code, checked for collision on insert. Objection: the check-then-insert is a race, and a unique constraint makes the check redundant. Verdict: accept. The design changed because the objection was about an invariant, and the invariant was yours.
How you know it worked
What now exists that did not before, and what question you can now ask.
- A design of yours exists before the assistant is opened, and the assistant's output is a list of objections to it.
- Every objection has a written verdict, and at least one verdict is "does not apply — because", which shows the objections were judged rather than absorbed.
- The implemented design is still recognisably yours, changed where the review was right.
- Objections that revealed assumptions went to a person, not back to the assistant.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?Do I have a design specific enough to be objected to, or only an intention?
- ?For each objection: is it right about my system, right about some other system, or wrong — and why?
- ?Which objection revealed an assumption, and who actually owns the answer to it?
- ?After implementing, what did the code show that the paper design could not?
What can go wrong
- The review loop never closes: every design gets objections, every objection gets a redesign, every redesign gets objections. Stop when the remaining objections are about things outside V1 or about assumptions you have decided to keep.
- Objections are accepted by count rather than by judgment. Twelve objections is not a verdict on the design; it is a list to sort, and a list where eleven do not apply is a good review of a good design.
- The "design" sent for review is a paragraph. A reviewer can only object to what is specific; send states, transitions and invariants, not intentions.
- The reviewer is used on things that do not need one. A rename does not need a state-machine review; the move is for designs with invariants that can be broken.
- Writing the design first costs the time it would have taken to read a generated one, and on a problem you understand poorly your first design will be worse than the generated one. That is the price of a design you can defend.
- Asking for objections rather than alternatives means you do not see the other design at all, and occasionally the other design contained an idea worth stealing. You can ask for it afterwards, once yours has been reviewed.
- Writing verdicts is bookkeeping, and bookkeeping is what gets skipped on a deadline. The verdicts are also the only record of why the design has the shape it has.
- "Never let the assistant propose a design." Proposing is fine after the review, as a source of ideas to judge against a design you already hold. The rule is about order, not prohibition.
- "The assistant's objections are authoritative." They are claims. The late-confirmation objection was right; the partial-pick one was right about a different store. Both arrived with the same confidence.
- "A design that survives review is correct." It has survived one reader's objections. Implementation and the failure path will find more; the review lowers the count, it does not zero it (Failure Path Second).
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALThe order — your artefact, then critique, then your decision, then your implementation — applies to designs, schemas, pseudocode, tests and prose; what changes is the form the objections take.
- TEAM-SPECIFICOn a team with human reviewers, the assistant is a first pass that makes the human review shorter; solo, it is the only reviewer, and the verdicts must be written with more care because nobody will challenge them.
- CONTESTEDA strong opposing view holds that on a problem you do not understand, seeing several generated designs first is the fastest way to learn the shape of the space, and that insisting on your own sketch first produces a worse sketch and a slower review. Proponents argue the sketch-first rule is a learning exercise dressed as engineering practice, and that experienced engineers routinely read alternatives before committing. The view is strongest on unfamiliar domains where the learner's first design would be wrong in ways they cannot yet see.
- ILLUSTRATIVEThe order lifecycle, the objections and the six-character code are invented to show the shape of a review; no real assistant transcript is quoted.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's "Review the LLM's answer" page at /manifesto/review is the same move with the roles reversed: there you review its output, here it reviews yours. Both exist because a design nobody has judged is a design nobody owns.