When one model writes the code and checks its own work, confidence can replace a real second opinion. Copying context into another assistant by hand works once, but loses history, makes the next review inconsistent, and gives no clear record of what changed after the feedback.
04 / AI developer infrastructure · Agent collaboration
Multi-Model AI Review and Debate Platform
Brand: CodeMoot
A developer tool that sends AI-written plans and code to a second model, then keeps the review, fix, and re-review in one tracked session instead of a throwaway prompt.
Treat review as a workflow with clear states: plan, review, fix, re-review, and pass or block. The second model is a reviewer with a defined job, not another general chat window.
A public MIT-licensed TypeScript repository and the published @codemoot/cli npm package, with review, debate, fix, plan, build, job, session, event, and policy workflows documented publicly.
CodeMoot is published and usable. The next test is whether teams catch more important issues or finish reviews faster than they do with one AI coding tool.
01
User and problem
Who needed this product, and why.
Developers who already use coding agents and want another model to review a plan, code change, or build without manually copying prompts, findings, and revisions between tools.
I built CodeMoot to give AI-generated code a structured second opinion. It connects Claude Code and Codex CLI through planning, review, debate, fixes, re-review, and build flows. Developers can see the session history, findings, background jobs, event stream, policy decisions, token use, and estimated cost instead of trusting an invisible exchange between agents.
02
Important decisions
Decision 01
Make review a loop, not a response
- Why it mattered
- A critique is useful only if findings can feed into a fix and the changed work can be reviewed again.
- What I did
- Create persistent review, fix, and re-review flows, plus debate history and planning workflows that retain the sequence of critique and revision.
- What it required
- The product needs session state, lifecycle commands, output limits, and recovery behavior rather than a thin wrapper around one model call.
- The result
- Developers can inspect how feedback changed the work and continue or stop the loop deliberately.
Decision 02
Give the agents distinct jobs
- Why it mattered
- Asking two models the same broad question can produce duplicated answers instead of useful disagreement.
- What I did
- Keep Claude Code as the primary working agent and use Codex CLI as a reviewer or critic, with structured prompts and explicit debate turns between them.
- What it required
- The workflow depends on both local tools and on the reviewer model applying its role consistently.
- The result
- Each model has a defined job: one develops the work and the other challenges it, reducing duplicated answers and making disagreements useful.
Decision 03
Make long reviews visible and controllable
- Why it mattered
- A review that runs for several steps needs visible progress, recovery when something fails, and a clear rule for findings serious enough to stop the work.
- What I did
- Use persistent sessions to keep history, background jobs so long reviews do not block the terminal, an event stream for live progress, token and cost totals, reusable presets, response limits, and policy gates that block critical findings or warn when revision is needed.
- What it required
- Background and watch modes require a worker process, and the MCP integration is still experimental rather than part of the stable product path.
- The result
- Developers can inspect what each agent did, resume interrupted work, control output and cost, and decide whether unresolved findings should block the next step.
03
What I built
What the product includes and how it works.
- Review, fix, and re-review workflows for files, prompts, and git changes
- Persistent multi-turn debates with status, history, export, and completion controls
- Flows that review a plan before implementation and run a build from start to finish
- Background jobs, saved sessions, live events, token totals, and estimated cost visibility
- Reusable review presets and policy rules that either block critical findings or warn about revisions
- A TypeScript monorepo with stable core and CLI packages plus an experimental MCP extension
How it works. Developers install @codemoot/cli and run workflows from the terminal. The TypeScript core stores session history, coordinates the working and reviewing agents, applies output and policy limits, and caches reusable context. The published CLI exposes those controls, while the MCP package remains an experimental extension for editor integration.
Visual
Product evidence
What the product looks like in practice.
04
What exists today
@codemoot/cli is available as a public npm package
Developers can install and use the released command-line product.The TypeScript source code is public under the MIT license
The main product and CLI are stable; the MCP integration is experimental.The public repository contains 624 automated tests across 47 files
The count comes from the repository test suite and can be checked by running it.The effect on review speed and code quality still needs to be measured
A controlled comparison with a single AI coding tool is the next product test.The reviewer runs through Codex CLI, which requires a ChatGPT subscription
CodeMoot adds no separate reviewer API charge when the developer already has that subscription.05
Reflection
What I learned, and what I would test next.
- Using more than one model helps only when each model has a distinct role and feedback can change the next step.
- Long-running agent work needs visible states, history, limits, and recovery paths just like any other background process.
- A policy gate turns a review finding into a decision someone must address, without assuming the reviewer model is always right.
Let’s discuss the product problem.