43 lines
6.5 KiB
Markdown
43 lines
6.5 KiB
Markdown
# 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").
|
||
- **Variations, not answers** (added 2026-07-28). [[thorsten-ball]] extends the same economics past code into *design decisions*: ask for 10–15 variants and pick one. His orb icon came from 15 AI-generated versions across styles and 18 palettes; AMP's news imagery from turn-by-turn Midjourney rounds. Generation is cheap, so the human's job moves from producing the artifact to **choosing among artifacts** — taste at AI speed, which is his answer to the slop objection ([[code-as-throwaway]]). The webinar-relevant part: this is the version of "make more cheap code" that needs no codebase, so it transfers directly to a non-engineer ([[2026-07-24-non-engineer-throwaway-verification]]).
|
||
- **Ask for proof, since you're waiting anyway.** Screenshots, benchmarks, dark-mode and light-mode variants, fifty tests in parallel — cheap generated artifacts whose only job is to make a claim checkable. See [[async-by-default]], where the practice belongs to delegation rather than to reading.
|
||
|
||
## 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]].
|
||
- 15 icon variants, Midjourney rounds, "ask the agent for proof" — [[2026-07-28-agentic-engineering-10x-developer]].
|
||
|
||
## 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]], [[async-by-default]] (proof artifacts as the delegated form of the same move)
|
||
- Entities: [[theo-browne]], [[eugene]], [[thorsten-ball]]
|
||
|
||
## 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? *(Sharpened 2026-07-28: [[async-by-default]] multiplies parallel agents without multiplying review capacity, and Thorsten names **token budget** as a winner/loser variable — so the honest answer may be that cheap code is cheap in money and expensive in attention, which is precisely the resource this page says is binding.)*
|
||
- Does "15 variations, pick one" hold where the choice needs a criterion rather than taste? Picking an icon is judgment you already have; picking among 15 candidate job descriptions or architectures may require the analysis the variations were supposed to replace.
|