Claude Code Autonome

Deux idées recâblent la façon dont les ingénieurs pilotent les agents IA : les boucles Ralph Wiggum et l'ingénierie basée sur les threads.

Ralph, c'est le comment-faire pour garder un agent qui tourne tout seul. Les threads, c'est le comment-faire pour mettre à l'échelle et mesurer cette autonomie. Assemblés ensemble, ils forment un système qui fonctionne pour construire des logiciels sans humain au volant.

Ce post, c'est l'assemblage.

Le modèle unifié

Voilà comment les pièces s'emboîtent :

L'ingénierie basée sur les threads fournit le squelette. Ton modèle mental, ce sont les threads : base, parallèle, chaîné, fusion, big, et longue durée. Chaque type de thread a son propre rôle.

Les boucles Ralph pilotent les L-threads. Le pattern de stop hook, la promesse de complétion, et le développement vérification-d'abord transforment les longues exécutions autonomes en quelque chose en quoi tu peux vraiment avoir confiance.

La vérification, c'est ce qui tient tout ça debout. Sans elle, les threads s'arrêtent trop tôt et les boucles tournent à l'infini.

Thread Types × Verification → Reliable Autonomous Work
     ↓
Ralph Loops = Implementation of L-Threads
     ↓
Result: Features shipping while you sleep

La stack de vérification

La règle de Boris Cherny tient en une phrase : donne toujours à Claude un moyen de vérifier son travail.

Elle apparaît à chaque couche du modèle unifié :

Une chose compte plus que les autres. Plus un thread tourne longtemps, plus sa vérification doit s'exécuter elle-même. Personne ne revoit un L-thread de 26 heures à la main. Le système doit se vérifier lui-même.

Construire la stack complète

Voilà une configuration qui colle tous les concepts ensemble :

