Why Slowing Down with AI Can Lead to Higher‑Quality Code

In a world that glorifies speed, Nolan Lawson’s recent post on Read the Tea Leaves reminds us that the true power of large language models (LLMs) lies not in churning out the quickest pull request, but in fostering a slower, more reflective development rhythm.

---

The Core Argument

Lawson’s thesis is simple yet counter‑intuitive: AI‑assisted coding can be used to write better code more slowly. The prevailing narrative—that LLMs exist solely to generate “barely‑passable slop” at breakneck speed—overlooks the flexibility of these models. By treating them as collaborative agents rather than shotgun code generators, developers can harness their bug‑finding abilities, enforce design principles, and ultimately produce a healthier codebase.

How the Technique Works

1. Multi‑Model Review – Lawson runs three distinct agents (Claude, Codex, and Cursor Bugbot) against a pull request. Each model has its own strengths: Claude tends to be conversational and good at reasoning about intent, Codex excels at syntactic correctness, and Cursor Bugbot focuses on security patterns.
2. Unified Ranking – The agents label each finding as critical, high, medium, or low based on criteria such as KISS, DRY, accessibility, and SQL indexing practices.
3. Human Validation – The developer reviews the aggregated list, discarding false positives and confirming genuine issues.
4. Iterative Fixing – Critical and high‑severity bugs are addressed first, with guidance from the agents. Medium‑level concerns are tackled only when the effort justifies the benefit, and low‑priority items are often left as documentation notes.

The workflow is deliberately slow: each iteration requires reading the AI’s explanations, cross‑checking with documentation, and sometimes writing additional unit tests. The payoff, however, is a set of fixes that are far less likely to regress.

Evidence from Practice

Lawson reports that this approach consistently uncovers “tons of bugs” with a near‑zero false‑positive rate. The bugs range from serious security flaws to subtle performance regressions and even misleading comments. Because the agents are asked to respect the same style guidelines that a human reviewer would enforce, the output aligns with the team’s existing code‑quality standards.

A striking observation is that velocity does not increase. Instead, the development cycle lengthens, but the quality of the code that lands in the main branch improves dramatically. The side‑effect is a deeper understanding of the codebase’s failure modes—knowledge that would otherwise be acquired only after a production incident.

Broader Implications

1. Re‑framing AI as a partner rather than a tool

When developers treat LLMs as co‑authors, they shift from a “push‑fast‑and‑break‑things” mindset to one where the AI acts as a safety net, surfacing hidden assumptions before they become costly bugs.

2. Reducing Technical Debt

By catching violations of KISS, DRY, and accessibility early, teams can prevent the accumulation of debt that typically requires large refactors years later.

3. Knowledge Transfer

The detailed explanations generated by the agents serve as living documentation. New team members can read the AI‑produced markdown, view Mermaid diagrams, and instantly grasp why a particular change was made.

4. Token Economics vs. Long‑Term Savings

Lawson admits that the method can be token‑hungry. However, the cost of a post‑deployment security breach or a performance outage often dwarfs the expense of extra API calls during review.

Counter‑Perspectives

Critics might argue that the slower cadence undermines the competitive advantage of rapid iteration, especially in startup environments where time‑to‑market is paramount. They may also point out that reliance on AI explanations could create a false sense of security if the underlying model drifts or is updated without thorough testing.

A pragmatic response is to apply the technique selectively: reserve the multi‑model deep review for high‑impact components (authentication, data pipelines, public APIs) while allowing simpler changes to proceed with a lighter AI‑assisted check.

Practical Steps to Adopt the Approach

1. Choose Your Agents – Start with the models you already have access to (e.g., Claude via Anthropic, OpenAI’s gpt‑4o, or open‑source alternatives like StarCoder). Ensure each can be invoked programmatically.
2. Define Bug Taxonomy – Write a short JSON schema that captures the categories Lawson mentions (critical/high/medium/low) and any project‑specific rules (e.g., “no inline styles in JSX”).
3. Automate the Pipeline – Use a CI step that runs each agent, aggregates results, and posts a comment on the PR with a ranked table. Tools like GitHub Actions or GitLab CI can orchestrate this.
4. Create a Review Checklist – Include a step for the human reviewer to verify each flagged issue and to document the resolution.
5. Iterate – After a few cycles, refine the prompts and the bug taxonomy based on false‑positive trends.

Closing Thoughts

Lawson’s essay is a reminder that speed without scrutiny is a brittle shortcut. By deliberately slowing down and inviting multiple AI perspectives into the review process, developers can transform LLMs from noisy code generators into disciplined guardians of quality. The result is not a faster ship, but a sturdier vessel—one that can weather future storms with fewer patches, less panic, and a deeper collective understanding of the code it carries.

---

Image credit: Nolan Lawson’s blog favicon