J'ai lancé une orchestration à cinq sous-agents pour refactoriser un module d'authentification. Ça m'a coûté 11 $, pris douze minutes, et produit un résultat pire que de le faire simplement dans un seul fil. Les sous-agents sont surévalués pour les développeurs solos, et les démos Twitter montrant de beaux essaims d'agents ne vous disent pas la partie où ça devient cher et bizarre.
Ne vous méprenez pas. Les sous-agents sont une vraie fonctionnalité avec de vrais usages. Mais le conseil par défaut — « décomposez tout en agents spécialisés » — est faux pour la personne qui construit un produit seule. La plupart du temps, vous voulez un agent plat à fil unique qui fait simplement le travail. Laissez-moi expliquer pourquoi.
Ce qu'un sous-agent coûte vraiment
Quand vous lancez un sous-agent, vous ne déléguez pas seulement une tâche. Vous démarrez un nouveau contexte qui ne sait rien de votre fil principal. Donc vous devez le briefer. Chaque sous-agent a besoin des fichiers pertinents, des conventions, de l'objectif, ré-expliqués à partir de zéro. Ce briefing, c'est des tokens. Le travail du sous-agent, c'est des tokens. Puis il rend compte, et synthétiser son rapport dans le fil principal, c'est encore des tokens.
Pour une tâche parallèle avec des frontières nettes, ce surcoût en vaut la peine. Pour une tâche où les pièces sont enchevêtrées — ce qui décrit la plupart du vrai code — vous payez la taxe du briefing encore et encore, et les sous-agents continuent de se marcher dessus parce qu'aucun ne voit le tableau d'ensemble.
La version à fil unique... a déjà le contexte. Elle a lu les fichiers une fois. Elle se souvient de ce qu'elle a fait trois étapes plus tôt. Pas de briefing, pas de synthèse, pas de surcoût de coordination. Souvent elle est à la fois moins chère et meilleure.
Le problème de la fragmentation du contexte
Voici la subtilité. Toute la raison pour laquelle les agents sont bons en codage, c'est le contexte partagé — le modèle tient le problème, les fichiers, et ses propres décisions antérieures en un seul endroit et raisonne sur l'ensemble. Les sous-agents brisent ça. Chacun ne voit qu'une tranche.
Donc le sous-agent A corrige la gestion des erreurs à sa façon. Le sous-agent B, briefé séparément, corrige la validation d'une façon différente. Aucun ne sait ce que l'autre a fait. Vous, dans le fil principal, devez maintenant réconcilier deux changements localement raisonnables qui ne s'assemblent pas. J'ai passé plus de temps à réconcilier la sortie des sous-agents qu'ils n'en ont économisé. C'est le piège.
Pour un développeur solo, votre avantage, c'est que vous tenez tout le tableau dans votre tête et que l'agent le tient en contexte. Fragmenter ça pour ressembler à une équipe, c'est jouer à faire semblant d'être une organisation que vous n'avez pas.
Quand les sous-agents paient vraiment
Je ne dis pas jamais. Voici où je fais vraiment appel à eux :
- Travail vraiment parallèle et indépendant. « Lance la suite de tests pendant que tu lintes aussi le code. » Pas d'état partagé, pas de réconciliation. Fan-out propre.
- Isolation du contexte intentionnelle. Quand une sous-tâche inonderait mon contexte principal de déchets que je ne veux pas polluer le fil principal — comme lire 40 fichiers pour répondre à une question. Le sous-agent lit les 40, retourne la seule réponse, mon contexte principal reste propre. C'est un excellent usage.
- Recherche délimitée. « Va comprendre comment fonctionne l'authentification de cette bibliothèque et fais un rapport. » L'exploration est désordonnée ; je ne veux que la conclusion.
Remarquez le schéma : les sous-agents gagnent leur place quand la sous-tâche est indépendante et résumable. Quand la valeur réside dans le fait de garder le désordre hors du fil principal, pas dans le fait de faire semblant d'être une équipe.
Le fantasme de l'orchestration
Il y a un genre de contenu qui vend le rêve multi-agents — un agent planificateur, un agent codeur, un agent réviseur, un agent testeur, tous coordonnés comme une petite entreprise. Ça a l'air incroyable dans un diagramme. Pour un développeur solo, c'est surtout un moyen de transformer une tâche à 0,50 $ en une à 6 $.
Le planificateur ré-explique la tâche au codeur. Le codeur produit du travail. Le réviseur, avec son propre contexte fraîchement démarré, relit tout pour le réviser. Le testeur relit tout encore. Chaque transfert retraite le même code. Vous avez recréé l'inefficacité d'une grande équipe — toute la surcharge de communication — sans le bénéfice, parce que c'est toujours juste vous et le modèle.
Un seul agent capable dans un seul fil planifie, code et se vérifie lui-même tout en tenant tout en contexte. Vous lisez le diff à la fin. C'est votre réviseur. Vous êtes l'organigramme.
Ma règle
Par défaut, rester à plat. Un fil, un agent, contexte complet. Faire appel à un sous-agent seulement quand je peux répondre oui à : cette sous-tâche est-elle indépendante, et est-ce que je veux seulement le résumé en retour ?
# La question que je pose avant de lancer un sous-agent :
# - Indépendant du travail principal ? (pas d'état partagé à réconcilier)
# - Résumable ? (je veux une conclusion, pas la sortie brute)
# Les deux oui -> sous-agent. Sinon -> rester à plat.
Tout le reste reste dans le fil principal, où le contexte est entier et la facture est petite.
L'essaim d'agents ressemble à l'avenir. Pour une personne qui livre un produit, c'est généralement un costume. Enlevez-le et faites simplement le travail dans un seul fil. Votre budget de tokens vous remerciera, et le code aussi.