Personally, I have Claude do the coding. Then 5.2-high do the reviewing.
replyI might flip that given how hard it's been for Claude to deal with longer context tasks like a coding session with iterations vs a single top down diff review.
replyThen I pass the review back to Claude Opus to implement it.
replyJust curious is this a manual process or you guys have automated these steps?
replyI have a `codex-review` skill with a shell script that uses the Codex CLI with a prompt. It tells Claude to use Codex as a review partner and to push back if it disagrees. They will go through 3 or 4 back-and-forth iterations some times before they find consensus. It's not perfect, but it does help because Claude will point out the things Codex found and give it credit.
replyMind sharing the skill/prompt?
replyNot the OP, but I use the same approach.
replyhttps://gist.github.com/drorm/7851e6ee84a263c8bad743b037fb7a...
I typically use github issues as the unit of work, so that's part of my instruction.
zen-mcp (now called pal-mcp I think) and then claude code can actually just pass things to gemini (or any other model)
replySometimes, depends on how big of a task. I just find 5.2 so slow.
replyI have Opus 4.5 do everything then review it with Gemini 3.
replyI don’t use OpenAI too much, but I follow a similar work flow. Use Opus for design/architecture work. Move it to Sonnet for implementation and build out. Then finally over to Gemini for review, QC and standards check. There is an absolute gain in using different models. Each has their own style and way of solving the problem just like a human team. It’s kind of awesome and crazy and a bit scary all at once.
replyHow do you orchestrate this workflow? Do you define different skills that all use different models, or something else?
reply