Using AI to write better code more slowly

Source: Hacker News

Introduction

Many people assume that AI‑assisted coding is only useful for spitting out low‑quality code as fast as possible—massive PRs, minimal review, and ship it. In reality, large language models (LLMs) are flexible enough to help write high‑quality code more slowly.

Why LLMs Can Be Useful for Quality

If Mythos taught us anything, it’s that LLM agents are really good at finding bugs. Throw them at a codebase enough times, and they will surface a large number of issues. This holds true for many other models as well; the latest public models from Anthropic and OpenAI can uncover plenty of bugs in an unsanitized codebase.

The challenge isn’t finding bugs—it’s prioritizing and validating them. To address this, I adapted a Claude skill from an article on AI‑code‑review debates. The core insight is that the more diverse models you involve in a PR review, the lower the chance of hallucinations or bogus bug reports.

The Multi‑Model Review Skill

Paraphrased workflow

1. Run a Claude sub‑agent, Codex, and Cursor Bugbot to scan the PR.
2. Rank each reported bug as critical, high, medium, or low.
3. Review the combined findings, research to rule out false positives, and write a final report.

You can customize the definition of “bug.” My criteria include adherence to the KISS and DRY principles, accessible HTML/JSX, proper indexing for SQL queries, etc.

In practice, this skill surfaces many bugs while keeping false positives near zero. The bugs range from critical security or correctness issues to mundane performance tweaks and even misleading comments.

Typical Workflow

1. Fix critical and high‑severity bugs with the agent’s assistance, iterating until none remain.
2. Skip medium‑level bugs when the effort outweighs the benefit (e.g., fixing a narrow edge case that requires many lines of code).
3. Abandon the PR if the volume of critical bugs indicates a fundamentally flawed approach.

Using this technique doesn’t necessarily increase raw development velocity. Often, the review uncovers pre‑existing bugs, leading to side‑quests of writing unit tests and fixing subtle flaws that pre‑date the PR. This slower, methodical style contrasts with the “10× productivity” myth of rapid, low‑quality output, but it yields a healthier codebase and deeper understanding of its failure modes.

How to Adopt the Slower “Vibe Coding” Style

• Ask the agent how the PR works and where it might fail.
• Generate documentation (e.g., Markdown with Mermaid charts) to visualize architecture.
• Use tools like Matt Pocock’s /grill‑me skill to interrogate the PR end‑to‑end.

You may not write more lines of code per unit time, and you might burn tokens discovering that a plan was misguided. However, this approach aligns with a careful, methodical, quality‑obsessed mindset—essentially a super‑powered version of the programming style many developers pursued before LLMs.

Conclusion

Take a deep breath, slow down, and try this multi‑model review technique. You may find that writing better code more slowly is both satisfying and beneficial for the long‑term health of your projects.