Pourquoi l’IA basée sur des agents n’est pas un bon partenaire de pair programming

• Comme les agents LLM écrivent du code bien plus vite que les humains, l’expérience de pair programming peut au contraire se dégrader
• À cause d’une automatisation trop rapide, l’utilisateur n’arrive pas à suivre et perd fréquemment le contexte du travail
• Ce phénomène ressemble au sentiment d’exclusion ressenti lors d’un pairing avec un développeur très expérimenté, et finit par affaiblir le contrôle qualité et la communication
• Comme solution, l’article propose de privilégier une collaboration centrée sur la revue de code asynchrone et de ralentir le rythme du pairing avec l’IA pour passer à un workflow centré sur la qualité et la communication
• Les agents IA doivent eux aussi être conçus pour “s’arrêter et dialoguer, en privilégiant le doute et la vérification plutôt que la confiance”

---

Les problèmes du pair programming avec les agents LLM

• Les agents IA (par ex. Copilot Agent) écrivent du code bien plus vite que le rythme de réflexion humain
• Résultat : le code déferle avant même que l’utilisateur ait pu suivre, ce qui entraîne une perte de contexte et une baisse de concentration dans le travail
• Quand l’agent demande de l’aide dans une situation problématique, l’utilisateur se retrouve déjà à devoir “rattraper les dégâts” sans avoir bien compris ce qui se passe ; au final, la charge de remettre en ordre un code parti dans la mauvaise direction augmente
• Au bout du compte, il devient difficile de maintenir la qualité, la communication et la bonne orientation du travail

• L’expérience de pairing avec les meilleurs agents IA rappelle les mauvais souvenirs d’un ancien pairing avec un programmeur humain exceptionnel
  • Le partenaire de pair martèle le clavier à une vitesse excessive et en silence, au point de rendre le code impossible à suivre
  • Toute l’énergie mentale est épuisée, puis on se détache progressivement du travail
  • Quand le pair se bloque et demande de l’aide, on vit une expérience déstabilisante parce qu’il est difficile de comprendre la situation
  • En cours de route, une implémentation qui s’écarte de l’objectif est produite, et la charge de la corriger dans les délais est reportée sur l’autre

The path forward: solutions concrètes

• 1. Collaboration asynchrone

  • Comme lorsqu’une personne prend l’initiative en pair programming humain, il est plus efficace de laisser l’IA écrire le code de manière autonome puis de le relire via une Pull Request
  • Avec des workflows asynchrones comme GitHub Coding Agent, l’utilisateur peut se concentrer sur la revue et le contrôle qualité

• 2. Un pairing “au tour par tour” en ralentissant le rythme

  • Au lieu du “Agent Mode” de l’IA, utiliser une approche pas à pas comme Edit/Ask Mode
  • Comme dans le ping-pong pairing (l’un propose, l’autre valide), l’utilisateur accepte ou examine directement les changements proposés par l’IA pour en contrôler le rythme
  • Il est préférable de ne pas utiliser l’IA uniquement pour résoudre des problèmes ou déboguer, mais de l’intégrer dans un workflow cohérent

Idées pour rendre le pairing avec un agent plus humain

• Permettre à l’utilisateur de régler directement la vitesse de sortie du code (lignes/minute, mots/minute)
• Une fonction pour mettre l’agent temporairement en pause, afin que l’utilisateur puisse poser des questions ou contester la direction prise
• Aller au-delà de l’UI de chatbot existante et fournir des primitives d’UI liées à l’avancement du travail (par ex. épingler la session en cours à une issue GitHub précise, liste de tâches intégrée, etc.)
• Concevoir l’agent pour qu’il s’arrête plus souvent et dialogue : vérifier “pourquoi on fait cela”, demander conseil, valider la direction, etc., afin de créer une ambiance de collaboration humaine
• Introduire un support avancé du chat vocal pour permettre à l’utilisateur de garder les yeux sur le code tout en communiquant avec l’IA à la voix

• Si ces fonctions étaient mises en place, elles permettraient une véritable expérience de collaboration humain-agent, au lieu du pairing actuel, rapide et unidirectionnel

Conclusion

