How Do Practitioners Build SE Agents? Insights from a Mixed-Methods Study
À travers une étude de méthodes mixtes menée auprès de 100 praticiens, cet article révèle que la construction d'agents de génie logiciel déplace les goulots d'étranglement du développement du codage vers des activités non liées au code comme l'exigence et la coordination, favorisant un flux de travail axé sur l'évaluation caractérisé par un processus en sept étapes et des défis tels que des signaux d'évaluation peu fiables et une dette de compréhension.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez que le développement de logiciels ressemblait autrefois à la construction d'une maison avec un marteau et une scie. Vous deviez couper chaque planche, clouer chaque bardeau et poncer chaque surface à la main. C'était lent, fatigant, et la « partie difficile » consistait simplement à manier le marteau.
Maintenant, imaginez que quelqu'un vous remette un robot magique et hyper rapide capable de couper, de clouer et de poncer une maison entière en un clin d'œil. Soudain, le marteau n'est plus le problème. Le problème est que le robot est si rapide qu'il construit un manoir entier avant même que vous n'ayez fini de dessiner les plans.
C'est exactement ce qui s'est passé lorsque les développeurs ont commencé à utiliser des agents SE (des robots IA qui écrivent du code). Une nouvelle étude menée par des chercheurs qui ont interrogé 20 constructeurs issus de 12 entreprises différentes et sondé 80 autres personnes a révélé que, bien que les robots aient rendu l'écriture de code peu coûteuse et rapide, ils n'ont pas fait disparaître le travail. Au lieu de cela, le « goulot d'étranglement » (l'embouteillage dans le processus) s'est simplement déplacé vers une autre partie de la route.
Voici ce que les chercheurs ont découvert, en utilisant le langage d'un explorateur curieux.
La nouvelle danse en sept étapes
L'article suggère que la construction de ces agents IA n'est plus une ligne droite, mais une danse circulaire en sept étapes. C'est moins comme une chaîne de montage d'usine et plus comme un jeu vidéo où vous rejouez sans cesse les niveaux pour obtenir un score plus élevé.
- Le Plan (Les exigences) : Vous dites au robot quoi faire. Mais désormais, vous devez rédiger les instructions de manière si claire que tant les humains que le robot puissent les lire.
- La Fiche d'évaluation (L'évaluation) : C'est la nouvelle étape la plus importante. Vous ne vérifiez pas seulement le travail à la fin ; vous utilisez une fiche d'évaluation pour guider le robot pendant qu'il travaille.
- Le Carburant (Les données) : Vous nourrissez le robot avec des exemples de bon travail pour qu'il apprenne.
- La Construction (Construction du système) : Vous choisissez un cerveau pour le robot (un modèle) et vous construisez un « harnais » (une armure équipée d'outils et de mémoire) autour de lui.
- L'Essai routier (Tests et déploiement) : Vous laissez le robot tourner et vous regardez s'il s'écrase.
- La Boucle de rétroaction (Feedback humain) : Vous observez ce qu'il fait et vous lui dites : « Non, fais-le de cette façon », ou « Oui, c'était super ».
- La Mise au point (Maintenance adaptative) : Le cerveau du robot peut recevoir une mise à jour de son créateur, changeant ainsi sa façon de penser. Vous devez constamment ajuster votre harnais pour rester à la hauteur.
Le grand changement : Du manieur de marteau au gestionnaire de robot
L'étude a révélé que, puisque les robots peuvent écrire du code si vite, l'idée ancienne selon laquelle « coder est la partie difficile » est invalidée. Les chercheurs soutiennent que coder n'a jamais été la partie la plus difficile ; c'était simplement la partie la plus bruyante.
Maintenant que le robot effectue le gros œuvre, le véritable travail s'est déplacé vers la révision et l'évaluation.
- L'effet « Vibe Coding » : Comme le robot peut construire des choses si vite, les frontières entre « chercheur », « ingénieur » et « gestionnaire » deviennent floues. Une seule personne peut désormais accomplir tout le travail, de l'idée initiale jusqu'à la correction du dernier bug.
- Le problème de la « Boîte noire » : Les chercheurs suggèrent que, comme le robot est une « boîte noire » (vous ne voyez pas exactement comment il réfléchit), vous ne pouvez pas simplement lui faire confiance. Vous avez besoin d'un style de Développement piloté par l'Évaluation. Cela signifie que vous définissez les règles du succès avant de commencer, et vous vérifiez constamment si le robot s'améliore réellement, et pas seulement s'il va plus vite.
Les Six Pièges (Défis)
Même avec des robots ultra-rapides, les constructeurs ont rencontré six obstacles majeurs. L'article suggère qu'il s'agit de problèmes réels et difficiles, et non de simples petits incidents.
- La Fiche d'évaluation défectueuse : Comment savoir si le robot a fait du bon travail ? Les chercheurs ont constaté que les « tests » utilisés pour noter le robot sont souvent défaillants. Parfois, le robot trouve une solution meilleure que celle attendue par le test, mais le test affiche « Échec » parce qu'il recherche l'ancienne réponse. D'autres fois, le test est simplement trop coûteux à exécuter à chaque fois.
- La malédiction du « Ne rien changer, tout changer » : C'est un phénomène étrange. Les chercheurs ont découvert que si l'entreprise qui a fabriqué le cerveau du robot effectue une mise à jour (même si vous n'avez pas touché à votre code), votre robot pourrait soudainement commencer à se comporter différemment. Un outil qui fonctionnait hier peut casser aujourd'hui, alors que vous n'avez changé aucune ligne de code.
- Sécurité vs Vitesse : Les constructeurs admettent souvent qu'ils ont peur des robots, mais qu'ils les laissent travailler quand même pour aller plus vite. L'article suggère que c'est dangereux. Une équipe a laissé un robot en liberté, et celui-ci a accidentellement supprimé le répertoire personnel d'un utilisateur parce qu'il avait oublié ses instructions.
- L'écart des « Règles non écrites » : Les robots ne peuvent lire que ce qui est écrit. Mais dans la réalité, beaucoup de connaissances sont simplement « dans la tête des gens » (comme la raison pour laquelle un mur spécifique a été construit de travers). Les chercheurs ont constaté que les robots ne peuvent pas accéder à ce savoir « implicite », ce qui crée de la confusion.
- La Dette de compréhension : C'est la plus grande surprise. Les robots écrivent du code plus vite que les humains ne peuvent le comprendre. C'est comme si le robot construisait un gratte-ciel en une journée, alors que vous essayez encore de comprendre le plan. Les constructeurs accumulent une « dette » de code qu'ils ne comprennent pas. Pour y remédier, certaines équipes commencent à sauvegarder les instructions pour reconstruire le code, plutôt que de sauvegarder le code lui-même.
- La Fausse productivité : Si vous comptez simplement le nombre de lignes de code que le robot écrit, il semble que tout le monde soit super productif. Mais les chercheurs suggèrent que c'est un piège. Écrire 10 000 lignes de code que personne ne comprend ou ne nécessite pas n'est pas de la « productivité ». C'est juste du « bruit ».
À quel point sommes-nous sûrs ?
Les chercheurs sont assez confiants dans leurs conclusions car ils n'ont pas seulement deviné ; ils ont mesuré.
- Ils ont interviewé 20 experts puis ont sondé 80 personnes supplémentaires.
- Lorsqu'ils ont demandé au groupe sondé s'ils étaient d'accord avec les résultats, 91 % ont approuvé le nouveau flux de travail, et entre 71 % et 95 % ont approuvé les défis spécifiques.
- Ils sont même retournés voir les personnes initialement interviewées pour vérifier s'ils étaient d'accord avec la synthèse (un processus appelé « vérification par les membres »), et les experts ont répondu : « Oui, c'est exactement ce que nous faisons ».
L'essentiel
L'article suggère que la construction d'agents IA n'a pas rendu le génie logiciel facile ; cela l'a simplement rendu différent. La « partie difficile » est passée de l'écriture du code à la gestion du robot, à la vérification de son travail et à la surveillance pour qu'il ne supprime pas accidentellement Internet.
Les chercheurs concluent que, à mesure que l'implémentation devient bon marché, les goulots d'étranglement ne disparaissent pas — ils se déplacent. L'avenir de la construction de logiciels ne consiste pas à taper plus vite ; il s'agit d'être un meilleur gestionnaire, un juge plus strict et un architecte plus intelligent pour les robots qui effectuent le gros du travail.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.