▶ YouTube Summaries

• https://www.youtube.com/watch?v=434cG4g5KLE
• Original title: Stop Reading Every Line of Code

Theo argues that most engineers are reading too high a percentage of the code they touch and, more importantly, generating far too little. His central reframe: AI-generated code is cheap and disposable, so even if the code that ships is so critical that lives depend on it, you should be writing enormous amounts of throwaway "slop" — custom debuggers, test harnesses, verification tools, one-off experiments — around that critical code rather than treating AI as something too dangerous to touch. The point is not to make your important code cheaper or to merge slop; it's to make far more cheap code that never ships but exists to test, verify, and answer questions.

He opens by acknowledging the video will frustrate both camps, then plants his flag: for the vast majority of engineers — whether building slop side-projects or medical-device firmware — the percentage of code being read is probably too high, and the amount being generated is too low. The prompt came from his own tweet: "How much better do the models have to get before you'll stop reading the code?" — and he insists the answer is not as simple as people assume.

To structure the argument he introduces an "importance of code" spectrum, from a slop website with one viewer at one end to pacemaker firmware at the other. All software sits somewhere on it. His key observation about human psychology: people consistently think their code is further down the critical end than it really is, and they think negatively about everyone "below" them. This makes the whole debate impossible, because listeners map any statement about AI code onto their own self-assessed position. Theo concedes his own code (LLM wrappers, formerly video infra) is nowhere near pacemaker-critical.

Rather than argue that people overrate their code, he grants the strongest version of the opposing case: assume every line you write truly is life-or-death. Even then, he says, you should read every shipped line — but code is useful for far more than shipping. Nobody writes 100% mission-critical code, and if your code is that important, you should be generating even more low-stakes code to verify the important code. Build custom debuggers, custom runtimes, custom logging and introspection tools. If a verification layer is itself too critical for AI, abstract one layer higher and build tooling on top of that. His refrain: "If you don't have a custom debugger for your software yet, you're not slopping hard enough."

He illustrates with numbers from his own career. At Twitch he might read ~1,000 lines a day and write ~200, of which ~100 were good enough to merge — sensible when writing code was expensive and everything merged was important. Today he reads roughly the same amount but generates 2,000+ lines and merges ~500. The scary-looking gap of unread generated code is fine, because most of that generated code is never reviewed or merged — it exists only to test ideas. The old objection ("writing 1,000 lines to check one line never made sense") no longer holds because code is now nearly free to produce.

He answers real pushback directly. To someone writing a financial ERP where mistakes cause huge losses: your code is probably important, so you should be writing an unbelievable amount of slop to verify it — every critical line backed by 100 or 10,000 lines of throwaway verification. He rejects the claim that being able to slop this much means your product isn't important. He endorses a viewer whose 80% of generated code goes into test harnesses and guardrails the LLM can read results from, producing fewer mistakes. His argument is explicitly not "read less of your shipped code" — it's "generate more code that isn't worth human attention."

He reframes with a concrete scenario: keep writing and hand-verifying your ~100 critical lines a day (maybe even fewer, ~80, given time spent elsewhere), keep reviewing your ~200-400 lines — but now also generate ~800 lines of pure slop that lives in another repo or scratch directory, never touching production. That slop explores, verifies assumptions, and tests the critical lines in ways that were never worth it before. His personal example: 10,000 lines of JavaScript to organize ~100 files on his Windows machine — "mental illness until the code is free to generate," then totally reasonable.

He credits AI as an infinite code generator that makes previously impractical work trivial: custom lint rules he now writes constantly, one-off debuggers and compiler hooks to inspect React performance, and telling Codex to spin up AWS resources to stress-test his systems instead of recruiting friends. He builds a funnel/tiers model (A = slop nobody should read, down to D = "death tier" where people die if it's wrong), stressing that nobody works exclusively in one tier and everyone should spend more time generating in the cheaper tiers. Tier-D code was historically so expensive that dabbling in other tiers felt pointless; that era is over.

For his own work (T3, Lakebed) he reads every function signature and API/SDK definition — because solid interfaces make long-term maintenance and releases safer — but cares far less about function bodies, citing DAX's practice of asking the agent for a per-file summary of a big diff instead of reading it line by line. A favorite technique: after defining a new API/SDK, spin up ~10 agents on deliberately dumber models (he loves Grok models for generating slop) to build things on top of it; if the dumb models can use the API, ship it, if not, fix it. To the pacemaker engineers: keep reading your tests and harnesses, but also have agents slop out three competing theories, write novel one-off tests, or port code to Rust to run against the suite — not to merge, but to answer real questions.

He closes by distinguishing himself from the loud "slop AI vibe-coding" crowd shipping broken services nobody uses — he says he hates them too, and that using AI to review your own code before bothering teammates is valuable (a separate rant). The takeaway: if your code is important, write code that isn't, to verify the code that is. Treat code as disposable — throwaway for one idea, one theory, one question — and be more creative. "Go be more creative. Write more slop."