Boucle GAN

Le premier brouillon de ton IA est du slop confiant. À chaque fois.

Pas parce que le modèle est mauvais. Parce qu'il n'a personne pour lui résister.

Ajoute un second agent dont l'unique travail est de démolir le premier, et soudain la qualité converge en 2 passes. Ce pattern s'appelle la Boucle GAN. Voici le guide d'implémentation complet.

C'est quoi une Boucle GAN ?

GAN signifie Generative Adversarial Network. En machine learning traditionnel, deux réseaux de neurones s'affrontent : un générateur crée de fausses images, un discriminateur essaie de détecter les faux. Ils s'entraînent mutuellement jusqu'à ce que le générateur devienne assez bon pour tromper le discriminateur.

On applique la même idée aux agents IA. Pas de réseaux de neurones requis. Juste deux instances Claude avec des jobs différents et une boucle qui tourne jusqu'à ce que la sortie atteigne un seuil de qualité.

Le générateur crée. L'évaluateur juge. Le générateur s'améliore. Répète jusqu'à ce que le score se stabilise.

Le problème qu'elle résout

Demande à une seule IA d'écrire quelque chose. Elle produira une sortie qui a l'air raisonnable. Structurée. Confiante.

Puis regarde de plus près. L'accroche est générique. Les chiffres sont vagues. Le CTA pourrait s'appliquer à n'importe quoi. L'IA n'avait pas de pression externe, donc elle a optimisé pour "paraît bien à la première lecture" plutôt que "performe vraiment."

L'IA ne sait pas ce qu'elle ne sait pas. Elle ne peut pas évaluer ses propres angles morts.

Un second agent, lisant la sortie à froid avec une rubrique en main, repèrera tout ce que le générateur a raté. Et il donnera un feedback spécifique et actionnable parce que c'est son seul travail.

Les deux agents

Chaque Boucle GAN a exactement deux rôles. Ils ne doivent jamais être le même agent.

Le Générateur a le contexte complet, des outils, et des compétences créatives. Il produit la meilleure sortie possible selon le brief. Il ne voit PAS la rubrique d'évaluation à l'avance. Lui donner la rubrique lui ferait optimiser pour la rubrique plutôt que pour la vraie qualité, ce qui annule tout l'intérêt.

L'Évaluateur a la rubrique et la sortie. C'est tout. Pas de mémoire du processus de génération. Pas d'investissement émotionnel dans le brouillon. Il lit à froid, note chaque dimension avec un raisonnement, et retourne un verdict structuré : accept, refine, ou reject. Quand il rejette, il fournit des citations exactes de la sortie, explique le problème, et donne une réécriture concrète.

Cette séparation est tout. Le générateur est optimiste par nature. L'évaluateur est adversarial par design. Aucun des deux rôles ne fonctionne bien si le même agent joue les deux.

Les définitions d'agents

Voici les deux fichiers d'agents dont tu as besoin. Sauvegarde-les dans .claude/agents/ dans ton projet.

L'agent Générateur

---
name: gan-generator
description: "GAN Harness — Generator agent. Creates output according to the brief, reads evaluator feedback, and iterates until quality threshold is met."
tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
model: claude-sonnet-4-6
---

You are the Generator in a GAN-style multi-agent harness.

## Your Role

You are the Creator. You build the output according to the spec.
After each iteration, the Evaluator will score your work.
You then read the feedback and improve.

## Key Rules

1. Read the spec first — always start by reading the brief or spec file
2. Read feedback — before each iteration (except the first), read the latest feedback file
3. Address every issue — feedback items are not suggestions, fix them all
4. Do not self-evaluate — your job is to create, not to judge
5. Commit between iterations — so the Evaluator sees clean diffs

## Workflow

### First Iteration
1. Read the brief / spec
2. Produce the output (post, code, design, document — whatever is specified)
3. Write generator-state.md: what you built, known issues, open questions

### Subsequent Iterations
1. Read feedback/feedback-NNN.md (latest)
2. List every issue the Evaluator raised
3. Fix by priority: critical issues first, then major, then minor
4. Update generator-state.md

## Generator State File

Write to generator-state.md after each iteration:

# Generator State — Iteration NNN

## What Was Built
- [output 1]
- [output 2]

## What Changed This Iteration
- Fixed: [issue from feedback]
- Improved: [aspect that scored low]

## Known Issues
- [anything you could not fix]

L'agent Évaluateur

---
name: gan-evaluator
description: "GAN Harness — Evaluator agent. Scores output against rubric, provides actionable feedback to the Generator. Be ruthlessly strict."
tools: ["Read", "Write", "Grep", "Glob"]
model: claude-sonnet-4-6
---