Couche 1 : Spécification (l'épingle)

Chaque exécution autonome commence par une spec. Cette spec est ton épingle. Elle empêche l'agent d'inventer le problème.

## Feature: User Dashboard
 
### Scope
 
- Display user metrics
- Show recent activity
- Add export functionality
 
### Out of Scope
 
- Real-time updates (Phase 2)
- Mobile responsiveness (Phase 2)
 
### Acceptance Criteria
 
- [ ] Metrics load in under 2 seconds
- [ ] Activity shows last 30 days
- [ ] Export generates valid CSV

Pointe vers du code existant quand tu peux. Dis ce que l'agent ne doit pas faire. Définis clairement à quoi ressemble "done".

Couche 2 : Vérification pilotée par les tests

Écris les tests en premier. Ces tests sont la couche de vérification qui rend les L-threads fiables.

// For each acceptance criterion, create a test
tests/
  dashboard/
    metrics.test.ts      # Verifies metrics load time
    activity.test.ts     # Verifies activity display
    export.test.ts       # Verifies CSV generation

Les agents qui tournent exécutent les tests encore et encore. Une boucle ne peut pas se fermer tant que les tests ne sont pas au vert. Rien de flou. Pas de sorties anticipées.

Couche 3 : Le stop hook

Configure ton stop hook pour imposer la vérification :

// stop-hook.js
module.exports = async function (context) {
  // Run test suite
  const testResult = await runTests();
 
  if (testResult.failed > 0) {
    return {
      decision: "block",
      reason: `${testResult.failed} tests failing. Continue work.`,
    };
  }
 
  // Check for completion promise
  if (!context.output.includes("complete")) {
    return {
      decision: "block",
      reason: "Completion promise not found. Verify all work is done.",
    };
  }
 
  return { decision: "allow" };
};

Le stop hook, c'est le videur. Il se fiche de ce que Claude pense. Il vérifie juste si les tests passent.

Couche 4 : Sélection du thread

Choisis maintenant le type de thread qui correspond au travail :

Petite fonctionnalité, un fichier : Thread de base. Prompt, l'agent travaille, revue.

Cinq fonctionnalités indépendantes : P-threads. Lance cinq terminaux, assigne une fonctionnalité à chacun.

Migration de base de données en trois phases : C-thread. Vérifie après chaque phase avant de continuer.

Décision d'architecture critique : F-thread. Obtiens l'avis de trois agents, compare les résultats.

Build de fonctionnalité overnight : L-thread avec boucle Ralph. Lance-le avant d'aller dormir.

Refactor multi-fichiers avec sous-tâches : B-thread. L'orchestrateur lance des workers pour chaque fichier.

Couche 5 : État de checkpoint

Garde l'état en dehors de l'agent. C'est particulièrement important pour les L-threads :

## Progress: User Dashboard
 
### Completed
 
- [x] Set up test infrastructure
- [x] Implement metrics API endpoint
- [x] Create metrics display component
 
### In Progress
 
- [ ] Implement activity feed
 
### Remaining
 
- [ ] Add export functionality
- [ ] Performance optimization

L'agent réécrit ce fichier pendant qu'il travaille. Si la fenêtre de contexte se remplit et que l'agent redémarre, il lit le fichier de progression et reprend là où il s'est arrêté.

Vérification de l'UI : la pièce manquante

Les tests peuvent passer pendant que l'écran est cassé.

Tout thread qui touche l'UI a besoin d'une vérification par screenshot en plus de la suite de tests :

Workflow extension for UI work:

1. Complete implementation
2. Take screenshots of affected components
3. Review each screenshot for visual issues
4. Rename verified screenshots with "verified_" prefix
5. Do NOT output completion promise yet
6. Run one more loop to confirm all screenshots verified
7. Only then output "complete"

C'est ce qui force la revue visuelle. Claude n'a aucun moyen de sauter la vérification des screenshots et d'appeler le travail terminé.

Mise à l'échelle avec Loom

L'échelon suivant, c'est l'orchestration style Loom.

Loom est un environnement construit pour les agents plutôt que pour les humains. Il câble des boucles Ralph ensemble en systèmes réactifs.

Niveau 1 : Boucle Ralph unique (L-thread) Niveau 2 : Plusieurs boucles Ralph en parallèle (P-threads de L-threads) Niveau 3 : Chaînes orchestrées de boucles (B-threads contenant des L-threads) Niveau 4 : Systèmes de produits autonomes (agents qui livrent, observent, et itèrent)

Au niveau 4, les agents :

• Livrent derrière des feature flags
• Déploient sans revue de code
• Observent les analytics
• Décident si les changements ont fonctionné
• Itèrent automatiquement

C'est le point final du Z-thread. Zéro input humain. Autonomie totale.

L'économie des boucles autonomes

Garder un agent qui tourne coûte environ 10,42 $ USD par heure sur Sonnet.

Ça remet les maths à plat.

Le coût n'est pas la limite. La limite, c'est combien de travail fiable tu peux définir.

Les équipes qui maîtrisent bien les boucles vérification-d'abord vont livrer à un rythme différent de celles qui ne le font pas. Pas légèrement différent. Un rythme complètement différent.

Patterns d'intégration courants

Pattern 1 : Planification + L-Thread

1. C-thread pour la planification (tu vérifies le plan)
2. Contexte frais
3. L-thread pour l'implémentation (boucle Ralph)
4. Revue finale

Pourquoi ça fonctionne : Planification et implémentation vivent dans des contextes séparés. Tu concentres ton attention sur le plan. Le build tourne tout seul.

Pattern 2 : Sprint de fonctionnalités en P-Thread

1. Écrire des specs pour plusieurs fonctionnalités
2. Lancer des P-threads (un par fonctionnalité)
3. Chaque P-thread tourne comme un L-thread en interne
4. Revue des fonctionnalités terminées au fur et à mesure

Pourquoi ça fonctionne : Le parallélisme est au niveau des fonctionnalités. L'autonomie est au niveau de l'implémentation.

Pattern 3 : Architecture en F-Thread

1. Définir la question d'architecture
2. Lancer un F-thread (3-4 agents)
3. Chaque agent propose une solution
4. Comparer les résultats, choisir le meilleur
5. Implémenter la solution choisie avec un L-thread

Pourquoi ça fonctionne : Tu obtiens plusieurs perspectives sur les décisions qui font mal à rater. Une fois choisie, le build tourne de façon autonome.

Pattern 4 : Orchestration en B-Thread

1. L'agent principal reçoit une grande tâche
2. La décompose en sous-tâches
3. Lance des agents workers (chacun tourne un mini L-thread)
4. Agrège les résultats
5. L'agent principal vérifie et commit

Pourquoi ça fonctionne : Le travail se divise proprement. Chaque worker garde une focale étroite. L'agent principal tient le thread ensemble.

Modes d'échec et corrections

Les threads se terminent trop tôt

Cause : Vérification faible Correction : Ajoute plus de tests. Rend les critères de complétion objectifs. Utilise la vérification par screenshot pour l'UI.

Les L-Threads tournent indéfiniment

Cause : Tâche impossible ou promesse de complétion manquante Correction : Définis des itérations maximales. Ajoute des critères de complétion explicites. Assure-toi que l'agent sait quand émettre la promesse.

Les P-Threads créent des conflits

Cause : Des agents modifient les mêmes fichiers Correction : Isole par fonctionnalité ou fichier. Utilise des git worktrees. Trace des lignes dures entre les travaux parallèles.

Les B-Threads perdent leur cohérence

Cause : Les sous-agents dérivent de l'objectif principal Correction : De meilleures specs. Plus de checkpoints. L'orchestrateur revoit le résultat des sous-agents.

La vérification passe mais le travail est faux

Cause : Les tests ne couvrent pas la vraie exigence Correction : Des critères d'acceptation plus stricts. Vérification par screenshot sur l'UI. Revois les premières exécutions à la main.

Le chemin d'implémentation

Commence là où tu es. Construis vers l'autonomie totale une semaine à la fois.

Semaine 1 : Fais tourner des threads de base fiables. Vérifie chaque résultat manuellement.

Semaine 2 : Ajoute des P-threads. Fais tourner deux agents en parallèle. Gère le changement de contexte.

Semaine 3 : Implémente la vérification pilotée par les tests. Écris les tests avant l'implémentation.

Semaine 4 : Essaie ton premier L-thread. Utilise le stop hook. Définis un compteur d'itérations max. Regarde-le tourner.

Semaine 5 : Mets les L-threads à l'échelle. Fais-les tourner la nuit. Fais confiance à la vérification.

Semaine 6 : Ajoute des B-threads. Laisse ton agent lancer des sous-agents. Orchestre des changements multi-fichiers.

Semaine 7 : Essaie les F-threads. Obtiens plusieurs avis sur les décisions d'architecture.

Semaine 8 : Combine les patterns. P-threads de L-threads. B-threads contenant des F-threads.

Mesure chaque semaine. Combien de threads. Combien de temps ils ont tourné. Combien de checkpoints le travail a nécessités.

La destination

Le génie logiciel se dirige vers des boucles autonomes mises à l'échelle par la pensée basée sur les threads.

• Plus de threads : Le parallélisme à chaque niveau
• Threads plus longs : Des heures et des jours, pas des minutes
• Threads plus épais : Des agents qui lancent des agents qui lancent des agents
• Moins de checkpoints : La vérification remplace la revue

Les développeurs qui travaillent ainsi ne font pas juste "utiliser l'IA". Ils gèrent des usines logicielles autonomes.

Ralph te donne la boucle. Les threads te donnent la forme. La vérification te donne la confiance.

Assemble les trois et tu obtiens des systèmes qui livrent pendant que tu dors.

Prochaines étapes

• Commence par les boucles Ralph Wiggum pour les fondations des L-threads
• Apprends l'ingénierie basée sur les threads pour le modèle mental
• Étudie les boucles de feedback pour les patterns de vérification
• Explore les workflows async pour la gestion des P-threads
• Construis des agents personnalisés pour l'orchestration B-thread

La boucle est simple. La vérification est ce qui compte. Les threads sont le multiplicateur.

Commence à construire maintenant.