--- title: "Discussion on \"How I make Claude Code and Codex review each other's work\" | Hashnode" description: "Discussion on \"How I make Claude Code and Codex review each other's work\". Originally published on dev.to: https://dev.to/iliyaoblakov/how-i-make-claude-code-and-codex-review-each-others-work-5dmh\nI build software for paying clients with Claude Code and Codex. Both are good" url: "https://hashnode.com/posts/how-i-make-claude-code-and-codex-review-each-other-s-work/6ad7dfe549a1732434479887" --- [Feed](https://hashnode.com/feed) / Discussion # [How I make Claude Code and Codex review each other's work](https://iliyaoblakov.hashnode.dev/how-i-make-claude-code-and-codex-review-each-other-s-work?utm_source=hashnode&utm_medium=feed) Originally published on dev.to: https://dev.to/iliyaoblakov/how-i-make-claude-code-and-codex-review-each-others-work-5dmh I build software for paying clients with Claude Code and Codex. Both are good Oct 20 · 7 min read · iliyaoblakov.hashnode.dev Read the article - [#ai](https://hashnode.com/tag/ai) - [#productivity](https://hashnode.com/tag/productivity) - [#git](https://hashnode.com/tag/git) - [#devops](https://hashnode.com/tag/devops) - [#claude](https://hashnode.com/tag/claude) - [#codex](https://hashnode.com/tag/codex) ## Written by [Iliya Oblakov](https://hashnode.com/@iliyaoblakov) @iliyaoblakov [View profile](https://hashnode.com/@iliyaoblakov) ## Responses 4 Markdown supported · ⌘↵ to post [Kartik N V J K](https://hashnode.com/@kartik-nvj) [Oct 22](https://hashnode.com/posts/how-i-make-claude-code-and-codex-review-each-other-s-work/6ad7dfe549a1732434479887/comment/6ad9f70f6d071392161f0567) "A reviewer that can fix what it finds is a second author" is going on a sticky note above my desk. The gap I keep watching for is the writer editing the tests in that same commit, since step 5 runs whatever tests the commit carries. Do you have a rule in RULES.md that makes a loosened or deleted assertion an automatic CHANGES REQUIRED? [Iliya Oblakov](https://hashnode.com/@iliyaoblakov) [Oct 22](https://hashnode.com/posts/how-i-make-claude-code-and-codex-review-each-other-s-work/6ad7dfe549a1732434479887/comment/6ad9f70f6d071392161f0567#reply-6ada7d9d0d1b0c368da5d35e) Thanks. You're right that it's the weak spot, because the gate runs whatever tests are in the commit. It isn't in RULES.md. It's in the review prompt Codex gets: every test change has to fail on the old behaviour, nothing can be weakened without a stated reason, and the reviewer has to check the diff for any weakened or deleted test. So a loosened assertion with no reason comes back as CHANGES REQUIRED, but it's the reviewer's call rather than a hard check in the script. A script that flags removed asserts in the diff would be a good addition, and I'll look at it. [Ascendra Ventures](https://hashnode.com/@ascendra-ventures) [Oct 21](https://hashnode.com/posts/how-i-make-claude-code-and-codex-review-each-other-s-work/6ad7dfe549a1732434479887/comment/6ad825a92e69f3a1ca8faf3f) Naming the verdict file after the commit hash is the detail I would point other people to. It closes the most common hole in AI review setups, where an ACCEPT from an earlier commit quietly covers code nobody reviewed. Step 2 deserves the most attention. Rules that name something visible in a diff and say how to check it are what turn review into findings instead of opinions, and the same idea works one level up. On client projects we write the finish line for the whole task in that style before the writer starts: what must work, what must stay exactly as it is, and how it will be checked. Then the reviewer has both the rulebook and the task's definition of done. Your gate proves the steps happened, as you say, not that the code is correct. Have you tried giving Codex the task's acceptance criteria as well as the diff, and did it catch different things? [Iliya Oblakov](https://hashnode.com/@iliyaoblakov) [Oct 22](https://hashnode.com/posts/how-i-make-claude-code-and-codex-review-each-other-s-work/6ad7dfe549a1732434479887/comment/6ad825a92e69f3a1ca8faf3f#reply-6ad9be61cbf3290f34172afa) Thanks. Yes, that's why the verdict file is named after the commit hash, so an ACCEPT for an older commit can't cover code that came after it. On acceptance criteria: yes, that's where I took it next. Each change now starts with a short "Done means" list, and Codex has to mark every line as met, not met or not checkable, with the house rules checked the same way. I count a "not checkable" answer as a finding about the brief, because it means I wrote a requirement nobody can verify. I wrote that up as a follow-up on my blog, "How to make Codex review Claude Code's commits", if it's useful.