• Nous observons aujourd’hui à la fois les limites et le potentiel du pair programming basé sur des agents IA
• Le pair programming avec des agents IA est plus efficace lorsqu’il est conçu autour de la communication, de la qualité et de la vérification — comme une collaboration humaine — plutôt qu’autour de la seule vitesse
• Une approche “plus lente, dialoguée, vérifiée et contextualisée” améliore la qualité du pairing avec l’IA

[panarch]

> 1. Collaboration asynchrone
> Comme dans le pair programming avec un humain, lorsqu’une personne mène activement l’avancement, il est plus efficace que l’IA écrive le code de manière autonome puis le fasse relire via une Pull Request.

J’utilise Codex depuis quelques jours, et je me reconnais davantage dans cette approche que dans le format agentique. Le fait de pouvoir faire tourner simultanément du travail sur plusieurs projets donne vraiment l’impression de travailler avec plusieurs développeurs juniors.
Le fait de pouvoir utiliser l’IA de manière asynchrone, sur plusieurs projets et même sur plusieurs tâches au sein d’un même projet, fait réellement sentir un gain de productivité arithmétique de 3 à 10 fois, voire davantage.

[GN⁺]

Avis Hacker News

• J’ai eu l’impression que ce texte expliquait exactement pourquoi j’ai vite arrêté d’utiliser l’IA de cette façon. Quand je veux construire quelque chose, j’ai déjà plus ou moins choisi la <i>méthode</i>, mais la façon dont l’IA s’y prend diffère souvent de ce que je veux. Et quand elle génère 2 000 lignes de code d’un coup, ça crée en fait encore plus de travail. Il faut lui dire des choses comme : « commence par supprimer tous ces commentaires, ça fait deux fois trop d’explications inutiles pour du code simple. N’abstrais pas X comme ça, moi je veux ceci… ». Et quand on donne un retour, les 2 000 lignes peuvent soudain se transformer en 700 lignes très différentes, ce qui rend le suivi vraiment difficile. Je n’aime pas non plus voir la base de code devenir un amas de scripts que je connais mal, avec des styles disparates. Il me faudrait une IA qui pense et code dans un style proche du mien, mais c’est justement très difficile. Travailler avec une IA me donne l’impression de travailler, le premier jour, avec quelqu’un qui n’a pas d’expérience. Personnellement, je pense moins que c’est un problème d’excès de confiance de l’outil qu’un problème de processus de conception devenu plus visible. Idéalement, il faudrait d’abord voir un document de conception du type : « je pense à cette approche, je vais gérer ces fonctions, ces classes et cet état de cette manière », puis, si cela convient, passer à l’implémentation.

  • Comme avec un ingénieur humain, je veux insister sur le fait qu’une session de planification est vraiment essentielle au départ. On discute d’abord avant d’écrire du code, on négocie les détails. Je pose volontairement une première question aussi vague que possible pour voir si des recommandations inattendues émergent, puis j’affine progressivement. Une fois suffisamment satisfait, je demande au LLM de créer deux documents, initialprompt.txt et TODO.md. initialprompt.txt contient un résumé du projet, l’instruction de lire TODO.md, ainsi que l’ordre de cocher chaque étape une fois terminée. Grâce à cette méthode, le LLM comprend à la fois l’objectif global et les tâches détaillées, et quand la conversation se coupe plus tard à cause des limites de contexte, il peut reprendre rapidement le fil du travail.

  • J’ai eu l’impression qu’il résumait exactement ma propre expérience. Les seules fois où j’ai mené à bien du code écrit par l’IA, c’était quand seul le résultat final comptait et que j’avais très peu de connaissances du domaine. Dès que j’ai une opinion forte sur ce qu’est un « bon » résultat, je finis généralement frustré et j’abandonne le projet. Avec la fonction architect de roo code pour poser l’approche d’abord, puis le code mode pour implémenter réellement, c’était moitié joie, moitié frustration. La leçon importante, c’est de toujours repartir sur une nouvelle tâche et de ne pas prolonger les conversations trop longtemps. D’ordinaire, j’ai tendance à découper les problèmes et à vérifier les résultats, mais avec les LLM j’ai plutôt eu tendance à leur balancer tout l’espace du problème d’un seul coup, et à échouer. J’ai essayé plusieurs fois pour trouver ma propre méthode, et aujourd’hui encore j’ai ajouté une fonctionnalité d’application en 30 minutes. Si je l’avais implémentée moi-même, cela aurait vraiment pris plusieurs jours. Et si j’ai noté seulement 30 minutes dans mon journal, c’est parce que je savais exactement ce que je voulais et que le processus ne m’intéressait pas. Cette expérience m’a aussi conduit à conclure qu’il est impossible, pour toutes ces raisons, de confier à l’IA du code que d’autres devront maintenir un jour.

  • Au final, c’est surtout une expérience épuisante, avec des résultats insatisfaisants. C’est ce que je dirais à quelqu’un qui se pose ces questions. Pour ma part, les seules fois où j’ai été satisfait du coding agentique, c’était pour des scripts très courts dont je me moquais de la qualité du code, ou pour des fonctions vraiment sans impact.

  • Le workflow recommandé dans le guide d’utilisation de Claude Code d’Anthropic vaut le détour. L’idée clé est : « fais-lui d’abord lire le code, puis établir un plan de changement, et seulement à la fin exécuter ». On peut revoir et corriger le plan avant que l’IA n’écrive une seule ligne de code. Si, avec un agent, il agit d’une manière qui ne vous convient pas — par exemple s’il code directement sans plan — il suffit de lui dire : « fais-le autrement ».

  • Cette histoire de générer 2 000 lignes de code d’un coup… on dirait presque un prompt du genre « fais tourner Skyrim entier sur SNES ». Ça me fait imaginer quelqu’un qui revient du déjeuner, lance le résultat et se met en colère parce que l’IA lui a fabriqué un Fallout façon PS1 avec seulement des attaques au corps à corps.

