# Paper 04: Review Economics and the Increment Sizing Rule **Series:** Aigile deep dives, paper 04 of 08. Elaborates working paper Sections 5 and 8. Depends on Paper 02. ## Abstract When generation is nearly free, verification is the constraint, and any methodology that treats review failure as a discipline problem will fail with disciplined people. This paper develops aigile's structural answer: review economics over review discipline. It specifies the four mechanisms that reprice review (executable acceptance criteria, diff-based review, the atomic PR, and the increment sizing rule), derives the sizing rule's three-way alignment of human attention, agent context, and blast radius, and defines the day-to-day working loop these mechanisms compose into. The claim throughout is economic: people review what is cheap to review and skip what is expensive, and the methodology's job is to move the important checks into the cheap category. ## 1. Position in the framework This paper governs the ephemeral layer's economics (Paper 02) and supplies the loop inside which the deviation protocol (Paper 05) and validation gates (Paper 06) fire. Its sizing rule is the load-bearing smallness that keeps every backward edge (Paper 01) short. ## 2. The problem in full ### 2.1 The asymmetry An agent produces a thousand-line change in minutes; a human needs an hour to review it honestly and thirty seconds to approve it dishonestly. Under that asymmetry, rubber-stamping is not laziness. It is the rational response of a busy person to a mispriced task, and it will recur under exhortation exactly as fast as it recurred before the exhortation. The complaint that people have become too lazy to read agent output misdiagnoses an economic problem as a moral one, and moral solutions to economic problems have a fixed failure rate of one hundred percent. ### 2.2 The velocity paradox Organizations adopting agents report the paradox: code production accelerates while deployment stability and debt worsen, because checking capacity did not scale with generating capacity. The distinction that matters is between **verification** (does the system do what the instructions said), which is increasingly mechanizable, and **validation** (does it do what the humans actually wanted), which is definitionally human (Paper 06). Review economics is the program of mechanizing verification honestly so that scarce human attention concentrates on validation. ## 3. The mechanism: four instruments ### 3.1 Executable acceptance criteria The human reviews intent once, at criteria approval; verification thereafter is mechanical and free. The formula: **the human validates the question, the machine validates the answer.** A criterion in prose ("retries must be safe") is a standing review cost and a drift surface; the same criterion as a test (submit the same order twice, assert one persisted record) costs one review ever. R4 (Paper 02) already requires executability with written justification for exceptions; this paper adds the economic reading: every criterion left in prose is a recurring tax voluntarily paid. ### 3.2 Diffs, not documents No participant is ever asked to re-read an artifact to find what moved. Specification changes present as spec-diffs with the same tooling, comment threads, and approval mechanics as code-diffs. The reviewable unit of the specification layer is the change, not the corpus. This single presentational choice removes the largest fixed cost in document review and is the reason spec review can survive contact with real schedules. ### 3.3 The atomic PR Code-diff, test-diff, and spec-diff travel as one reviewable, mergeable unit; updating the specification is part of the definition of done, not a follow-up task, because follow-up documentation tasks have a completion rate indistinguishable from zero. The atomic PR is simultaneously an economic instrument (one review context instead of three), the primary drift-prevention channel (Paper 05: divergence resolved at birth), and the embedded conformance gate for small teams (the merge reviewer, seeing spec and code together, is the conformance check without a standing role). ### 3.4 The increment sizing rule > An increment is correctly sized when **one human can review it in one sitting and one agent can implement it in one session's context.** The rule aligns three constraints that normally fight: - **Human attention.** Review quality degrades nonlinearly with diff size; a sitting is the honest unit of sustained attention. - **Agent context.** Work exceeding one session forces context reconstruction, and reconstruction is where agents silently lose constraints (every reconstruction is a fresh roll of the amnesia dice, Paper 02). - **Blast radius.** A mis-specified or mis-implemented increment costs at most one slice of rework, which is what made the Orderly skeleton in Paper 01 cheap to be wrong about. The rule replaces story-point estimation entirely: sizing is a binary test against two observable capacities, not a negotiation about abstract effort. Both capacities are measurable per team and per agent generation, and both move; the rule's parameters are recalibrated at retrospectives (Paper 08), not fixed in doctrine. ## 4. The working loop The instruments compose into aigile's day-to-day shape: 1. **Intent.** A human expresses feature intent; agents assist in drafting and challenging it. 2. **Slice.** Decomposition under the sizing rule; the first slice is always a walking skeleton (Paper 06). 3. **Specify thinly.** One-screen spec, executable criteria, detail budgeted per Paper 05's rule (what must be true, not what happens to be true). 4. **Build.** Agent or pair implements; deviations take the Paper 05 protocol, never silence. 5. **Verify.** Criteria run mechanically; the atomic PR is reviewed in one sitting. 6. **Validate.** Human gates per Paper 06's triggers. 7. **Learn.** Retrospective routing per Paper 08. Smallness is the invariant across all seven steps: small PRs keep human review real, small slices keep agent context coherent, small demos keep validation cheap, and short slices keep every backward edge short. In aigile, smallness is not a style preference. It is the load-bearing property. ## 5. Normative protocol > **R11 (Atomicity).** Code, tests, and specification changes for an increment merge as one unit. A merged increment with an unshipped spec-diff is a defect, not a task. > **R12 (Sizing).** No increment exceeds one human sitting to review or one agent session to implement. Oversized work is split before it starts, not apologized for after. > **R13 (Executability default).** Acceptance criteria are executable; each prose criterion carries a written justification and is counted (the count is a retro input). > **R14 (Diff presentation).** Specification review is always presented as change against approved baseline, never as re-read of the whole. ## 6. Orderly worked example Orderly's "consolidated invoicing" feature, rebuilt under this paper after the Paper 01 disaster: the human intent is one paragraph. Slicing yields six increments, the first being the walking skeleton (one invoice, two orders, correct grouping key, ugly rendering). Its spec is 22 lines; five of six acceptance criteria are executable, the sixth ("the invoice layout is acceptable to the pilot customer") carries its R13 justification and routes to the feature demo. Increment three comes back from slicing at an estimated two sessions and is split (tax computation separated from currency rounding). Each PR is reviewed in under twenty minutes; the reviewer of increment four catches, in the spec-diff, that a retry criterion was quietly weakened, which under the old regime would have been invisible inside a document re-read nobody performed. Total human review time for the feature: under two hours, all of it real. ## 7. Failure modes - **Batching relapse:** increments merge individually but demo in bulk, recreating big-bang validation. Counter: Paper 06 triggers bind to increments, not calendars. - **Sizing inflation:** "one sitting" quietly grows to three hours. Counter: measure actual review durations; the parameter is empirical, not aspirational. - **Executability theater:** criteria technically executable but asserting nothing (tests without meaningful oracles). Counter: adversarial review framing (Paper 07) and mutation-style spot checks at retro. - **Spec-diff blindness:** reviewers approving spec-diffs faster than they can be read. Detection: approval latency under humanly possible reading time is itself a metric alarm. ## 8. Metrics Review minutes per increment (distribution, not average); increments split by the sizing rule per feature; prose-criterion count and trend; time from merge to validation; approval-latency alarms; rework fraction per increment (should be bounded by slice size). ## 9. Open questions Empirical sizing parameters across agent generations (session capacity is a moving target); whether reviewer rotation preserves review quality or dilutes context; the interaction of R11 with trunk-based development at high increment frequency; economic modeling of the prose-criterion tax to give R13 a price tag. ## 10. Derivative artifacts Playbook chapter: the loop end to end with templates (intent paragraph, one-screen spec, atomic PR checklist); reviewer guide (what to check in a spec-diff); metrics dashboard specification; training material on slicing under the sizing rule.