L’IA accélère le développement, mais génère 1,7 fois plus de bugs

• D’après l’analyse de 470 PR open source, le code écrit par l’IA contient en moyenne 1,7 fois plus de problèmes que celui écrit par des humains
• Les principaux défauts, comme les erreurs logiques, la baisse de lisibilité et les vulnérabilités de sécurité, sont nettement plus fréquents dans le code IA ; les problèmes de lisibilité sont notamment plus de 3 fois plus nombreux
• Les omissions dans la gestion des erreurs, les erreurs de concurrence et les incohérences de nommage sont fréquentes dans le code IA, ce qui alourdit la revue et accroît les risques en production
• Les causes identifiées incluent une compréhension insuffisante de la logique métier, la recherche d’une exactitude superficielle et une préférence pour des patterns peu efficaces
• Le rapport souligne la nécessité de renforcer les dispositifs de contrôle qualité du code IA et d’introduire des प्रक्रédures de revue, de sécurité et de test adaptées à l’IA

---

Vue d’ensemble du rapport AI vs Human Code Generation

• CodeRabbit a mené cette étude afin d’analyser de manière empirique les différences de qualité entre le code écrit par l’IA et celui écrit par des humains
  • 470 PR GitHub open source ont été examinées, dont 320 coécrites avec l’IA et 150 écrites uniquement par des humains
  • Tous les résultats ont été normalisés en nombre de problèmes pour 100 PR, puis la fréquence de chaque type de problème a été mesurée via une comparaison statistique des ratios
• En conclusion, l’IA améliore la productivité, mais augmente aussi le taux d’erreurs
  • En moyenne, 10,83 problèmes par PR rédigée par l’IA, contre 6,45 pour une PR humaine
  • Les erreurs les plus graves ont été trouvées plus souvent dans le code IA

Limites de l’étude

• Comme il était impossible de vérifier directement si une PR avait été écrite par l’IA, les PR portant le signal co-authored-by ont été classées comme rédigées par l’IA
  • Les PR sans ce signal ont été considérées comme humaines, sans qu’une séparation parfaite soit possible
• Malgré cette limite, les différences statistiques de patterns de problèmes entre les deux groupes restent significatives
• La méthodologie complète est publiée à la fin du rapport

Les 10 principaux constats

• Tous les types d’erreurs ne sont pas exclusifs à l’IA, mais dans la plupart des catégories, le taux d’erreur du code IA est plus élevé
  • Humains et IA commettent les mêmes types d’erreurs, mais l’IA les produit plus souvent et à plus grande échelle

• 1. Une hausse de 1,7x du nombre total de problèmes

  • En moyenne 10,83 problèmes par PR IA, contre 6,45 pour une PR humaine
  • Les PR avec une forte concentration de problèmes (outliers) sont bien plus nombreuses dans le code IA, ce qui accroît la charge de revue

• 2. Augmentation des erreurs les plus graves

  • Les problèmes majeurs et critiques sont 1,4 à 1,7 fois plus nombreux

• 3. Hausse de 75 % des problèmes de logique et d’exactitude

  • Cela inclut les erreurs de logique métier, mauvaises dépendances, défauts de flux de contrôle et erreurs de configuration
  • Leur correction est coûteuse et ils peuvent mener à des incidents en production

• 4. Plus de 3x de problèmes de lisibilité

  • Les conventions de nommage, la structure du code et la cohérence d’expression se dégradent nettement
  • Même si le code semble propre en apparence, les violations des patterns locaux sont fréquentes

• 5. Doublement des oublis de gestion d’erreurs et de chemins d’exception

  • Les vérifications de null, conditions de garde et logiques de gestion d’exception manquent souvent
  • Il s’agit d’un type de défaut directement lié aux pannes de service

• 6. Jusqu’à 2,74x plus de problèmes de sécurité

  • Parmi les exemples typiques : mauvaise gestion des mots de passe et vulnérabilités de référence d’objet
  • Il ne s’agit pas de vulnérabilités inédites, mais la plupart des défauts de sécurité sont amplifiés

