The Case for Slow AI Coding: Prioritizing Quality Over Velocity

The prevailing narrative around AI-assisted coding often emphasizes speed above all else. The goal, as imagined by many, is to use LLMs as "slop cannons"—generating hundreds of lines of code in seconds, merging massive pull requests (PRs) with minimal vetting, and shipping as fast as possible. This "vibe coding" approach prioritizes raw velocity, but it often comes at the cost of technical debt and a diminished understanding of the system.

However, there is a powerful alternative: using AI to write better code, even if it means doing so more slowly. By shifting the focus from generation to verification, developers can leverage LLMs not as a replacement for thinking, but as a super-powered tool for craftsmanship.

Shifting the Paradigm: From Generation to Verification

Rather than asking an AI to "build this feature," a more robust workflow treats the LLM as a rigorous critic. The core insight is that while LLMs can be prone to hallucinations when generating complex logic, they are exceptionally good at finding bugs and edge cases when given a specific target to analyze.

The Multi-Model Review Strategy

One effective technique for reducing false positives and hallucinations is to employ a "debate" or multi-model review process. Instead of relying on a single agent, you can deploy multiple models (e.g., Claude, Codex, and specialized bug-bots) to review the same PR.

By instructing a primary agent to coordinate these sub-agents—ranking findings by criticality (Critical, High, Medium, Low) and then researching the results to rule out bogus bugs—you create a high-signal filter. This process often uncovers not only bugs in the new code but also pre-existing flaws in the codebase that had previously gone unnoticed.

A Methodical Workflow for Quality

For those prioritizing quality, the workflow shifts from "prompt and merge" to an iterative loop:

1. Critical Fixes First: Use agents to identify and fix all critical and high-severity bugs under human guidance.
2. Pragmatic Triage: Skip medium or low-priority fixes where the effort outweighs the benefit (e.g., rewriting 100 lines to fix a rare edge case).
3. Architectural Pivot: If the review reveals too many critical flaws, abandon the PR entirely, recognizing that the initial approach was misguided.
4. Deep Understanding: Use tools like Mermaid charts or "grill-me" prompts to ensure the developer understands the PR front-to-back before merging.

Insights from the Community

Technical discussions around this "slow AI" approach reveal several key themes regarding the evolution of the developer's role.

The New Bottleneck: Judgment over Syntax

Many developers have noted that the bottleneck of software engineering has shifted. As one contributor put it:

"Coding is becoming less of a bottleneck than judgment. Generating code is easy now; deciding whether the generated approach is maintainable 6 months later is harder."

In this environment, the primary skill is no longer the ability to write syntax quickly, but the ability to validate, triage, and architect. The developer becomes a coordinator of agents, focusing on quality control, regression testing, and benchmarking.

AI as a Tutor and Craftsmanship Tool

Beyond bug-hunting, using AI slowly can be a powerful educational tool. Some developers use LLMs as tutors, writing their own (potentially broken) code first and then asking the AI to explain the errors. This tight feedback loop prevents the "deskilling" that occurs when AI writes the entire solution.

Others find that AI helps them break out of fixed patterns. By seeing how an agent approaches a problem, a senior developer can discover new idioms or hacks they might have overlooked due to years of habit.

The Psychological Trade-off

This approach is not without its challenges. Some developers report a "psychological ramp" where it is too easy to slide into laziness. There is also the risk of "anchoring," where seeing an AI's first (potentially wrong) attempt makes it harder for a human to think of a fresh, better solution from scratch.

Conclusion: Locally Inefficient, Globally Beneficial

Adopting a slower, more methodical AI workflow may feel locally inefficient. You might spend more time in review loops than you would have spent writing the code by hand. You might burn thousands of tokens just to realize your plan was wrong.

However, this is the same trade-off as traditional code reviews: they slow down the individual commit but benefit the entire team and the long-term health of the project. By treating AI as a junior developer—competent but prone to skipping essential steps—experienced engineers can use these tools to advance their craft rather than simply accelerate their output.