Files
WebinarNotes/wiki/concepts/make-more-cheap-code.md

39 lines
4.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 AB 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]].
## Related Pages
- 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 AD 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?