L'ingénierie par threads

Comment tu sais vraiment que tu progresses en développement assisté par IA ?

Pas "j'ai l'impression d'être productif". En comptant. En mesurant. En montrant, avec des chiffres, que cette semaine est meilleure que la précédente.

L'ingénierie par threads est le cadre qui rend ça possible. Chaque morceau de travail assisté par IA devient une unité discrète appelée un thread. Une fois que le travail apparaît sous forme de threads, tu peux les optimiser.

Un thread, c'est une unité de travail de développement étalée dans le temps, pilotée par toi plus un agent.

Deux points dans chaque thread nécessitent un humain :

1. Le début. Tu fais une invite ou tu planifies.
2. La fin. Tu révises ou tu valides.

Et le milieu ? L'agent s'en occupe via des appels d'outils.

C'est le thread de base. À chaque fois que tu lances Claude Code et que tu envoies une invite, tu as démarré un thread. L'agent exécute des appels d'outils (lit des fichiers, écrit du code, lance des commandes), et quand il s'arrête, tu vérifies le résultat.

Idée simple. Grosses conséquences.

L'insight central : les appels d'outils correspondent à peu près à l'impact (en supposant que l'invite valait la peine d'être lancée).

Avant 2023, les appels d'outils, c'était toi. Tu modifiais le code. Tu ouvrais les fichiers. Tu lançais les commandes. Toute la chaîne était manuelle.

Aujourd'hui tu arrives au début (l'invite) et à la fin (la révision). Le milieu se gère tout seul.

Celui qui lance plus d'appels d'outils utiles gagne sur celui qui en lance moins. C'est le nouveau tableau de bord.

Une fois que le thread de base a du sens, le scaling suit naturellement. Six patterns couvrent presque tous les workflows assistés par IA.

1. Thread de base

La fondation. Une invite, du travail par l'agent, une révision.

Tous les patterns suivants se construisent là-dessus. Un thread de base bancal veut dire que rien au-dessus ne fonctionnera non plus.

Pour quoi l'utiliser. Tâches simples, corrections rapides, modifications sur un seul fichier.

2. P-Threads (Exécution parallèle)

Plusieurs threads qui tournent en même temps.

Boris Cherny, qui a créé Claude Code, garde cinq instances Claude Code ouvertes dans son terminal, numérotées de 1 à 5. En plus, il en lance 5 à 10 autres dans l'interface web de Claude Code.

Ça fait 10 à 15 threads parallèles. Un agent ship l'auth, un autre bosse sur les endpoints API, un autre écrit des tests. Tu fais une invite, tu changes d'onglet, tu fais une invite, tu changes d'onglet, tu fais une invite. Ensuite tu reviens vérifier.

Pour quoi l'utiliser. Tâches indépendantes, revues de code, branches de fonctionnalités, recherche.

Comment améliorer. Ouvre plus de fenêtres de terminal. Pousse les agents en arrière-plan vers l'interface web de Claude Code. Fork des terminaux avec des outils custom.

3. C-Threads (Charges de travail enchaînées)

Travail multi-phases avec des checkpoints humains entre les phases.

Parfois le travail ne rentre pas dans une seule fenêtre de contexte. Ou les enjeux sont assez élevés pour que tu veuilles regarder chaque étape avant que la suivante commence.

Les C-threads divisent le travail en phases :

• Phase 1 : Migration de base de données
• Phase 2 : Mises à jour de l'API
• Phase 3 : Changements frontend

Tu révises entre les phases. Tout ce qui est cassé se détecte tôt, avant de se transformer en gros rollback.

Pour quoi l'utiliser. Déploiements en production, gros refactors, migrations sensibles, workflows multi-étapes.

Compromis. Ton attention. Les C-threads coûtent plus de temps humain. Lance-les quand le risque le justifie.

L'outil ask user question dans Claude Code supporte les C-threads nativement. Un agent peut se mettre en pause au milieu d'un workflow et te poser une question avant de passer à la phase suivante.

4. F-Threads (Fusion)

Une invite, plusieurs agents, puis tu fusionnes les meilleurs résultats.

Pense "le meilleur parmi N" sur des workflows entiers. Lance la même invite sur quatre agents. Regarde les quatre sorties. Choisis le gagnant. Ou assemble les parties les plus solides de plusieurs sorties en quelque chose de mieux que chacune d'elles.

