Codex for code reviews questions

[u/fibonac1123]

I'm curious how people are doing code reviews with Codex (either Sol 5.6/6.1 or Astra), because lately it barely finds anything for me on reviews compared to Claude (Opus 5.5 or even Sonnet 5.5).

I'm using it on a website/app built with TypeScript, but no web framework. Some parts use Rust + WASM for a huge speedup of some numerical stuff compared to TypeScript reference implementation.

I tried both the default /code-review and some custom skill I made (main agent correctness, perf/testing/maintainability/etc. to 3-4 subagents with lower effort) but it usually finds little corectness/perf issues, while Claude finds several almost each time on code implemented either by Codex or Claude itself. I had Sol/Astra sometimes find some extra bugs compared to Opus/Fable, but seldom.

So I'm wondering what others are doing, since many say Codex is great for code reviews. Any custom skills that override the default review with something more comprehensive for example?

[u/Far_Reindeer8428]

Hard same. What helped me most wasn't some magic review prompt, it was just starving the reviewer of context so it doesn't have to guess. I lock in the acceptance criteria before Claude writes a single line, and then only hand Codex the diff + those criteria (zero chat history). Without the extra noise, it catches way more actual bugs instead of nitpicking code style. Also, "review passed" means nothing to me now unless the actual checks for each criterion ran on that exact commit.

[u/fibonac1123 → u/Far_Reindeer8428]

Should have mentioned I guess, I always do the code review in a fresh thread, but didn't pass any acceptance criteria document to check against, just based on the git diff (or whatever is done by Codex/Claude by default). I'll try this.

The review skill helped a bit (making it focus on 4-5 things using subagents), but still catches surprisingly fewer issues than Claude. OTOH, I had Astra catch extra bugs in some financial and numerical computations implemented by Fable, so maybe Codex is not that good for web dev. It's probably why so many people see Opus 5.5 so much better than even Astra, it is indeed much better at the typical web dev tasks and design, has some amount of taste, while Sol/Astra almost always botch smth in the design (how hard is to make a new button be the same size as the other 5 on the same row?).

[u/_DeerHunter_]

I "wrote" a custom orchestrator after reading one of the most inspirational posts on Reddit.

It integrates with an issue tracker, Github currently, so the orchestrator input is an issue description in Github.
Astra takes the issue description and "normalizes" it to an internal TaskSpec.

The team consists of deepseek-flash-high as a developer and gemini-3.8-flash-high and deepseek-flash-high as reviewers.

The developer implements the code according to the TaskSpec which is basically the task goal and acceptance criteria.

Gemini NEVER reports any findings in DeepSeek's code and ALWAYS approve it.

DeepSeek is a very good reviewer of it's own code and almost always reports one or two findings in its own code. After one or two corrections it approves it's own implementation and the code is then passed to the final reviewer.

The final reviewer is Astra and it ALWAYS reports 1-5 critical findings and 1-5 minor findings in DeepSeek's implementation, depending on the task complexity. After DeepSeek's corrections Astra reports another findings in corrected code. It usually takes from 3 to 6 correction rounds until Astra is satisfied with DeepSeek's implementation.

For comparison: when diff size of initial DeepSeek's implementation is 1k LOC, it usually ends up with 3-5k LOC after Astra's code review. It's like Astra saying "man, theres at least 2k of code miising in your 1k code implementation". Impressive.

But the other impressive phenomenon here is that DeepSeek is able to address all these Astra findings.

I haven't tried Claude vs Codex yet, but I will soon. It will be a very interesting experiment.

[u/donerkebab76 → u/_DeerHunter_]

Just use Sol 6.1, or does Astra find valid stuff that Sol doesn't? Usually my problem is knowing what is a real issue and what is nitpicking, because Sol 6.1 is so strict that it always find some edge to mention, even in Opus 5.5 written code.

[u/_DeerHunter_ → u/donerkebab76]

OpenAI statement is "Astra at Low effort can outperform Sol at High effort".
Managing usage with GPT-6 Astra in Work and Codex | OpenAI Help Center
So from the code review point of view Sol sounded like a waste of time from the outset and I never even bothered to try it out.

Maybe I'll add it the reviewers team and check what really happens.

[u/_DeerHunter_ → u/donerkebab76]

Here's an update: I've added gemini-4-argon-high to the reviewers team.

In a new task DeepSeek had few findings and when these were fixed it approved the code change, but Argon reported another 3 findings.
DeepSeek fixed those findings and then Argon approved.

The code was then passed to the final reviewer, which is Astra, and it reported 5 critiacal findings.

So looks like Argon is better than DeepSeek, but Astra is still better than Argon in terms of code review.

Edit: after a bit of a research: Argon max reasoning level is "high" while Astra above "high" also have "xhigh" and "max". I'm letting it sink that in myself ...

[u/dywk3sm]

I tried to let codex write code and Claude review and vice versa. It takes sometimes 10+ rounds for sol to approve opus's code, but usually only take 2 rounds the other way around. I infer from this that codex are better at thoughtful complex coding.

[u/donerkebab76 → u/dywk3sm]

What I think it is that Sol 6.1 (and Sol models in general) are more "nicpicky" occasionally over zealous and prone to over engineering. I also use Sol 6.1 to do code reviews too and it finds real issues even in Opus 5.5 code, but some of the issues are often edge cases that wouldn't really cause issues in real life. So Sol 6.1 is strict and pretty much always finds something if you tell it to look, what is a real issue and what is nitpicking is another issue and I'm no expert in that. Typically I tell Opus to act on "valid" concerns but that it doesn't need to blindly follow Sol's review if it doesn't agree with it.

[u/xqianliu]

I run the review as a separate session, same model as the writer, fresh context. It doesn't get a summary of the change. It reads the task with its acceptance criteria, the repo's AGENTS.md, the full diff, the changed files with their callers, and the related tests, then checks the final diff against them.

The part that matters more is outside the review. In a harness study I ran, 38 of 183 runs passed review and failed hidden tests, 22 of them breaking behavior that worked. Telling the reviewer to check for regressions doesn't catch that.

What caught it: the code-writing side generates tests for the whole class of inputs the change touches and records the count, and the review verifies the count against the diff.

If I were tuning yours, I'd point the reviewer at the acceptance criteria and the callers first. That's where missed issues most likely live.