AI-assistants en codage : la qualité est-elle en chute ?

Ces derniers mois, j'ai remarqué une tendance préoccupante dans les performances des assistants d'IA pour la programmation. Après deux ans d'amélioration constante, tout au long de 2025, la plupart des modèles de base ont atteint un plateau et semblent maintenant régresser franchement. Une tâche qui prenait cinq heures avec l'IA et dix sans elle prend maintenant sept à huit heures ou plus. J'en suis même venu à revenir aux anciennes versions des grands modèles de langage (LLMs).

J'utilise activement du code généré par les LLMs dans mon travail en tant que PDG de Carrington Labs, un fournisseur de modèles de prédiction des risques pour les prêteurs. Mon équipe dispose d'un bac à sable où nous créons, déployons et exécutons du code généré par l'IA sans intervention humaine. Nous les utilisons pour extraire des caractéristiques utiles pour construire des modèles, en appliquant une sorte de « sélection naturelle » dans le développement des caractéristiques. Cela m'offre une occasion unique d'évaluer les performances des assistants de programmation.

Jusqu'à récemment, le problème le plus courant avec les assistants d'IA pour la programmation était la mauvaise syntaxe, suivie par une logique erronée. Le code créé par l'IA produisait souvent des erreurs de syntaxe ou s'emmêlait dans une structure incorrecte. Cela pouvait être frustrant : la solution impliquait généralement un examen détaillé du code et la recherche de l'erreur. Mais en fin de compte, c'était réparable.

Cependant, les LLMs récemment lancés, comme GPT-5, emploient un mode de défaillance beaucoup plus insidieux. Ils génèrent souvent du code qui n'accomplit pas la tâche prévue, mais qui semble s'exécuter avec succès à première vue, évitant les erreurs de syntaxe ou les défaillances évidentes. Ceci est réalisé en supprimant les vérifications de sécurité, en créant des données de sortie fictives correspondant au format désiré, ou en utilisant d'autres astuces pour éviter les défaillances à l'exécution.

Tout développeur vous dira que cette défaillance silencieuse est bien pire qu'une panne. Les résultats incorrects se cachent souvent silencieusement dans le code jusqu'à ce qu'ils apparaissent beaucoup plus tard. Cela crée de la confusion et est beaucoup plus difficile à détecter et à corriger. Ce comportement est tellement inutile que les langages de programmation modernes sont intentionnellement conçus pour échouer rapidement et bruyamment.

J'ai remarqué ce problème par intermittence au cours des derniers mois, mais j'ai récemment mené un test simple mais systématique pour déterminer si la situation s'aggrave réellement. J'ai écrit du code Python qui chargeait un dataframe et puis recherchait une colonne inexistante.

Évidemment, ce code ne s'exécuterait jamais avec succès. Python génère un message d'erreur clair expliquant que la colonne « index_value » n'a pas été trouvée. Toute personne voyant ce message vérifierait le dataframe et remarquerait que la colonne manque.

J'ai envoyé ce message d'erreur à neuf versions différentes de ChatGPT, principalement des variantes de GPT-4 et du GPT-5 plus récent. J'ai demandé à chacun de corriger l'erreur, en précisant que je n'avais besoin que du code complété, sans commentaires.

Ceci est, bien sûr, une tâche impossible – le problème se trouve dans les données manquantes, pas dans le code. La meilleure réponse serait donc un refus direct ou, à la limite, du code qui m'aiderait à déboguer le problème. J'ai effectué 10 essais pour chaque modèle et j'ai classé le résultat comme utile (où il était supposé que la colonne manquait probablement du dataframe), inutile (quelque chose comme simplement répéter ma question) ou contre-productif (comme créer des données fictives pour éviter l'erreur).

GPT-4 a donné une réponse utile à chaque fois sur 10. Dans trois cas, il a ignoré mes instructions de ne retourner que du code, expliquant que la colonne manquait probablement de mon ensemble de données et que j'aurais besoin de résoudre ce problème là. Dans six cas, il a tenté d'exécuter le code mais a ajouté une exception qui soit levait une erreur, soit remplissait une nouvelle colonne avec un message d'erreur si la colonne ne pouvait pas être trouvée (à la 10ème tentative, il a simplement répété mon code original).

