From Creation to Review

Overview

The last topic of Module 7 and of Part 3. It is the most personal one in the guide so far.

Module 1 made a claim and asked you to treat it as a strong thesis rather than settled fact: when generation becomes cheap, code and designs stop being the scarce thing, and the bottleneck moves to deciding what to build and verifying the result. Modules 4 to 7 are the evidence. Every module in it has been, in some sense, about checking — evaluating model output, verifying actions, auditing a corpus, red-teaming a design.

This topic is about what that does to your week.

The shift, concretely

graph LR
  A["Generation<br/><i>cheap, fast,<br/>plausible by default</i>"] --> B["Many candidate<br/>designs and<br/>implementations"]
  B --> C["<b>Review</b><br/><i>the bottleneck</i>"]
  C --> D["One decision<br/>you can defend"]

  classDef cheap fill:#7C7C7C,stroke:#5E5E5E,stroke-width:2px,color:#ffffff
  classDef many fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef neck fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  classDef out fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  class A cheap
  class B many
  class C neck
  class D out

Supply of candidate work rises; your capacity to validate it does not. The terracotta box is where the queue forms, and it is the part nobody staffs for.

A checklist, because “review it” is not an instruction

The instruction “review this design” tells a person nothing about what to do. Reviewing generated architectural work needs explicit questions, because the thing you are hunting has no signature.

Six questions, in the order that catches the most:

Does it satisfy the stated requirements — named individually? Not “does it look adequate”. Walk the ASR list and point at the mechanism for each. A requirement with no corresponding mechanism is the most common real defect and the easiest to miss, because nothing in the document says a requirement is unaddressed.

What did it omit? The hardest question, because absence has no signature. A generated design will not tell you it skipped the erasure path, the overflow behaviour, or the unknown-outcome state. The countermeasure is a checklist you bring with you rather than one you derive from the document in front of you.

What did it assume without saying? Spare capacity. A cooperative downstream system. Idempotency support that may not exist. A corpus that can answer the questions.

Where is a trade-off unnamed? A design that lists only benefits is incomplete by construction. For every technique, ask what it costs — Module 1 made this the guide’s recurring rule and it is the fastest review heuristic available.

Does it respect the constraints, or assume them away? Residency, compliance, the legacy system, the deadline. Constraints get quietly converted into preferences in generated work, because they read like preferences.

Would the person who can block this approve it? The organisational test, and the one no automated pass can perform.

Why this work is harder than writing

Module 1 said it; Modules 4 to 7 have earned the right to say it more bluntly.

Reviewing is worse work than creating. Writing has flow. Review has vigilance, which does not sustain — attention degrades over pages in a way that producing does not. Writing produces an artifact you can point at. Review produces the absence of a problem, which nobody will ever see and nobody will thank you for.

And the failure mode is specific: “it looks right.” Generated output is fluent by construction, and fluency reads as correctness. The error you are looking for is almost never malformed. It is a confident, well-structured, plausible answer that is wrong about something you would need domain knowledge to catch — which is why Module 1 argued that Domain Authority appreciates as generation gets cheap. This is that argument arriving with evidence behind it.

What that implies structurally

Two things, both of which are architecture rather than attitude.

Review has to be scheduled and resourced, not squeezed into the gaps. Capacity to validate is now the constraint, and a constraint you do not plan for becomes a queue — or worse, becomes a rubber stamp, which is a review that has stopped functioning while still appearing in the process diagram.

Verification discipline needs artifacts. Unaided vigilance degrades; a checklist does not. The six questions above, the ASR list, the rubric, the adversarial suite — these exist so that review quality does not depend on how tired you are at four o’clock. Module 9 turns this into governance, with review protocols for AI-generated architecture as an explicit part of the practice.

Module 10 returns to the career consequence, and the short version is this: the skill that is appreciating is not producing designs faster. It is knowing what to check, and having the domain knowledge to catch what fluency hides.

Reviewing the Modules 4–6 design

Applying the six questions to the artifacts, and noticing which defects the questions actually caught.

Requirements, named individually. Walking the Module 2 ASR list against the design finds every number with a mechanism except one: overflow behaviour on the action path had no designed response until the context topic added it. That is question one doing exactly its job — a requirement with no mechanism, invisible in a document that reads well.

Omissions. Three, all found by bringing a checklist rather than by reading harder: erasure did not reach the cache; the unknown-outcome state had no behaviour; machine-drafted resolutions could enter the corpus.

Unstated assumptions. That the Rails monolith honours idempotency keys — which a 2016 monolith may not, and which is a question for Ivan Petrov rather than a thing to assume. And that the 38% deflectable figure describes the corpus rather than the ticket topics.

Unnamed trade-offs. The confirmation gate’s deflection cost was named, which is good. The quality bar for degraded rungs was not, until the fallback topic required it.

Constraints respected? Residency is handled through three gates including the evidence gate, so yes. Capacity is the weaker one: the design assumes a slot that Module 3’s displacement statement bought, and nothing re-checks that it still exists.

Would the blocker approve? Module 6’s privacy design was written for exactly that test, which is why it is six sections in a reviewable shape rather than an architecture diagram.

The pattern worth noticing: every defect found above was found by a question brought to the document, not by reading the document more carefully. That is the whole argument for verification discipline being an artifact rather than a virtue.

Feeds the workbook

This topic shapes the antipattern review more than any other: use the six questions as its structure. The rubric requires finding at least one real problem in your own design, and the second question — what did it omit — is where real problems actually live.

→ Part 3 ends here. The design has been built, operated, and then attacked by its own author. — Module 8 — Working Through the Organisation

Optional workbook: Exercise 7 turns this module into artifacts. The exercises build on each other, so work them in order or not at all.