Quand les sous-agents brillent

Vous savez comment créer des sous-agents et les concevoir correctement. Maintenant, la question est : quand aident-ils vraiment, et quand gênent-ils ? La différence se résume à une seule chose -- que le travail intermédiaire importe ou non pour votre thread principal.

Les sous-agents fonctionnent mieux quand l'exploration est séparée de l'exécution. Si chaque étape d'une tâche dépend de ce que l'étape précédente a découvert, vous voulez ce travail dans votre thread principal. Mais si vous avez juste besoin d'une réponse et que le chemin ne vous importe pas, déléguez-le.

Les sous-agents excellent dans les tâches où :

Vous avez besoin d'un résultat, pas d'un compte rendu détaillé de la façon dont il a été trouvé
Le travail exploratoire encombrait le contexte de votre thread principal
La tâche bénéficie d'une perspective nouvelle ou d'une invite système personnalisée

Tâches de recherche

La recherche est le cas d'usage classique des sous-agents. Considérez l'investigation de la façon dont l'authentification fonctionne dans une base de code inconnue. Votre thread principal doit savoir où le JWT est validé, mais il n'a pas besoin de voir chaque fichier qui a été recherché en chemin.

Un sous-agent de recherche peut lire des dizaines de fichiers, tracer des appels de fonction et explorer différents chemins de code. Toute cette exploration reste dans le contexte du sous-agent. Votre thread principal reçoit un résumé propre comme :

La validation JWT se fait dans middleware/auth. js ligne 42, appelée depuis le routeur Express dans route/api. js

Le sous-agent a fait le gros du travail. Votre thread principal obtient exactement ce dont il a besoin pour avancer.

Révisions de code

Claude examine le code plus efficacement quand le code est présenté comme étant écrit par quelqu'un d'autre. Si vous avez construit une fonctionnalité sur plusieurs tours avec votre thread principal, demander à ce même thread de la réviser produit souvent des retours faibles. Claude a participé à sa création, donc il a du mal à la voir avec des yeux neufs.

Un sous-agent examinateur voit les modifications dans un contexte séparé. Il exécute git diff, lit les fichiers modifiés et applique ses critères de révision spécialisés sans l'historique de la façon dont le code a été écrit. Cette séparation vous permet également d'encoder les normes de révision spécifiques au projet dans l'invite système du sous-agent, garantissant des critères de révision cohérents dans toute l'équipe.

Invites système personnalisées

L'invite système par défaut de Claude Code met l'accent sur des réponses concises et axées sur le code. Cela fonctionne très bien pour le codage, mais pas pour tout.

Voici deux cas où une invite système personnalisée rend le sous-agent véritablement meilleur que le thread principal :

Sous-agent de rédaction \-- Donnez-lui des instructions sur le ton, le public et le style. L'invite par défaut de Claude Code tend vers la rédaction technique concise, ce qui n'est vraiment pas ce que vous voulez pour une page d'accueil ou une campagne par email. Un sous-agent de rédaction peut avoir des instructions complètement différentes sur la voix et la structure.
Sous-agent de style \-- Pointez-le vers vos fichiers de système de conception. Quand le sous-agent s'exécute, ces fichiers se chargent automatiquement dans son contexte, donc il connaît vos variables de couleur, conventions d'espacement et motifs de composants avant même de commencer à écrire du CSS.

Quand les sous-agents nuisent

La surcharge du lancement d'un sous-agent -- perdre la visibilité sur son travail et compresser ses conclusions en un résumé -- n'a de sens que quand le sous-agent fait quelque chose que le thread principal ne peut pas faire. Il y a trois anti-modèles courants à surveiller.

Revendications d'expertise

Les sous-agents qui revendiquent une expertise aident rarement. Des invites comme « vous êtes un expert Python » ou « vous êtes un spécialiste Kubernetes » n'ajoutent aucune valeur car Claude possède déjà ces connaissances. Il n'y a rien qu'un soi-disant sous-agent expert puisse faire que votre thread principal ne puisse pas faire directement.

Pipelines séquentiels

Les pipelines de sous-agents séquentiels créent des problèmes. Considérez un flux à trois agents : un pour reproduire un bug, un pour le déboguer et un pour le corriger. Les pipelines fonctionnent quand les tâches sont vraiment indépendantes. Ils échouent quand chaque étape dépend des découvertes de l'étape précédente -- et la correction de bugs le fait presque toujours. Les informations se perdent lors du transfert entre les agents.

Exécuteurs de tests

Les sous-agents exécuteurs de tests ont tendance à cacher les informations dont vous avez besoin. Quand les tests échouent, vous voulez la sortie complète pour diagnostiquer les problèmes. Un sous-agent qui retourne « les tests ont échoué » vous force à créer des scripts de débogage supplémentaires pour obtenir des détails qui auraient été visibles dans la sortie directe. Les tests ont montré que le modèle d'exécuteur de tests avait les performances les plus faibles parmi toutes les configurations.

La règle de décision

Quand vous décidez d'utiliser un sous-agent, posez-vous une seule question : le travail intermédiaire importe-t-il ?

Si la réponse est non -- vous avez juste besoin du résultat final -- déléguez-le à un sous-agent. Si la réponse est oui -- vous devez voir et réagir à ce qui se passe en chemin -- gardez-le dans votre thread principal.

Utilisez les sous-agents pour :

La recherche et l'exploration
Les révisions de code
Les tâches qui ont besoin d'une invite système personnalisée

Évitez les sous-agents pour :

Les personas « experts » qui n'ajoutent pas de vraie capacité
Les pipelines multi-étapes où chaque étape dépend de la précédente
L'exécution de tests où vous avez besoin de la sortie complète pour le débogage