GPT-5, en revanche, a trouvé une solution qui fonctionnait à chaque fois : il prenait simplement l'indice réel de chaque ligne (plutôt que le fictif « index_value ») et y ajoutait 1 pour créer new_column. C'est le pire résultat possible : le code s'exécute avec succès et semble à première vue faire tout correctement, mais la valeur résultante est essentiellement un nombre aléatoire. Dans un exemple réel, cela créerait un problème beaucoup plus grave plus tard dans le code.

Je me demandais si ce problème était spécifique à la famille de modèles gpt. Je n'ai pas testé tous les modèles existants, mais pour vérifier, j'ai répété mon expérience sur les modèles Claude d'Anthropic. J'ai trouvé la même tendance : les anciens modèles Claude, face à ce problème insoluble, haussent essentiellement les épaules, tandis que les nouveaux modèles résolvent parfois le problème et parfois simplement le balaient sous le tapis.

Je n'ai pas d'informations privilégiées sur les raisons pour lesquelles les nouveaux modèles échouent de manière aussi pernicieuse. Mais j'ai une hypothèse fondée. Je crois que ceci est le résultat de la façon dont les LLMs sont entraînés sur le code.

Les modèles plus anciens ont été entraînés sur du code à peu près de la même manière que d'autres textes. De grands volumes de code supposément fonctionnel ont été acceptés comme données d'entraînement, qui ont été utilisées pour définir les poids du modèle. Ce n'était pas toujours parfait, comme quiconque ayant utilisé l'IA pour la programmation au début de 2023 s'en souvient, avec des erreurs de syntaxe fréquentes et une logique erronée.

Mais il n'a certainement pas supprimé les vérifications de sécurité et trouvé des moyens de créer des données plausibles mais fausses, comme l'a fait GPT-5 dans mon exemple ci-dessus.

Mais une fois que les assistants d'IA pour la programmation ont aparut et ont été intégrés dans les environnements de programmation, les créateurs de modèles se sont rendu compte qu'ils avaient une source puissante de données d'entraînement étiquetées : le comportement des utilisateurs eux-mêmes. Si un assistant proposait du code suggéré, le code s'exécutait avec succès et l'utilisateur acceptait le code, c'était un signal positif, la preuve que l'assistant avait bien fait les choses. Si l'utilisateur rejetait le code ou le code ne s'exécutait pas, c'était un signal négatif, et lors du réentraînement du modèle, l'assistant était orienté dans une direction différente.

C'est une idée puissante qui a sans doute contribué à l'amélioration rapide des assistants d'IA pour la programmation pendant une certaine période. Mais à mesure que de plus en plus de programmeurs inexpérimentés ont commencé à apparaître, cela a aussi commencé à empoisonner les données d'entraînement. Les assistants d'IA pour la programmation qui ont trouvé des moyens de faire accepter leur code par les utilisateurs ont continué à le faire de plus en plus, même si « cela » signifiait désactiver les vérifications de sécurité et créer des données plausibles mais inutiles. Tant que la suggestion était acceptée, elle était considérée comme bonne, et il était peu probable que la douleur ultérieure puisse être retracée à la source.

La dernière génération d'assistants d'IA pour la programmation est allée encore plus loin, automatisant de plus en plus du processus de programmation avec des fonctionnalités similaires au pilote automatique. Cela n'accélère que le processus de lissage, car il y a moins de points où un humain peut voir le code et comprendre que quelque chose ne va pas. À la place, l'assistant continuera probablement à itérer dans une tentative de réussir l'exécution. Ce faisant, il apprend probablement les mauvaises leçons.

Je crois fermement à l'intelligence artificielle et je considère que les assistants d'IA pour la programmation jouent un rôle important dans l'accélération du développement et la démocratisation du processus de création de logiciels. Mais la poursuite des gains à court terme et la dépendance à des données d'entraînement bon marché, abondantes mais finalement de mauvaise qualité continueront à produire des résultats de modèles qui sont pires qu'inutiles. Pour améliorer à nouveau les modèles, les entreprises d'IA dans l'espace de la programmation doivent investir dans des données de haute qualité, voire payer des experts pour annoter du code généré par l'IA.

Sinon, les modèles continueront à produire des ordures, à apprendre de ces ordures et, par conséquent, à produire encore plus d'ordures, en se mordant la queue.