Using AI to write better code more slowly

Posted May 25, 2026 by Nolan Lawson in software engineering. Tagged: AI. 2 Comments A lot of people seem convinced that the point of AI coding is to write low-quality code as fast as possible. Spew out barely-passable slop, open massive PRs, and merge them unvetted. Ship it! But the thing is, LLMs are very flexible. And you can use them just as effectively to write high-quality code more slowly. This statement seems completely obvious to me at this point, and I almost didn t want to write this post for that reason. But there seem to be enough people convinced that LLMs are only good as slop cannons that it s worth making the opposite case. 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 find so many bugs that you ll barely know what to do with them. Like many others, I ve also found this is true of non-Mythos models – some may be better than others at finding subtle bugs or avoiding false positives, but the fact is that the latest public models from Anthropic and OpenAI are good enough to find plenty of bugs in an unscrutinized codebase. The problem is not so much finding the bugs, but instead prioritizing and validating them. For this reason I have a Claude skill I adapted from this article s core insight, which is that the more, different models you throw at a PR review, the less likely you are to get hallucinations or bogus bugs. 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. That s basically it. You can add your own definition of bug if you want – mine has stipulations about the KISS and DRY principles, writing accessible HTML/JSX, using proper indexes for SQL queries, etc. In my experience, this skill always finds tons of bugs in a PR, and the false positive rate is near zero. It finds so many bugs that you ll be bored senseless if you try to tackle them all. They ll range from critical security or correctness bugs to the more mundane medium-level perf bugs to low-level this comment is misleading -type bugs. When I use this technique, I haven t necessarily seen my velocity go up. If anything, the review process often finds pre-existing bugs, so I end up on a tangential side-quest where I m writing unit tests and fixing subtle flaws that pre-date the PR. This is the opposite of the 10x productivity slop-cannon style of development that most people imagine when they think of vibe coding, but I find it very satisfying. It s a great way to improve the overall health of the codebase while also teaching you about the odd corners of it. In my experience, the happy-path of a complex architecture is less interesting than its failure modes. And pre-LLMs, this is usually how I got familiar with a codebase anyway: understanding where the assumptions break down, and then getting my hands dirty to fix it. If you re the kind of person who is skeptical that AI coding is good for anything, then I doubt this post will persuade you. But if you re the kind of developer who uses agents to write multi-hundred-line PRs that you barely understand yourself, I d invite you to slow down a bit and try this other, slower style of vibe coding. Ask an agent how your PR works and how it might fail. Have it write Markdown docs with Mermaid charts if necessary. Use Matt Pocock s /grill-me skill until you understand the entire PR front-to-back. You might not be more productive in terms of raw lines of code. You might burn a ton of tokens just to find out that your entire plan was wrongheaded from the start. But I find this style of coding to be a more super-powered version of the kind of programming I was already trying to do before LLMs: careful, methodical, quality-obsessed, focused on making things better for the next coder. So take a deep breath, slow down, try this technique, and see if you don t enjoy writing better code more slowly. Posted by heckj on May 25, 2026 at 9:32 AM I ve found the same technique — doing multiple sweeps — super effective for all kinds of review; I use the same for editorial review of grammar, punctuation, spelling, and so on. One thing I ve realized is that wiping the context *between* sweeps also helps. And I ve started to switch up my code reviews to 5-7 different lens running in parallel — looking for different kinds of issues — and then collating the results and loosely ranking them. Posted by Nolan Lawson on May 25, 2026 at 10:07 AM You re right, clearing context really seems to help. That s one of the reasons my reviewer skill specifies that the main agent shouldn t do original research until all 3 sub-agents have returned – otherwise there s a tendency to be influenced by the first result. I haven t tried splitting up reviewers into different archetypes, but maybe it helps when you have a PR that spans multiple

Using AI to write better code more slowly

Key takeaways

More in computer-science