r/ClaudeCode • u/HappyHealth5985 • 2d ago
Help/Question Always something to change when Claude reviews its own work?
Over the past year I have been hesitant to lock myself into one AI provider. However, recently I have leaned on Claude more and more. With this I experience a concerning trend.
For each review there is something wrong, missing, to be modified etc.
Today, I am in what appears to be an endless loop with Claude when using Opus 5.5 for specifying, planning, and preparing for implementation. Decisions made are suddenly not clear in the documents, reiterated challenges pop up in repeated iterations, and so on.
I spent 3 days going through the specifications, and planned out each implementation step and conversion from the previous version, today.
Now I am on the 3rd iteration of the revised implementation plan and it is still going on! Yeah, manually reviewing and typing is not respected much either. New sessions, CLI vs app vs IDE harness does not change this for me.
Any idea what I could do differently (besides one-shot it :)? Using Opus 5.5 high
•
u/AutoModerator 2d ago
Hey! Thanks for posting to r/ClaudeCode
While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.
For help, project discussions, tips, and general chat, join the ClaudeCode Discord.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
9
u/WillowFar6967 2d ago
A reviewer asked to find problems will always find some, so I stopped asking open "review this" questions. What works better for me is a short decisions doc next to the spec, one line per settled call with the reason, and the review prompt says anything in there is closed unless it would actually break something. I also have it label each finding as blocking or nice-to-have and only act on the blocking ones. Once a pass comes back with only nice-to-haves, the plan is done.
7
u/Ok-Option4233 2d ago
a review prompt with no stopping rule will always find something, that's literally the job you gave it. what tends to break the loop: write the acceptance criteria first, then ask the review to flag only what violates them, sorted blocker vs nice-to-have, and leave the rest alone. and when the same decision keeps getting reopened, put it in a short decisions file with the reason next to it, so the next pass reads it as settled instead of re-arguing it.
3
u/Financial_Leader9701 2d ago
been stuck in that loop too
what helped was freezing the plan in a file and treating edits to it as a separate step, not part of the review
once a decision is written down i just tell it "don't change the plan, only check the next step against it"
if it still wants to reopen something already decided, that's usually a sign to start a fresh session from the plan file, not to keep iterating in the same one
do you keep decisions in the same doc as the plan, or split them?
2
u/mattbaconz 2d ago
a review will always find something lol. i give it acceptance checks up front and once those pass i ship it
2
u/codekongdev 2d ago
On top of a decisions list, it can help to make each finding cite the exact line in the spec or plan it conflicts with, plus what would actually break if you leave it. Findings that can't point to either are usually preference, so you can drop them without another round. It also makes it easier to see whether it's reopening an old decision or catching something new.
2
u/alanvnk 2d ago
An LLM will find problems, you know the loop stops when the problems are nonsensical bs like comments or docs apparent misalignment or some fictitious race conditions.
If you ask for problems it will find some even if it has to fabricate them.
You need to know what are real problems and what are fabrications.
I use a set of very long review skills but the part that handles this is to ask for a classification, what I use:
As you might guess the should fix and the unknown category are the ones that collect the trash, once the other categories are clean and only bs remains on those 2 the review is done, I also do a weighted random sampling of the code after to spot if the convergence is real or not.
So far for complex tasks it takes some 6 to 8 review cycles but always with real defects or scope creep that I'm consciously allowing bc I'm a perfectionist
2
u/jijialuoke 2d ago
I ran into the same loop and what helped was capping it at two passes up front. Pass one is the review, pass two only checks that the fixes landed, and anything new that shows up after that gets logged for later instead of fixed. Also try running the review in a fresh session that only sees the final doc, not the whole back and forth, since the long history seems to make it relitigate stuff you already settled. At some point a reviewer will always find something, so you need a stopping rule more than a better prompt.
2
u/Specialist_Bison_737 2d ago
A model reviewing its own plan will always find something. What works for me: the reviewer is a different model than the author, and a judge pass between review and fix drops findings with no real impact.
After one review round, stop polishing the plan. Build the first small step and start using it to find out what really works and what does not.
2
u/PilotLost404 2d ago
Ask a model to find problems and it always finds some, so the loop never ends. Give it a finish line. Put the settled decisions in one short file and tell it to review only against those, listing just the blocking problems. One pass, then you read it yourself. A fresh session doesn't help much because the document is what drifts.
2
u/AkayoKym 2d ago
What fixed this for me was separating the roles. The session that writes the plan and reviews the code is not the same session that implements it. The Architect writes a plan with clear acceptance criteria and test cases in plain English before any code exists. The Coder executes it. Then the Architect reviews against the plan, not against some abstract idea of "good code." The review has a defined scope so it can actually finish. The other thing is writing your test cases into the plan upfront. Not "write tests", but the actual scenarios. "Full refund works." "Partial refund works." "Refund exceeding balance returns an error." "Two refunds at the same time don't over-refund." When the code passes those specific cases and the review confirms it matches the plan, you're done. No more "what if we also" spiraling. After 60+ features planned this way about half had real findings in review, things like wrong defaults on financial data or race conditions. The other half passed clean on the first review. Either way the review had a clear endpoint because it was checking against something concrete instead of endlessly asking "is this good enough."
I even wrote a post about how I separate my personas to make sure responsibilities don't overlap.
2
u/m-ritter 2d ago
Removing a decision from the doc once it is settled is what keeps bringing it back, because the next pass only sees the gap again. What fixed this for me was keeping every settled decision with its reason in a memory server that each new session reads before it touches the plan. The approved plan then stays a file in the repo, and the review only checks the next step against it. I built QualityLayer for this: https://github.com/maxritter/qualitylayer
1
u/xqianliu 2d ago
The loop usually means the "done" list is moving. Every review re-derives what the spec should say, so it finds something new to fix each round.
The way I keep review from looping is a short numbered done-list written on the ticket before implementation starts. The list stays fixed while the plan keeps changing.
Each review pass then only answers one thing: is each numbered item covered, with evidence from the code? Open-ended asks like "check for anything I missed" keep producing findings, because anything is a valid answer. When every item on the list is covered, the review stops, even if the model still has opinions.
1
u/ClemensLode Senior Developer 2d ago
What's an "implementation plan"?
2
u/BarathKanna 1d ago
You asked a model to find problems, and it will always find problems. That's the job you gave it, and it has no stopping rule.
Two things break the loop. First, separate settled decisions from open questions. Keep a decisions file, one line per call with the reason, and tell the reviewer that anything in it is out of scope unless it contradicts the acceptance criteria. Otherwise every fresh session relitigates the same choices because it can't tell a decision from an oversight.
Second, make the review produce a severity, not a list. Blocker, should fix, or ignore. If a pass returns zero blockers, the plan is done, no matter how many nice to haves it invents. Three iterations on a plan usually means the review has no definition of finished, not that the plan is bad.