You are the Evaluator in a GAN-style multi-agent harness.

## Your Role

You are the Critic. You score the Generator's output against a strict rubric
and provide detailed, actionable feedback.

## Core Principle: Be Ruthlessly Strict

> You are NOT here to be encouraging. You are here to find every flaw.
> A passing score must mean the output is genuinely good — not "good for an AI."

Your natural tendency is to be generous. Fight it:
- Do NOT say "overall good effort" — this is cope
- Do NOT talk yourself out of issues you found ("it's minor, probably fine")
- Do NOT give points for effort or potential
- DO penalize heavily for vague claims, AI slop patterns, and missing specifics
- DO compare against what a professional human would ship

## Evaluation Workflow

### Step 1: Read the Rubric
Read the criteria file for this task type.
Read the spec / brief for what was asked.
Read generator-state.md for what was built.

### Step 2: Score

Score each criterion on a 1-10 scale using the rubric file.

Calibration:
- 1-3: Broken or embarrassing
- 4-5: Functional but clearly AI-generated
- 6: Decent but unremarkable
- 7: Good — solid work
- 8: Very good — professional quality
- 9: Excellent — polished, senior quality
- 10: Exceptional — ships as-is

### Step 3: Write Feedback

Write to feedback/feedback-NNN.md:

# Evaluation — Iteration NNN

## Scores

| Criterion | Score | Weight | Weighted |
|-----------|-------|--------|----------|
| [criterion] | X/10 | 0.X | X.X |
| TOTAL | | | X.X/10 |

## Verdict: PASS / FAIL (threshold: 7.0)

## Critical Issues (must fix)
1. [Issue]: [exact quote] → [how to fix]

## Major Issues (should fix)
1. [Issue]: [exact quote] → [how to fix]

## Minor Issues (nice to fix)
1. [Issue]: [exact quote] → [how to fix]

## What Improved Since Last Iteration
- [improvement]

## Feedback Quality Rules

1. Every issue must have a concrete "how to fix" — not just "this is bad"
2. Reference specific elements — not "the hook needs work" but quote the exact text
3. Quantify when possible — "3 out of 5 items have no concrete numbers"
4. Acknowledge genuine improvements — calibrates the loop

La configuration de la boucle

Sauvegarde ça en tant que gan.json dans ton projet (ou dans ton dossier .claude/) :

{
  "default_threshold": 7.0,
  "max_iterations": 3,
  "escalation": "accept-with-notes",

  "profiles": {
    "my-task": {
      "generator": {
        "agent": "gan-generator",
        "skills": ["relevant-skill-here"]
      },
      "evaluator": {
        "agent": "gan-evaluator",
        "criteria_file": "evaluator/my-task-criteria.md"
      },
      "scoring": {
        "dimensions": [
          {"name": "hook_power",     "weight": 0.25},
          {"name": "value_density",  "weight": 0.25},
          {"name": "brand_voice",    "weight": 0.20},
          {"name": "clarity",        "weight": 0.20},
          {"name": "cta",            "weight": 0.10}
        ],
        "threshold": 7.0,
        "max_iterations": 3
      },
      "sprint_contract": [
        "Each item here is a binary gate check that must pass before shipping",
        "Example: hook lands before 210-char cutoff",
        "Example: no forbidden words",
        "Example: all claims verified against source of truth"
      ]
    }
  }
}

Le sprint_contract est une liste de règles binaires passe/échoue. L'Évaluateur les vérifie en premier, avant même de calculer le score pondéré. Un seul gate raté signifie reject, peu importe la qualité du reste.

À quoi ressemble une vraie rubrique

L'Évaluateur n'est aussi bon que sa rubrique. Des critères vagues produisent des scores vagues.

Une vraie rubrique définit chaque dimension avec trois exemples d'ancrage : exceptionnel (9-10), acceptable (6-7), et à rejeter (1-4). Chaque ancrage inclut un exemple ET une raison, pour que l'Évaluateur puisse calibrer de façon cohérente à travers les itérations.

Voici la dimension Hook Power de la rubrique de post LinkedIn :

### Hook Power (weight: 0.20)

What you're measuring: Would this stop a busy professional from scrolling?
Must land before the 210-character cutoff.

Score 9-10 (Exceptional):
  "I was quoted $15,000 for an MVP. I built it for $197 in a weekend."
  Why: Specific dollar amounts, unexpected contrast, lands in 67 characters.
  Personal stake. Reader wants to know how.

Score 6-7 (Acceptable):
  "Building a SaaS doesn't have to take months. Here's a faster way."
  Why: Clear promise but no specificity, no numbers, no personal stake.

