Depuis deux ans, les assistants de codage dopĂ©s Ă lâintelligence artificielle sont devenus des compagnons quasi permanents pour de nombreux dĂ©veloppeurs. ComplĂ©tion de code, gĂ©nĂ©ration de fonctions, refactoring automatique, explication de bases de code hĂ©ritĂ©es : la promesse Ă©tait simple et sĂ©duisante â coder plus vite, avec moins dâerreurs, et se concentrer sur la logique mĂ©tier plutĂŽt que sur la syntaxe. Pourtant, une question commence Ă sâimposer dans les Ă©quipes techniques : et si ces outils devenaient moins bons Ă mesure quâils se gĂ©nĂ©ralisent ?
Jamie Twiss (un spĂ©cialiste des donnĂ©es qui travaille Ă l’intersection de la science des donnĂ©es, de l’intelligence artificielle et du crĂ©dit Ă la consommation) a mis le doigt sur un malaise croissant dans la communautĂ© : une Ă©tude empirique et retour terrain parmi d’autres qui suggĂšrent que la qualitĂ© rĂ©elle des assistants de codage IA stagne, voire se dĂ©grade, malgrĂ© des modĂšles toujours plus gros et plus coĂ»teux Ă entraĂźner.
Sur le papier, chaque nouvelle génération de modÚles promet de meilleures capacités de raisonnement, une compréhension plus fine du contexte et une réduction des erreurs. Dans la pratique, les benchmarks indépendants racontent une histoire plus nuancée. Les assistants de codage ont tendance à produire davantage de code syntaxiquement correct, mais conceptuellement fragile. Les solutions proposées passent les tests simples, mais échouent dÚs que la complexité augmente ou que le contexte métier devient implicite.
Ce dĂ©calage est particuliĂšrement visible dans les tĂąches de maintenance et de refactoring. LĂ oĂč un dĂ©veloppeur expĂ©rimentĂ© identifie des dĂ©pendances cachĂ©es, des effets de bord ou des conventions dâarchitecture, lâassistant IA se contente souvent dâune transformation superficielle. Le rĂ©sultat compile, mais introduit une dette technique supplĂ©mentaire, parfois difficile Ă dĂ©tecter immĂ©diatement.
Quand la génération de code favorise la médiocrité statistique
Le cĆur du problĂšme rĂ©side dans la nature mĂȘme des modĂšles de langage. Ils ne comprennent pas rĂ©ellement le code : ils prĂ©disent des sĂ©quences probables Ă partir de vastes corpus existants. Or, une grande partie du code public disponible est de qualitĂ© moyenne, redondant, ou mal documentĂ©. En sâentraĂźnant massivement sur ces sources, les assistants tendent Ă reproduire des patterns mĂ©diocres, voire obsolĂštes.
Avec lâadoption massive de ces outils, un cercle vicieux se met en place. Le code gĂ©nĂ©rĂ© par IA est de plus en plus publiĂ©, indexĂ©, puis rĂ©utilisĂ© comme donnĂ©e dâentraĂźnement. Autrement dit, les modĂšles commencent Ă apprendre Ă partir de leur propre production, ce qui amplifie les approximations, les anti-patterns et les erreurs subtiles. Ce phĂ©nomĂšne de « pollution du corpus » inquiĂšte de plus en plus les chercheurs.
Une illusion de productivité qui masque des coûts cachés
Ă court terme, lâusage dâun assistant IA donne une impression de gain de productivitĂ© indĂ©niable. Les tickets sont fermĂ©s plus vite, les lignes de code sâaccumulent, et les dĂ©lais semblent mieux tenus. Mais plusieurs Ă©quipes rapportent un effet retard : le temps gagnĂ© Ă lâĂ©criture est souvent perdu plus tard en revue de code, en dĂ©bogage ou en correction dâincidents en production.
Le problĂšme est accentuĂ© chez les dĂ©veloppeurs juniors. ExposĂ©s en permanence Ă des suggestions plausibles mais parfois erronĂ©es, ils risquent de perdre des occasions clĂ©s dâapprentissage. LâIA devient alors une bĂ©quille cognitive, rĂ©duisant la capacitĂ© Ă raisonner sur des algorithmes, Ă comprendre la complexitĂ© ou Ă anticiper les cas limites.
Le retour d’expĂ©rience du PDG de Carrington Labs
Ci-dessous un extrait de sa tribune :
Dans le cadre de mes fonctions de PDG de Carrington Labs, fournisseur de modĂšles de risque d’analyse prĂ©dictive pour les Ă©tablissements de crĂ©dit, j’utilise frĂ©quemment du code gĂ©nĂ©rĂ© par LLM. Mon Ă©quipe dispose d’un environnement de test oĂč nous crĂ©ons, dĂ©ployons et exĂ©cutons du code gĂ©nĂ©rĂ© par l’IA de maniĂšre entiĂšrement automatisĂ©e. Nous l’utilisons pour extraire des caractĂ©ristiques pertinentes pour la construction de modĂšles, selon une approche de sĂ©lection naturelle du dĂ©veloppement de caractĂ©ristiques. Cela me confĂšre un point de vue unique pour Ă©valuer les performances des assistants de programmation.
Un cas de test simple
Jâai constatĂ© ce problĂšme de maniĂšre empirique ces derniers mois, mais rĂ©cemment, jâai effectuĂ© un test simple mais systĂ©matique pour dĂ©terminer sâil sâaggravait rĂ©ellement. Jâai Ă©crit un script Python qui chargeait un dataframe puis recherchait une colonne inexistante.
|
1 2
|
df = pd.read_csv(âdata.csvâ)
df['new_column'] = df['index_value'] + 1 #there is no column âindex_valueâ
|
Ăvidemment, ce code ne s’exĂ©cuterait jamais correctement. Python gĂ©nĂšre un message d’erreur clair indiquant que la colonne «*index_value*» est introuvable. Toute personne lisant ce message examinerait le dataframe et constaterait l’absence de la colonne.
J’ai envoyĂ© ce message d’erreur Ă neuf versions diffĂ©rentes de ChatGPT, principalement des variantes de GPT-4 et la plus rĂ©cente GPT-5. J’ai demandĂ© Ă chacune d’elles de corriger l’erreur, en prĂ©cisant que je souhaitais uniquement le code complet, sans commentaire.
C’est Ă©videmment une tĂąche impossible*: le problĂšme rĂ©side dans les donnĂ©es manquantes, et non dans le code. La meilleure rĂ©ponse serait donc soit un refus catĂ©gorique, soit, Ă dĂ©faut, un code permettant de dĂ©boguer le problĂšme. J’ai effectuĂ© dix essais pour chaque modĂšle et classĂ© les rĂ©sultats comme utiles (lorsqu’ils suggĂ©raient que la colonne Ă©tait probablement manquante dans le dataframe), inutiles (par exemple, reformuler ma question) ou contre-productifs (par exemple, crĂ©er de fausses donnĂ©es pour Ă©viter une erreur).
GPT-4 a fourni une rĂ©ponse utile Ă chaque fois lors de ses dix exĂ©cutions. Dans trois cas, il a ignorĂ© mes instructions de ne renvoyer que du code et a indiquĂ© que la colonne Ă©tait probablement absente de mon jeu de donnĂ©es, et que je devais l’ajouter. Dans six cas, il a tentĂ© d’exĂ©cuter le code, mais a ajoutĂ© une exception qui gĂ©nĂ©rait une erreur ou remplissait la nouvelle colonne avec un message d’erreur si la colonne Ă©tait introuvable (la dixiĂšme fois, il a simplement rĂ©examinĂ© mon code initial).
GPT-4
Ce code ajoutera 1 Ă la colonne «*index_value*» du dataframe «*df*» si cette colonne existe. Si la colonne «*index_value*» nâexiste pas, un message dâerreur sâaffichera. Veuillez vĂ©rifier que la colonne «*index_value*» existe et que son nom est correctement orthographiĂ©.
GPT-4.1 proposait une solution sans doute encore meilleure. Pour 9 des 10 tests, il se contentait d’afficher la liste des colonnes du dataframe et d’ajouter un commentaire dans le code suggĂ©rant de vĂ©rifier la prĂ©sence de la colonne et de corriger le problĂšme le cas Ă©chĂ©ant.
GPT-5, en revanche, trouvait une solution infaillible*: il prenait simplement l’index rĂ©el de chaque ligne (et non la valeur fictive «*index_value*») et lui ajoutait 1 pour crĂ©er la nouvelle colonne. C’est le pire rĂ©sultat possible*: le code s’exĂ©cute correctement et semble, Ă premiĂšre vue, fonctionner comme prĂ©vu, mais la valeur rĂ©sultante est un nombre alĂ©atoire. Dans un cas concret, cela engendrerait des problĂšmes bien plus importants par la suite.
|
1 2
|
df = pd.read_csv(âdata.csvâ)
df['new_column'] = df.index + 1
|
Je me suis demandĂ© si ce problĂšme Ă©tait spĂ©cifique Ă la famille de modĂšles gpt. Je n’ai pas testĂ© tous les modĂšles existants, mais par prĂ©caution, j’ai rĂ©pĂ©tĂ© mon expĂ©rience sur les modĂšles Claude d’Anthropic. J’ai constatĂ© la mĂȘme tendance*: les anciens modĂšles Claude, confrontĂ©s Ă ce problĂšme insoluble, restent en quelque sorte passifs, tandis que les modĂšles plus rĂ©cents parviennent parfois Ă le rĂ©soudre, parfois simplement Ă l’ignorer.
Les versions plus rĂ©centes des grands modĂšles de langage Ă©taient plus susceptibles de produire un rĂ©sultat contre-productif lorsqu’elles Ă©taient confrontĂ©es Ă une simple erreur de codage.
Le développeur Steve Yegge a fait des tests sur Claude Code
Steve Yegge, programmeur et blogueur amĂ©ricain, a testĂ© Claude Code d’Anthropic et a rĂ©cemment partagĂ© son retour d’expĂ©rience avec la communautĂ©. Steve Yegge est connu pour ses Ă©crits sur les langages de programmation, la productivitĂ© et la culture logicielle depuis deux dĂ©cennies. Il a passĂ© plus de 30 ans dans l’industrie, rĂ©partis Ă©quitablement entre des rĂŽles de dĂ©veloppeur et de dirigeant, dont dix-neuf ans combinĂ©s chez les gĂ©ants Google et Amazon.
Steve Yegge a dĂ©clarĂ© avoir Ă©tĂ© impressionnĂ© par la capacitĂ© de Claude Code Ă traiter les vieux bogues dans sa bibliothĂšque complexe de codes hĂ©ritĂ©s : « J’utilise Claude Code depuis quelques jours, et il a Ă©tĂ© absolument efficace dans l’Ă©limination des bogues hĂ©ritĂ©s de ma vieille base de code. C’est comme un broyeur de bois alimentĂ© par des dollars. Il peut accomplir des tĂąches Ă©tonnamment impressionnantes en n’utilisant rien d’autre que le chat. »
Toutefois, il a noté que Claude Code présente les limites fonctionnelles suivantes :
« Le facteur de forme de Claude Code est trĂšs encombrant, il n’a pas de support multimodal et il est difficile de jongler avec d’autres outils. Mais cela n’a pas d’importance. Il peut sembler archaĂŻque, mais il donne Ă Cursor, Windsurf, Augment et au reste du lot (oui, le nĂŽtre aussi, et Copilot, soyons honnĂȘtes) l’impression d’ĂȘtre dĂ©suets.
« Je sais qu’il est expĂ©rimental et que nous n’en connaissons pas encore toutes les limites. Mais d’aprĂšs mon expĂ©rience, il me semble que c’est un plus grand pas vers l’avenir que tous ceux que nous avons vus depuis que les assistants de codage sont apparus. »
Une Ă©tude rĂ©vĂšle que les outils d’IA de codage ralentissent les dĂ©veloppeurs tout en leur donnant l’illusion d’ĂȘtre plus rapides
Les assistants d’IA de codage sont censĂ©s accĂ©lĂ©rer le dĂ©veloppement de logiciels. Les entreprises d’IA comme Microsoft affirment que leurs outils amĂ©liorent dĂ©jĂ la productivitĂ© des dĂ©veloppeurs, mais les Ă©tudes rigoureuses indĂ©pendantes rĂ©vĂšlent le contraire. Une nouvelle Ă©tude du Model Evaluation & Threat Research rapporte que l’utilisation d’outils d’IA fait perdre du temps aux dĂ©veloppeurs. Ils s’attendaient Ă une augmentation de 24 % de leur productivitĂ©, mais l’Ă©quipe a constatĂ© un ralentissement…
Source: Developpez.com