49 lines
5.9 KiB
Markdown
49 lines
5.9 KiB
Markdown
# 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).
|