# Stop Reading Every Line of Code > [!question] Lingering Questions > - What's the best available fraction of generated code that should merge vs. stay disposable? Theo's ratios are illustrative, not measured. > - Risk tiers for what deserves full review are currently personal intuition, not governance — who should own that policy, and what does it look like written down? > [!tip] Article Ideas > - "Artifact lifetime sets review cost" — a talk or post distinguishing ten-minute sandbox probes from ten-year production APIs, and why one review process for both is the actual failure mode, not AI-generated code itself. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Disposable Code Should Produce Evidence Not Become the Product]] — this vault already has a Permanent note capturing this source's central claim; this Literature note supplies the remaining, undercaptured atoms > - [[3. Resources/Permanent Notes/The Bottleneck Moved From Code Generation to Review and Judgment]] — directly related claim on where review effort should concentrate ## Metadata - Source: [[3. Resources/Readwise/Articles/Stop Reading Every Line of Code]] - Format: YouTube video/talk by Theo (t3.gg). ## Author's thesis The provocative title is a reframe, not a permission slip: the real distinction AI collapses isn't "read vs. don't read," it's production code vs. temporary, evidence-generating code. Developers should keep full scrutiny on anything that ships, while using AI to generate cheap, isolated code — experiments, harnesses, load tests, debuggers, competing solutions — that attacks assumptions and improves the evidence behind the small part that does ship. ## Key arguments (≤3) 1. **Disposable code is an instrument, not a product.** Most AI-generated code in this workflow never enters production — it exists to explore, test, measure, or explain, and can be judged by whether it answered its question, not by production-code standards. 2. **Review effort should scale with consequence, not source.** Critical APIs and shipped changes still get direct human reading; the fact that code was AI-generated doesn't change how much scrutiny it deserves once it's headed to production. 3. **Volume of generation is not value.** Only a fraction of what gets generated should merge — the workflow depends on deletion discipline as much as generation speed. ## Claim atoms ### Generated code can be evidence Claim: Code that never ships can test assumptions and alternate designs. Evidence: stress tests, debuggers, sample clients, and API experiments cited as disposable-code use cases. Limit: reported from experience, not controlled results. ### Review effort follows consequence Claim: Critical interfaces and shipped changes still deserve direct reading regardless of how they were produced. Evidence: the speaker describes personally reading API definitions and production code that matters. Limit: risk tiers currently rest on individual judgment, not written governance. ### Cheap code changes which questions are feasible to ask Claim: One-off programs can now answer questions that used to cost too much to implement. Evidence: bespoke asset tools and load tests cited as newly-affordable investigations. Limit: cloud, security, and cleanup costs for throwaway infrastructure remain real and unmeasured. ### Volume is not value Claim: Only a fraction of generated code should merge. Evidence: the speaker separates generated, reviewed, and merged output into distinct categories. Limit: the specific ratios given are illustrative, not derived from data. ## Permanent candidates - **Disposable code should produce evidence, not become the product** — already captured in this vault at [[3. Resources/Permanent Notes/Disposable Code Should Produce Evidence Not Become the Product]] (created 2026-08-11). Not recreated here. - **Review scrutiny should scale with consequence, not with how code was produced** — supported by the "review effort follows consequence" atom; distinct from the existing note, which covers the disposable-code side, not the production-review side. → promoted. ## Processing checklist - [ ] Add artifact-lifetime labels to AI coding notes (sandbox probe vs. production-bound) going forward - [ ] Draft a written risk-tier policy for what deserves full review, rather than leaving it to individual judgment - [x] Connect into the relevant MOC — [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] ## Links - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — AI-assisted development practice and review discipline