• 7. Moins de problèmes de performance, mais concentrés côté IA

  • Les appels I/O excessifs sont environ 8 fois plus nombreux
  • L’IA privilégie un code centré sur la clarté, au détriment de l’efficacité

• 8. Environ 2x plus d’erreurs de concurrence et de dépendance

  • Les erreurs d’ordre, mauvais flux de dépendance et mauvais usage du contrôle de concurrence sont fréquents

• 9. 2,66x plus de problèmes de formatage

  • Les erreurs formelles, comme l’indentation, les espaces ou les incohérences de style, sont nombreuses
  • Même avec des formatters et linters automatiques, le bruit augmente dans le code IA

• 10. Doublement des incohérences de nommage

  • Les noms peu explicites, incohérences terminologiques et identifiants génériques sont fréquents, ce qui augmente la charge cognitive des reviewers

Causes des problèmes

• L’IA comprend mal la logique métier
  • Elle génère le code à partir de patterns statistiques et rate les règles du système
• Une génération centrée sur l’exactitude en surface
  • Le code semble correct, mais présente des défauts dans la protection du flux de contrôle ou l’ordre des dépendances
• Non-respect des conventions propres au dépôt
  • Les règles de nommage, de structure et de format sont ramenées à des formes trop génériques
• Affaiblissement des patterns de sécurité
  • Sans consigne explicite, l’IA reproduit des patterns de code anciens ou vulnérables
• Préférence pour la simplicité plutôt que l’efficacité
  • Tendance à utiliser des I/O répétées et des structures non optimisées

Réponses recommandées pour les équipes d’ingénierie

• Adopter l’IA ne consiste pas seulement à gagner en vitesse ; cela exige aussi de repenser le dispositif d’assurance qualité

• 1. Fournir suffisamment de contexte à l’IA

  • Il faut préciser les règles métier, patterns de configuration et contraintes d’architecture pour réduire les erreurs
  • Inclure dans les prompts des consignes propres au dépôt et des schémas

• 2. Imposer un style de code basé sur des politiques

  • Utiliser CI, formatter, linter et guide de style pour prévenir les problèmes de lisibilité

• 3. Ajouter des garde-fous d’exactitude

  • Tests obligatoires, vérifications null/types, standardisation de la gestion des exceptions et conditions de garde explicites

• 4. Renforcer les paramètres de sécurité par défaut

  • Centralisation des credentials, interdiction de l’usage direct des mots de passe et exécution automatique de SAST et de linters de sécurité

• 5. Orienter vers des patterns efficaces

  • Traitement par lot des I/O, choix approprié des structures de données et indications de performance

• 6. Mettre en place une checklist de PR adaptée à l’IA

  • Lors de la revue, vérifier les points suivants :
    • couverture des chemins d’erreur
    • exactitude du contrôle de concurrence
    • validation des valeurs de configuration
    • mode de gestion des mots de passe

• 7. Automatiser la revue du code IA

  • Afin d’éviter que l’augmentation de la fatigue de revue ne fasse passer des bugs inaperçus, le rapport propose d’utiliser un outil de revue de code IA (CodeRabbit)
    • Cela permet de standardiser la qualité des revues et de réduire le temps d’examen et la charge cognitive

Conclusion

• Les outils de coding IA sont de puissants accélérateurs, mais accélérer sans garde-fous est risqué
• Le code généré par l’IA présente une variabilité, un taux d’erreur et un niveau de gravité plus élevés
• Il est essentiel d’utiliser l’IA comme outil complémentaire et non comme substitut, tout en renforçant les dispositifs de qualité, de sécurité et de test
• Pour concilier vitesse et qualité, une gouvernance d’ingénierie intentionnelle est nécessaire
• L’usage d’outils de revue de code IA peut concrètement aider à maintenir la qualité

[cshj55]