• Chaque fois qu’un de mes textes arrive en première page de HN, j’ai toujours peur de lire les commentaires et de voir à quel point je suis idiot, ou de tomber sur des remarques agressives destinées à me rabaisser. Mais parfois, si j’ai vraiment bien choisi le titre, personne ne lit mon texte et tout le monde parle juste de son propre sujet, ce qui me permet d’échapper à ces critiques.

  • Je trouve ça à la fois drôle et réaliste. On voit souvent le même schéma dans d’autres articles. Quoi qu’il en soit, j’aime ce type de discussion, donc ça m’amuse.

  • J’ai aimé l’article. Ça donnait un peu une impression de « comment apprécier le pair programming avec l’IA ». C’était utile, donc merci.

• Quand j’ai utilisé un agent LLM pour la première fois, je m’attendais à une communication bidirectionnelle, à un vrai pair programming collaboratif. En réalité, j’ai trouvé un partenaire qui voulait tout résoudre entièrement à sa manière. Et dès que j’essayais de corriger un peu quelque chose, cela cassait le contexte du code écrit par l’IA, ce qui rendait l’expérience encore plus pénible. Ce que je veux, c’est une vraie collaboration : un peu moi, un peu l’IA, en alternance.

  • On lui demande s’il a réessayé récemment. Mon expérience est différente. Je modifie le code généré par l’IA, puis je lui demande de relire les fichiers. En général, elle répond quelque chose comme « je vois qu’il y a eu des changements dans le fichier ». Si l’IA modifie le code, je lance ensuite les tests et je lui fais un retour pour qu’elle améliore itérativement. Cette façon de faire marche bien avec Zed et Claude Sonnet.

  • En général, ma méthode consiste à prendre d’abord la proposition de l’IA, puis à refactorer ou à la reprompter si nécessaire. Cette approche augmente artificiellement le taux d’acceptation, et ce sont justement ces statistiques que les entreprises d’IA peuvent ensuite utiliser pour affirmer que « l’IA écrit du très bon code ». En réalité, il y a beaucoup de moments où l’on se dit simplement : « bon, tant pis, je vais corriger ça moi-même ».

  • Moi, j’obtiens généralement le type de conversation que je veux en ajoutant d’emblée : « discutons d’abord, ne modifie pas le code ». Une fois qu’on a suffisamment échangé, je termine par « applique ».

  • Si vous voulez une certaine forme de collaboration, le conseil est de la demander explicitement au LLM. C’est utile de préparer quelques documents de prompts réutilisables dans toutes les conversations.

  • Dernièrement, garder le contexte n’est plus vraiment difficile, donc les modifications de code ne posent pas de problème non plus. J’utilise uniquement le mode Ask, pas le mode commande, avec Opus dans Claude Code et o3 max dans Cursor. J’évite volontairement le mode agent, parce que, comme dans l’article d’origine, j’en retire de moins en moins de bénéfices à mesure que le temps passe. J’utilise rarement l’autocomplétion par tabulation, et je modifie moi-même 80 à 90 % du code proposé avant de le retaper. Grâce à ça, je peux continuer à taper à 170 wpm. La vitesse de sortie d’Opus et de o3 max est suffisamment limitée pour que la lecture ne soit pas trop pénible ; au début c’était trop rapide, mais on s’y habitue vite. Mon avis personnel, c’est que si GitHub Copilot résume pour vous toute l’expérience LLM, alors vous n’avez connu qu’une expérience de niveau motel.

