Stop Reading Every Line of Code  🔗 **Source:** [Stop Reading Every Line of Code](https://www.youtube.com/watch?v=434cG4g5KLE) > [!note]+ Document Notes > tags: ["ai-assisted-development", "code-review", "software-testing", "experimental-code", "developer-productivity", "risk-management"] > author: "Theo" > source: "YouTube" > reference: "https://www.youtube.com/watch?v=434cG4g5KLE" > date_created: "2026-07-22" > > # 🏷️ Stop Reading Every Line of Code > <!-- deep-read:sections start --> ## 🧭 Table of Contents - References - Summary - Main Content and Notes - References - Paraphrase - Newsletter - Action Items - Hypotheses - Methodology - Questions - Future Research - Implications - Learning Styles Assessment - Accessibility Assessment - DEIB Assessment - Logical Validity - DARVO Analysis - Conclusion - Refactor Appendix - Template Library ## 🔗 References - [Original video](https://www.youtube.com/watch?v=434cG4g5KLE) - [NIST Secure Software Development Framework](https://csrc.nist.gov/Projects/ssdf) - [Google Engineering Practices: Code Review](https://google.github.io/eng-practices/review/) ## 📝 Summary **What happened:** Theo argues that developers should keep reviewing code that ships while generating far more disposable code for experiments, test harnesses, load tests, debuggers, API probes, and competing solutions. **Why it matters:** AI changes the cost of writing code. The key distinction is no longer read versus do not read; it is production code versus temporary evidence-generating code. **Stakeholders:** Developers, reviewers, engineering managers, security teams, regulated organizations, maintainers, and users affected by software failures. **Risks:** The provocative title can be read as permission to skip review; generated test code can share the implementation’s blind spots; more experiments can create access, cost, cleanup, and supply-chain risks. **Bottom line:** Do not reduce scrutiny on code that matters. Generate cheap, isolated code that attacks assumptions and improves the evidence used to review the small part that will ship. ## 📖 Main Content ### 1. Separate generated from shipped code Most generated code in the proposed workflow never enters production. It exists to explore, test, measure, or explain. ### 2. Scale verification around risk Critical APIs and production changes still receive direct review. Disposable agents and harnesses can try more theories than a human would write by hand. ### 3. Treat code as an investigative medium One-off debuggers, load generators, data transformations, and sample clients become affordable when generation cost falls. ### 4. Keep boundaries explicit Temporary code belongs in isolated folders, repositories, or disposable infrastructure with no implied path to merge. ### 5. Measure outcomes, not line counts The speaker’s invented ratios explain the idea but do not prove productivity, safety, or quality. ## 🗒️ Notes - The accurate thesis is ‘write more cheap code,’ not ‘verify less production code.’ - Generated tests are evidence only if their oracle and assumptions are independent of the implementation. - Disposable code still needs secrets, cost, network, and cleanup controls. - High-risk systems need formal assurance beyond code reading. - The insults aimed at critics weaken an otherwise useful distinction. ## 📚 References - The transcript is the primary source for the speaker’s argument. - NIST SSDF and established review guidance supply a baseline for code that reaches production. - The productivity ratios in the video are illustrative and not observed data. ## 🗣️ Paraphrase 1. Developers often hear ‘stop reading code’ as a claim about merging unreviewed output. 2. The speaker instead separates code that ships from code that generates evidence. 3. When generation is cheap, teams can build more test clients, stress tools, debuggers, and alternate implementations. 4. Production interfaces and critical changes still deserve direct scrutiny. 5. The quality gain comes from using temporary code to challenge assumptions, not from counting generated lines. 6. Teams need isolation and deletion rules so experiments do not become accidental dependencies. ## 📰 Newsletter ### Write more throwaway code, not less-reviewed code The useful idea behind the inflammatory title is simple: keep the review bar for production, then surround that code with disposable probes, stress tests, sample clients, and competing implementations. Cheap generation can buy more evidence. It does not buy a waiver from judgment. **WordPress angle:** Plugin and Core contributors can use disposable WordPress Playground sites, generated fixtures, and alternate patches to test a change while keeping the actual diff small and reviewed. ## ✅ Action Items ### DevRel - Demonstrate an AI-generated test harness that never enters the plugin release artifact. ### OSPO - Define repository policy for generated experiments, licensing, provenance, and deletion. ### Community - Run a review workshop that labels production, test, fixture, and exploratory code before discussing scrutiny. ### WordPress teams - **Core:** Keep production patches small and reviewed; use generated fixtures to test edge cases. - **Core Performance:** Measure user-visible cost before proposing a performance change. - **Core AI:** Define safe disposable-agent patterns and independent test oracles. - **Core Program Team:** Route cross-team work to named owners and a release milestone. - **Mobile:** Check the equivalent task on small screens and with mobile assistive technology. - **Playground:** Offer one-command sandboxes for throwaway experiments and failure injection. - **Community:** Turn the strongest lesson into a contributor discussion with affected users represented. - **Training:** Create a short exercise that keeps the authentic task and supplies safe practice. - **Marketing:** State the user benefit without turning an example into proof. - **Support:** Add a diagnostic question when the source exposes a recurring support failure. - **Design:** Check focus, hierarchy, error recovery, comprehension, and alternate interaction paths. - **Documentation:** Add a verified example and name its version, scope, and limits. - **Photos:** Use inclusive media with accurate alternative text when visuals support the lesson. - **TV:** Publish captions, a transcript, and chapter markers for any related recording. - **Polyglots:** Flag terms that need translator context and test text expansion and right-to-left layouts. - **Accessibility:** Test the relevant flow against WCAG 2.2 AA with manual assistive-technology checks. - **Meta:** Check whether WordPress.org discovery, metadata, or contributor tools need a change. - **CLI:** Support dry runs and machine-readable diffs for generated maintenance actions. - **Hosting:** Translate operational claims into access controls, logs, backups, and tested recovery. - **Tide:** Add an automated check only when it is deterministic and low-noise. - **Openverse:** Use openly licensed supporting media and preserve attribution and descriptions. - **Themes:** Test the result in both classic and block themes when presentation is involved. - **Plugins:** Exclude experimental harnesses and secrets from release packages. ### The WPOCC - Publish enterprise guidance for risk-tiered review and disposable agent sandboxes. ### FAIR - Keep generated verification artifacts portable and disclose model, prompt, dependencies, and license where retained. ## 🧪 Hypotheses - Teams that generate isolated verification code will find more defects without increasing production diff size. - Risk-tier labels will reduce accidental merging of exploratory output. - Independent test generation will find more failures than tests produced in the same prompt as the implementation. - Disposable load tests will shorten performance feedback cycles. - Teams without cleanup budgets will accumulate generated-code debt. ## 📊 Methodology - Randomize comparable changes to standard review or review plus generated probes and compare escaped defects. - Track generated, reviewed, merged, deleted, and retained lines as separate categories. - Use seeded defects and independent test oracles. - Measure reviewer time, cloud cost, false confidence, and cleanup work. - Stratify results by risk class and team experience. ## ❓ Questions - What evidence makes disposable code trustworthy enough to influence a merge? - How should generated test oracles be checked? - When does an experiment become a maintained dependency? - Which WordPress changes need direct line review regardless of test coverage? - How should teams budget cloud and cleanup cost? ## 🔮 Future Research - Risk-tiered review protocols for agent-generated work. - Independent test generation and mutation testing. - Supply-chain controls for temporary dependencies. - Measures of reviewer comprehension under higher output volume. - Deletion and retention policies for generated artifacts. ## 💡 Implications - **Practice:** Keep production diffs small, isolate experiments, generate competing checks, and delete aggressively. - **Policy:** Label generated artifacts and define which classes can never ship without human review. - **Security:** Use least-privilege sandboxes, fake data, cost limits, and independent validation. - **Education:** Teach code as a tool for inquiry while preserving architecture and review skills. - **Funding:** Invest in test infrastructure and reviewer capacity, not only generation volume. ## 🧠 Learning Styles Assessment - **Visual:** A diagram or before-and-after screen would make the system easier to scan. - **Aural:** The spoken format works well; chapters and a corrected transcript improve review. - **Verbal:** Clear definitions and short summaries would help readers retain specialist terms. - **Kinesthetic:** Have learners generate three disposable tests against one reviewed WordPress patch. - **Logical:** A two-axis matrix of code risk and artifact lifetime would clarify the proposal. - **Social:** A guided group review can expose assumptions that one practitioner misses. - **Solitary:** A checklist and source links support independent follow-up. - **Naturalistic:** Not central to this source; system and component classification are more useful. - **Estimated reading level:** Professional reading, roughly grades 11–college, because of specialist terms. ## 📊 Accessibility Assessment - **Perceivable — WCAG 2.2 AA 1.1, 1.2, 1.3, 1.4:** Keep accurate captions, a transcript, speaker names, headings, meaningful links, and text alternatives for visuals. - **Operable — WCAG 2.2 AA 2.1–2.5:** The player and page need full keyboard access, visible focus, large targets, and no traps. - **Understandable — WCAG 2.2 AA 3.1–3.3:** Define jargon, preserve a clear sequence, identify errors, and give recovery instructions. - **Compatible — WCAG 2.2 AA 4.1:** Use semantic structure, correct names and roles, and assistive-technology-tested controls. - **Cognitive accessibility:** Add chapters, concise takeaways, stable terms, and a low-distraction reading layout. - **Motor accessibility:** Avoid precision-only and drag-only controls; support keyboard, switch, and voice input. - **Sensory accessibility:** Do not rely on audio, color, or a visual demonstration alone to communicate meaning. ## 🌍 DEIB Assessment - **Cultural breadth:** The examples come from a narrow commercial software context. - **Inclusive language:** The central distinction is clear, but profanity and insults reduce access and trust. - **Neurodiversity support:** A diagram and stable terms would help listeners follow the changing line-count examples. - **Representation:** High-risk and regulated developers are discussed but not included as speakers. - **Psychological safety:** Critics are mocked, which can discourage engineers from raising legitimate safety concerns. ## ✅ Logical Validity ### Strong reasoning - The production-versus-investigation distinction resolves much of the apparent contradiction. - The API example shows how lower-quality agents can test whether an interface is understandable. - The argument preserves review for critical code rather than treating model output as inherently safe. ### Fallacies and weak moves - **Straw man — critics of generated code:** The speaker often treats critics as claiming all generated code is destined for production. **Fix:** Address concerns about test validity, cost, and maintenance directly. - **Ad hominem — people who disagree:** Calling critics stupid does not answer their safety claims. **Fix:** Remove insults and compare workflows with evidence. - **False precision — invented line counts:** Specific ratios sound empirical although the speaker says they are made up. **Fix:** Use a conceptual diagram or publish measured data. - **False dilemma — generate more or be bad at the job:** Teams may have legal, cost, privacy, or operational reasons to limit generation. **Fix:** State the conditions under which disposable generation helps. ### Tone of voice Provocative, profane, and combative, with a useful operational distinction buried under status challenges. ## 🛡️ DARVO Analysis - **Deny:** The speaker does not deny software risk; he denies that all generated code needs production-level review. - **Attack:** He attacks critics’ intelligence and self-importance. - **Reverse victim and offender:** He sometimes casts safety-focused critics as the source of engineering failure. - **Assessment:** Attack is present; the reversal is rhetorical rather than a sustained DARVO pattern. ## 🎯 Conclusion The safe version of the idea is to preserve or raise scrutiny on production code while using isolated generated code to produce more evidence. Teams should test whether this actually improves defect discovery and reviewer understanding. ## 🧱 Refactor Appendix ### Literature Split Pad #### H1 — Generated code can be evidence - **Claim:** Code that never ships can test assumptions and alternate designs. - **Evidence:** Examples include stress tests, debuggers, sample clients, and API experiments. - **Limit:** The source reports experience, not controlled results. #### H2 — Review effort follows consequence - **Claim:** Critical interfaces and shipped changes still deserve direct reading. - **Evidence:** The speaker says he reads API definitions and production code that matters. - **Limit:** Risk tiers need governance, not personal intuition alone. #### H3 — Cheap code changes feasible questions - **Claim:** One-off programs can answer questions that once cost too much to implement. - **Evidence:** The video cites bespoke asset tools and load tests. - **Limit:** Cloud, security, and cleanup costs remain. #### H4 — Volume is not value - **Claim:** Only a fraction of generated code should merge. - **Evidence:** The speaker separates generated, reviewed, and merged output. - **Limit:** The invented ratios cannot prove the best fraction. ### Atomic Split Pad #### Z1 — Disposable code is an instrument Temporary code can measure or challenge production behavior without becoming product surface. #### Z2 — Verification needs an independent oracle Tests generated from the same mistaken assumption can confirm the wrong implementation. #### Z3 — Artifact lifetime sets review cost A ten-minute sandbox probe and a ten-year production API should not share one review process. #### Z4 — Generation volume needs deletion discipline Cheap creation creates value only when teams can identify and remove what should not persist. ### Fleeting Queue - Add artifact-lifetime labels to AI coding notes. - Test one plugin patch with three independent generated clients. - Create a disposable-infrastructure cost ceiling checklist. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Stop Reading Every Line of Code.md|Stop Reading Every Line of Code by youtube.com]] ## Highlights - good bit, but I'm generating way more. And what I merge has increased. Let's increase a meaningful amount. We'll say it's 500 lines of code being merged a day. We're kind of in danger because there's a lot of code here that is being generated that is not being read. And that's scary. Except for the fact that most of this code that is being generated is not being put up for code review. It's not being merged. It's not being used for much of anything other than testing ideas. This did not used to ([View Highlight](https://read.readwise.io/read/01ky55r4pzb4hkf8jadkr19wvf)) - Note: Generated code used only for experiments carries a different persistence risk. - Tags: risk-management, code-review - understand. You now generate 800 lines of code. And this 800 lines of code is absolute [ \_\_ ] slop. And you don't touch this in your actual product. This 800 lines of code sits in another repo or at the very least some other [ \_\_ ] up directory in your important repos. And all it does is explores. It verifies assumptions. It tests those 80 lines before in all the crazy ways that were never worth it before because writing a thousand lines of code to make ([View Highlight](https://read.readwise.io/read/01ky55r5qr1er638wcwc27fp7h)) - Note: Disposable code can test assumptions without entering the product. - Tags: software-testing, experimental-code - could die, that got so ingrained in your head as it should because if it doesn't, people die. That era is over now. I'm not saying move faster. I'm not saying merge slop. All I am saying is that everybody can benefit some amount from the infinite code generator that we now all have access to on Bedrock, on codeex, on cloud code, on whatever. I'm not telling you to make your code cheaper. I'm telling you to make more cheap code. And that's a huge difference. And there are a ton of creative ways you can do this. If you're ([View Highlight](https://read.readwise.io/read/01ky55r3mm9rsz9b9xbk18987t)) - Note: The core claim is more disposable code, not lower-quality production code. - Tags: code-review, experimental-code - asked the agent for a summary of what it did in every file. Anything weird will stick out immediately and one to 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. Very much agree here. The way I would think of this is the engineers who wrote mostly tier C and B code should find the right ways to get the pieces that matter out of the parts that are in this tier so they can ignore more of the parts here. And figuring out where to cut these layers is important. I read all of the function ([View Highlight](https://read.readwise.io/read/01ky55r73jpffy55f53xe4y33g)) - Note: Review can focus on interfaces and boundaries, but critical internals still need risk-based inspection. - Tags: code-review, interfaces ## Links - [[3. Resources/Permanent Notes/Disposable Code Should Produce Evidence Not Become the Product]] — evidence-for: temporary probes and comparisons can be generated freely while shipped code stays reviewed. - [[3. Resources/Permanent Notes/Cheap Generation Raises the Total Maintenance Bill]] — limits: retained prototypes create maintenance debt.