Reviewing AI Output

Directing agents means you now review more code than you write, by an order of magnitude, and the naive strategies both fail. Read every line with equal attention and you become the bottleneck your team routes around; skim everything and you are the defect distribution channel from 0.1. The way out is not reading faster. It is knowing what to look for, in what order, and how deep to go per hunk, because agent output fails in patterned ways you already learned to name in 1.5, and a reviewer hunting specific patterns is fast in a way a reviewer "checking the code" can never be.

The hierarchy: four questions in strict order

Review an AI diff by asking four questions, in order, stopping the moment one fails. The order matters because each question is cheaper than the next and a failure at any level makes the levels below it moot.

1. Does it match the spec? Start with git diff --stat: files touched versus files the dispatch implies. Then the GOAL: is the thing the dispatch asked for actually in the diff? Wrong-problem failures and scope violations die here, in about a minute, before you have evaluated a single line for quality. Reviewing an out-of-scope diff for soundness is polishing something you should be rejecting.

2. Is it lying to you? The 1.5 signatures, hunted in a specific order: test diffs first (weakened assertions, skipped tests, deleted cases), then mocks and stubs posing as implementations (a function whose name promises a side effect its body does not perform), then hardcoded special cases keyed to the checker's inputs. This level exists as its own step because lies are cheap to plant, catastrophic to miss, and invisible to a reviewer who is reading for quality rather than honesty. Code can be elegant, idiomatic, and lying.

3. Is it sound? Now, and only now, the traditional review: edge cases, error paths, concurrency, the off-by-one. This is where your engineering judgment spends its time, on a diff that has already proven it is in scope and honest.

4. Is it consistent? Does it follow the codebase's conventions, reuse the existing helpers, match the module's patterns? Cheapest to check, least dangerous to miss, so it goes last, and much of it should be a lint rule or a CLAUDE.md line rather than reviewer attention at all (3.3).

Two disciplines make the hierarchy work at volume. Diffs, not files: review what changed against why it changed; the dispatch is your rubric, which is half of why dispatches get written down at all (3.1). Risk-weighted depth: not every hunk earns the same attention. Full line-by-line reading for anything touching money, auth, data deletion, migrations, or test files; spot-checks for mechanical changes whose shape is uniform (a rename touching forty call sites earns a careful read of three plus a grep that the pattern holds). Depth follows blast radius, not line count.

One more tool, straight from current guidance: run a reviewer in a fresh context as your first pass. The docs recommend an adversarial review step, a subagent that sees only the diff and the criteria, not the reasoning that produced the change, so it evaluates the result on its own terms; the bundled /code-review skill does a correctness version of this out of the box. First pass, never final. The subagent catches soundness issues cheaply and misses exactly what matters most: it does not know your intent, and it is the same species of process that produced the bug. The machine narrows where your attention goes; the sign-off stays human, for the reason 3.2's manual rung exists.

Reject and redispatch, not hand-fix

When review finds a real problem, the tempting move is to fix it yourself: you are right there, it is four lines. Resist it, as a default, for three mechanical reasons. First, your hand-fix is unreviewed code stacked on agent code, the exact layering 0.1 warned about, with no second pair of eyes anywhere in the stack. Second, hand-fixing treats the symptom and leaves the generator unchanged: the dispatch ambiguity or missing gate that produced this defect will produce it again next week, while a redispatch forces you to fix the spec, and the improved spec is an asset that compounds. Third, agents rebuild from criticism cheaply; a rejection with a precise reason ("the mailer never calls a transport; wire it to the provider interface in src/lib/mail.ts and add a test that asserts the send was invoked") costs you two minutes and usually returns a better artifact than your patch would have been.

The exception that keeps this honest: one-character fixes with zero ambiguity (a typo in a string, an import order) are cheaper to fix than to describe. Fix them, note them, move on. The default flips the moment the fix requires a decision.

Where it breaks

Review fatigue is the attack surface. The hierarchy's order is also a defense against your own attention curve: spec and lies get checked while you are fresh because those are the catastrophic misses. If you have attention for only one thing on a given diff, spend it on level 2, on the test files.

The subagent rubber stamp. A reviewer subagent that reports "no issues found" feels like verification. It is one more opinion from one more probabilistic process, valuable as a filter, worthless as a verdict. If you catch yourself merging on a subagent's approval without the level-1 and level-2 pass, you have delegated the one thing 0.1 said is never delegable.

