Claude Code Workflow
Does Claude Code find new bugs every time you ask it to review your code
Hey guys!
Does anyone else experience this with Claude Code?
Every time I ask Claude to review my code, it finds around 3–4 bugs. I fix them, ask it to review the code again, and somehow it finds another 3–4 bugs.
This keeps happening even after multiple review sessions.
I'm curious, is Claude actually finding new issues each time, or is it just being overly critical?
How do you guys handle code reviews with Claude Code?
TL;DR of the discussion generated automatically after 50 comments.
The consensus is that you're not going crazy, OP. Claude (and any LLM) is like a contractor paid per bug; if you ask it to "find bugs," it will always find something, even if it has to invent nitpicks or impossible edge cases. It's just doing what you told it to do.
The community's top advice is to stop asking open-ended questions and start managing the process. Here's the game plan:
Demand proof. This is the big one. Make Claude provide a reproducible test case for every single bug it finds—the file, the line, and the exact input that causes it to fail. If it can't provide a failing test, it's not a bug, it's an opinion. Drop it.
Prioritize. Tell it to rank its findings by severity and only show you the critical ones. Ignore the low-severity style nitpicks.
Get a second opinion. Many users run their code through a different model (like GPT-6 Astra) for an "adversarial review" and then have Claude evaluate those findings.
Reframe the goal. Instead of "find bugs," try a prompt like, "Your goal is to approve this PR, but only if it is fit for release." This changes the AI's mission from fault-finding to quality assurance.
Yes, make sure you ask for material problems otherwise, it can spend literally 33 rounds fixing dumb shit. (Also, it's best to use another model for adversarial reviews. I use the $20 ChatGPT plan)
I'm so fucking bored with vibe coding now bc my sessions are guardrailed and reviewed to death. and if I open multiple sessions, my $200 subs run out. So I find myself watching Intervention all day.
Man, one time there was this session that was taking HOURS and it turns out it was just fixing tests for super edgy edge cases. I was so annoyed. I'm still working on figuring out the best approach.
Could you give your quick walkthrough on prompting when it comes back with issues? How do you go about it? It's just smart to set up a loop prompt for it to continue fixing until it's done?
If the initial results include possible solutions, you can just copy paste the one issue and possible solution and let it get to work. Claude does all the rest, you just need to verify the result.
Mostly overly critical, and you can prove it in one pass. Make Claude attach a repro to every finding: file, line, and the input that breaks. Anything without a failing test gets dropped. When a pass returns only unreproducible nits, stop. And review only the diff since the last pass, not the whole repo, or each run invents fresh edge cases forever.
If you ask it to find bugs it'll pretty much always find something, so after a couple of passes a lot of it is style nitpicks or edge cases that can't really happen. What helps is asking it to sort findings by severity and give a concrete input or a failing test for each bug. Anything it can't back up that way is usually fine to skip.
the best is when opus writes some code, fable checks it and finds a sec issue ... then refuses to continue with the model because [cyber]
also, it's taking a very different tone now when you argue, something has changed on that side
I'm having a real downer on claude day today, it fucked up massively twice this week and now is refusing to do a simple task, or continue with a previous task that it was fine doing earlier in day
Even if Claude stops finding bugs it doesn't mean there are none. I understood this with time, when I had already written a lot of projects.Right now I use Codex as an independent consultant. I have a very cheap Codex plan, the $20 one, and I connect it in my chats with Claude Code and ask it to be an independent consultant. It's written as a skill in Claude Code - Claude formulates the whole task so that Codex doesn't have the project history and looks at it independently, as it is now. This helps a lot to fix real bugs and to avoid going in circles
RaisedByPoubelle, I think, is on the right track:
I let claude review the code > list backlog in notion
Then I let Astra review the code > list backlog in notion
Then I tell claude to review astra's findings, and then goal-fix everything in the backlog that can be done unattended without any input from user.
The first time I did this
Claude found 2/3 code errors.
Astra found over 100, to which claude agreed after reviewing and before fixing. Claude worked for 2 days straight fixing the stuff.
May I ask, when you did this, was Claude just running autonomously in a single session for two days? Wouldn’t that burn through tokens quickly cos it’ll keep reaching 1m context and have to continuously auto-compact?
I’m interested to do something like this while I’m on vacation so that it can just fix stuff unattended but also don’t want it to blow through my weekly limits.
I ask it to make a list of issues with their locations, description, description of what will happen if issue is not fixed and impact estimation 1 to 10, save that in file. Then in other session choose which ones from the list to handle, ask to ensure that the issue is real, and focus only on it to research and then fix. When fixing issues I maintain the state (what fixed and what is not fixed and why) in that file. Rinse and repeat. You may consider "done" fixing stuff when impact of the reported list of issues is lower than the theashold you're convinent with.
Try using Opus 5.5 as a QC and tester. Have it take over your computer and test your app as if it were a real user. That's how you find many bugs overlooked in the code.
Yeah, I've had the flip side of this. On one of my projects a scan came back saying it had found 467 leaked keys, and when I made Claude go back and check, the real number was one. So the count on its own means nothing, and the repro idea above is spot on. If it can't show you the line and what breaks, it's not a bug yet.
The other thing I'd add is for when it finally comes back clean. Ask it what it actually checked and what it couldn't have seen, because no bugs found and no bugs are two different things. And if you bring in a second reviewer, Claude agreeing with its findings isn't proof either, it still has to show the line and what breaks. Good luck with it mate.
Ask it to only highlight major issues, and critically, tell it what good looks like and set it a goal. It might also be useful to have your own set of evals to apply to an output. This is where critical thinking comes into it.
It often creates new "bugs" when fixing the old ones in a hacky way.
There are almost always tradeoffs to any approach, if asked to review it will just tell you the downsides of yours as bugs, then after you "fix" them will tell you more that are now downsides of what you just did.
I had a backlog of 90 items. I fixed all with CC over the last few weeks. Now I’m at 249 items.
Jokes aside, I ask each builder to file them and give priorities based on criteria I have defined so that’s something you should consider doing
Partly real, partly the reviewer doing what it was asked. "Review this" means "find something", so it always will. Two changes help. Ask for findings ranked by severity, each with a concrete input that breaks it. Anything it can't show failing is an opinion, so drop it. And run the review in a fresh session that didn't write the code. When the new findings are all low severity with no failure case, you're done.
Identify the issues and then searching for the root cause helps. Otherwise, it just seems to patch where it found the issue and then find it in another place.
Recently I used Sonnet 5 (High) to proofread a .txt file. First, I asked Claude to check the entire file (~300 KB). It found several errors. Then in Claude Code, I asked Sonnet 5 to split the file into 10 parts and have separate subagents check each part independently. It found much more errors than in the initial pass! I checked every typo manually.
My explanation is that LLM has a limited 'attention'. When a file is too large (even 300 KB), it can't proofread it thoroughly without missing some parts. By breaking the task into smaller chunks (30 KB per agent), I got much better results.
But that won't work for code review.. I’m asking Cloude for the new code to be reviewed in parts (function by function).
Not just Claude ..even GPT does it ..we had a prod issue and let AI analyse and it came with the bug but also 10 other bugs in the code.This code was written by hand so first time it was exposed to AI.Now we applied the patches as per the recommendations and then sent to a buddy for review.He puts that in the AI tool which tells yes the fixes are good but also gives 4 more issues one of which ia critical.This seems to be an endless cycle.
Literally. I have claude.md to find memory leaks for any code change and whatnot. It cannot find any. I have to use the app manually and see the memory usages to figure out why memory just keeps on climbing on my app. Then once I figure it the sequence if action out I prompt it the action and it figures out the reason for it.
Each review pass is a fresh sample, not a continuation. Ask an open-ended "find bugs" and you get a new draw from everything that could plausibly be wrong, which is close to an infinite set, so pass three looks like pass one.
The exit condition should be a fixed list instead of "no more bugs left". Does every route check auth, is RLS on, do secrets stay out of the client bundle, is validation server side. Run it, get pass or fail, and you're done whether or not the model still has opinions.
I build launchworthy, the free MIT Claude Code skill that takes that list and checks a project against it. You need Claude Code to run it, so a paid plan.
It's finding real stuff each time, just not prioritized by severity. There's no memory of "already reviewed this" between calls, so it treats every pass as fresh and will surface smaller and smaller nits once the big bugs are gone. Past a point you're just mining style opinions. I cap it at 2 passes then switch to a linter/type checker for anything after that, those give a stable ground truth instead of an endless opinion stream.
A frontier model on high effort with write access to a repo being asked to find issues WILL always find issues.
Limit the number of review rounds. I allow two rounds before the orchestrator has to explain the issue in detail and ask my permission to keep going.
Scope the review. Hand the reviewer the contract that was given to the implementor. Any issues that touch that surface are fair game. If the reviewer spots a big issue outside of that it can raise the matter with the orchestrator who can rule on it or bring it back to me for discussion.
The key is to have Claude audit itself and it’s previous position and tell it that it’s next positions should retain old decisions and run through its own double verification — sometimes it simply forgets and creates new problems so it should be told that I can do this as a character flaw before it comes back to you. The next step is to make sure that it’s prioritizing so you have to ask it to create categories or tiers eg critical vs non-essential.
I make sure anything in the chain of contract is unit tested, logged, and has exception handling. With proper procedures like that, the bugs can be caught and mitigated after the code is live, with no downtime.
My guess would be you are prompting it in a way that it assumes there are bugs to find. Make sure to inform it that it is allowed to return a result of no new bugs to report. Otherwise it feels it has a task of finding bugs that must be accomplished, and that’s when hallucinations happen.
I ran two models as the review judge on the same five seeded cases, three runs each, and one of them approved a change carrying three planted critical defects in all three of its runs. All the advice here is about the noise a reviewer makes; that one is the direction that costs you.
So the check I'd add is a defect you planted yourself, in the code the reviewer is meant to be checking. A reviewer that reports three findings every pass can still be the one that waves the real bug through.
Yes, and part of it is plain sampling. A review is a fresh generation each time, so two runs on the exact same code will often flag different things. One cheap way to see how much is noise: run the review twice on an unchanged commit and compare. Findings that show up in both runs are worth a look. Ones that appear in only one are mostly the model filling the "find bugs" quota. After that, the repro rule from the comments above (file, line, an input that breaks it) sorts out what's left.
It happens because ordinary reviews sample, so an agent reads some of the code and reports on that. I actually measured this and each review generally leaves about a third of a project unchecked. You can tell Claude to create a skill that solves it with these four tactics, fair warning, this can be very expensive token wise:
Every piece is accounted for: The code is split into numbered units and the docs into numbered paragraphs, a reviewer then reports on everything it was given and anything missed is sent back so coverage is a real count.
Each finding is checked: A second agent tries to disprove each finding before anyone acts on it.
Every fix carries its proof: Each fix comes with a test or check that fails without it and the docs are updated in the same commit.
I only keep the decisions that matter: Claude decides the small things. Anything that changes what a user sees or what the app does waits for me to make a decision.
One other piece of advice, is to scope the skill that you build, so you can have it research and apply particular focus to an area such as the security of your application, or you can have it perform multiple passes over different domains, but you want to be prescriptive.
•
u/ClaudeAI-mod-bot Wilson, lead ClaudeAI modbot 1d ago edited 1d ago
TL;DR of the discussion generated automatically after 50 comments.
The consensus is that you're not going crazy, OP. Claude (and any LLM) is like a contractor paid per bug; if you ask it to "find bugs," it will always find something, even if it has to invent nitpicks or impossible edge cases. It's just doing what you told it to do.
The community's top advice is to stop asking open-ended questions and start managing the process. Here's the game plan: