- À mesure que des outils CLI orientés agent comme Claude Code, OpenAI Codex et Cursor s’imposent, l’usage des « agents de code parallèles », qui consistent à faire tourner plusieurs agents IA en même temps pour travailler en parallèle, progresse
- De nombreux ingénieurs s’en servent pour gagner en productivité, et l’approche peut s’appliquer au-delà du simple développement à la recherche, à la maintenance et aux tâches basées sur des consignes
- Il existe toutefois aussi des inquiétudes : la vitesse de revue du code peut devenir un goulot d’étranglement, et le flux de concentration (flow) peut être perturbé
- Les développeurs les plus expérimentés ont tendance à être plus à l’aise avec l’usage d’agents parallèles, grâce à leur capacité à mener de front multitâche et revue de code
- Dans le travail avec des agents parallèles, les pratiques d’ingénierie de base comme les tests, les petites unités de travail, le refactoring et la revue de code sont des éléments clés pour préserver la fiabilité et la qualité
Diffusion des agents IA parallèles et évolution des méthodes de développement
- Avec la généralisation d’outils CLI orientés agent comme Claude Code, OpenAI Codex et Cursor, une tendance apparaît : les ingénieurs font exécuter plusieurs agents en même temps pour réaliser un travail en parallèle
- L’ingénieur d’Anthropic Sid Bidasaria a mentionné au cours d’un échange qu’il avait amélioré sa productivité en faisant tourner plusieurs agents
- L’expert en AI engineering Simon Willison l’explique ainsi dans son billet « Adopter le mode de vie des agents de code parallèles »
- Au départ, il était sceptique, estimant que la revue du code généré par l’IA constituait un goulot d’étranglement, mais ces dernières semaines il a commencé à utiliser naturellement des agents parallèles
- Il n’est possible de revoir et d’intégrer qu’un changement important à la fois, mais le nombre de tâches que l’on peut lancer en parallèle sans augmenter fortement la charge cognitive augmente
- L’usage d’agents parallèles est particulièrement utile pour la recherche, les tâches de maintenance et les tâches guidées par consignes
Impact sur les pratiques traditionnelles du software engineering
- Le travail avec des agents parallèles pourrait bouleverser des décennies de pratiques en software engineering
- Si un ingénieur qui fait tourner plusieurs agents en même temps est plus productif qu’un collègue « mono-thread » concentré sur un seul problème à la fois, alors c’est tout à fait possible
- Avant l’IA, l’ingénierie reposait en grande partie sur le maintien d’un état de flow (immersion)
- Comprendre les composants → construire, vérifier et itérer sur une solution → soumettre une pull request ou fusionner et déployer
- Les interruptions dans ce processus nuisent à l’immersion et le retour dans le sujet demande du temps ; c’est pourquoi beaucoup de développeurs attachent de l’importance à des plages de concentration protégées
- Mais cela ne vaut pas pour tous les ingénieurs très productifs : certains excellent dans le multitâche et les changements de contexte
- L’ingénieur le plus productif que l’auteur ait connu comme manager pratiquait de nombreux context switches et gérait plusieurs tâches simultanément
- Une journée type : revue de code → travail de développement → stand-up → développement
(avec en réalité des interruptions permanentes : demandes de revue, demandes d’aide, questions du management, etc.)
Pourquoi les ingénieurs seniors sont bien adaptés aux agents parallèles
- Les ingénieurs seniors et au-delà ont de bonnes chances de s’adapter naturellement au travail avec des agents IA parallèles
- Ils gardent en tête les workflows parallèles de leurs équipes
- Ils effectuent des revues de code sur 2 à 5 flux de travail
- Ils ont acquis une capacité à gérer les interruptions et à continuer d’avancer malgré une concentration régulièrement brisée
- Ils savent donner des consignes à leurs collègues, ce qui aide aussi pour déléguer et expliquer des tâches urgentes
- Ils possèdent également de bonnes compétences rédactionnelles, utiles pour une communication écrite efficace dans les revues de code, documents RFC, tickets ou critiques du travail des collègues
- En utilisant des agents IA, les ingénieurs qui veulent gagner en productivité peuvent développer des qualités attendues chez de très bons leaders techniques
- Jusqu’à présent, les personnes qui utilisent avec succès des agents parallèles sont observées majoritairement parmi les ingénieurs seniors et plus
- Cela dit, Armin Ronacher, créateur de Flask, a indiqué qu’il utilisait moins les agents parallèles qu’auparavant
- « Mon cerveau a une limite quant à la quantité qu’il peut relire. »
L’avenir du travail avec des agents parallèles et les incertitudes à venir
- Nous entrons désormais dans une nouvelle ère où tous les développeurs peuvent commencer à travailler en parallèle avec des agents de code
- Il reste incertain de savoir si cela rendra réellement les ingénieurs plus productifs, ou si cela leur donnera seulement l’impression d’être plus productifs
- Il est possible que des ingénieurs qui se concentrent sur une seule tâche à la fois produisent, avec le temps, des logiciels plus fiables
- Il est aussi possible que le travail avec des agents parallèles entraîne davantage de problèmes et de travail répétitif, annulant ainsi les gains
- Malgré cela, on peut s’attendre à ce que davantage de développeurs expérimentent les agents parallèles
Pourquoi les fondamentaux du software engineering restent cruciaux avec les agents IA
- Même lorsqu’on utilise des agents IA, les bases du software engineering restent essentielles
- Tests : appliquer des tests unitaires à tous les side projects (ne pas faire confiance à son propre travail sans validation)
- Tâches petites et explicites : décrire des tâches de faible portée et fournir des exemples
- Refactoring : tous les 3 ou 4 travaux, demander à l’agent de refactorer le code qu’il a écrit (extraction de méthodes, déplacement vers une nouvelle classe, etc.)
- Revue : suivre le travail de l’agent
- Réaliser soi-même les petites tâches : garder l’IDE ouvert et effectuer directement les changements de quelques lignes pour conserver une bonne connaissance de la codebase
- D’autres ingénieurs racontent la même expérience : des pratiques d’ingénierie qui « forcent » l’agent à faire passer tous les tests donnent de meilleurs résultats
- Les agents IA étant non déterministes et, dans une certaine mesure, peu fiables, ces pratiques permettent une approche pratique beaucoup plus fiable
7 commentaires
Comme l’a mentionné Armin Ronacher, je pense que le goulot d’étranglement est la charge cognitive du relecteur. Si l’on est déjà occupé par le code ou d’autres tâches, cela devient de fait difficile à appliquer. J’estime même que cela peut produire l’effet inverse, avec une baisse de qualité inattendue ou un temps de vérification plus long.
Je crains qu’au nom de l’utilisation de l’IA et des gains de productivité, le multitâche ne devienne la norme chez les développeurs.
J’arrive à suivre jusqu’à 3 agents, comme
fe,beetdata, mais au-delà mon cerveau n’y arrive plus T_T.Grâce à l’IA, le TDAH est désormais la nouvelle norme ? Plus besoin d’aller à l’hôpital ?
Je les utilise en en lançant plusieurs, comme si c’étaient des collègues évaluateurs infatigables, en les arrêtant et en les relançant sans cesse mdr
> L’ingénieur le plus productif que j’ai connu à l’époque où j’étais manager faisait beaucoup de context switching et gérait plusieurs tâches en même temps
> Acquérir une capacité à gérer les interruptions pour continuer à avancer dans une situation où la concentration est sans cesse brisée
vs
> Réduire les changements de contexte, terminer une tâche avant de passer à la suivante, et consigner sa mémoire dans des outils externes
> Les changements de contexte fréquents (context switching) augmentent la charge de contrôle du cortex préfrontal et du lobe pariétal
> - https://fr.news.hada.io/topic?id=24026
Personnellement, j’ai souvent envie de faire du multitâche, mais comme ça m’épuise trop, j’essaie de m’en méfier.
Je trouve que les méthodes simples qu’on peut appliquer régulièrement sont les meilleures.
Le cerveau humain n’est pas parallèle non plus, haha. De toute façon, si la vérification se fait au final de manière séquentielle, le parallélisme ne peut pas avoir une si grande utilité.
Si on considère qu’il s’agit d’un PM plutôt que d’un coéquipier développeur, et qu’on procède en parallèle, ça colle à peu près.