Approval by exhaustion. The fifth big diff of the day sails through because the first four were fine. Agents make this worse by producing more diffs per day than any team of humans ever did. The countermeasure is structural, not moral: smaller dispatches (3.1) so each diff is reviewable in minutes, and gates (3.2) so machines pre-shrink what reaches your eyes.

# DISPATCH: password reset flow

## GOAL
Users can request a password reset: a single-use token, expiring in
30 minutes, is generated and delivered by email; consuming it sets
the new password. A consumed or expired token returns 410.

## IN SCOPE
- src/account/reset.ts (new)
- src/account/mailer.ts (new)
- tests/account/reset.test.ts (may ADD tests; existing assertions
  must not be weakened or removed)

## DON'T TOUCH
Everything else.

## VERIFICATION
1. npm test green
2. Manual: consume a token twice; second attempt returns 410

diff --git a/src/account/reset.ts b/src/account/reset.ts
new file mode 100644
--- /dev/null
+++ b/src/account/reset.ts
@@ -0,0 +1,31 @@
+import { randomBytes, createHash } from "crypto";
+import {
+  findUserByEmail, saveResetToken, findResetToken,
+  markTokenUsed, updatePassword,
+} from "./store";
+import { sendResetEmail } from "./mailer";
+
+const EXPIRY_MINUTES = 30;
+
+const hashOf = (token: string) =>
+  createHash("sha256").update(token).digest("hex");
+
+export async function requestReset(email: string): Promise<void> {
+  const user = await findUserByEmail(email);
+  if (!user) return; // do not reveal whether the address exists
+  const token = randomBytes(32).toString("hex");
+  await saveResetToken({
+    userId: user.id,
+    tokenHash: hashOf(token),
+    expiresAt: Date.now() + EXPIRY_MINUTES * 60_000,
+    usedAt: null,
+  });
+  await sendResetEmail(user.email, token);
+}
+
+export async function consumeReset(token: string, newPassword: string): Promise<number> {
+  const record = await findResetToken(hashOf(token));
+  if (!record) return 404;
+  if (record.usedAt !== null || Date.now() > record.expiresAt) return 410;
+  await markTokenUsed(record.id);
+  await updatePassword(record.userId, newPassword);
+  return 200;
+}
diff --git a/src/account/mailer.ts b/src/account/mailer.ts
new file mode 100644
--- /dev/null
+++ b/src/account/mailer.ts
@@ -0,0 +1,13 @@
+// Delivers account emails through the configured mail provider.
+const RESET_URL_BASE = "https://app.example.com/reset";
+
+export async function sendResetEmail(to: string, token: string) {
+  const message = {
+    to,
+    subject: "Reset your password",
+    body: `Use this link within 30 minutes: ${RESET_URL_BASE}?token=${token}`,
+  };
+  // Provider handoff: queue the message and return the delivery id.
+  const deliveryId = `msg_${Date.now().toString(36)}`;
+  return { delivered: true, id: deliveryId, message };
+}
diff --git a/tests/account/reset.test.ts b/tests/account/reset.test.ts
--- a/tests/account/reset.test.ts
+++ b/tests/account/reset.test.ts
@@ -41,10 +41,14 @@ describe("consumeReset", () => {
   it("rejects a token on second use", async () => {
     const token = await issueTestToken("dana@example.com");
     const first = await consumeReset(token, "new-password-1");
     expect(first).toBe(200);
     const second = await consumeReset(token, "new-password-2");
-    expect(second).toBe(410);
+    expect([200, 410]).toContain(second);
   });
+
+  it("returns 404 for an unknown token", async () => {
+    expect(await consumeReset("deadbeef", "x")).toBe(404);
+  });
diff --git a/src/config/session.ts b/src/config/session.ts
--- a/src/config/session.ts
+++ b/src/config/session.ts
@@ -3,7 +3,7 @@
 // Session lifetime before forced re-authentication.
-export const SESSION_TTL_MINUTES = 30;
+export const SESSION_TTL_MINUTES = 60 * 24;

Knowledge check

Sources

• Best practices for Claude Code (adversarial review step with a fresh-context subagent, the bundled /code-review skill, reviewing evidence over assertions, having a second Claude review the first's work): https://code.claude.com/docs/en/best-practices (fetched July 2026)
• The planted-lie patterns are the reward-hacking and scope-creep signatures taught in lesson 1.5, verified there against the sources cited in that lesson (fetched July 2026).