• Le pair programming n’est pas adapté à toutes les situations. Dans bien des cas, il ne l’est même pas du tout. Comme je l’ai déjà dit ailleurs, les suggestions d’autocomplétion du LLM cassent mon flux de concentration : il faut s’arrêter régulièrement pour lire, relire, accepter ou rejeter, et cela détruit complètement le flow de programmation. J’ai vraiment eu du mal à intégrer l’autocomplétion IA dans mon workflow.

  • Je pense pareil. La solution, c’est d’utiliser à la fois un IDE sans IA et Cursor/VS Code, en alternant entre les deux. Le vrai deep work est impossible quand on discute avec un chatbot.

  • J’ai récemment acheté un nouveau portable et réinstallé mon IDE, et après quelques heures de code, j’avais l’impression que quelque chose était « bizarre ». J’ai fini par comprendre que j’avais oublié de me connecter à GitHub Copilot, donc je travaillais sans IA. J’ai eu l’impression d’écrire de façon bien plus proactive, sans attendre l’autocomplétion. Cursor, en particulier, perturbe constamment mon flux d’usage, au point que même des fonctions comme « prédire la position du prochain curseur » me paraissent totalement inutiles. À l’avenir, je pense laisser Copilot désactivé et n’utiliser des outils de style agent comme aider que pour le boilerplate ou les tâches répétitives.

  • L’autocomplétion IA ou les suggestions de code sont particulièrement mauvaises quand on utilise un langage fortement typé. C’est correct à 80 % du temps, mais l’autocomplétion de l’IDE est quasiment juste à 100 %. L’approche par agent IA est meilleure pour deux raisons : 1) elle n’interrompt pas constamment le fil de pensée ; 2) elle peut compiler et exécuter les tests elle-même, corriger ce qui est faux, puis vous rendre du code correct.

  • Moi, au contraire, j’adore l’autocomplétion. Je dois écrire en Go, où il y a énormément de boilerplate, et ce n’est pas un problème qu’on résout simplement en ajoutant une bibliothèque, donc il y a beaucoup de cas où taper directement est plus rapide. Pour écrire du code pénible, mes mains vont plus vite que l’IA, mais l’autocomplétion reste vraiment utile. Je lis une suggestion d’une ligne instantanément, et même une suggestion longue peut passer si elle ressemble à ce que j’allais écrire. À force, on finit par sentir ce que l’IA va prédire. Ce n’est pas un gain de productivité monumental, mais pour les messages de logs, les boucles for et autres choses pénibles, ça fait vraiment gagner du temps. À mon avis, cela n’aide que lorsque je lis beaucoup plus vite que je ne tape.

  • Le pair programming n’est pas toujours approprié, mais je pense qu’il est utile dans la majorité des situations. S’il fonctionne mal, c’est souvent parce qu’une personne — ou les deux — ne s’implique pas vraiment dans le processus, parce qu’un des deux rejette l’idée en disant « ça ne marche pas comme ça », ou parce qu’on essaie de respecter les règles du pair programming de manière trop rigide.

