Quand le codage par IA alourdit le travail de vérification

Les agents de codage IA peuvent réduire fortement le coût de création du code, mais ce gain peut déplacer la contrainte d’ingénierie vers une étape ultérieure. Une fois que les agents produisent du code plus vite que les ingénieurs ne peuvent le comprendre et le diagnostiquer, la vérification, le débogage et l’analyse des incidents commencent à déterminer le débit. Pour les responsables de l’ingénierie, la vitesse de génération du code constitue donc une mesure incomplète de la productivité, car le code généré doit encore franchir le reste du processus de livraison logicielle.

Cette contrainte en aval donne un sens précis à la question provocatrice : « Les codeurs IA causent-ils plus de problèmes qu’ils n’apportent de valeur ? » Les éléments disponibles étayent une conclusion plus restreinte : une génération plus rapide peut créer un goulot d’étranglement lorsque l’analyse humaine ne suit pas le rythme. La question de savoir si les agents de codage améliorent la productivité globale de l’ingénierie reste plus large ; l’unité d’analyse utile est donc l’ensemble du parcours qui va du code généré à un logiciel que les équipes peuvent comprendre, vérifier et exploiter.

Les agents de codage IA peuvent créer un déficit de vérification et de débogage

Les preuves de ce goulot d’étranglement proviennent d’un sondage mené par le cabinet de recherche indépendant Coleman Parkes. Il portait sur 300 développeurs logiciels et responsables de l’ingénierie au Royaume-Uni et aux US, et a été publié dans le rapport d’Undo, Overcoming the limitations of coding agents in complex software systems. Undo fournit des outils de débogage et a donc un intérêt commercial à souligner l’importance du débogage et des approches qui le rendent plus efficace. La plupart des équipes de développement logiciel interrogées ont indiqué que les agents IA peinent à identifier les problèmes dans du code complexe, ce qui situe la difficulté au moment où la sortie générée doit être comprise et corrigée.

Ce constat général devient plus utile lorsqu’on le décompose en différentes formes de travail en aval. Certains résultats concernent des diagnostics erronés, d’autres du code généré incorrect, tandis qu’un autre mesure le temps perdu à analyser la sortie de l’IA. Ensemble, ils montrent plusieurs façons dont une génération rapide peut créer du travail supplémentaire plus tard dans la livraison logicielle.

Le résultat de 93% est important, car l’hallucination a une conséquence précise pendant le débogage. Un agent peut fournir une explication erronée d’un problème existant, orientant potentiellement l’enquête vers la mauvaise cause. Les ingénieurs doivent alors vérifier le diagnostic avant de faire confiance au correctif proposé, ce qui ajoute une décision supplémentaire au workflow de débogage.

Cette charge de diagnostic peut commencer plus tôt lorsque l’implémentation générée elle-même est erronée. Cinquante-cinq pour cent des répondants ont déclaré que les agents introduisent trop souvent du code incorrect, les reprises retardant les cycles de livraison. Le code peut toujours être produit à faible coût et rapidement, mais les ingénieurs perdent une partie de ce gain lorsqu’ils doivent identifier une sortie défectueuse, déterminer le comportement attendu et refaire le travail concerné.

La nécessité d’inspecter la sortie générée va au-delà des cas nécessitant des reprises. Quatre-vingt-quatorze pour cent ont reconnu perdre en productivité au moins une fois par mois parce qu’ils devaient analyser du code généré par l’IA. Ce résultat montre que la compréhension de la sortie produite par la machine mobilise l’attention des ingénieurs pour presque tous les répondants, tandis que l’échantillon de 300 personnes au Royaume-Uni et aux US du sondage définit la population sur laquelle repose ce constat.

Undo relie cette charge d’analyse à la manière dont les ingénieurs passent leur temps. L’entreprise affirme que les développeurs ont tendance à passer deux fois plus de temps à déboguer qu’à écrire du code, le débogage représentant en moyenne 16,9 heures par semaine. Undo attribue cette charge au fait que les ingénieurs logiciels ne parviennent pas à suivre le rythme des agents de codage qu’ils utilisent, une interprétation cohérente avec le problème commercial auquel répondent ses outils de débogage.

