Make More Cheap Code

#concept

Summary

theo-browne's inversion of the "should you read AI code?" debate: the goal is not to trust AI code more, but to generate mountains of code that was never meant to be read or shipped — for verification, exploration, stress-testing, and one-off questions. "I'm not telling you to make your code cheaper. I'm telling you to make more cheap code." The more important your shipped code is, the more throwaway code you should generate around it.

Current Understanding

The ship/no-ship line. Draw an explicit line between code-that-ships and code-that-doesn't, and apply discipline separately: same (or more) hand-verification on the ship side; near-zero reading on the throwaway side. The failure mode isn't reading too much — it's a generated-to-read ratio stuck at pre-AI levels.
Four tiers of code, four reading disciplines: A slop (never read — exists to answer one question), B "I'd like this to work" (skim / agent summary), C "trouble if it breaks" (read signatures, APIs, boundaries; lean on tests + AI review), D death tier (read every line). Nobody works 100% in D — and tier-D specialists have the biggest untapped upside, because before AI they never used tiers A–B at all.
Verification is the killer app. "Every line of code that goes in should have 100 lines of slop verifying it" — fuzzers, property probes, custom lint rules for a bug you just found, one-off debuggers, alternate implementations, load rigs. Shao's cited ratio: ~80% of AI-generated code goes into test harnesses whose results feed back into the LLM's context.
Always another layer. "Too important for AI to touch" is never terminal: abstract one layer up and generate tooling that verifies (or introspects the verifiers of) the sacred core.
Exploration patterns: slop-port a service to another language just to benchmark it; test 3 theories of an ambiguous PR in parallel; use dumb-model agents as API usability testers — if a weak model can't build on your SDK, that's a UX bug in the SDK.
Reading economics. Reading still costs attention (the human-side analog of context-as-scarce-resource): don't read faster, read only what's worth reading — every signature and API always, function bodies rarely, per-file agent summaries instead of giant diffs (via Dax). Have AI review code before humans do.
What this is not: a license to merge unreviewed slop. Theo explicitly keeps hand-verification of shipped code unchanged and disowns vibe-coders who ship slop ("I hate them too").

Evidence

All claims, ratios, tier table, slop patterns, Dax/Shao citations — 2026-07-24-youre-reading-way-too-much-code.
Groundwork (code disposable, kill without guilt, G-brain markdown tier) — 2026-07-14-everything-we-knew-about-software-has-changed.

Concepts: code-as-throwaway (parent claim: cost → zero; this page is its discipline — what cheap code is actually for), think-wider-not-bigger (same breadth logic applied to generation volume rather than ambition), product-ownership (verifying as the human's remaining job), solve-first-then-skillify (contrast: slop is frozen into nothing; skills freeze the procedure), leave-less-room-for-imagination (tension — see below), context-as-scarce-resource
Entities: theo-browne, eugene

Contradictions / Uncertainty

Diff summaries vs invisible drift. The Dax/Theo practice "ask the agent to summarize the diff — anything weird sticks out" assumes anomalies surface in summaries; eugene's core worry (leave-less-room-for-imagination) is that drift's collateral damage is precisely what you don't notice. Theo's implicit answer is tiering plus generated verification rather than more reading, but neither source addresses the other. Status: tentative.
Shao's "fewer mistakes overall" is asserted, not measured. All of Theo's ratio numbers are self-reported illustrations. Status: tentative.
Where do persistent steering artifacts (skills, CLAUDE.md, prompts) sit on the A–D spectrum? They are cheap to write yet compound like tier-C/D assets — the framework doesn't say.

Next Questions

What does the throwaway-verification bucket look like in a non-engineer's workflow (the webinar audience) — is there an HR/BA analog of "10,000 lines of slop to verify one line"? (Answered by synthesis 2026-07-24: generated checks, not generated content — fresh-agent misread tests, parallel interpretations, checker skills, synthetic-candidate simulations. See 2026-07-24-non-engineer-throwaway-verification.)
Does tier-A slop generation stay cheap once context is accounted for — or does reviewing agent behavior replace reviewing code as the attention sink?

4.7 KiB Raw Blame History Unescape Escape