1,7 fois, c’est moins que ce que je pensais… ?

[ds2ilz]

J’ai ressenti des choses assez similaires en codant moi aussi avec l’IA. Quand on regarde les causes bien résumées, je pense que c’est parce que le contexte ne fournit pas assez des éléments que les humains considèrent comme acquis quand ils codent, comme les patterns, les conventions de nommage, la gestion des cas limites, les conditions de garde, etc.
Du coup, j’ai créé un fichier de règles qui regroupe justement ce genre de choses, et quand je code, je lui donne l’instruction de toujours lire ce fichier et de le respecter. Et là, il suffit d’améliorer le fichier de règles pour que le résultat s’améliore considérablement.

[princox]

J’ai un peu peur qu’on pense : « on en a produit énormément, donc 1,7 fois plus, ce n’est pas presque gratuit ? »...

[kimjoin2]

Mais au moins, c’était rapide, non ? Ça me fait penser à ce mème, lol.

[GN⁺]

Avis Hacker News

• Je pense qu’il existait déjà une forme de « vibe coding » avant l’IA

  • J’ai vu beaucoup de développeurs empiler des vérifications de null sans jamais se demander pourquoi l’objet était null
  • Cette approche peut être utile dans certains cas, mais si tout un système est construit comme ça, la maintenance devient un cauchemar
  • Le vibe coding basé sur l’IA donne l’impression d’accélérer un style où l’on « voit juste le résultat souhaité à l’écran sans savoir pourquoi ça fonctionne »
  • J’ai déjà travaillé dans une entreprise comme ça, où les vérifications de null avalaient les exceptions et enterraient discrètement les erreurs
    • L’équipe se félicitait de son intelligence, mais en réalité le système tournait avec du code copié-collé de StackOverflow et une vieille architecture MVP
    • Dans ce genre d’environnement, il était presque impossible de penser de manière indépendante
    • Cela dit, des outils comme Claude Code peuvent vraiment augmenter la productivité sur une base de code bien conçue
  • Copier-coller depuis StackOverflow puis s’arrêter au niveau « bon, ça tourne à peu près », c’est précisément ça, le vibe coding
    • L’IA n’a fait qu’automatiser ce processus
  • Ce n’est pas tant « voir ce qu’on veut voir » que « afficher n’importe quoi à l’écran »
    • Un null-check ajouté sans réflexion peut plus tard provoquer des erreurs de données subtiles, dont la cause devient très difficile à retracer
  • Je suis d’accord aussi, mais le vibe coding rend surtout plus rapides les développeurs dépendants de StackOverflow
    • On voit augmenter le nombre de développeurs qui ne résolvent pas eux-mêmes leurs problèmes
    • Et en plus, la fiabilité est encore plus faible qu’avant
  • Ce qui me frustre le plus avec l’IA, c’est qu’elle reproduit tel quel un style de code moyen propre à chaque langage
    • Je suis le principe selon lequel « si on ne crée pas de données incorrectes, il n’y a rien à traiter ensuite », mais l’IA le viole sans arrêt
    • Elle définit à peine les types, maintient rarement les invariants, et essaie de tout traiter avec des chaînes et des entiers
    • Du coup, j’utilise l’IA par petites touches via la tab-completion, puis je corrige moi-même les erreurs structurelles
    • Après correction, l’IA suit aussi dans la bonne direction, donc si l’intégration IDE et LSP s’améliore, ce sera bien plus utile