Score 1-4 (Reject):
  "In today's rapidly evolving tech landscape, AI is changing everything."
  Why: Generic, forbidden phrase, says nothing unique. Reader scrolls past.

Les exemples d'ancrage sont la partie la plus importante. Sans eux, deux évaluations de la même sortie lui donneront des scores différents à chaque run. Avec eux, les scores restent cohérents à travers les itérations, ce qui fait converger la boucle.

Un vrai exemple : boucle par boucle

Voici un post LinkedIn qui passe par 3 rounds.

Brief : Écris un post LinkedIn sur la façon dont Build This Now utilise 18 agents IA pour construire des fonctionnalités SaaS.

Boucle 1 — Le Générateur tourne à froid :

In today's fast-paced world of software development, AI is completely
changing how we build products. Our innovative platform leverages
cutting-edge AI agents to help you build your SaaS faster and
more efficiently than ever before.

#AI #SaaS #startup #tech #innovation

L'Évaluateur score la Boucle 1 :

DIMENSION SCORES:
- hook_power:           2/10 — forbidden phrase opener, zero specificity
- value_density:        2/10 — no concrete information in any sentence
- brand_alignment:      2/10 — "innovative", "cutting-edge" are banned words
- platform_optimization: 3/10 — 5 hashtags OK but no character discipline
- cta_effectiveness:    1/10 — no CTA present

OVERALL: 2.1/10

GATE CHECKS:
- No forbidden words: FAIL ("cutting-edge", "innovative", "fast-paced world")
- Single clear CTA: FAIL

VERDICT: reject

CRITICAL ISSUES:
1. Hook: "In today's fast-paced world" → forbidden phrase, replace with
   a specific personal story or data point. Example:
   "I rebuilt auth and payments 3 times in 2 years. Same 3-week slog. Every time."

Boucle 2 — Le Générateur incorpore le feedback :

I spent 3 weekends rebuilding the same auth and payments system.

With Build This Now, I describe the feature. 9 AI agents take over:
database architect designs the tables, backend developer writes the
API, designer builds the UI, tester catches the bugs.

One feature, 10-60 minutes. No more rebuilt boilerplate.

What are you still building by hand that you shouldn't be?

#BuildThisNow #indiehacker #buildinpublic #solofounder #SaaS

L'Évaluateur score la Boucle 2 :

DIMENSION SCORES:
- hook_power:           7/10 — personal, relatable, but "I spent 3 weekends"
                               is passive. "3 weekends" needs more punch.
- value_density:        8/10 — concrete agent names, real time range
- brand_alignment:      8/10 — on-brand, hashtag count correct
- platform_optimization: 8/10 — good length, hashtags at end
- cta_effectiveness:    8/10 — question CTA invites comment

OVERALL: 7.7/10

GATE CHECKS: all pass

VERDICT: refine

MAJOR ISSUES:
1. Hook: "I spent 3 weekends" is weak. The data point "3 weekends" is good
   but "spent" is passive. Rewrite opener to front-load the pain with
   a harder verb. Example:
   "I rebuilt auth and payments 3 times in 2 years. Same 3-week slog. Every time."

Boucle 3 — Un correctif ciblé :

I rebuilt auth and payments 3 times in 2 years. Same 3-week slog. Every time.

Then I described the feature in plain English and watched 9 AI agents
build it in 45 minutes: database, API, UI, tests. All wired. All clean.

Build This Now ships what used to take a week, in an afternoon.

What are you still rebuilding by hand?

#BuildThisNow #indiehacker #buildinpublic #solofounder #SaaS

L'Évaluateur score la Boucle 3 :

DIMENSION SCORES:
- hook_power:           9/10 — "3 times in 2 years" is specific and damning
- value_density:        9/10 — every sentence adds new information
- brand_alignment:      9/10 — BTN voice, correct claims
- platform_optimization: 9/10 — clean format, right length
- cta_effectiveness:    8/10 — question CTA invites comment

OVERALL: 8.9/10

GATE CHECKS: all pass

VERDICT: accept

Trois boucles. 2,1 à 8,9.

Comment le lancer

La façon la plus simple de lancer la boucle manuellement avec claude -p :

# Step 1: Generator runs first
claude -p --agent gan-generator \
  "Brief: write a LinkedIn post about [topic]. Save output to output/draft.md.
   Write generator-state.md with what you produced."

# Step 2: Evaluator scores it
claude -p --agent gan-evaluator \
  "Read output/draft.md and evaluator/linkedin-criteria.md.
   Score against the rubric. Write feedback to feedback/feedback-001.md.
   Be ruthlessly strict."

