Multi-Agent Code Review with Cross-Lineage LLMs and a 'Coxswain' for Enhanced Bug Detection and Recursive Improvement

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: advanced
Categories: Quality Control, Context & Memory, Debugging, Multi-Agent
Original source: r/ClaudeAI post/comment

What problem this solves

Overcoming the 'over-agreeableness' and correlated errors of single or same-lineage AI agents in code review and development, leading to more robust bug detection and a self-improving process.

Summary

A multi-agent workflow (two coding agents from different LLM lineages, one 'coxswain' agent, and a human) for code development and review. It incorporates a 'Recursive Directed Improvement' loop where identified mistakes are turned into process rules for the agents, fostering continuous improvement and reducing recurring errors.

Why it is useful

This workflow is valuable because it directly addresses a critical limitation of single LLM agents: their tendency to be over-agreeable and prone to correlated errors. By proposing a structured multi-agent approach with agents from different lineages and an independent 'coxswain' role, it significantly enhances bug detection and the robustness of AI-assisted development. The inclusion of a 'Recursive Directed Improvement' loop provides a clear methodology for continuous learning and process refinement, making the system more reliable over time. The open-source musubi project offers a concrete, adaptable implementation for users seeking more dependable AI assistance in coding.

Workflow

1. Set up two AI agents (e.g., Claude Code and Codex) from different training lineages to act as peers.
2. Assign each peer agent a specific slice of the codebase or task.
3. Instruct peer agents to back their claims with evidence and review each other's work.
4. Introduce an optional (but recommended) third 'coxswain' agent role.
5. The coxswain agent's role is to hold the overall strategy and standards, observe the agreement between the two peer agents, and independently test assumptions (e.g., external API status).
6. A human always approves every merge, ensuring final oversight.
7. After each development/review cycle, conduct a short retrospective to identify what went wrong or what was missed.
8. Turn identified mistakes or failures into new rules or process steps that the agents must follow in subsequent runs (Recursive Directed Improvement).
9. Repeat the cycle, allowing the setup to absorb new standards and improve over time.

Tools / artifacts

• Claude Code (or similar LLM)
• Codex (or similar LLM from a different lineage)
• GitHub repository (musubi)
• Protocol documentation
• Metrics script (for analyzing agent transcripts)
• Codebase under development/review

Validation signals

• "It worked. It caught real bugs a single agent had waved through."
• Specific example: 'The pair agreed, confidently, that an external API was broken. The third role did not buy it and tested the thing. API was fine. The credentials had expired.'
• "Across the four projects, about a third of the peer reviews flagged something the other agent had missed, call it a few hundred catches."
• Mention of 'a handful of honest escapes, each written up, where both agents waved a bug through and CI or I caught it after the merge,' indicating transparent reporting and further learning points.
• Experiment run across four real projects (three codebases, one non-code).
• Open-source project 'musubi' provides a concrete implementation, protocol documentation, and a metrics script for re-running logs.

Cautions

• The workflow explicitly includes a human in the loop for every merge approval, which is a critical safety measure against AI-generated errors or unsafe code.

Limitations

• The 'blind spot thesis is still just a theory' and lacks a controlled trial comparing same-lineage agents to different-lineage agents.
• The 'rough numbers' are not a controlled scientific result and are based on a limited set of projects.
• Requires setting up and managing multiple LLM agents, potentially from different providers, which adds complexity.
• The 'coxswain' role, while valuable, adds another layer of orchestration and prompt engineering.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

---

This post was generated automatically from the workflow library database.