• Ma position est un peu compliquée. Depuis au moins un mois, j’essaie activement d’utiliser tous les outils LLM possibles au travail pour apprendre à les exploiter au mieux. En nombre de lignes de code, ma productivité augmente clairement. Mais je ne peux pas dire que je sois plus productif dans l’ensemble. Sur presque chaque tâche terminée, il y a des comportements bizarres impossibles à expliquer, ou bien des modifications qui touchent des zones sans rapport et qu’il faut ensuite annuler. Les tests générés automatiquement par l’IA ont l’air plausibles au début, mais d’autres indicateurs comme la couverture montrent clairement leurs limites. J’ai souvent l’impression de devoir remonter plusieurs étapes en arrière pour atteindre le résultat voulu. Ce n’est même pas une question de gain ou d’apprentissage : on a l’impression de reculer franchement. Une fois, il a même ajouté en douce 50 000 lignes d’import inutiles dans un module qui ne faisait pas partie du périmètre initial. Une autre fois, alors que les règles étaient claires, il a détruit toute la structure orientée objet pour tout réécrire avec une masse de if/else. Le problème, c’est que les résultats varient énormément selon les cas : parfois, pour exactement la même tâche, c’est parfait ; d’autres fois, tout est cassé. J’ai essayé différentes manières d’assigner le travail et de le guider, mais même sur des tâches similaires, le comportement change trop, ce qui rend la relecture des changements toujours pénible. Et même quand le code est presque bon, si on lui demande de ne corriger qu’un point précis, il peut faire partir tout le travail dans une autre direction. D’après mon expérience, c’est efficace pour écrire de petits outils, mais difficile d’en attendre des résultats cohérents sur des bases de code moyennes à grandes.

• Les agents LLM donnent l’impression de trop parler et de croire en permanence qu’ils ont raison. Ils manquent de concision et expliquent en longueur des choses qu’une seule ligne suffirait à dire. Ils ajoutent de longs commentaires même pour des changements mineurs. On a l’impression qu’ils essaient de m’enseigner quelque chose et qu’ils en font toujours trop.

  • Certains comportements que les gens détestent (« sorties trop longues, commentaires excessifs, etc. ») peuvent être des effets secondaires du fait que les LLM ont été conçus pour améliorer l’efficacité sur d’autres aspects. Une sortie longue est associée à du code moins paresseux et à de meilleurs scores sur certains benchmarks de performance. Les commentaires en excès peuvent aussi renforcer le contexte local, améliorer la qualité du code généré ensuite et réduire les erreurs.

  • J’ai essayé sonnet 4 hier, et il a passé 15 minutes à tester et refactorer en boucle pour ne changer qu’une seule valeur de configuration. Au final, il a modifié 40 fichiers pour rien. Il essayait sans cesse de lancer un débogueur inexistant et continuait aussi à tenter d’ouvrir des pages web nécessitant une authentification. J’ai vraiment senti à quel point on est encore loin de la perfection.

• D’après mon expérience, le problème n’est pas que ce soit trop rapide, mais au contraire trop lent. C’est une lenteur ambiguë, et c’est encore pire. Si c’était plus rapide, je pourrais suivre le code en temps réel et travailler avec. Si c’était plus lent, je pourrais faire autre chose puis revenir. Mais en réalité, ça finit en 50 secondes à quelques minutes, donc on ne peut ni se concentrer sur autre chose ni vraiment rester dans le flux. Je pense qu’il vaudrait mieux itérer plus rapidement, en unités plus petites. Au fond, ce qu’il faudrait, c’est une autonomie comparable à une revue humaine, par exemple un travail indépendant qu’on revoit ensuite comme une merge request (PR). La boucle actuelle — donner une tâche, attendre 1 à 3 minutes, lire le résultat, faire un retour, recommencer — est pour moi le pire scénario.

  • Ça me fait penser à la BD de The Oatmeal sur « l’internet lent vs pas d’internet du tout ».

  • Si vous perdez votre concentration, quelqu’un conseille de mettre un aquarium de 30 L sur le bureau. Apparemment, c’est parfait pour regarder dans le vide.