Pourquoi ça marche. Plus de tentatives augmentent les chances de succès. Un agent peut rater là où un autre excelle. Quatre angles valent mieux qu'un.

Pour quoi l'utiliser. Prototypage rapide, questions de recherche, décisions d'architecture, revues de code où la confiance compte.

L'avenir du prototypage. Les F-threads vont dominer le prototypage rapide. Lance plusieurs agents, donne-leur le même problème, fusionne leurs sorties. Plus de compute achète plus de confiance.

5. B-Threads (Big/Meta)

Un thread qui contient d'autres threads à l'intérieur.

C'est là que ça devient méta. Des invites lancent d'autres invites. Des sous-agents font tourner d'autres sous-agents. Un agent orchestrateur lance un planificateur, puis un constructeur, puis un réviseur.

De ton poste d'ingénieur, tu fais quand même une invite au début et tu révises à la fin. En dessous, plusieurs threads se gèrent eux-mêmes.

L'exemple le plus clair. Les sous-agents. Dis à Claude Code "utilise des sous-agents pour gérer ces trois tâches" et il spawn trois threads à l'intérieur de lui-même. Une invite de ta part, trois threads qui tournent.

Pour quoi l'utiliser. Changements multi-fichiers complexes, workflows d'équipes d'agents, builds orchestrés.

Le pattern. Les agents écrivent des invites pour toi. L'orchestrateur écrit des invites pour les agents workers. La sortie monte d'un facteur 10 sans que l'effort monte d'un facteur 10.

6. L-Threads (Longue durée)

Autonomie prolongée sans humain dans la boucle.

Le thread de base, poussé à l'extrême. Pas 10 appels d'outils. Essaie 100. Pas 5 minutes. Essaie 5 heures. Boris a fait tourner des threads pendant plus de 26 heures.

Les L-threads nécessitent :