Cette pression devient plus lourde de conséquences à la frontière de la production. Le sondage a révélé que 35% du code généré par l’IA atteint la production avant que les équipes de développement ne comprennent pleinement ce que fait ce code. Des erreurs de codage peuvent donc entrer dans des systèmes en fonctionnement alors que la compréhension de l’équipe reste incomplète, faisant de la compréhension de l’implémentation générée une partie de l’analyse d’incident.

Ces mesures établissent un décalage de débit au sein du développement assisté par l’IA. Les agents peuvent rendre la création de code moins coûteuse tandis que les ingénieurs supportent des coûts d’analyse, de reprise, de débogage et d’investigation en production. Pour les responsables de l’ingénierie, la mesure de la productivité doit donc aller au-delà de la génération et prendre en compte le travail nécessaire pour comprendre et exploiter ce que les agents produisent.

Les défaillances les plus difficiles sont celles qui semblent presque correctes

Ce besoin de compréhension augmente lorsque le logiciel généré se comporte de manière plausible tout en restant subtilement erroné. Greg Law, fondateur et PDG d’Undo, formule la distinction ainsi : « Quand le code est manifestement défaillant, la cause est généralement facile à trouver », avant d’évoquer le cas plus difficile : « Là où les ingénieurs peinent, c’est avec du code qui est presque – mais pas tout à fait – correct. C’est dans ces moments-là qu’ils perdent des jours à essayer de démêler ce qui s’est mal passé et pourquoi. »

Un code presque correct crée un problème de diagnostic parce que les ingénieurs doivent d’abord établir quel comportement est erroné, puis en expliquer la cause. Une défaillance évidente peut rapidement resserrer le champ de l’enquête, tandis que des défaillances subtiles peuvent préserver suffisamment de comportement attendu pour laisser plusieurs causes possibles en jeu. Selon Law, ces cas peuvent mobiliser des jours pendant que les ingénieurs déterminent à la fois ce qui a échoué et pourquoi.

Ce travail d’investigation reste nécessaire lorsqu’un système d’IA ne dispose pas de suffisamment de preuves sur l’application en cours d’exécution. Undo avertit que les applications peuvent être difficiles à expliquer et que les systèmes d’IA peuvent produire des réponses assurées malgré des preuves incomplètes sur le comportement de l’application. Dans ces conditions, un agent peut halluciner une cause de bug ou d’instabilité, de sorte que les ingénieurs ont une autre sortie de diagnostic à vérifier avant d’agir.

La dépendance aux preuves distingue la génération de code du débogage. Générer une implémentation plausible commence par un changement demandé, tandis que diagnostiquer un comportement inattendu exige suffisamment d’informations pour reconstituer ce que le logiciel a réellement fait. Lorsqu’un agent ne dispose pas de ces informations, la confiance dans sa réponse ne peut pas établir que l’explication causale est correcte.

La charge de travail humaine qui en résulte se déplace vers la résolution de problèmes en aval lorsqu’un agent ne peut pas établir la cause de manière fiable. Undo affirme que c’est là que les ingénieurs passent désormais l’essentiel de leur temps. Produire une première implémentation peut demander moins d’effort, tandis que déterminer si le logiciel généré se comporte correctement et enquêter sur un comportement inattendu exige davantage de jugement.

Le workflow complet du codage IA montre où les gains de productivité peuvent stagner

La différence entre génération et diagnostic devient plus claire lorsqu’on les traite comme les étapes d’un même workflow. Un agent IA peut générer rapidement du code, après quoi les ingénieurs doivent comprendre et analyser ce qu’il a produit. Une partie de cette sortie peut passer en production alors que cette compréhension reste incomplète, permettant à des erreurs de codage ou à des comportements inattendus d’émerger dans un système en fonctionnement.

Une défaillance en production fait alors du déficit de compréhension initial une partie de l’enquête. Un agent IA travaillant à partir de preuves incomplètes peut mal diagnostiquer la cause, ce qui signifie qu’un ingénieur peut devoir vérifier son explication, reprendre le débogage et enquêter sur l’incident. Les reprises et l’investigation peuvent donc absorber une partie de la productivité gagnée en accélérant l’implémentation initiale.

Cette séquence peut modifier la manière dont la capacité d’ingénierie est utilisée, même lorsque l’agent est très efficace pour produire du code. La compréhension humaine et le débogage peuvent progresser plus lentement que la sortie générée ; ainsi, l’augmentation du volume de génération accroît la demande sur les étapes qui suivent. Une fois ce point atteint, le débit réel dépend de la capacité de l’équipe à établir ce que fait le code, s’il est correct et pourquoi il se comporte de manière inattendue.

