WebinarNotes/wiki/sources/2026-07-24-youre-reading-way-too-much-code.md

You're reading way too much code — Theo Browne

#source

Source Metadata

• Date: YouTube video (publication date not stated in source), 24:11 — https://www.youtube.com/watch?v=434cG4g5KLE
• Raw path: raw/sources/You're reading way too much code.md
• Source type: video essay (conclusions/notes)
• Speaker: theo-browne (t3.gg / T3 / Lakebed)
• Ingestion date: 2026-07-24

Core Claims

• The problem isn't reading too much code in absolute terms — it's reading too high a percentage, because engineers aren't generating enough code that doesn't matter. "I'm not telling you to make your code cheaper. I'm telling you to make more cheap code." See make-more-cheap-code.
• The importance-of-code spectrum runs from "slop website with one viewer" to "pacemaker firmware." The AI-code debate stalls because people (a) overestimate where they sit on it and (b) project every claim they hear onto their own tier.
• Four tiers of code (A slop / B "I'd like this to work" / C "trouble if it breaks" / D death tier), each with its own reading discipline — from "never read it" (A) to "read every line" (D). Nobody works 100% in D.
• Steelman granted, then inverted: if your production code could kill someone, that's a reason to read every shipped line and to generate 100–10,000× more throwaway code to verify it. "Every line of code that goes in should have 100 lines of slop verifying it."
• There is always another layer: if the core is too important for AI, abstract up — custom debuggers, runtimes, lint rules, load rigs. If the verification tools are too important, build tools that introspect them.
• What changed: writing is nearly free, reading still costs attention — so the generated-to-read ratio should skyrocket while hand-verification of shipped code stays the same or increases.
• Explicit anti-endorsements: merging unreviewed slop, reducing verification of shipped code, "move faster" as an end. "I hate them too. We're on the same side" (re: vibe-coders shipping slop).

Key Evidence / Details

• Ratio shift (his own numbers): pre-AI ~1,000 read / 200 written / 100 merged per day; now ~1,000 read / 2,000+ written / ~500 merged — the unmerged bulk exists to test ideas and is never reviewed. Reframing chart for a tier-D engineer: read goes up in absolute terms (200→400), slop goes 0→800+, merged stays ~100.
• Shao's ratio (cited approvingly): ~80% of AI-generated code goes into test harnesses and guardrails, with harness results fed back into the LLM's context — fewer mistakes overall.
• Concrete slop patterns: on-demand custom lint rules for a found bug pattern; one-off debuggers; slop-porting a Go service to Rust just to benchmark the test suite; 10 dumb-model agents building on a fresh API — their failures are UX bugs in the API; agent with AWS access spinning up throwaway load rigs; testing 3 theories of an ambiguous PR in parallel; bespoke one-off test suites.
• Tier-C reading tricks (via a Dax post): after a big diff, ask the agent for a per-file summary instead of reading the diff — "anything weird will stick out"; read function signatures and API definitions always, care less about bodies. Theo's Lakebed version: read every signature/API, use slop (the 10-dumb-agents test) to verify them.
• "Writing 10,000 lines of code to organize 100 files is mental illness until the code is free to generate. Then all of a sudden it's totally reasonable."
• Closing principles: code is useful for things other than shipping; draw the ship/no-ship line and apply discipline separately per side; if you can't find slop opportunities "you're not creative enough"; don't read faster — read only what's worth reading; have AI review code before humans do.

Connections

• Entity: theo-browne (his second source in the vault)
• Concepts: make-more-cheap-code (created from this source) · code-as-throwaway (this source answers its open question: the durable artifact includes the verification harness) · think-wider-not-bigger (same author-move: reframe a human-side habit as the bottleneck) · leave-less-room-for-imagination (tension: agent-summary-instead-of-diff vs Eugene's invisible collateral damage — logged there) · product-ownership (verifying as the human's remaining job) · context-as-scarce-resource (reading costs attention — the human-side analog)
• Related sources: 2026-07-14-everything-we-knew-about-software-has-changed (his earlier talk: code disposable, kill without guilt — this source supplies the discipline for that stance); 2026-07-21-larysa-interview (Eugene's trust carve-out and invisible-drift worry — the audience this source's tier framework speaks to)
• Tools/people mentioned: Codex, AWS, Grok-tier models, Dax, Shao, Lakebed

Open Questions

• Shao's "~80% into harnesses, fewer mistakes overall" is cited without data — is there any measured before/after? Status: tentative.
• The tier framework assumes you can cleanly separate ship-code from slop; where do skills/prompts/CLAUDE.md files (which do persist and steer future generations) fall on the A–D spectrum?
• Does the "agent per-file summary instead of the diff" practice survive Eugene's objection that drift is precisely what a summary hides? (Logged as a tension in leave-less-room-for-imagination.)

Change Impact on Wiki

• Created make-more-cheap-code (concept — throwaway generation for verification/exploration; four tiers; always-another-layer).
• Updated code-as-throwaway (verification as the durable use of cheap code; partial answer to its "what is the durable artifact" question), theo-browne (second source; sharpened stance — explicitly anti-slop-shipping), leave-less-room-for-imagination (new logged tension on diff summaries vs invisible drift), 2026-07-14-everything-we-knew-about-software-has-changed (reciprocal related-source link), overview (8→9 sources; "verifying" half of the spine deepened).