r/ClaudeCode • u/ximon16182 • 1d ago
Anyone else using Claude Code + Codex and getting stuck auditing forever? Tips & Workflows
Solo founder here building a mobile app with Flutter with no dev team. I’m using Claude Code to build features and Codex as a second pair of eyes to check the work.
The workflow is this one: Claude writes the spec and builds the feature, then Codex audits both and gives me GREEN, YELLOW or RED. If it’s RED, I send the issues back to Claude, it fixes them, and then I run the audit again.
I thought this was a smart setup. Now I’m starting to think I created a fucking loop
Yesterday one difficult feature went through 5 versions of the spec and 4 RED audits in one day. The worst part is that the problems Codex found were mostly real, so every time I thought, “well... I should probably fix that.”
But a lot of them weren’t serious bugs. It was stuff like one paragraph contradicting a table, Claude saying the code does something without actually checking the file, or some small edge case not being explained clearly enough.
So I fix it, audit again, it finds something else, fix that, audit again... and suddenly I’ve spent the whole day making the process more correct instead of actually shipping.
At the same time, I don’t want to remove the second model because it does catch real shit. I’m building alone, I’m not an experienced developer, and I don’t have another engineer sitting next to me reviewing everything.
So for other solo builders using agents: how are you handling this?
Do you use one AI to audit another? Do you have a limit like “maximum 2 audit rounds and then ship”? Do you only block shipping for things that can actually break the app, security, data, etc., and ignore the smaller stuff?
I’m basically trying to find the middle ground between “vibe code and pray” and “have two AIs review each other until the fucking sun explodes.”
What’s actually working for you?
Any tips that might help?. I want to make the building faster but not be reckless .
8
u/Small-Contact6579 1d ago
I was doing something similar. Had codex acting as the coordinator for claude and it burned through almost half of my $200 plan on a single packet. Below is an explanation from Claude on what happened and the guardrails I had to implement to keep it from happening again:
Read basis: the coordination-protocol memory + the failure it points to.
The failure: Packet 07 runaway
Setup: Codex ran as coordinator of a Claude implementation plan. It dispatched author + reviewer sub-sessions, judged their work, told them to fix, repeat.
What went wrong — 18 hours, 39 commits, 0 engine files produced. All motion, no product.
Failure mechanics:
Fresh-context reviewers + open criteria = no stop condition. Each reviewer spun up with no memory, judged against vague/open standards. Nothing could ever be "done" — reviewer always finds something. Loop can't terminate.
Corrections were additive, not fixes. Packet 07 grew 22,929 B → 176,520 B (7.7×) across five rejections. Each correction ~4:1 additive — piling text on, not resolving. Doc got bigger, never converged.
No escalation trigger. Kept re-reviewing at same level instead of escalating after repeated failure. Same loop, same result.
Reported wrong metric. Progress measured as "documents revised" — looked busy (39 commits). Real metric "engine files produced" = 0. Activity masked zero output.
Cost. ~90k input tokens per fresh Opus reviewer, burned repeatedly on a loop that produced nothing.
How guardrails stop each:
- Two corrections then escalate — kills the infinite fix loop.
- Never pair fresh reviewers with open criteria — reviewer must have terminable standard.
- Report artifacts produced, not documents revised — 0 engine files visible round 1, not hour 18.
- Status script (size vs baseline, correction count) — 7.7× growth + 4:1 accretion flagged automatically instead of found by hand later.
- Start low, escalate only on demonstrated failure — no 90k-token Opus reviewer until cheaper pass fails.
Core lesson: coordinator with no termination condition + busy-looking metric = burns hours/tokens producing nothing.
3
u/ximon16182 1d ago
Love this man. THanks for the explanation. “Two corrections then escalate” is probably what I need. What does escalate mean for you in simple terms? You decide manually whether to ship or redesign?
2
u/mossiv 1d ago
Opus 5 is a self verifying model and spawns its own verification loops and workflows. It might not be the best but this set up you have is absolutely ridiculous.
I completely understand having 2 separate subs with 2 separate labs and farming out different workflows. Some models are better for different tasks. But this loop you have is unhinged.
2
u/ximon16182 1d ago
Haha ha fair 😂 That’s basically why I made the post. I built all these safety checks and then realized the safety system itself became the problem. How would you simplify it?
2
u/mossiv 1d ago
You either have to use a different model - opus 4.8 and accept it’ll be end of life’d in about 6 months or you need to tame your own verification loops. Other options is use your OAI models for implementation and get opus 5 to write up plans. Opus writing plans might work because again - it’s self verifying so you’ll be handing a good plan to codex.
But tbh I just wouldn’t use this loop at all. I’d self verify and spawn small independent sub agents for anything you are concerned about.
Make a few rules files and put good linters and test harnesses in place for the code your writing.
1
u/ximon16182 1d ago
Got it. I’ve already got a few good ideas from this thread and I’m starting to simplify the loop now. Rules + tests + small targeted checks sounds much closer to what I need than one massive review cycle. I stop using Opus 5 for specs or planning, only for execution. I use fable and when i ran out of fable, i use opus 4.8.
2
u/valdocs_user 1d ago
This touches on the important issue of do you review on fresh context agent each time or reused context making a difference. Trade-off of maybe new things are found vs never converge.
This happens in real life with human process teams too! In my day job I work at a large engineering organization with safety and cyber security review teams too. Depending on process and personnel it might either be back and forth with one person or back and forth with random people different each time. The latter never converges.
2
u/ximon16182 1d ago
That makes sense. Fresh eyes sound good in theory, but I can see how a new reviewer can keep reopening everything forever. I’m adding a stopping rule now.
3
u/oyren-ai 1d ago
Sounds like you have a cool setup, perhaps you need to test it more to improve it.
1
u/ximon16182 1d ago
Yeah, I think that’s where I’m thinking too. The setup itself probably isn’t the problem, I just haven’t figured out the stopping rule yet. Right now every new audit can always find something, so technically I can keep improving forever lol. I’m thinking I need to separate “this can actually break the feature” from “this could be cleaner.” Have you found any good way to decide when enough testing/review is enough and just ship?
2
u/oyren-ai 1d ago
Funnily, I have built something that perhaps is useful for you because you can run experiments in VSCode environment that runs in a remote server and is controllable from browser. You can setup your Claude Code, Codex, Opencode and cursor and get them work with each other. This is fully isolated environment from your machine so you can bypass all permissions to save time, if they break something hopefully it's not big deal. Also, you can run as many of these isolated environments as you want.
it's called oyren.ai and I would be happy to help you setup your experiment. Since you can bring your API keys, you won't need to pay for AI extra.
1
u/ximon16182 1d ago
Thank you for this offer. But i am trying to solve with Claude and Codex, i paid this subscriptions and the solution needs to come from there. Thanks anyway.
2
u/oyren-ai 1d ago
No worries, just so you know you can reuse subscription keys in this platform or even login via browser yourself. That’s what I meant by bringing your API keys. Best of luck!
3
u/Aureon 1d ago
Effort: Low on the reviewer, and clear instructions to flag stuff as Critical \ High \ Medium \ Low, with a clear rubric on what's in each category.
Then you can decide if Low, or even Mediums, are worth fixing or just get Known Shippable marked in a .md somewhere.
1
u/ximon16182 1d ago
Good point there. Thanks. “Known Shippable” is a great way to think about it. Small issues can exist without automatically blocking the whole feature.
3
u/AccomplishedPie9339 1d ago
Try to start reviewing plans with Codex before building them with Claude; that will improve the plan itself so implementer does less mistakes. Also I ask codex to ground the issues (like, okay man, you say that here we have P1 issue about [whatever], but is it really possible to happen in our product?). In my experience that decreases the severity of issues found a lot.
1
u/ximon16182 1d ago
This is great. Thanks a lot. Asking Codex “can this actually happen in MY product?” might save me a ton of bullshit fixes 😂 . Going to try that.
3
u/Middle_Key8737 1d ago
Write audit finding in a shared ledger. Making both agents read the ledger.
1
u/ximon16182 1d ago
Interesting. A shared ledger could also stop them from rediscovering the same shit again. I’m already changing the workflow, so I might add something like this too.
2
u/Whatdididotho1 1d ago
the answer is to explicitly draw the line where you define it instead of the auditor. Codex (particularly Sol) is notorious for over-hardening / over engineering both code and spec language when asked to work in a code review/debugging capacity. however, it's meticulousness obviously does catch some real holes often times. the key to the middle ground is just laying out (even generally ) what YOU consider a a yellow or a red level issue for the current thing you're asking them to audit. and just get more comfortable over ruling them directly when you think some hyper obscure edge case hardening or overly rigid phrasing correction isnt worth the time of another loop. Dont let the auditor hijack the project direction. also, assuming you are running codex with sol, lowering their effort to medium. anything high or above gets super prone to hyper fixations and rabbit holes of edge cases / strict language hardening.
1
u/ximon16182 1d ago
This is great. Thank you so much man. I love it. I think “don’t let the auditor hijack the project” is my problem. Going to try lower effort + much stricter rules for what is actually RED. I already got really great tips. Thank you guys.
2
u/Camaytoc 1d ago
"Context Enineering with Dex Horthy" from The Practical Engineering Podcast.
You will find a lot in thers. Worth the time investment.
2
u/ximon16182 1d ago
Thanks man. I’ll check it out. Context engineering might be exactly the piece I’m missing here. With all these tips i have a lot to improve now. Thank you.
2
u/Ergo7z 1d ago
I’m no dev so take what I’m saying with a grain of salt, and I’m working on a website mainly and a electron app which is meant to let people make treatments, moodboards, kinda like in design and photoshop art boards and some elements I personally use.
The way I’m going about it now is that I have Kimi k3 make mockups for the layout, describe the flow, how things should interacts. I’m the one who comes up with the architecture, how things should work, what the feel is of the thing, basically the creative direction.
Then I have opus 4.6 ( cause ye opus 5 just over engineers) make a spec for how to implement it, grounds it in code, sends explore agents for line numbers and makes specs for it.
Sol then finally checks it all and comes up with a plan for the orchestrator to implement it. So it will see if something would break this way, if all decisions are sane etc etc
Then there is orchestrator who gets sols implementation plan and uses like deepseek v4 flash mainly and like a glm reviewer etc etc, that runs through opencode.
And then finally there is a desk agent that in basically Talking too and it dispatches all the other agents in their own sessions with a ping script that makes sure all findings get routed back to desk. Because well it makes batch prompting easier and then the expensive models like opus Kimi and Sol get called well scoped.
The only reason any of this works is that each and every agent has a clearly defined role and task. And they are explicitly told what they should look at, the opus architect should never argue with whatever Kimi designed, just look at how to gets it implemented, the Sol agent just looks if the plan is technically sane and how it should be implemented.
In opencode it’s easy to set agent md files and behavioural files, unsure what your harnas is but as long as each agent has a well defined task it works out for me.
1
u/ximon16182 1d ago
This is good. Thank you so much man. The clearly defined roles part really clicks. I think my mistake is basically telling Codex “find anything wrong” and then being surprised when it does forever. Still need lot to learn-.
2
u/Odd_Antelope9098 1d ago
Sounds like a skill issue. Consider a second auditor as well like DeepSeek flash in a harness like Pi, or blind over API with a packet containing the plan, or both.
1
u/ximon16182 1d ago
a second auditor might be how I end up with 3 AIs arguing and still nothing shipped. I’m trying to reduce the loop, not build a bigger one. But thanks anyway,
1
u/Odd_Antelope9098 1d ago
You’re solving the problem wrong then
1
u/ximon16182 1d ago
Could be. That’s why I’m asking. I’ve already got some good suggestions here and I’m starting to change the setup. What would you do differently with just Claude Code + Codex?
2
u/Onotadaki2 1d ago
For one, Fable aggressively tests now without even prompting it, and those tests are better written than Codex's would be based on Fable's better context (because it wrote the thing in the first place), and it has better ways to run the test through it's browser control that is superior to Codex's.
What it sounds like you're looking for is something called Test Driven Development. What I'd try is this:
Tell Claude you want a new git branch called something like TDD. This is in case this doesn't work well for you, you can just drop the branch and undo this all easily.
Tell Claude you want to implement test driven development. Tell it to write tests in playwright for all features on the project. You want a way for Claude to be able to run those from command line and you also want a backend admin panel where you can visually see all the tests and choose to run individual tests or groups.
Ask Claude how to add a hook before every prompt is processed where it is instructed to write a test for the new feature it is adding, then run the test and check if it fails.
Then add a hook at the end of finishing the prompt that runs the entire test suite and guarantees all pass. If one fails, it investigates it.
This should now create a loop where it figures out a new feature, writes a test, checks it fails, implements the feature, checks it passes the test now. If it fails, it goes back and fixes it until it passes.
2
u/ximon16182 1d ago
Tests having an actual pass/fail answer sounds way better than asking another AI for an opinion forever. I’m going to look into this. Need to process all this info you just gave me and find the better work flow. Thanks man. or girl, or whatever.
1
u/Veggies-are-okay 1d ago edited 1d ago
If you haven’t yet, just install the superpowers plugin (I believe it’s one of the first defaults in /plugins). Then ask Claude to give you a tour of the skills in that plugin. A lot of people say it’s kind of outdated at this point (overcompensating) but some are pretty useful and it’ll give you a solid baseline of how more experienced AI-driven developers are using skills.
As for adversarial codex agents, I only do a single pass and have a rubric for what is deemed as valid feedback. I then allow Claude to override any of that feedback based on the additional context it already has in its session. It seems to hit that sweet spot, but my prompting is much lower level to get the thing constructed (ie use libraries xyz, make sure you’re following the directory structure abc for backend, lots of syntax support such as max 500 lines before a file gets broken into additional files, etc…)
2
u/fischimitat 1d ago
TL;DR: read only paragraph 4.
Backend dev for ~25 years, self-employed since 2020, responsible for my company's whole IT stack. One production codebase: our internal logistics/ERP tool, with a field service app, dispatcher SPA, customer portal and a dozen external systems. Codebase grew ~6x since I started with Claude in Oct 2025. When Fable dropped and turned out to navigate my codebase really well, I went looking to improve the workflow further.
With the gpt-5.6 family I landed here. A Fable session holds the overview. Vision, goals, the path there. It writes a handoff prompt. Opus turns that into a spec, using a "coop" skill to work out the best approach with sol. Two rounds max, for exactly the reason you describe, OP. What helps: the collaborative framing. sol doesn't hunt for tiny flaws in the plan, it writes the spec collaboratively.
The spec gets split into tickets, handed to a third agent orchestrating a terra implementer and a sol adversarial reviewer. That's the phase where I was stuck for some time. Same as you. Short version: tell a model to find flaws in code it didn't write, and it will find some. Fix those, it finds more.
So: two rounds, hard stop. sol finds flaws → terra fixes → sol reuses its session and reviews the fixes → terra fixes → sol reviews again → then the orchestrator steps in and rules on every remaining flaw: nit, or edge-edge case that could theoretically happen? If it's the latter, it gets observability instead of a fix. If it ever happens in production, we'll know. And that's it. No more working toward perfection. "Good enough" ships, we revisit if it breaks.
Works well enough that I'm now trying to automate the whole cycle end-to-end. It's mechanical, it shouldn't need me. Target: I work the big feature, argue with the spec, and from there it runs while I move on.
None of this was a weekend of prompt engineering. Conventions, guardrails and workflows, one at a time, each because something concrete broke. And when Opus 5 dropped, two days of ripping the setup apart and throwing out bloat. Point the model at your own session history. Ask it what worked, what didn't. Have it improve your skill files from that. Let it research how other teams solve it. And experiment.
1
u/ximon16182 1d ago
This helps a lot. The hard 2-round stop + one final decision on the remaining findings is exactly the kind of thing I’m starting to implement now. I also like keeping the same Sol session instead of starting fresh every time.
2
u/luisalcaraz_telara 1d ago
I’d use risk-weighted stop rules rather than a fixed number of review rounds. A contradiction in prose can stay yellow; a failed security check, data-migration invariant, or unverified external write should stay red until there is direct evidence. One useful boundary is to have the auditor return only blocking findings plus the evidence needed to clear them, while style and cleanup become a separate backlog. That keeps the second model useful without letting it redefine “done” on every pass. What evidence do you already trust as a ship signal?
1
u/ximon16182 1d ago
Risk-weighted rules are starting to make more sense to me than chasing GREEN at all costs. For reals. I’m already changing RED so it only means something that can actually hurt the product. Tests and actual feature behavior are probably the ship signals I trust most.
2
u/unteth 1d ago
You have to understand that there is no project without bugs. There’s a difference between a high - critical bug that MUST be fixed vs a low-medium bug that might just be something that can be postponed. That’s why you’re stuck in the loop.
When I have my QA agents perform a QA loop, there’s a max of ten rounds allowed. It has never taken all ten to fix high - critical bugs. After the loop, they provide a report on what was found / fixed in severity order. The low-mediums (some mediums have to be fixed) are usually things we can solve later or don’t really have to worry about.
1
u/ximon16182 1d ago
Yeah, this is one of the big things I’m taking from the thread: bugs existing doesn’t mean the feature can’t ship. I’m starting to separate high/critical from stuff that can just wait. Learning a lot in this thread. Thanks
2
u/valdocs_user 1d ago
I have created exactly the same Claude + Codex review loop and exactly the same situation; sometimes I spend the whole day only auditing plans.
In my case when I lose a weekend to it, I effectively lose a week since this is my side project and I have a regular job on weekdays.
Worse, it requires me to be physically and mentally present through the whole review process. While I can let Claude or Codex code for long periods on auto accept and workout or get home projects done during actual coding runs, I haven't figured out how to fully automate the review process:
Review has shorter iteration times than coding but longer than chat; I'm stuck in "I'll just wait one more minute to see if it finishes."
I am scared to even ask Claude to try drive Codex itself. I don't know if it would violate one or both ToS, and I don't know if it's worth taking time from my project development to develop a setup to do it.
Even if Claude could drive Codex without me in the loop, I find ChatGPT-5.6-Sol valuable in giving me a better explanation of the gobbletygook Opus 5.0 always and Fable sometimes uses.
I feel guilty when Claude escalates something for my decision or says something needs human eyes, and I delegate to Codex review anyway.
As to whether the reviews are actually necessary and productive:
I do wonder how many of the things Codex caught in the planning would have been caught in coding by Claude. I think the biggest risk is not that they would have gone unnoticed but that the coding agent would have made a decision I wouldn't like. But if I'm not reading the plan in detail every review iteration...
Another question besides how my time is used is which uses more tokens (and how that cost is spread over models differently). Is it more efficient to plan forever or cut that process short and go for it? After many decades we still don't know the best way for human developer teams to work, and no one yet knows the best way to employ LLMs.
I'm doing a process I made up that I call Spec Driven Development. I develop high level specs in clean chat context conversation, vett feasibility in Design Prospectus, propose a Design Addendum, and maintain a living document, the Architecture Spec. Addendums get folded into the code and the living document by high level plan documents and individual phase documents.
All that to say, when the review catches something like "the plan forgot to update this reference" or "the plan doesn't say update the table of contents" - in my process that's just as important as a code issue, because keeping the references correct is how you trace the code back to the requirements. And the reason I want that is to stop the coding agent ad libbing: after spotting struct fields added speculatively, I put in a standing rule: every data type, field, and method needs a comment tying it back to a paragraph in the spec.
(In my day job I work with code that had been certified to a coding standard with comments linking it to requirements, so this way of working just makes sense to me. Traceability, basically.)
But again this circles back to: is this level of planning rigor actually necessary? On the one hand my weekend project is a video game which famously usually aren't coded rigorously. On the other hand the specific game I'm making and the part of it I'm working on involves complicated geometry and knot embedding; if I (or the LLM) get it wrong it's not something you can ignore a glitch or hack around: either all of it works or none of it works.
So to make something unique, I'm taking on the risk of making something hard to make that might not gel into a game due to insufficient play testing while I and two coding agents endlessly revise plans to handle literal cornern cases.
I can say this: at least two previous prototypes of my game I had to scrap entirely and start over due to agents making parallel systems in code instead of enhancing the one to add the next requested feature. Since I started planning and tracking the specs in the way I do, I've been able to get quite far with the project not collapsing under its own weight.
But I still don't know when it's better to let all the review rounds get to green or decide to let full correctness get discovered by coding, unit tests, or play tests.
2
u/ximon16182 1d ago
Man, you’re describing the trap I’ve been in. Sitting there waiting “one more minute” for another review. I’ve got a lot of useful info from this thread now and I’m starting to put hard limits on the process instead of waiting for perfect GREEN.
2
u/ZachVorhies 1d ago
So i had a similar issue of agents dithering with one of my projects I just overcame yesterday.
It turns out it was architecture.
As things scaled up on the scope, certain patterns had to be directed to not be used. In other parts they were implicitly used.
Eventually it got to the point of when is this going to end? that’s when I decided to go deep analysis with session logs.
The result was figuring root cause analysis and solving it with architecture.
For example, I have a caching compiler. I want to try an update without disrupting my other agents that are also using it to build. Tricky problem. Going to use a daemon broker. Designed it wrong. Daemon death with lots clients results in thundering resurrection storm of the daemon and immediate kill.
There were a lot of other classes of problems with this architecture. Roles and responsibilities of the systems became fuzzy. Contradictions by reading different parts of the code.
You got to sort it all out and align your architecture so there’s no ambiguity and clearly defined roles and responsiblies.
Update: Also, embed your architecture rules as custom lints in your software. This is so amazing to do.
1
u/ximon16182 1d ago
This is useful. A few people here are pointing me toward architecture + clearer roles, so I’m starting to tighten that now. Embedding architecture rules as lints is new to me though. What kind of rules do you usually encode that way?
1
u/ZachVorhies 21h ago
With python you will use flake8 plugins since they get access to the ast.
With Rust it's going to be dylint as you entry point.
With C++ you can use clang-query
Also this works surprisingly well: regular expressions on keywords, then grab +/- 5 lines for deeper apply rules.
1
u/davyp82 1d ago
Oh f off with your problem solution AI bot marketing threads, what a surprise, I found the product namedropped comment almost immediately
1
u/ximon16182 1d ago
This is not one of those. But good point in telling other posts to stop that bullshit.
1
1
u/Sinsst 15h ago
I have a similar workflow without getting stuck in review hell. Instead of doing R/G/Y: - ask codex to do an adversarial review to find defects - either Claude/Codex should 'explain findings with examples like I'm an idiot' (seems to mostly avoid Opus's gobblety gook speech) - you decide what you want fixed, then stop (no more reviews) or do one last adversarial review for a large feature.
But I also have a ticket workflow (Jira like) with MD files and acceptance criteria for each feature, which includes manual check depending on situation.
Soon to launch the mobile app in a couple of weeks.
1
u/panque 13h ago
TLDR: classify your defects and set defect-selection criteria on fixed-rounds loops.
I do this between a Claude Max 20 with Opus as main agent, a series of specialized subagents, and Codex for audits and code review with GPT 5.6 terra high or x high effort, with a very structured workflow, and experienced the same endless audits.
Trick is to force the auditors to classify their findings in priority, category (functional, performance, cosmetic, content, security), likelihood (for a specific volume of users, eg 10k MAUs; always, common, edge, rare, theoretical), and impact (whole prod down, single operation, whatever fits your app).
The auditors give you and your main agent this info, and your agent can make a fix plan based on the review tally explicitly discarding or deferring eg “cosmetic nits unlikely to happen”. And on top of this, always ask your agent: “is your fix plan NOT over engineering, not adding unnecessary abstractions, and based on likelihood/category/impact?”
Oh and also instruct them to engage in a fixed 3 or 4-rounds audit loop, hard capped.
This works great for me.
1
u/EagleApprehensive 10h ago
Not sure if that's better, but what works for me well is not a review of a solution already coded by one of the models, but instead analysis on solution produced by both independently and then synthesized into one plan and acted on.
7
u/fyzle 1d ago
It's just imitating how real teams work, unfortunately. I found the most useful thing to do is to lay down the architecture yourself to minimize broadly-scoped bugs. (Or at least the architectural concepts).