• En tant que développeur, je n’utilise presque jamais l’IA, à part parfois un chatbot pour des questions hors projet. Je me demande si certains l’utilisent aussi pour des projets clients, ou seulement pour des projets personnels. Et si c’est pour des clients, est-ce que vous incluez dans le contrat le fait que le code est transmis à une IA ? La plupart des clients ont des NDA ou d’autres clauses de non-divulgation externe, et certains ont même interdit explicitement l’usage de l’IA. Je serais curieux de savoir si certains ont rencontré des clients qui acceptent des exceptions pour les outils de coding IA.

  • Moi, je l’utilise presque uniquement en interne, et seulement parce que l’entreprise a des directives claires sur l’usage de l’IA. En pratique, j’ai l’impression que cela ne me fait pas vraiment gagner du temps, donc je ne paierais pas pour ça sur mes projets personnels. Et sur un projet personnel, le plaisir de construire soi-même compte davantage que le résultat, donc j’aime mieux fabriquer directement que faire du prompt.

  • Il arrive aussi que le client demande activement l’usage de l’IA. Il espère une meilleure qualité et un développement plus rapide — autrement dit, une réduction des coûts — même si, en pratique, la réalité est souvent différente de cette attente.

  • Je ne partage avec OpenAI/Anthropic que du code suffisamment public pour pouvoir être collé tel quel dans un champ de recherche web.

  • Moi, je ne partage rien. Même pour les projets internes, je ne peux partager du code à l’extérieur qu’en échange d’une rémunération. Et comme je traite aussi des données personnelles, exposer du code à des entreprises américaines ferait peser un risque juridique trop important.

• Enfin quelqu’un a mis le doigt exactement sur le problème. L’IA affiche une confiance excessive sur la conception, puis part dans des détails d’implémentation arbitraires sans concertation. Même pour des API mockées, elle casse souvent la structure, ce qui impose une reprise. J’aimerais que le comportement du LLM soit plus collaboratif, qu’il pose immédiatement des questions quand il manque de détails. On ne peut pas donner toutes les informations dans le prompt initial, et les prompts supplémentaires cassent le contexte et la logique de pensée de la conception de départ. Je me demande si c’est moi qui l’utilise mal, et j’aimerais connaître une meilleure méthode. J’aimerais aussi que les LLM progressent vers un mode où ils reçoivent et intègrent les retours de manière plus progressive. Je me demande si l’ajout ou la mise à jour de contexte est intrinsèquement difficile, mais j’ai envie de continuer à apprendre.

  • Aujourd’hui, la plupart des stacks prennent en charge des sessions de « design/planning », donc commencer par là aide probablement déjà. Un workflow qui me réussit bien, avec grand modèle comme petit modèle, consiste à démarrer par quelque chose comme : « sur la base de @file, @docs, @examples, je veux faire _ dans @path en me référant à @module_requirements.md — discutons d’abord de tout ce qui est nécessaire avant toute implémentation réelle ». On discute dans les deux sens jusqu’à être d’accord, puis on peut enregistrer ça dans un fichier .md ou simplement enchaîner avec « maintenant, fais-le ». On peut aussi encapsuler ce workflow dans des fichiers .rules ou .md, ou dans des snippets d’IDE, afin de le réutiliser à chaque nouvelle tâche. Il faut aussi garder à l’esprit que les LLM récents ont besoin de beaucoup plus de contexte, donc il faut essayer des approches différentes selon chaque base de code ou projet, et les résultats varieront aussi en conséquence.

  • J’ai aussi l’impression que plus il y a d’informations, plus l’IA se met à confondre les choses. Il existe probablement des moyens de contourner cela. Elle est très forte pour extraire de tout petits fragments d’information, mais je trouve dommage que tout le secteur se concentre uniquement sur les modèles de chatbot. Je me demande à quoi ressemblerait le monde si nous n’avions jamais continué à inventer le clavier, la souris, les interfaces graphiques ou l’écran tactile.

• À mon avis, le bon usage de l’IA est justement ce style collaboratif où elle sert d’assistante, et la mode actuelle qui consiste à se focaliser sur « l’IA écrit directement le code » montre plutôt que l’industrie logicielle part dans la mauvaise direction. Je ne laisse jamais l’IA écrire du code à ma place. Je l’utilise pour critiquer le code que j’ai écrit ou pour élaborer des stratégies de conception de structures logicielles à grande échelle. Je m’en sers comme d’un consultant stratégique : quand on prépare bien le contexte du LLM, on peut obtenir un excellent guide. Mais le sujet principal reste toujours moi : c’est à moi de comprendre, d’exécuter et de garder la maîtrise, sans jamais donner à l’IA une responsabilité supérieure à celle d’un simple conseiller. Je considère l’IA comme un « idiot savant » et je pense qu’il faut la manier avec prudence.