You need to read less code (hear me out)

Key technological concept: “How much code should you read?”

• The speaker argues most engineers read too much of their own code relative to its true importance.
• Core premise: code spans a spectrum of importance—from harmless “slop” to systems where mistakes can cause catastrophic harm.

Product/engineering guidance: code verification via AI-generated “slop”

• Even for mission-critical code (e.g., pacemaker firmware), the speaker claims the biggest risk is not under-reading—it’s not generating enough additional code to verify the important parts.
• Rather than merging/shipping everything, they advocate:
  • Keep human review focused on the core code that matters.
  • Use AI to generate lots of extra auxiliary code (their term: “slop”) to:
    • stress test
    • probe assumptions
    • extend test coverage

Proposed workflow shift (practical)

• Historically (pre-AI): writing code was expensive, so teams relied on fewer lines and more direct human reading/review.
• Today (AI era): code is “cheap,” so teams should:
  • generate more code overall
  • ensure the code that goes into production is still appropriately verified
• Key emphasis: don’t reduce reading/review of the most critical “bottom-tier” code—increase throwaway/testing code that checks it.

“Code funnel” / tiers model (importance stratification)

The speaker frames a funnel of code importance with tiers:

• Tier A (top): “slop” code (should not require human reading)
• Tier B/C (middle): the common engineering reality for most teams
• Tier D (bottom): “death” / extremely critical code where failure is dangerous

Main change proposed: Tier D code was previously too expensive to test heavily, so engineers focused elsewhere. With AI, they argue there should now be more activity verifying Tier D using adjacent “slop” and tooling.

Concrete examples of AI-assisted verification

• Diff summarization for anomaly detection
  • An agent summarizes a large diff per file after changes, highlighting anomalies so weird parts stand out quickly.
• API/SDK correctness
  • Human review focuses on function signatures and interface contracts.
  • AI generates many “dumber model” attempts that build against the SDK to test usability—even if the generated code won’t be shipped.
• Port/performance experiments
  • Use an agent to generate an alternate implementation (e.g., Rust vs Go) and run the existing test suite to answer:
    • “will it work?”
    • “what breaks?”
• Testing infrastructure
  • Use AI to spin up AWS stress/load tests automatically.
• Building custom developer tools
  • Generate custom lint rules.
  • Create one-off debuggers and compiler hooks for deeper verification.

Warning against common pushback

• They challenge the assumption that if AI can generate lots of code, the product must be unimportant.
• Counter-argument: if a system is truly critical (financial loss, deaths, etc.), then verification should be far more aggressive—including potentially large amounts of additional test/debug code.

AI code review (secondary recommendation)

• They also suggest using AI to review code—not as a replacement for human rigor, but to deepen verification before humans spend time.
• Claim: humans shouldn’t be bothered until multiple agents have verified it deeply.

Main speakers / sources

• Primary speaker: the video author (unnamed in subtitles); the speaker references “Theo” and “Dax” as other individuals.
• External references mentioned:
  • A tweet by the speaker that inspired the video: “How much better do the models have to get before you’ll stop reading the code?”
  • Mentions of Dax (via a referenced post) and “Kotek” (posed as a hypothetical question).
• Sponsor: WorkOS (mentioned in the intro; not central to the technical argument beyond the sponsorship segment).