• Les critiques du vibe coding sont légitimes, mais en réalité la qualité du code était déjà médiocre avant l’IA

  • La plupart des codes étaient livrés lentement et avec une faible qualité
  • Certains estiment que si des livraisons plus rapides permettent de valider plus vite des idées, un certain niveau d’erreurs peut être acceptable
  • Aujourd’hui, il est de plus en plus fréquent que la direction demande : « pourquoi faut-il des mois pour une fonctionnalité de cette taille ? »
  • Mais si une « petite fonctionnalité » prend du temps, ce n’est pas à cause des algorithmes, c’est à cause de l’infrastructure et de l’organisation de la collaboration
    • L’IA ne résout pas ces problèmes de fond
  • Les coûts de maintenance et la complexité s’accumulent comme des intérêts composés avec le temps
    • Le vibe coding peut convenir à des projets de court terme, mais pas à des systèmes de long terme
  • À mes yeux, l’important est l’équilibre entre les développeurs intentionnels et les développeurs vibe
    • L’IA renforce excessivement le versant vibe et casse l’équilibre du système
  • Plus importante que la qualité du code, c’est la compréhension partagée du problème métier et de la solution technique
    • Même si la qualité est faible, il est plus important de bien connaître les raisons et les compromis
  • En revanche, voir quelqu’un qui ne connaît pas le logiciel dire aux développeurs qu’ils travaillent mal, ce n’est pas vraiment quelque chose de positif

• Dire que « le code IA crée 1,7 fois plus de problèmes » ne parle que du nombre de bugs détectés

  • En pratique, comme les revues de PR sont souvent insuffisantes, beaucoup de problèmes dans le code généré par IA passent aussi inaperçus
  • Certaines études disent que les revues de code devraient se concentrer moins sur la chasse aux bugs que sur la compréhension et le partage de la structure
  • À l’inverse, certains estiment que le code IA, avec plus de commentaires et une meilleure lisibilité, est au contraire relu plus attentivement
    • Dans le code humain, on voit plus souvent des commentaires du style « je ne sais pas ce que c’est, mais si on le supprime tout casse »

• Il n’y a pas longtemps, sur .NET, Copilot m’a proposé une implémentation de IComparable, ce qui m’a fait gagner quelques minutes

  • Mais il avait renommé les variables en x et y, et j’ai passé une heure à déboguer
  • Si je l’avais écrit moi-même, je n’aurais pas fait cette erreur
  • Malgré tout, au final, c’était presque exactement le code que j’aurais écrit

• On a déjà connu des situations similaires auparavant

  • En ignorant la gestion des erreurs et les edge cases, on pouvait livrer bien plus vite, mais cela finissait par devenir une bombe à bugs
  • L’IA donne l’impression de pousser cette logique à l’extrême
  • D’où la blague : « à ce compte-là, autant migrer vers Erlang ou Elixir »

• J’ai trouvé intéressant qu’une entreprise centrée sur les LLM affirme que « l’IA est moins nulle qu’on ne le pense »

  • Mais Coderabbit, en tant qu’entreprise de revue de code par LLM, a au contraire intérêt à dire : « l’IA est chaotique, donc il faut la relire avec de l’IA »
  • J’utilise aussi Copilot comme outil de revue, et les revues IA sont presque toujours justes, donc c’est très utile avant une revue humaine

• J’utilise souvent CodeRabbit, mais il y a encore beaucoup de faux positifs

  • Il lui arrive de signaler « absence de validation des données » alors que le code a déjà été vérifié
  • Cela dit, si on lui indique qu’il a tort, l’outil l’apprend et l’accepte

• « 1,7 fois plus » et « augmenté de 1,7 fois » ne veulent pas dire la même chose

  • Mais au fond, ce débat sur les chiffres ressemble surtout à une querelle sans intérêt

• L’agentic AI coding n’est qu’un outil ; mal utilisé, il produira évidemment de mauvais résultats

  • Comme exemple d’usage réussi, je recommande le cas de justhtml en Python
  • En revanche, la logique binaire du type « si tu ne sais pas t’en servir, tu es incompétent » pose problème
    • Que l’on trouve l’IA utile ou non, cela relève simplement d’une différence d’expérience

• La formule du titre, « le code IA crée 1,7 fois plus de problèmes », est imprécise

  • En réalité, les « problèmes » incluent aussi des questions de formatage et de naming, pas seulement des bugs
  • Le chiffre précis sur les bugs n’est pas indiqué dans l’article