Multi-IA adversariale : du LLM Council (concept) a Claude Octopus (production)¶
Resume¶
Deux approches du meme probleme — contrer la sycophantie LLM par la confrontation multi-modeles :
LLM Council (Ole Lehmann, 1.3M vues) : skill Claude Code avec 5 advisors (Contrarian, First Principles, Expansionist, Outsider, Executor) + peer review anonymisee + chairman synthesis. Tout tourne sur le meme modele (Claude), diversite simulee par prompting.
Claude Octopus (nyldn, 2.3K stars GitHub, relaie par Korben) : plugin Claude Code qui orchestre 3 vrais modeles en parallele — Codex (implementation), Gemini (recherche), Claude Sonnet 4.6 (synthese). Consensus gate a 75% : bloque si les modeles ne convergent pas. 32 personas specialisees auto-activees, 48+ commandes, Dark Factory Mode (Markdown → code teste), review adversariale 4 agents (Codex logique, Gemini secu, Claude archi, Perplexity CVE) avec commentaires inline sur PR GitHub. Orchestrateur en Bash. 30-60 sec par requete, 3x tokens. Un seul dev.
Analyse critique¶
La progression est claire :
| LLM Council | Claude Octopus | |
|---|---|---|
| Diversite | Simulee (5 roles, 1 modele) | Structurelle (3 vrais modeles) |
| Consensus | Chairman subjectif | Gate 75% quantitative |
| Pipeline | One-shot | 4 phases (Double Diamond) + quality gates |
| Review | Peer review anonymisee | 4 agents adversariaux inline sur PR |
| CI/CD | Non | Reaction engine (auto-repond echecs CI) |
| Cout | 1x tokens | 3x tokens, 30-60s/requete |
| Maturite | Skill newsletter | Plugin 2.3K stars, open-source |
Le LLM Council est un concept marketing (lead magnet newsletter). Claude Octopus est une implementation reelle avec de la traction.
Ce qui est solide dans Octopus : - Vrais modeles differents = diversite structurelle (cf. paper sycophantique MIT : meme un bayesien ideal est vulnerable sur un seul modele) - Consensus gate quantitatif (75%) = pas de "chairman" subjectif - Reaction engine qui auto-repond aux echecs CI = boucle fermee - 5 providers gratuits (OAuth Codex/Gemini, GitHub Copilot, Qwen free tier, Ollama local)
Ce qui reste limite : - Un seul dev, "vibe code a donf" (Korben) — perennite ? - 30-60s par requete, 3x tokens — cout significatif pour du dev iteratif - 32 personas auto-detectees par intent — boite noire, risque de mauvais routage - Pas de metriques de qualite publiees (combien de bugs catches vs faux positifs ?)
Pertinence ProbatioVault¶
Impact faible mais comparaison instructive. Notre architecture fait la meme chose differemment :
| Claude Octopus | ProbatioVault | |
|---|---|---|
| Modeles | 3 en parallele (Codex, Gemini, Claude) | 2 strict (Claude produit, Codex review) — Art. II |
| Consensus | 75% agreement gate | Scoring 8 axes, GO >= 8 partout |
| Phases | 4 (Double Diamond) | 11 etapes constitutionnelles |
| Personas | 32 auto-detectees | 15 agents definis dans config/agents/ |
| Escalade | Sur desaccord | Sur NON_CONFORME ou RESERVE |
| Tracabilite | Logs dans ~/.claude-octopus/ | Jira + JSONL + Art. III |
| Review | 4 agents inline PR | Gate PMO ⅗/8 + Codex adversarial-review |
Notre approche est plus rigoureuse (constitutionnelle, tracable, scoring quantitatif, plafond 3 iterations). Octopus est plus agile (plug-and-play, multi-provider facile). Les deux resolvent le meme probleme (sycophantie / blind spots) par des architectures complementaires.
Le point le plus interessant d'Octopus pour nous : le reaction engine qui auto-repond aux echecs CI. Notre /forge fait la meme chose (boucle correction pipeline GitLab) mais de maniere moins integree.