Most people picture AI coding as a slop cannon: spit out barely-passable code, open giant pull requests, merge them unvetted, ship it. A developer writing on Hacker News makes the opposite case. LLMs are flexible enough to do the reverse just as well, helping you write high-quality code more slowly. According to the Hacker News piece, the real win isn’t raw speed. It’s using AI agents to hunt bugs, deepen your understanding of a codebase, and ship work the next coder will thank you for.
Here’s how to put that into practice.
Quick Start
You’ll learn a slower, quality-first style of AI-assisted coding built around multi-model bug review. What you need: access to a couple of coding agents (a Claude sub-agent, Codex, and a tool like Cursor Bugbot), a pull request to review, and a willingness to follow the bugs wherever they lead.
The core insight
Agents are genuinely good at finding bugs. Throw them at a codebase enough times and they’ll surface more than you know what to do with. The hard part isn’t finding bugs, it’s prioritizing and validating them. The fix: the more different models you point at a single PR, the lower your odds of hallucinations or bogus findings. Disagreement between models filters out the noise.
Step 1: Run a multi-model bug review
The author built a Claude skill that, paraphrased, says:
Run a Claude sub-agent, Codex, and Cursor Bugbot to find bugs in this PR ranked by critical/high/medium/low. Once they’re all done, review their findings, do your own research to rule out false positives, and write a final report.
Why it matters: ranking by severity tells you where to spend attention first, and the human review step at the end is what keeps the false-positive rate near zero.
Step 2: Define what “bug” means to you
You can extend the skill with your own standards. The author’s version includes the KISS and DRY principles, writing accessible HTML/JSX, and using proper indexes for SQL queries. This is where the review stops being generic and starts enforcing the quality bar you actually care about.
Step 3: Work the findings in order
Expect a flood, ranging from critical security and correctness issues down to “this comment is misleading.” The author’s workflow:
- Have an agent fix all the criticals and highs, with your guidance on the proper solution, then repeat until no criticals or highs remain.
- Skip highs and mediums where the juice isn’t worth the squeeze, like 100 lines of code to fix a narrow edge case.
- Abandon the PR entirely if it has so many criticals that the whole approach is clearly misguided.
That last point is the one most people skip. Sometimes the right move is to throw the work out, not patch it.
Step 4: Make the agent teach you the code
Understanding beats velocity here. Ask an agent how your PR works and how it might fail. Have it write Markdown docs with Mermaid charts if that helps. The author uses Matt Pocock’s /grill-me skill until they understand the entire PR front-to-back.
What to expect
A warning worth repeating: this won’t feel like 10x productivity. The author says velocity didn’t necessarily go up. Reviews often surface pre-existing bugs, which sends you on side-quests writing unit tests and fixing flaws that predate your PR. You might burn a ton of tokens only to learn your whole plan was wrongheaded from the start.
That’s the point. You trade lines-of-code speed for codebase health and real understanding. As the author puts it, the failure modes of a complex architecture are more instructive than its happy path.
Why this matters
The loudest AI-coding stories are about shipping faster and reviewing less. This is a useful counterweight. The same models that generate slop are, with a different prompt and a slower posture, excellent reviewers and teachers. The skill that decides which you get is yours, not the model’s.
Next steps
Start small. Pick one open PR and run two or three models against it before merging. Write down your own definition of “bug” and turn it into a reusable skill. Then add the understanding pass, asking an agent to explain and stress-test the change until you could defend every line. You can read the full argument over at Hacker News.