• Des invites solides (bonne planification = bonne invite)
• Une vérification fiable (pour que l'agent sache quand il a terminé)
• Un état checkpointé (pour que le travail survive aux limites de contexte)

Le lien avec Ralph. La technique Ralph Wiggum est construite autour des L-threads. Un stop hook garde l'agent en boucle jusqu'à ce que le travail soit vraiment terminé. Pas de sortie prématurée. Pas de prise en main.

Pour quoi l'utiliser. Builds de fonctionnalités de nuit, gros codebases, épuisement du backlog.

Un autre type de thread pointe vers la direction que prend le développement.

Z-threads. Threads zéro-contact. Confiance totale dans tes agents. Pas de nœud de révision du tout.

Ce n'est pas du vibe coding. C'est de l'ingénierie agentique avec tellement de vérification et tellement de garde-fous que revoir la sortie devient vraiment facultatif.

L'agent ship en production. Surveille les analytics. Décide si le changement a porté ses fruits. Itère.

La plupart des ingénieurs n'en sont pas encore là. Mais tout pointe dans cette direction. L'objectif : des systèmes assez fiables pour que la révision ne soit plus requise.

Chaque pattern de thread revient à quatre fondamentaux :

1. Contexte. Ce que l'agent sait
2. Modèle. Quel modèle tourne
3. Invite. Ce que tu demandes
4. Outils. Ce que l'agent peut toucher

Mets ces quatre éléments au point et tu as des agents. Toute optimisation de thread atterrit sur l'un d'eux.

• De meilleures invites = des threads plus longs
• Un meilleur contexte = un travail plus précis
• De meilleurs outils = plus de capacités
• De meilleurs modèles = plus de fiabilité

Pour les L-threads surtout, le stop hook porte le poids.

Quand ton agent essaie de s'arrêter, le stop hook intercepte :

1. L'agent essaie de terminer
2. Le stop hook exécute le code de validation
3. Décision : la tâche est-elle vraiment terminée ?
4. Si non : bloque l'arrêt, continue à itérer
5. Si oui : autorise la fin

C'est le cœur technique des boucles Ralph. Le stop hook ne laisse pas l'agent quitter quand il croit avoir terminé. Il le laisse quitter quand le travail est vérifié.

L'ingénierie par threads te donne quelque chose que tu peux vraiment mesurer.

1. Lance plus de threads (P-Threads)

Tu peux ajouter plus d'agents parallèles ? Boris est à 10-15. Tu peux atteindre 5 ? Tu peux atteindre 3 ?

Mesure. Threads simultanés en cours.

2. Lance des threads plus longs (L-Threads)

Les threads peuvent-ils aller plus loin en appels d'outils avant que tu doives intervenir ?

Mesure. Moyenne d'appels d'outils par thread avant intervention.

3. Lance des threads plus épais (B-Threads)

Les threads peuvent-ils s'imbriquer dans d'autres threads ? Une invite peut-elle se déployer en cinq sous-agents ?

Mesure. Travail par invite que tu écris.

4. Lance moins de checkpoints

Tu peux réduire le nombre de révisions humaines ? Ta vérification génère-t-elle assez de confiance pour les sauter ?

Mesure. Phases qui tournent avant une vérification manuelle.

L'amélioration sur l'une de ces quatre dimensions est une vraie progression en tant qu'ingénieur agentique. C'est la métrique. C'est comme ça que tu sais.

Voilà ce que ça donne sur une vraie journée :

Lundi matin. Cinq fonctionnalités à ship.

Ancienne façon. Fonctionnalité 1. Done. Fonctionnalité 2. Done. Répète. Cinq sessions séquentielles.

Façon par threads :

1. Écris les specs pour les cinq fonctionnalités (phase de planification)
2. Lance cinq instances Claude Code parallèles (P-threads)
3. Donne à chaque instance une fonctionnalité
4. Révise les premiers résultats terminés pendant que les autres tournent
5. Certaines fonctionnalités ont besoin de phases découpées (C-threads)
6. La plus complexe spawn des sous-agents (B-thread)
7. La tâche de nuit tourne comme un L-thread avec une boucle Ralph

Mêmes cinq fonctionnalités. Sauf que maintenant tu fais tourner plus de threads, des threads plus épais, et des threads plus longs.

L'ingénierie par threads et les boucles Ralph s'emboîtent parfaitement.

Ralph répond à la question : comment je garde un agent en marche de façon fiable jusqu'à ce qu'il ait vraiment terminé ?

L'ingénierie par threads répond : comment je scale l'usage des agents et mesure que je progresse ?

Ralph produit des L-threads. L'ingénierie par threads te dit quand les L-threads battent les P-threads et quand les B-threads sont le bon choix.

Le stop hook derrière Ralph est le même que celui qui maintient les L-threads en vie. Le développement vérification-d'abord est ce qui fait fonctionner l'un ou l'autre pattern.

Les ingénieurs qui prennent de l'avance ne "utilisent pas seulement l'IA". Ils pensent en threads.

Chaque tâche commence par une question : quel type de thread est-ce ? Le paralléliser ? L'enchaîner ? Nicher des sous-threads à l'intérieur ?

Le goulot d'étranglement se déplace. Avant c'était "à quelle vitesse je code ?" Maintenant c'est "combien de threads utiles je peux lancer ?"

Scale ton compute. Scale ton impact.

Commence petit :

1. Audite ton travail. Combien de threads tu lances maintenant ? (Pour la plupart des ingénieurs : 1.)

2. Ajoute un P-thread. Ouvre un deuxième terminal. Lance une tâche parallèle pendant que le premier agent est encore occupé.

3. Chronomètre tes threads. Compte les appels d'outils avant que tu interviennes. Suis ce chiffre.

4. Essaie un C-thread. Découpe une grosse tâche en phases explicites. Révise entre les phases.

5. Travaille vers les L-threads. Mets en place la vérification. Laisse un agent tourner 30 minutes sans surveillance.

Le but n'est pas d'atteindre 15 Z-threads parallèles demain. Le but c'est un gain régulier et mesurable. Plus de threads. Des threads plus longs. Des threads plus épais. Moins de checkpoints.

C'est la seule vraie façon de savoir que tu progresses. Pas un sentiment. Un comptage.

• Ajoute des boucles Ralph Wiggum pour l'autonomie des L-threads
• Adopte les workflows asynchrones pour lancer des agents parallèles
• Étudie la conception des sous-agents pour les architectures B-thread
• Construis des boucles de feedback pour les patterns de vérification

L'ingénierie par threads transforme le codage IA d'un artisanat en pratique mesurable. Tu peux le suivre. Tu peux l'améliorer. Tu peux le scaler.

Commence à compter tes threads.