Using AI to write better code more slowly

Nolan Lawson (Read the Tea Leaves) · article · 2026-05-25 source ↗ Reader 🖥️

AI Slop Code Was Never the Bottleneck Code Quality Cognitive Debt Multi-Agent Orchestration Pull Requests & Async Code Review Vibe Coding

LLMs are flexible enough to produce either fast, unvetted slop or slower, carefully reviewed and understood code, and deliberately choosing the latter — running multiple different models to hunt for bugs, personally validating and triaging what they find, and refusing to ship a PR you don't fully understand — is a better way to use AI for programming, even without a velocity payoff.

practical · mixed — Primarily argumentative (rebutting the 'AI coding means slop' framing) and expository (describing a concrete personal workflow), with a few first-person anecdotal beats functioning as evidence rather than storytelling for its own sake.

Structure

Part	Role
Opening rebuttal (paras 1-3): names the 'ship AI slop fast' mentality and asserts LLMs can just as effectively produce high-quality code slowly.	thesis statement
Mythos/bug-finding context (paras 4-5): LLM agents are already good enough at finding bugs that the bottleneck has shifted.	evidence / premise-setting
The adapted skill (paras 6-9): run several different reviewers (Claude sub-agent, Codex, Cursor Bugbot), rank findings, do independent research to rule out false positives, write a final report; reports near-zero false positives.	method / central evidence
Triage workflow (para 10): fix criticals/highs, skip low-value mediums, abandon misguided PRs.	operationalization of the method
Velocity disclaimer and satisfaction claim (paras 11-12): no clear velocity gain; time instead goes to fixing pre-existing bugs and learning the codebase's failure modes; framed as satisfying rather than fast.	concession + reframing of the value proposition
Direct address to the 'barely understand the PR' developer (para 13): invitation to slow down, interrogate the PR with the agent, use /grill-me until you understand it front-to-back.	call to action
Closing reframing (paras 14-15): reclaims this as a 'super-powered' version of pre-LLM careful, methodical programming; closing exhortation.	conclusion

Key terms

slop cannon
An LLM used purely to mass-produce low-quality, barely-passable code that is shipped in large PRs without real scrutiny.
vibe coding Vibe Coding
Stretched/reclaimed by Lawson to describe his own slower, carefully-reviewed style of AI-assisted coding ('this other, slower style of vibe coding') — the opposite of its usual sense.
juice isn't worth the squeeze
A cost/benefit heuristic for skipping medium- or high-severity findings whose fix would cost disproportionately more effort than the bug's real impact (e.g., 100 lines of code for a narrow edge case).
prioritizing and validating
The author's name for the actual bottleneck in AI-assisted bug-hunting, as distinct from 'finding' bugs, which he treats as already-solved.

Propositions

explicitLLMs are flexible enough to be used just as effectively to write high-quality code slowly as to write low-quality code fast — 'slop' is a choice of use, not an inherent property of the tool.conf: high
explicitThe latest public LLM agents from Anthropic and OpenAI are already good enough at finding bugs that repeatedly running them against an unscrutinized codebase will surface more bugs than a team can act on.conf: high
explicitThe genuine difficulty in AI-assisted bug-hunting is not finding bugs but prioritizing and validating them.conf: high
explicitRunning several different models (not just one) against a PR review reduces the rate of hallucinated or bogus bug reports.conf: high
supportsAgentic Code Review · p10 — Lawson's named practice (Claude sub-agent + Codex + Cursor Bugbot) is a concrete instance of the heterogeneous-reviewer strategy p10 recommends from measured PR data — running deliberately different tools rather than agonizing over a single 'best' one.
explicitcorroboratedRequiring the reviewer to also do independent research to rule out false positives before writing a final report is what makes a multi-model bug hunt trustworthy.conf: high
extendsAgentic Code Review · p13 — Lawson's mandatory human-research step to rule out false positives is a concrete answer to the 'borrowed confidence' risk p13 names in a closed same-family model loop — he supplies the workflow for what keeping a human in the loop actually looks like.
supports ←Google Mantis: An Agentic Vulnerability Scanning Harness for Reducing False Positives · p3 — Both treat independent, structured multi-stage verification — sandboxed reproduction here, independent research there — as the mechanism that makes a false-positive-filtering claim trustworthy rather than an unverified LLM assertion.
explicitThis careful, multi-model review practice has not increased Lawson's shipping velocity; it often turns into fixing pre-existing, unrelated bugs it happens to surface.conf: high
refinesTrust Factory · p7 — Beck's claim that slowing down augmented development is 'the path to actually going faster' is not confirmed by Lawson's own account of running a comparably slower, careful practice — he explicitly reports no velocity gain and grounds the case for slowing down in quality/satisfaction rather than a speed payoff.
implicitImproving codebase health and personally understanding a system's failure modes is worth doing with AI assistance independent of whether it improves velocity.conf: medium
supportsFrom Async Code Reviews to Co-Creation Patterns · p15 — Lawson's description of review-as-a-side-quest that teaches him a codebase's failure modes is a first-person instance of code review functioning as a quality-building, learning-accelerating practice rather than a gate.
explicitA PR should be actively triaged against a personal severity/effort bar — fix criticals and highs, skip lower-value findings where the fix cost exceeds the benefit, and abandon the PR outright if the volume of criticals reveals the whole approach was misguided.conf: high
implicitA developer should not ship or merge a PR — agent-authored or not — that they do not fully understand, and should use AI tooling itself to close that understanding gap (ask the agent how the PR works and might fail, generate docs, use /grill-me).conf: high
implicitReal comprehension of a complex architecture comes from understanding where its assumptions break down (its failure modes), not from its happy path — true before LLMs and still true with AI-assisted bug-hunting as the new route to that understanding.conf: medium

Arguments

Running multiple different AI models against a PR, combined with independent human validation, produces a near-zero false-positive rate on surfaced bugs while still catching a large volume of real ones. strength: medium

Explicit premises:

The latest public models from Anthropic and OpenAI are individually good enough to find plenty of bugs in an unscrutinized codebase; some are better than others at avoiding false positives.
The more, different models thrown at a PR review, the less likely the result is hallucinations or bogus bugs (adopted insight).
The workflow explicitly requires the reviewer to do their own research to rule out false positives before writing a final report.

Implicit premises:

Different models fail in largely uncorrelated ways (different vendors, training data, architectures), so their false positives don't overlap while genuine bugs tend to be independently corroborated — an unstated independence assumption about model error.
The human doing 'your own research' has the time, skill, and incentive to actually verify each flagged item rather than deferring to the AI tools' severity ranking.

Inferences:

The technique's reliability depends on genuine model diversity; if the 'different' models converge over time (shared RLHF processes, shared training corpora), the near-zero-false-positive property could quietly erode without Lawson noticing, since his evidence is personal impression across his own PRs, not a controlled or ongoing measurement.
The token/time cost of running three separate reviewers plus a human validation pass on every PR is never weighed against the value captured — a resource trade-off the piece's own 'juice isn't worth the squeeze' logic would seem to demand applying to the technique itself, not just to individual bugs.

Developers should deliberately choose a slower, more careful style of AI-assisted coding — reviewing, understanding, and validating AI output — over the fast 'slop cannon' style, even without a velocity payoff.