Les assistants de codage IA sont censés réduire le travail requis pour transformer l’intention d’un développeur en logiciel fonctionnel. Mais certains utilisateurs des modèles Opus 4.8 et Opus 5 d’Anthropic déclarent qu’ils doivent consacrer plus de temps, d’invites et de jetons à corriger la langue des modèles, parfois même à acheminer leur sortie vers des modèles d’IA moins chers pour la rendre utilisable.
Dans un numéro détaillé de GitHub, Peter Bower, fondateur et PDG de la start-up technologique SpaceCell basée à Londres, a déclaré que la tendance d’Opus 4.8 à utiliser une terminologie confuse ou inventée créait un travail supplémentaire dans les flux de travail de développement logiciel, en particulier lors de la génération de la documentation du code.
Et ce, bien qu’il ait été explicitement et à plusieurs reprises invité à éviter certains termes et à utiliser des alternatives spécifiées, a écrit Bower, ajoutant que le modèle continuait à introduire des termes indésirables, forçant des passes de nettoyage répétées, y compris via des modèles Sonnet ou Haiku moins chers, pour rendre la documentation « saine et présentable ».
Ces laissez-passer supplémentaires, a-t-il ajouté, faisaient grimper les coûts des jetons jusqu’à deux fois plus élevés qu’ils ne l’auraient été autrement.
Le problème de Bower, qui a été publié le mois dernier, a depuis reçu près de 265 remerciements, ce qui pourrait indiquer que plusieurs autres utilisateurs ont été confrontés à un problème avec la cohérence linguistique de l’Opus 4.8 d’une manière ou d’une autre.
Certains ont même déclaré avoir été confrontés à un problème similaire. Bower lui-même fait également référence à un subreddit ClaudeAI dans son numéro, qui souligne l’incohérence linguistique de l’Opus 4.8. Cela a également reçu un nombre important de votes positifs, qui sont l’équivalent sur Reddit d’un pouce levé souvent utilisé sur les réseaux sociaux pour indiquer l’approbation ou le soutien d’une publication ou d’un commentaire.
Un autre fil de discussion subreddit signale un problème similaire avec l’Opus 5, les utilisateurs signalant la tendance du modèle à produire des résultats déroutants et difficiles à analyser, et il a reçu près de deux fois plus de votes positifs.
Pourquoi des résultats flous de l’IA pourraient ralentir le développement de logiciels
Selon les analystes, pour les équipes de développement d’entreprise, la nature persistante du problème signalé avec les modèles Opus pourrait entraîner une baisse significative de la productivité.
« Les cycles de correction répétés peuvent éroder la productivité lorsque les développeurs passent suffisamment de temps à examiner, rediriger et réparer les résultats de l’IA. Cela compense le temps gagné en générant du code via un assistant de codage ou toute autre tâche », a déclaré Abhishek Satapathy, analyste principal chez Avasant.
Cette érosion de la productivité, selon Advait Patel, ingénieur principal en fiabilité des sites (SRE) chez Broadcom, est également liée aux aspects opérationnels du cycle de vie du développement logiciel (SDLC), car une prose peu claire générée par l’IA pourrait affecter la documentation de conception, les runbooks, les enregistrements de décision d’architecture (ADR) et les rapports d’incidents.
« Un runbook rédigé dans un style que les ingénieurs trouvent difficile ou désagréable à lire, par exemple, pourrait devenir un problème lors d’un incident, lorsque les équipes doivent rapidement comprendre et agir en fonction des informations dont elles disposent », a déclaré Patel.
La révision du code, a ajouté Patel, présente un autre problème potentiel en raison d’une prose peu claire : « Les descriptions de demandes d’extraction trop complètes ou confuses sont susceptibles d’être survolées plutôt que soigneusement examinées, augmentant le risque que des détails importants ou des défauts potentiels soient manqués. »
Un résultat flou pourrait avoir des répercussions sur les coûts
Les implications d’une prose peu claire s’étendent également aux coûts.
En effet, le prix payé par les entreprises pour un outil de codage d’IA ne reflète pas nécessairement le coût d’obtention d’un résultat utilisable, a déclaré Bhupendra Chopra, directeur des revenus de la société de conseil informatique Kanerika.
Si les développeurs doivent effectuer des passes répétées pour corriger, réécrire ou réviser une réponse, ou la faire passer par un autre modèle, alors ces étapes supplémentaires font partie du coût global de réalisation de la tâche, y compris le temps de révision humaine, a ajouté Chopra.
Et la plupart des entreprises, selon Patel, ne réalisent souvent pas ce calcul car tout cela « est regroupé sur une seule ligne » dans la facture de leur agent de codage.
Ce coût caché pourrait également avoir des implications sur la capacité d’Anthropic à retenir les développeurs.
« Changer d’assistant de codage ou de modèle sous-jacent est devenu relativement facile pour les équipes de développement, d’autant plus que les plates-formes de codage prennent de plus en plus en charge les modèles de plusieurs fournisseurs, bien que les entreprises soient susceptibles de rencontrer des coûts irrécupérables dans la configuration, les hooks et la configuration MCP. Mais le code ne bouge pas, les dépôts ne bougent pas, et aucun plan de migration n’est donc nécessaire », a déclaré Patel.
« C’est un véritable risque commercial pour tout fournisseur de modèles. Un faible coût de changement signifie que la bonne volonté est votre seul verrou, et les plaintes concernant la lisibilité érodent rapidement la bonne volonté parce que les gens les frappent quotidiennement », a noté Patel.
Des solutions de contournement rapides peuvent ne pas suffire
Cependant, Anthropic n’a pas encore répondu au problème GitHub de Bower, qui décrit également les changements qu’il estime que l’entreprise devrait apporter pour résoudre le problème.
Le fondateur de la startup a demandé à Anthropic de modifier le style d’écriture par défaut du modèle pour le rapprocher d’un « livre blanc technique ou d’une bonne réponse Stack Overflow », qui est « claire, déclarative et directe ».
Il a également appelé à ce que le modèle soit moins verbeux tout en adhérant fermement aux instructions définies dans CLAUDE.md et répétées au cours d’une conversation, arguant que ces instructions devraient persister plutôt que d’être progressivement remplacées par le style de communication par défaut du modèle.
Entre-temps, Patel, qui a déclaré avoir été confronté à une dérive de modèle similaire au travail, en particulier lorsqu’il travaillait avec des référentiels impliquant une pile Jenkins, Python, Terraform, GKE et Helm, a souligné un correctif que lui et son équipe utilisent lors de la génération de documentation et de résumés de demandes d’extraction.
Plutôt que de demander à Claude d’être concis, son équipe utilise des règles explicites dans la configuration du projet pour interdire des formulations spécifiques, car demander de la concision peut parfois rendre le résultat plus court mais plus énigmatique, a déclaré Patel.
Cependant, Patel a averti que s’appuyer simplement sur des solutions de contournement rapides pourrait ne pas suffire pour les entreprises, car le comportement du modèle peut changer au fil du temps.
« Le comportement du modèle est une cible mouvante », a déclaré Patel. « Une modification de version peut modifier le registre de sortie sans que vous déployiez quoi que ce soit, et rien dans votre pipeline ne vous alerte à ce sujet. »
Cela signifie que les DSI et les responsables de l’ingénierie doivent traiter les changements de comportement des modèles comme quelque chose qui doit être testé et surveillé en permanence.
« Épinglez les versions de modèle pour tout ce qui se trouve dans un pipeline au lieu de suivre les dernières. Conservez un petit ensemble d’évaluation de vos propres tâches réelles et réexécutez-le à chaque changement de modèle. Suivez le taux de rejet et de reprise, c’est votre avertissement précoce. Et ne laissez pas trente équipes inventer chacune leurs propres solutions de contournement non documentées », a conseillé Patel.