Les auteurs du rapport d’Undo soutiennent qu’une intervention humaine continue ne peut pas soutenir ce rythme. Si une personne doit guider l’IA à travers chaque correction de bug ou déterminer la cause de chaque comportement inattendu, la capacité humaine d’investigation reste la ressource limitante tandis que les agents continuent à générer rapidement du code. Leur argument intègre la compréhension, la vérification, le débogage et la réponse aux incidents dans le calcul de productivité qui commence avec le code généré par l’IA.

L’étape suivante proposée est une IA capable d’enquêter

Cette contrainte de capacité conduit à la réponse proposée par Undo : appliquer l’IA à une plus grande partie du cycle de livraison logicielle et donner aux agents de débogage la capacité d’enquêter. Pour le débogage, cela signifie un agent capable de recueillir de manière autonome des preuves et des données, puis de les utiliser pour parvenir à des conclusions exactes. Un agent enquêtant sur un comportement en production disposerait alors d’informations sur ce que le logiciel a réellement fait pendant son exécution, lui fournissant des éléments pour une explication causale.

Le contexte d’exécution est au cœur de cette proposition, car des preuves détaillées sur un logiciel en cours d’exécution peuvent fournir une base plus solide pour déterminer ce qui s’est passé et pourquoi. Cette capacité cible directement le problème de diagnostic halluciné identifié dans le sondage. Pour les responsables de l’ingénierie, la question d’évaluation qui en découle est de savoir si la capacité d’investigation peut croître au même rythme que la capacité de génération une fois que les agents peuvent produire du code plus vite que les équipes ne peuvent établir ce qu’il fait réellement.

Law présente explicitement la réponse proposée par Undo autour de ce déséquilibre : « Leur défi, c’est que si les agents excellent à écrire rapidement des quantités massives de code, ils sont moins capables de le déboguer. Le résultat, c’est que les ingénieurs sont ensevelis sous une avalanche de code qui dépasse largement la capacité humaine de débogage. C’est pourquoi nous devons leur donner un moyen d’améliorer l’IA en débogage, en alimentant les agents avec le contexte riche de ce que le code fait réellement à l’exécution. »

La prescription de Law émane d’une entreprise qui vend des outils de débogage, ce qui procure à Undo un avantage commercial si les équipes d’ingénierie traitent le débogage et les preuves d’exécution comme des priorités. Le mécanisme qui sous-tend la proposition reste concret : le débogage exige des preuves sur le comportement de l’application, et Undo propose de donner aux systèmes d’IA accès à ces preuves afin qu’ils puissent prendre en charge eux-mêmes une plus grande part du travail d’investigation. Un système d’IA capable d’acquérir de manière autonome des preuves d’exécution et de raisonner à partir d’elles traiterait l’étape d’investigation où, selon Undo, la génération rapide de code crée une contrainte de capacité.

Points clés à retenir pour les décideurs

• Mesurez la charge de travail en aval : Les agents de codage IA peuvent accélérer la création de code tout en augmentant l’analyse, les reprises et le débogage. Les responsables de l’ingénierie peuvent évaluer la productivité sur l’ensemble du cycle de livraison, y compris le coût de compréhension et d’exploitation du code généré.
• Préparez-vous aux défaillances subtiles : Un code généré par l’IA presque correct peut être plus difficile à diagnostiquer que des défaillances évidentes, surtout lorsque les agents manquent de preuves d’exécution. Les équipes d’ingénierie peuvent exiger une vérification des diagnostics de l’IA avant que les correctifs n’atteignent la production.
• Suivez l’ensemble du workflow de codage IA : Une génération plus rapide peut faire de la compréhension humaine et du débogage la contrainte sur le débit de livraison. Les CTO peuvent suivre le temps de vérification, les reprises et l’analyse des incidents en parallèle des gains de génération de code.
• Donnez aux agents de débogage des preuves d’exécution : Undo soutient qu’une IA d’investigation a besoin d’accéder à des preuves sur la manière dont le logiciel s’est réellement comporté pour diagnostiquer les défaillances de façon fiable. Les équipes plateforme et d’ingénierie peuvent évaluer si le contexte d’exécution aide les agents à enquêter sur les bugs avec moins d’intervention humaine.