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

49 lines
5.9 KiB
Markdown
Raw Permalink 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.
# 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 10010,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 AD 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).