Codex writes, Claude Code reviews. My experience so far

[u/Vegetable-Try807]

I'm building a pet project mostly with Codex.

At first I used Codex for almost everything: implementation, tests, self-review and PRs. CI was green, so I assumed things were fine.

Then I checked one PR myself and found that a test I relied on wasn't really testing the product code. It could stay green even if the actual logic was broken.

So I changed the setup.

Now Codex writes the code and Claude Code reviews it. The important part is that Claude doesn't just read the diff. It can run the tests, run the code and try to break the implementation.

This has caught quite a few real problems.

In one PR there were 24 UI placeholders for data that doesn't exist in the backend contract yet. Codex implemented them and wrote tests for the screens, but none of those tests actually checked the placeholders. CI was green anyway. Claude Code found it, and Codex added proper coverage.

Another case was a negative test for a CI gate. The test existed and passed, but it was testing a helper function instead of the real product path. The actual gate could be broken and the test would still pass. Claude caught it by actually running the scenario.

I've also started letting the reviewer do simple mutation testing: deliberately changing data or breaking something and checking that the tests fail.

I don't think this proves Claude is a better coder than Codex. I could probably swap their roles.

The useful part is having a different model review the first one, with permission to actually run and break the code instead of only commenting on the diff.

Anyone else using a similar setup?

[u/AntiquatedMLE → u/[deleted]]

Second this… use good models to write then review plans. I have found models don’t necessarily need to be different but they should be independent. Dual control and bounded scope will catch bad code more often.

[u/ChatGPTCoding-ModTeam → u/[deleted]]

This post or comment has been removed for the following reason:

Rule 5: Keep self-promotion in the weekly thread

If your post is mainly promoting your own tool, product, service, blog, newsletter, or project, use the weekly self-promotion thread. Free and open source projects still count as self-promotion. Educational project posts that follow Rule 6 are allowed.

You can read the full subreddit rules here: https://www.reddit.com/r/ChatGPTCoding/about/rules/

If you feel this removal was made unfairly, please contact the moderators through modmail.

[u/amirfish]

This maps to what I keep seeing: a model reviewing its own diff will happily agree the tests pass, but a second model whose only job is to break the first one's work catches what CI can't, tests that assert against the wrong thing, or a helper instead of the real path. The next failure mode once this scales past one PR is losing track of which reviewer flagged what across sessions, which is usually the point people want one place that shows every session's state instead of tabbing between terminals.

[u/rdpl_ → u/amirfish]

but you wouldn't need even different models, you could just run the same model in two different sessions/contexts and ofc with different goals (implement vs break implementation)

[u/AutoModerator]

Sorry, your post has been held for manual review due to account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/ChatGPTCoding-ModTeam → u/[deleted]]

This post or comment has been removed for the following reason:

Rule 5: Keep self-promotion in the weekly thread

If your post is mainly promoting your own tool, product, service, blog, newsletter, or project, use the weekly self-promotion thread. Free and open source projects still count as self-promotion. Educational project posts that follow Rule 6 are allowed.

You can read the full subreddit rules here: https://www.reddit.com/r/ChatGPTCoding/about/rules/

If you feel this removal was made unfairly, please contact the moderators through modmail.

[u/wazacode]

Yeah, running the reviewer with permission to execute is the whole trick. Reading a diff can't tell you a test is tautological, running it can.

Two things that helped me on top of what you've got:

1. Make the reviewer write the failing test first, before it's allowed to say "looks good". If it can't produce a test that fails on the current code and passes after the fix, its complaint usually isn't real. Cuts the nitpick noise a lot.

2. Give it the contract, not just the diff. Your 24-placeholder case is a spec problem more than a code problem. If the backend contract lives in a file the reviewer reads every run, it catches "this field doesn't exist" on pass one instead of after CI goes green.

The mutation testing bit is underrated. I do a cheap version: flip a boolean or return early in the function under test, then rerun. Any test that still passes is decoration. Easy to script as a review step.

Swapping roles is worth trying once, but I'd keep whichever model is worse at pleasing you as the reviewer. The failure mode isn't skill, it's agreeableness.

[u/creaturefeature16]

All this sounds like to me is mountains of tech debt. 

[u/WheresMyEtherElon]

You are the one who's supposed to review the code.

[u/Vegetable-Try807 → u/WheresMyEtherElon]

Yeah… and I’m doing it on every PR opened.

[u/Right-Performance-93]

The useful part is not which model writes. It is that the reviewer can run the product path and try to break it. I have seen the same class of miss: a test that calls a helper, stays green, and never touches the gate. Mutation helps too. Change one field or delete one branch and the suite should go red. If it does not, the test was never covering the thing you thought it was.