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.
The skill says (paraphrasing):
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.
My typical workflow is:
- Have an agent fix all the criticals and highs (with my guidance on the proper solution), then repeat until no criticals/highs
- Skip highs/mediums where the juice isn’t worth the squeeze (e.g. 100 lines of code to fix a narrow edge case)
- Abandon the PR if it has so many criticals that I realize the whole approach is misguided
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.
Read the Tea Leaves 
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 domains (frontend, backend, infra, etc.).
Posted by Ashah on May 26, 2026 at 1:15 AM
would you be able to share your skill?
Posted by Nolan Lawson on May 26, 2026 at 6:13 PM
Sure thing, here is the skill. I lightly edited it since it contained some specifics of my particular codebase. Note that you’ll need
ghinstalled, and also that I use Claude with Opus 4.7 on xhigh thinking and Codex with GPT 5.5 on high thinking. (I’m happy to wait 20 minutes for a better review!) You’ll probably want to tweak it for your particular codebase or the kinds of bugs you want it to find.Posted by Spencer Karenbauer on May 25, 2026 at 7:03 PM
I agree in a way. I think the idea now more so with vibe coding is individuals do not know how to write code properly and take all of these advanced AI tools like Claude/Cursor/etc as the end all-be all of solutions. They are great at baselines and can work through. But they should NOT be used as stand-alone tools. Enablement and governance need to be occuring simultaneously prior to implementing things like this in production.
Posted by Nolan Lawson on May 25, 2026 at 8:57 PM
Right, the way I think of it is that an LLM’s output is just the first draft. The real work starts with the code review. And there is a lot of scaffolding/documentation you can put in place to make this process way more effective.
Posted by Giuseppe on May 26, 2026 at 12:30 AM
Can you explain how you run multiple models in only one prompt and how to handle the differents output?
Posted by Nolan Lawson on May 26, 2026 at 6:14 PM
See my comment above; I’ve posted the full skill. 🙂
Posted by Ollie on May 26, 2026 at 5:07 AM
This matches my experience closely. I’ve been building a voting app with Next.js and Supabase, and the most valuable thing an agent did wasn’t write features — it was flag that my RLS policies had a gap I hadn’t considered. I would have shipped that. Fixing it took a few hours and sent me down a rabbit hole on Postgres row-level security I didn’t expect to go down that week.Not a productivity win by any typical metric. But now I actually understand that part of the stack. The “pre-existing bugs as a side quest” description is exactly right — and honestly it’s more satisfying than the feature work.
Posted by Graham Wheeler on May 26, 2026 at 7:59 AM
in my team we built an adversarial code review tool with multiple personas each doing reviews (e.g. architect, test engineer, compliance PM,…) then a synthesizer to collate the results. And that tool goes back and forth with the “fixer” agent until “everyone” agrees the PR is good, at which point a human looks at it. It works well, but definitely takes time and burns a lot of tokens.
So similar to what you are doing but with multiple personas versus multiple models.
Posted by Marcelo Lima on May 26, 2026 at 9:11 AM
Estamos chamando de modelos abertos os modelos proprietários de aluguel quase livre ? Pensei que aberto era aberto, reprodutível era reprodutível , fechado era fechado e exclusivo era exclusivo.
Minha visão é que: sim, subterfúgios podem ser utilizados para TENTAR revisar e melhorar o codigo. Mas isso não resolve o problema de janela de contexto para programas complexos. É so um truque que como outros milhares, são absorvidos pelas companhias detentoras de agentes de codificação, que recebem os prompts, as aceitações e pós processam verificando quais truques serao incorporados e QUAIS NÃO VALEM A PENA pois saberiam que os clientes reclamariam do alto custo.
Posted by Ashton Antony on May 26, 2026 at 9:51 AM
The “pre-existing bugs as a side quest” framing really clicks for me. I’d add that this workflow has an underrated onboarding use case. I’ve used it on unfamiliar codebases and it’s one of the fastest ways to build a mental model of where the bodies are buried. Better than reading docs, honestly.
The one thing I’d push back on slightly: this approach still requires enough domain knowledge to triage what the agents surface. The false positive rate might be near zero for an experienced dev, but a junior who can’t distinguish a real race condition from a theoretical one is still going to get overwhelmed. The agents find the bugs; you still need to understand them.
Posted by Nolan Lawson on May 26, 2026 at 5:31 PM
That’s a good point. Sometimes the bugs it finds are along the lines of: “if a future author adds a new enum here…” or “if this job happens to run before this other job…”, and this is either very unlikely (just put a comment on the enum warning people!) or impossible (Job B can’t run before Job A). But even in those cases it’s a code smell, so often worth a comment at least.
Posted by jrrembert on May 26, 2026 at 10:19 AM
Great to see you come over to the dark side (re: AI coding)!Only thing I would add is to occasionally consider reviewer archetypes in terms of both their seniority level and “primary” role. I find myself increasingly reviewing code created by product managers, designers, and other traditionally low/no-code roles (including lawyers and marketers). It’s often useful for me to review the code using a senior lens, but create the bug/explanation in language that they can both understand, and encourage them to learn.A verbatim example I used last week to explain Single Responsibility Principle:”Looks pretty good. You got it working, which is the hard part. One issue: this function is doing too many things which may make it easier to change later. It’s kind of like mixing campaign strategy, copywriting, and reporting into one giant spreadsheet.
There’s a software idea called SOLID that gives names to this kind of thing (Single Responsibility Principle).
Next time, ask the AI: ‘Can you refactor this so each function or file has one clear responsibility?’”
Posted by Daily Reading List – May 26, 2026 (#791) – Richard Seroter's Architecture Musings on May 26, 2026 at 4:57 PM
[…] Using AI to write better code more slowly. I see a lot of folks writing about their angst and loss of joy because of what AI can now do. I […]
Posted by handsome tong on May 26, 2026 at 7:34 PM
I’ve been using Claude on a side project and your description of drowning in bug reports is spot-on—Mythos might just be the sanity check I need. It’s easy to fall into the slop cannon mentality, so thanks for making the case for going slow and high-quality.
Posted by Why "AI-Assisted Slowness" Beats Turbo-Coding Every Time - Honoz.com on May 27, 2026 at 8:04 AM
[…] Source: nolanlawson.com […]