JournalDAY 42 / X

FIELD NOTE / X

The decision log is the new review anchor.

The complete written thought and the evidence behind it. The video edition will follow its public release.

Journal September 25, 2026 · X target November 8, 2026

The decision log is the new review anchor.

Video caption

The decision log is the new review anchor. Repairs can erase an invariant that was never recorded. The code is implementation evidence for an owned choice. #EricFieldNotes

Full written post / accessibility read

When agents write most of the code, reviewing every line first can hide the higher-order mistake: the team chose the wrong boundary, ownership model or user outcome. The reviewer needs to see the decision the patch claims to implement.

Suppose a team chose a guarded allocator because a promotion route bypassed the old stock rule. Months later an agent simplifies the call graph. Without the original failure and test, it may remove the guard while leaving a tidy, green-looking patch.

A short decision packet names the customer outcome, options rejected, chosen boundary, invariant, owner and observation that would prove it wrong. Attach a protected regression fixture. A successor agent receives the packet when work touches that boundary.

Ask whether the observed test still supports the decision, then review the patch against that contract. Do this because fast code generation makes preserving the reason for the code more valuable, not less.

#EricFieldNotes

Four-beat scene transcript

1. The decision log is the new review anchor.

When agents write most of the code, reviewing every line first can hide the higher-order mistake: the team chose the wrong boundary, ownership model or user outcome. The reviewer needs to see the decision the patch claims to implement.

Visual: A thousand-line diff can implement the wrong objective beautifully.

2. A later session sees code without why.

Suppose a team chose a guarded allocator because a promotion route bypassed the old stock rule. Months later an agent simplifies the call graph. Without the original failure and test, it may remove the guard while leaving a tidy, green-looking patch.

Visual: Repairs can erase an invariant that was never recorded.

3. Record the falsifier with the choice.

A short decision packet names the customer outcome, options rejected, chosen boundary, invariant, owner and observation that would prove it wrong. Attach a protected regression fixture. A successor agent receives the packet when work touches that boundary.

Visual: Options, owner, prediction, test and rollback.

4. Review the decision before the diff.

Ask whether the observed test still supports the decision, then review the patch against that contract. Do this because fast code generation makes preserving the reason for the code more valuable, not less.

Visual: The code is implementation evidence for an owned choice.

Research and claim limits

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

More notes from the work ↗