9.4 KiB
Conclusions
Source: https://www.youtube.com/watch?v=434cG4g5KLE Title: You're reading way too much code Duration: 24:11 Speaker: Theo Browne (t3.gg / T3 / Lakebed)
Core thesis
Most engineers are reading too high a percentage of their code — not because the code that matters shouldn't be read, but because they aren't generating enough code that doesn't matter. AI has made code cheap; the smart move isn't to merge more slop into your product, it's to write mountains of throwaway code around it to verify, explore, stress-test, and answer questions that were too expensive to bother with before.
"I'm not telling you to make your code cheaper. I'm telling you to make more cheap code."
The importance-of-code spectrum
All software lives on a spectrum:
| End | Example |
|---|---|
| Low | "Slop website with one viewer" |
| High | "Firmware for a pacemaker" |
Two big mistakes people make when arguing about AI code:
- They assume they're further along the spectrum than they actually are.
- They project the statement they hear onto their own tier — if they like it, they assume the speaker is at or above their tier; if they don't, they assume the speaker is below.
This makes the "should you read AI code?" debate nearly impossible because everyone is thinking too highly of themselves.
The old ratio vs. the new ratio
Theo's example numbers from his own workflow:
| Era | Read/day | Written/day | Merged/day |
|---|---|---|---|
| Pre-AI (Twitch era) | 1,000 | 200 | 100 |
| Now | ~1,000 | 2,000+ | ~500 |
Reading has not gone down. Writing and merging have both gone up — but the critical, unspoken piece is that a huge chunk of the newly generated code is never merged and never reviewed because it wasn't ever meant to be shipped. It exists to test ideas.
The key argument (Theo grants the strongest version of the opposition)
Steelmanned position: "Every line of code in my job is so important that a mistake could kill someone / bankrupt a business / stop a heart."
Theo grants this. Then:
- If your production code is that important, you should absolutely read every line of it.
- But — that's not a reason to write less code overall. That's a reason to write 10,000× more throwaway code to verify it.
- "Every line of code that goes in should have 100 lines of slop verifying it. Every line that goes in should have 10,000 lines of code of slop that you can use to verify the system."
- If the core is too important for AI to touch — abstract one layer higher. If the verification layer is too important — abstract another layer higher. Custom debuggers. Custom runtimes. Custom logging. Custom lint rules. Load-test rigs. Property-based probes.
Trap Theo calls out: "our verification tools are also too important for AI to touch." → Then build tools that introspect the verification tools. There is always another layer.
Referenced (approvingly): Shao's ratio — ~80% of his AI-generated code goes into test harnesses and guardrails, with the LLM getting the harness results in its context. Fewer mistakes overall.
The four tiers of code
| Tier | Label | Attitude toward reading |
|---|---|---|
| A — Slop | "I would rather die than have anyone read this code" (e.g. 10K lines to organize 100 files on his own machine) | Don't read it. It exists to answer one question. |
| B — "I'd like this to work" | Personal tools, experiments, prototypes | Skim. Ask the agent for a summary. |
| C — "I'll get in trouble if this breaks" | Product code that can be reverted | Read the pieces that matter — signatures, APIs, boundaries. Rely on tests + AI review. |
| D — Death tier | Pacemakers, ERPs, financial systems, medical devices | Read every line. Verify obsessively. |
Most people spend across multiple tiers. Nobody spends 100% in D. And that's the leverage point — because the tier-D specialists barely used tiers A-B before (since writing bad code by hand was as costly as good code), they now have the biggest untapped upside in throwaway code.
What actually changed
- Before: writing code was expensive → all your writing effort had to be worth merging → reading was cheap by comparison → high read-to-write ratios made sense.
- Now: writing code is nearly free → writing 10,000 lines to verify one line finally makes sense → reading is still expensive (it still costs attention) → the ratio of generated to read should skyrocket.
"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."
What "more slop" actually looks like in practice
Concrete examples Theo gives:
- Generate custom lint rules on demand for a specific bug pattern you found
- Build one-off debuggers and compiler hooks for a specific investigation
- Slop-port your Go service to Rust just to run the test suite against it and see if it's faster (knowing most won't merge)
- Spin up 10 agents with dumb models (grok tier) to try building on top of a freshly designed API/SDK — if dumb models can use it, ship it; if they can't, fix the API
- Give Codex AWS access and tell it to spin up services and stress-test your system
- When a PR is ambiguous — have an agent try 3 different theories in parallel and test all 3
- Missing tests? Have an agent write a bespoke test suite for the one-off theory you're worried about
Reading tricks for tier-C code (via Dax)
From a Dax post Theo quotes approvingly:
"Lately after a big diff change, instead of reading the diff, I ask the agent for a summary of what it did in every file. Anything weird will stick out immediately and one or two prompts later it's completely how he wants it. Files and function signatures he needs to know, but he cares less about the function body."
Theo's own version — for Lakebed:
- Reads every function signature and API definition, always — because stable APIs = maintainability
- Uses slop to verify the APIs — the 10-dumb-agents test above
The pattern Theo doesn't endorse
- ❌ Merging unreviewed AI slop into production
- ❌ Reducing verification of code that ships
- ❌ "Move faster" as an end in itself
- ❌ Being one of the loud lovable/vibe-coder-ships-slop people — Theo openly calls those the most obnoxious people on earth and says "I hate them too. We're on the same side."
The pattern he does endorse:
- ✅ Same (or more) hand-verification of code that ships
- ✅ Much more generation of code that never ships
- ✅ Using AI to review code before humans do
- ✅ Treating code as disposable — "for one idea, one theory, one question, one thing"
Reframing chart — "same read, more write, same merge"
| Metric | Old day for a tier-D engineer | New day (Theo's proposal) |
|---|---|---|
| Lines written for prod (hand-verified) | 100 | 80-100 (roughly unchanged) |
| Lines read (hand-reviewed) | 200 | 400 |
| Lines generated as throwaway slop | 0 | 800+ |
| Merged | 100 | 80-100 |
Read goes up in absolute terms. Slop goes way up. Merged is unchanged. Percent-of-code-you-read as a share of generated falls dramatically — which is the whole thing Theo is defending.
Cross-cutting principles
- Code is useful for things other than shipping. Exploration, verification, debugging, one-off answers, "does this API feel right when a dumb model uses it".
- Draw a line between code-that-ships and code-that-doesn't. Change your discipline separately on each side.
- The importance of your ship code is not a reason to write less other code — it's a reason to write way more.
- If you feel you can't find slop-generation opportunities, you're not creative enough, not the tools' problem.
- Reading takes real energy. Don't try to read faster — try to only read what's worth reading.
- Have AI review your code first before bringing it to your team.
Actionable takeaways for engineers on important systems
- Identify which tier (A/B/C/D) your daily code actually falls in — be honest, most work is B/C
- Keep hand-review discipline on tier-D code exactly as-is
- Add a bucket in your repo (or a sibling repo) explicitly for throwaway verification code
- For your critical production module, plan 10,000 lines of AI-generated verification as a first-class output: fuzzers, property tests, alternate implementations, custom debuggers
- Whenever you find a subtle bug, have an agent generate a custom lint rule for it
- Ambiguous PR? Have an agent A/B/C-test three theories in parallel
- For any new API/SDK you own, spin up dumb-model agents to try to use it — treat their failures as UX bugs in your API
- Route giant diffs through agent-generated per-file summaries instead of line-by-line reads
- Add AI code review as a pre-human step in your workflow
- For load/performance questions, delegate to an agent with cloud access to spin up throwaway rigs
Who this is for
- Engineers on important systems (finance, medical, infra, ERP) who feel defensive about AI-generated code
- Skeptics who conflate "AI slop shipped to prod" with "any AI-generated code at all"
- Engineers with high read/write ratios who haven't yet added throwaway-verification work to their toolkit
- Anyone still writing code as if generation cost is the bottleneck (it isn't — attention is)