# Step 3: Generator iterates with feedback
claude -p --agent gan-generator \
  "Iteration 2. Read feedback/feedback-001.md FIRST.
   Address every issue. Update output/draft.md.
   Update generator-state.md."

# Repeat until VERDICT: accept

Tu peux aussi le lancer entièrement automatisé avec l'agent loop-operator de everything-claude-code :

# Set env vars to configure the loop
GAN_MAX_ITERATIONS=5 GAN_PASS_THRESHOLD=7.5 \
  claude -p --agent loop-operator \
  "Run a GAN loop using gan-generator and gan-evaluator.
   Brief: [your task]. Criteria file: evaluator/my-criteria.md.
   Stop when score >= 7.5 or after 5 iterations."

La règle critique : pas de mémoire entre les passes

L'Évaluateur lit la rubrique à neuf à chaque passe. Ce n'est pas optionnel.

Un évaluateur avec la mémoire des scores précédents va les gonfler avec le temps. Il a noté quelque chose 6 au dernier round, alors il le note 7 ce round pour montrer "des progrès", même si l'amélioration réelle était minimale. Rubrique fraîche, regard neuf, à chaque fois.

La configuration de la boucle enforce ça :

{
  "max_iterations": 3,
  "escalation": "accept-with-notes"
}

Quand max_iterations est atteint sans passer le seuil, le système livre la meilleure version avec des notes plutôt que de bloquer indéfiniment. La sortie n'est peut-être pas parfaite, mais c'est la meilleure que le générateur pouvait produire en 3 rounds, et tu as un enregistrement de ce que l'évaluateur a signalé.

Bonus : utilise Codex comme ton Évaluateur

La version la plus puissante de cette boucle utilise deux systèmes IA différents. Claude comme générateur. OpenAI Codex comme évaluateur.

Pourquoi ça compte : l'évaluateur cherche des failles dans la sortie de Claude. Mais Claude et Codex ont été entraînés sur des données différentes, avec des objectifs différents, des architectures différentes, et des ensembles de faiblesses connues différents. Claude évaluant Claude rate les angles morts qu'ils partagent. Codex évaluant Claude repère une classe différente de problèmes entièrement.

Deux labs IA, se battant pour ta sortie.

Si tu as le codex-plugin-cc installé dans Claude Code :

# Install the plugin
/plugin marketplace add openai/codex-plugin-cc

# Use it in your loop
/codex:adversarial-review output/draft.md

Ou invoque Codex comme agent évaluateur directement dans ta configuration de boucle :

{
  "profiles": {
    "adversarial": {
      "generator": {
        "agent": "gan-generator",
        "skills": ["linkedin-post"]
      },
      "evaluator": {
        "agent": "codex",
        "command": "/codex:adversarial-review",
        "criteria_file": "evaluator/linkedin-criteria.md"
      }
    }
  }
}

L'évaluateur Codex lance /codex:adversarial-review sur la sortie du générateur et passe le fichier de critères comme contexte. Il challengera les décisions de design, signalera les hypothèses que Claude ne remet pas en question, et notera depuis une perspective complètement différente.

L'évaluation cross-modèle n'est pas un gadget. Quand le générateur et l'évaluateur partagent la même distribution d'entraînement, ils partagent les mêmes angles morts. Une boucle cross-modèle ferme ce gap.

Ce que tu obtiens après 3 rounds

Une sortie qui converge. Pas parfaite, mais de façon fiable au-dessus du seuil.

Le système livre du contenu qui aurait nécessité une heure de revue manuelle en 3 boucles automatisées. Tu arrêtes de lire chaque ligne. Tu arrêtes de douter des accroches. Tu lis le résumé de l'évaluateur et tu vérifies spot-check la sortie finale.

La rubrique fait le travail. Tu définis ce que "bien" signifie une fois. Chaque sortie est tenue à ce même standard, à chaque fois, sans dérive et sans ego.

L'ensemble complet de fichiers pour une Boucle GAN fonctionnelle :

.claude/
  agents/
    gan-generator.md      ← generator agent definition
    gan-evaluator.md      ← evaluator agent definition
  subsystems/
    content/
      gan.json            ← loop config with profiles and thresholds
      evaluator/
        linkedin-criteria.md    ← rubric for LinkedIn posts
        carousel-text-criteria.md
        x-thread-criteria.md
        reddit-criteria.md
output/
  draft.md                ← generator output
  generator-state.md      ← what was built each iteration
  feedback/
    feedback-001.md       ← evaluator feedback per round
    feedback-002.md
    feedback-003.md

Copie les définitions d'agents ci-dessus, écris un fichier de rubrique pour ton type de tâche, fixe un seuil, et lance.

Posté par @speedy_devv

Boucle GAN

On this page