Anchor code review in a design decision log.

Video caption

Anchor code review in a design decision log.

The successor needs the rejected options and failure evidence.

Question, alternatives, invariant, falsifier and evidence link.

My rule: Then inspect whether the code actually implements it.

#EricFieldNotes

Full written post / accessibility read

If agents produce much of the implementation, engineering review has to begin with the intended outcome and the assumptions underneath it. A decision log is useful when it records enough causal detail for a later person or agent to repair the system without inventing the original rationale.

A later session reads 'we use a reservation service' but not why direct stock writes failed, which test redlined them, or what cost the alternative had. It can simplify away the service in good faith. The lost information is causal, not textual.

For consequential architecture changes, store a short packet with decision owner, alternatives, tradeoff, non-negotiable invariant, cheapest falsifying test and rollback trigger. Route that packet to later agents only when their task touches the same boundary. Preserve its linked test outside their writable patch.

Make review ask three questions: Is this still the right product choice? Did the negative test run? Does the observed system match the decision? Do this because high-volume generated code only helps when the team's intent survives every later rewrite.

#EricFieldNotes

Four-beat scene transcript

1. Anchor code review in a design decision log.

If agents produce much of the implementation, engineering review has to begin with the intended outcome and the assumptions underneath it. A decision log is useful when it records enough causal detail for a later person or agent to repair the system without inventing the original rationale.

Visual: The hardest review question shifts from syntax to justified behavior.

2. A summary does not preserve a decision.

A later session reads 'we use a reservation service' but not why direct stock writes failed, which test redlined them, or what cost the alternative had. It can simplify away the service in good faith. The lost information is causal, not textual.

Visual: The successor needs the rejected options and failure evidence.

3. Keep an owned decision packet.

For consequential architecture changes, store a short packet with decision owner, alternatives, tradeoff, non-negotiable invariant, cheapest falsifying test and rollback trigger. Route that packet to later agents only when their task touches the same boundary. Preserve its linked test outside their writable patch.

Visual: Question, alternatives, invariant, falsifier and evidence link.

4. Approve the decision and its evidence.

Make review ask three questions: Is this still the right product choice? Did the negative test run? Does the observed system match the decision? Do this because high-volume generated code only helps when the team's intent survives every later rewrite.

Visual: Then inspect whether the code actually implements it.

Research and claim limits

• OpenAI Agents SDK/Codex orchestration example (S07)
• METR randomized trial (S20)

The examples identified as illustrative or simulated are design probes, not reported incidents. Vendor specifications do not establish workload performance.