- Le livre blanc Coding on Copilot de GitClear analyse, à partir de données sur les modifications de code, si le code assisté par l’IA peut améliorer la productivité tout en pesant sur la qualité et la maintenabilité
- Le code churn, c’est-à-dire le code annulé ou modifié dans les deux semaines suivant son écriture, devrait doubler en 2024 par rapport au niveau de référence d’avant l’IA en 2021
- Après la diffusion de Copilot, la part de code ajouté et de code copié-collé a augmenté, tandis que la baisse du code déplacé suggère un affaiblissement du refactoring et de la réutilisation
- L’étude de GitHub de 2022 estimait que les utilisateurs de Copilot terminaient leurs tâches 55 % plus vite, mais GitClear se concentre sur les coûts de maintenance à long terme plutôt que sur la productivité
- L’analyse de 153 millions de lignes de code modifié, écrites entre janvier 2020 et décembre 2023, montre que les responsables techniques doivent évaluer l’effet de l’adoption de l’IA à l’aune des indicateurs de qualité du code
La nature du code assisté par l’IA selon le livre blanc de GitClear
- Le livre blanc Coding on Copilot étudie quelles différences apparaissent, en matière de qualité et de maintenabilité, entre le code assisté par l’IA et celui qu’un humain aurait écrit
- La question centrale est de savoir si le code assisté par l’IA se rapproche davantage de la contribution soigneusement peaufinée d’un développeur senior, ou du travail fragmenté d’un prestataire de courte durée
- GitClear est une entreprise qui vend un outil de revue de code dans le cloud, et cette étude se concentre sur l’évolution de la composition des changements de code depuis l’adoption de l’IA
Des signaux négatifs sur la maintenabilité
- GitClear a identifié des tendances préoccupantes du point de vue de la maintenabilité
- Le code churn désigne la proportion de lignes de code annulées ou mises à jour dans les deux semaines suivant leur écriture
- Ce taux devrait doubler en 2024 par rapport au niveau de référence d’avant l’IA en 2021
- La proportion de code ajouté et de code copié-collé augmente par rapport au code modifié, supprimé ou déplacé
- Pour cette raison, le code généré par l’IA est jugé similaire à celui d’un contributeur de passage, susceptible d’enfreindre le principe DRY dans les dépôts qu’il visite
Trois changements liés à la diffusion de Copilot
- GitClear met en avant trois évolutions importantes depuis l’adoption de Copilot : le churn, le code déplacé et le code copié-collé
-
Un churn en hausse
- L’« utilisation de Copilot » serait fortement corrélée au push de code erroné dans les dépôts
- Cela est associé à un flux où du code assisté par l’IA est ajouté rapidement, puis annulé ou corrigé peu après
-
Un code déplacé en baisse
- La baisse du code déplacé suggère une diminution du refactoring et de la réutilisation
- Combinée à la hausse du code copié-collé, elle laisse penser que les implémentations actuelles des assistants IA n’encouragent pas suffisamment la réutilisation du code
- Au lieu de favoriser la création de code DRY via le refactoring, elles offrent la tentation de répéter du code existant d’une simple frappe
-
Un code copié-collé en hausse
- Le code copié-collé est considéré comme un facteur de forte charge pour la maintenabilité à long terme
- Lorsque des lignes de code, et non de simples mots-clés, sont répétées, cela est interprété comme un signal indiquant qu’il n’y a pas eu le temps d’évaluer l’implémentation précédente
- Quand on réajoute du code au lieu de le réutiliser, les mainteneurs doivent ensuite fusionner des chemins de code parallèles qui implémentent des fonctions redondantes
Contraste avec les études sur la productivité
- L’étude de GitHub de 2022 estimait que les développeurs utilisant Copilot terminaient leurs tâches 55 % plus vite que ceux qui ne l’utilisaient pas
- Cette même étude mesurait aussi des effets positifs, au-delà de la productivité, sur la satisfaction des développeurs et la préservation de leur énergie mentale
- À la différence de ces résultats sur la productivité, le livre blanc de GitClear analyse surtout les changements dans la composition des modifications de code et dans la maintenabilité lors de l’usage de l’IA
Des évaluations divergentes dans les études associées
- Exploring the Verifiability of Code Generated by GitHub Copilot : l’étude trouve des éléments allant dans le sens du consensus de la littérature existante, selon lequel Copilot est un outil puissant mais ne doit pas « piloter l’avion » seul
- Assessing the Quality of GitHub Copilot's Code Generation : l’analyse empirique conclut que Copilot est un outil prometteur, mais qu’une évaluation plus complète sera nécessaire à l’avenir
- Sea Change in Software Development: Economic and Productivity Analysis of the AI-Powered Developer Lifecycle : à mesure que la maîtrise du prompting génératif progresse, un lien singulier et difficile à dissocier se forme entre l’humain et l’IA
- The Impact of AI on Developer Productivity: Evidence from GitHub Copilot : les effets hétérogènes observés suggèrent qu’un pair programmer IA pourrait aider certaines personnes à se tourner vers une carrière dans le développement logiciel
- Study of software developers' experience using the Github Copilot Tool in the software development process : les avis des développeurs étaient partagés ; les attitudes étaient globalement positives, mais l’intention réelle d’usage restait limitée, et des préoccupations de sécurité ont émergé
Périmètre de l’analyse et questions en suspens
- GitClear a collecté et analysé 153 millions de lignes de code modifié écrites entre janvier 2020 et décembre 2023
- L’étude estime aussi qu’avec la flambée de popularité de l’IA, nous sommes entrés dans une époque où les lignes de code s’ajoutent plus vite que jamais
- La question de 2024 serait moins de savoir comment Copilot va redéfinir le métier de développeur que de déterminer qui prendra en charge le travail de nettoyage qui en découle
1 commentaires
Avis sur Hacker News
J’ai arrêté mon abonnement après 2 mois. Le coût mental de corriger les erreurs de ce flot de vomissures de code était trop élevé, et pour les tâches non triviales ou liées à SQL, c’était presque inutile, même en lui fournissant d’abord tout le schéma.
Comme je sais ce que je veux écrire, c’était beaucoup moins pénible de le faire moi-même, et il était plus facile de corriger mes propres erreurs que celles du bot. Je m’inquiète pour les juniors qui vont se retrouver ensevelis sous ces déchets.
J’utilise ChatGPT au lieu de Copilot, et je suis surpris par tout ce qu’il peut faire, mais il reste difficile d’appeler ça du « bon code ». Je peux lire du JavaScript, mais comme je me suis spécialisé dans iOS ces 14 dernières années, je connais mal les bonnes pratiques côté navigateur, donc je m’en sers ; et même quand j’obtiens du code qui fonctionne globalement, je vois les mauvais choix et les bizarreries.
À propos de l’IA actuelle, je pense que la bonne attitude consiste à éviter les deux extrêmes, « c’est déjà terminé » comme « ce n’est rien ». Aux seconds, il faudrait une analogie du genre : « un chien jongle, remplit une déclaration d’impôts et fait cuire un gâteau, et au lieu d’être impressionné qu’il puisse le faire, on se plaint qu’il laisse tomber les balles, se trompe dans les chiffres et que la recette n’est pas terrible ».
Copilot est surtout utile comme outil d’autocomplétion qui réduit la saisie quand on écrit du code prévisible basé sur le contexte. Si vous écrivez une enum class dans une fenêtre, il peut autocompléter son utilisation dans une autre grâce au contexte ; quand vous rédigez une série de tests unitaires, une pression sur Tab suffit à générer le squelette du cas de test suivant.
En particulier dans les langages dynamiques, Copilot complète assez bien IntelliSense.
Il y a quelques mois, j’ai écrit sur la manière dont l’industrie du doublage et de la voix off finirait inévitablement par être poussée dehors par les modèles de synthèse vocale, avec des exemples dans la composition typographique, la reliure et la gravure musicale : https://news.ycombinator.com/item?id=38491203
Mais si le développement lui-même se vide ainsi de sa substance, je ne sais pas bien quel serait l’état final. Après tout, ce sont les développeurs qui ont mené les remplacements du passé. Une forme de déclin et d’effondrement social ne me paraît pas complètement absurde.
« Analyse ce JSON et insère ces champs au bon endroit dans la base de données » est un excellent cas d’usage pour faire écrire du SQL par Copilot. On pourrait utiliser un plugin ORM ou un middleware, mais pour un MVP ou une maquette, ce serait une optimisation prématurée excessive.
En revanche, j’utilise souvent l’API ChatGPT et je la trouve assez pratique. Quand j’ai écrit un update SQL touchant des millions de lignes, je lui ai demandé de le modifier pour le découper en lots et journaliser l’état après chaque lot ; et quand j’ai eu une erreur 401 en accédant au feed nuget d’Azure DevOps, il m’a donné non seulement la cause, mais aussi le yaml pour corriger le problème.
Dans les deux cas, j’aurais pu le faire moi-même avec un peu de recherche, mais c’est vraiment appréciable de ne pas avoir à passer ce temps à chercher.
GPT-4 a fortement amélioré mon efficacité au travail. Je crée surtout de petites applications PHP CRUD qui résolvent des problèmes du quotidien, et comme je n’utilise ni framework ni structure MVC, le code généré par GPT-4 à partir d’instructions claires est facile à comprendre et fonctionne généralement du premier coup.
En général, je lui demande de modifier un fragment d’environ 25 lignes pour l’adapter à une fonction de reporting précise ; par exemple, si je lui demande de regrouper cette page par X et de sommer Y, il réagit exactement comme il faut. Après une QA et des tests rapides, c’est terminé ; pour des tâches peu complexes et clairement décrites, c’est un changement majeur.
Le processus ressemble à la manière dont un programmeur senior découpe une tâche en composants de base et la confie à un junior. Ici, GPT-4 joue le rôle d’un programmeur junior à 20 dollars par mois, et comme il me fait gagner du temps, je le paie volontiers de ma poche.
Cela dit, comme quand je demandais enfant pourquoi il fallait apprendre les maths alors qu’on avait une calculatrice, je comprends maintenant pourquoi il faut apprendre les bases. Sans les fondamentaux, on ne peut pas l’utiliser efficacement. Si GPT-4 avait existé quand j’apprenais PHP, je ne comprendrais pas les bases aussi bien qu’aujourd’hui. Je bénéficie du fait d’avoir appris avant l’arrivée de l’outil.
Je n’ai pas non plus l’impression que la qualité du code soit particulièrement plus basse ; parfois, au contraire, il produit un résultat plus soigné.
Je pense qu’une grande partie des critiques arrive encore trop tôt ; on est plutôt face à une avancée cahoteuse qui nécessite davantage de support d’infrastructure. Où est l’intégration avec les linters pour éviter de produire des résultats qui ne compilent pas ? Où sont les fonctions capables de détecter et corriger automatiquement les erreurs faciles ?
La forme que les tests devraient prendre dans un environnement de développement avec IA générative, et la manière dont ils devraient évoluer, restent aussi des questions ouvertes. Il existe peut-être de meilleures approches qui maximisent les bénéfices et réduisent les coûts de méthodes procédurales comme le TDD ou le BDD.
Ces un ou deux dernières années, un grand changement technologique a simplement été jeté dans les workflows existants. Avec n’importe quel outil, le résultat vient de la combinaison entre les capacités de l’outil et l’expérience de la personne qui l’utilise.
Le secteur doit accumuler beaucoup plus d’expérience et de sagesse dans l’intégration de l’IA générative au développement pour pouvoir estimer sa valeur nette réelle. Je pense qu’il faut encore au moins 2 ou 3 ans, non pas à cause de l’adaptation de la technologie, mais du temps nécessaire aux humains pour s’adapter.
J’ai déjà vu une équipe de jeunes dans la vingtaine générer des montagnes de spaghetti full-stack par-dessus le framework CRUD de base que j’avais créé. Si l’on peut générer un « MMO framework » en 60 secondes, l’incitation à créer une app TODO à partir de zéro diminue.
C’est un peu comme quand j’ai utilisé Firebase avant d’apprendre les bases du relationnel il y a 12 ans, et qu’il m’a fallu des années pour arriver aux fondamentaux.
On ne peut pas prédire l’avenir avec exactitude, mais je pense que notre manière de percevoir la qualité va changer.
Il règne une ambiance où la technologie semble devoir être le sauveur des grands problèmes dans tous les domaines autour de nous — véhicules électriques, santé, IT, finance, etc. Dans le même temps, il devient de plus en plus clair que la technologie sert surtout à faire grossir les marchés, les gouvernements, les États, etc., et qu’elle fonctionne en ajoutant une couche de plus sur des abstractions qui fuient déjà. On a l’impression qu’elle cherche moins à résoudre les problèmes qu’à en dissoudre les symptômes.
La qualité implique de la lenteur ; le traitement des symptômes a ses limites, et comme l’humain ne pourra pas relever les défis en continuant simplement à empiler toujours plus d’abstractions, cette lenteur deviendra nécessaire, à mon avis.
Je pense que l’idée selon laquelle il faudrait aller plus vite est erronée. En tant qu’humains, si nous cherchons à résoudre les choses pour obtenir des gains superficiels sans comprendre les bases du défi, il n’en sortira pas de qualité.
Les LLM sont un désastre pour notre domaine. Parce qu’ils flattent l’erreur de l’humain moyen qui veut atteindre son objectif sans faire le vrai travail. Le vrai travail consiste à appliquer des hypothèses sur la justesse et à comprendre ce que l’on cherche réellement à résoudre.
Heureusement, tout le monde ne cherche pas à aller plus vite : certains réapprennent les fondamentaux, appliquent des décisions réfléchies et affûtent leur pensée et leurs outils pour produire une qualité qui tiendra dans la durée.
Mon expérience est presque inverse. Au lieu que fouiller dans des API ou des bibliothèques désordonnées bloque la partie difficile, les LLM rendent douloureusement évident le moment où ma réflexion n’est pas solide sur les tâches qui comptent.
Pour faire quelque chose avec un LLM, il faut écrire ; et pour écrire, il faut réfléchir. Ce qui m’est souvent le plus utile, c’est de formuler soigneusement ce que je veux faire, de me faire challenger par le LLM, de trouver et clarifier les zones floues de ma pensée dans le processus, puis de pouvoir relire plus tard l’historique de cette conversation.
C’est particulièrement utile au début d’une app, quand on lui donne forme : cela permet de suivre ce que je pensais devoir faire à ce moment-là, puis de réexaminer plus tard si c’est toujours le cas.
Ils écoutent un pro jouer en club, rentrent chez eux et essaient de l’imiter, mais finissent avec un amas confus sans bases. Il insistait sur le fait qu’il faut se satisfaire de choses simples et construire progressivement des fondations plus solides.
Cette idée s’applique presque telle quelle à l’usage de code généré par l’IA.
Les meubles IKEA en sont un bon exemple. Quand on fabrique soi-même un meuble, la sensation d’être autour de lui est bien meilleure qu’avec les objets façon carton d’IKEA. Mais dans la tête des gens, le coût, la vitesse et la commodité semblent primer.
Les modèles d’IA retirent cette expérience intrinsèque et ne donnent que la crème du résultat final. C’est un peu comme regarder du porno au lieu d’entretenir une vraie relation qui mène au sexe.
Utilisés intelligemment, les outils de type Copilot aident. Ils prennent en charge le boilerplate et les parties ennuyeuses, ce qui permet aux humains de se concentrer sur la réflexion lourde.
En plus, on en est encore au début. Il est trop tôt pour porter un jugement, et ils ne semblent pas près de disparaître.
La méthodologie semble comparer l’activité de commits de 2023 aux années précédentes et interpréter les changements comme une hypothèse, sans savoir quelle part impliquait Copilot. C’est une approche assez fragile.
Il est aussi écrit que « les prévisions pour 2024 ont été réalisées en exécutant une régression quadratique sur les données existantes avec l’Assistant gpt-4-1106-preview d’OpenAI ». Je me demande s’ils ont vraiment demandé à GPT de faire une régression sur quatre points de données au lieu d’utiliser un simple outil de régression comme sklearn, R ou Excel. Même si cela a été fait correctement, avec seulement quatre points de données et la première réserve en plus, ce n’est pas très convaincant.
Dit comme ça, régression quadratique paraît sérieux, mais avec deux points de données, cela revient en fait à « prolonger la ligne telle quelle ». La prédiction pour 2024 n’a donc, sur le fond, presque aucune signification.
Je suis l’auteur de l’étude originale. Je suis heureux de voir que beaucoup de gens se préoccupent de la qualité du code à long terme. Le fait qu’en 2023, le code modifié puis abandonné et la duplication — autrement dit le copier-coller — aient augmenté, tandis que le code déplacé diminuait, a dépassé nos attentes.
J’aimerais que les équipes de développement et les créateurs d’assistants IA adoptent des mesures et des incitations qui encouragent le code réutilisé plutôt que le code nouvellement ajouté. Les équipes placées sous des managers qui pensent qu’il faut inclure les LoC dans l’évaluation des performances sont particulièrement exposées. D’après une étude de GitHub, c’est le cas d’environ un tiers d’entre elles, et la génération actuelle d’outils d’assistance au code rend trop facile le fait d’appuyer sur Tab puis de committer, en plantant ainsi de la dette technique pour l’avenir. Comme l’a dit Adam Tornhill sur Twitter : « le défi central de la programmation assistée par IA est qu’il devient trop facile de générer en masse du code qu’il n’aurait jamais fallu écrire ».
Cela dit, la portée de l’étude actuelle est limitée par le fait qu’elle ne mesure pas directement le code écrit par l’IA. Elle ne fait que tracer la corrélation entre la qualité du code et la diffusion des assistants IA au cours des quatre dernières années. J’aimerais que GitHub ou d’autres entreprises d’assistants IA collaborent à une étude de suivi afin de mesurer directement les différences de qualité entre du « code entièrement suggéré par l’IA », du « code suggéré par l’IA puis modifié par un humain » et du « code écrit à partir de zéro ».
Dans la prochaine étude, j’aimerais aussi mesurer directement comment la fréquence des bugs évolue avec l’usage de l’IA. Si vous avez d’autres idées de choses qu’il serait utile de mesurer, n’hésitez pas à les proposer. J’essaie de publier un nouvel article de recherche environ tous les deux mois.
La réutilisation du code peut être puissante au sein d’une même base de code, mais j’ai aussi vu qu’elle pouvait créer de la confusion lorsqu’elle traverse les frontières entre bases de code. Elle peut être utile, ou bien inappropriée et source de confusion ; le résultat dépend en grande partie du jugement.
Je pense qu’il vaut mieux évaluer les développeurs sur les résultats du logiciel. Par exemple, l’impact organisationnel rapporté à l’utilisation des ressources, ou les erreurs de service qui ne proviennent pas de services dépendants ni de l’infrastructure.
Le programmeur moderne n’est pas seulement responsable du code : c’est un mélange assumé d’ingénieur qualité/testeur, de chef de produit technique, de chef de projet, de programmeur, d’ingénieur performance et d’ingénieur infrastructure. Je ne cherche pas à dénigrer l’étude elle-même ; je suis content qu’il y ait des gens qui se soucient profondément de la qualité du code, mais je pense qu’il faut envisager autrement la façon d’évaluer.
Je me demande aussi s’ils ont contrôlé d’autres explications possibles, comme l’évolution de l’économie de la tech.
Cet article a benchmarké les performances des LLM les plus populaires sur des tâches de refactoring de code réel, et indique que l’IA n’a fourni un refactoring fonctionnellement correct que dans 37 % des cas.
Le codage assisté par IA est réellement utile, mais il faut continuer à garder des humains expérimentés dans la boucle et fixer des attentes réalistes au-delà du discours marketing.
Mon flux de travail consiste généralement à parcourir la documentation, faire un prototype, nettoyer un peu le code, ajouter des tests, déplacer des choses, les casser, retravailler, étudier la documentation, refactorer davantage, puis seulement ensuite comprendre suffisamment le problème pour supprimer 80 % du code et le reconstruire correctement.
Si Copilot me donne, à l’étape du prototype, du code qui fonctionne suffisamment bien pour que je passe simplement à la suite, je n’approfondis pas assez ma compréhension pour structurer correctement l’ensemble. Il permet de sauter 90 % du flux de travail, mais il y a un prix à payer. Bien sûr, dans les dernières étapes du développement, Copilot peut être très utile.
Si les résultats de l’étude sont justes, cela ne me surprend pas. Le mauvais code vient d’une compréhension insuffisante, et Copilot ne peut pas avoir une compréhension supérieure à celle que je lui fournis. Il peut écrire du code meilleur que celui d’un programmeur moyen, mais le résultat ne peut pas être meilleur que l’entrée. Les gens se concentrent tellement sur le « prompt engineering » ; je ne comprends pas pourquoi ils s’étonnent qu’un mauvais « prompt » dans VSCode produise un mauvais résultat.
D’après mon expérience, Copilot est excellent pour aider à démarrer. Le code est parfois bon, parfois quelconque, parfois complètement cassé.
Mais il est précieux parce qu’il aide à lancer la réflexion. Avant de l’utiliser, je perdais beaucoup plus de temps. C’est peut-être simplement que mes circuits cérébraux sont particuliers.
Je suis junior et j’ai installé Codeium dans VSCode, mais la plupart du temps c’est très distrayant. Je ne comprends pas très bien pourquoi autant de gens utilisent ce genre d’assistants.
Des outils comme Phind sont utiles. Quand quelque chose m’échappe, dans environ 60 % des cas ça m’aide à comprendre le problème. Typiquement, ça trouve de petits bugs que je n’avais pas vus parce que j’étais fatigué ou à côté de la plaque.
En revanche, Codeium peut être utile pour générer du boilerplate de framework, mais dans ma petite expérience — scrapers, pipelines de données simples, JS pur + HTML/CSS — parcourir ses suggestions est très agaçant. Surtout parce que ça ne fonctionne souvent pas, parfois pour une raison triviale comme un argument manquant, et qu’il faut quand même passer du temps à déboguer.
En JavaScript, il y a aussi ce style courant qui consiste à enchaîner sans fin des méthodes et des fonctions anonymes comme une guirlande, et je trouve ça vraiment pénible. Je préfère découper les lignes et donner des noms aux fonctions et aux variables. Les suggestions de code suivent souvent ce style, probablement à cause des données d’entraînement. Codeium dit qu’il apprend de ça, et parfois c’est effectivement le cas.
Ce qui m’inquiète le plus, c’est que si, en tant que junior, je confie mon code à ce genre d’assistant, comment suis-je censé apprendre ? Donner du contexte et des questions à Phind peut aider à apprendre, ou au moins indiquer une direction à explorer soi-même sur Internet, mais je ne vois pas comment on apprend en appuyant simplement sur Tab.
Il y a quelques jours, j’ai compris que beaucoup de gens, développeurs compris, utilisent les LLM non pas comme un outil pour progresser, mais comme un substitut à l’effort. Ce n’est pas seulement la peur d’être remplacé par l’entreprise : même du point de vue de l’introspection, je trouve ça inquiétant.
Le code n’est pas la passion de ma vie, mais j’aime ça. Parce que ça permet de faire advenir des choses et de gérer de la complexité. Si on ne comprend pas ce qui se passe, on ne peut rien construire, et on ne peut pas non plus voir quand la complexité est en train de nous dévorer.
Continue comme ça, ne change pas, et tu iras dans la bonne direction. Tu es clairement sur la bonne voie.
Le point important, c’est que j’ai tellement écrit de spécifications d’API à la main au cours de ma carrière que 1) je voyais immédiatement les problèmes et 2) je pouvais les corriger sans aide supplémentaire. Corriger les modèles à la main allait plus vite que peaufiner le prompt.
Dans un domaine que l’on connaît bien, c’est étonnant de voir une tâche qui aurait pris toute la matinée être faite en 30 secondes. En revanche, je ne demande pas à l’IA de faire des choses que je ne saurais pas faire moi-même. À la place, je discute beaucoup avec elle des compromis, des problèmes de sécurité potentiels, etc., autour de ce sur quoi je travaille.
C’est comme un ingénieur junior titulaire d’un doctorat dans le langage que j’utilise. Il ne comprend pas beaucoup de choses, mais ce qu’il comprend, il semble le comprendre en profondeur.
Certains développeurs, surtout en JS, adorent le chaînage alors qu’il n’apporte aucun bénéfice à part tout garder sur une seule ligne. Et ce n’est pas un bénéfice. Continue comme tu fais, et ne laisse pas cet idiome stupide infecter ton esprit.
Les moments où cette technologie impressionne, c’est quand elle s’aligne sur mon style et mes préférences : nommer les choses comme je le souhaite, réutiliser correctement la méthode que je viens d’écrire plutôt que réimplémenter la même logique, etc.
Je ne l’ai pas beaucoup utilisée sur des projets vides ou petits, mais si l’outil ne s’appuie pas fortement sur le contexte environnant pour se caler sur la manière dont j’écris déjà, j’imagine que l’expérience doit être beaucoup moins idéale.
Le principal usage des assistants IA, pour moi, a été d’écrire des tests et d’accélérer les modifications répétitives du type « comme ceci, mais un peu différent ». Avec IntelliJ + GitHub, quand un nouveau paramètre doit être répercuté dans plusieurs méthodes et fichiers, il suffit souvent de saisir soi-même les deux ou trois premières variantes, puis le reste se fait avec entrée + tab. Le contexte remplit la suite.
Codeium dans VSCode semble moins abouti côté IA, et le plugin donne aussi l’impression que les touches de suggestion et d’acceptation interfèrent souvent de façon gênante. Ça reste utile pour les tâches répétitives, mais moins pour proposer une manière d’atteindre l’objectif.
J’ai décidé d’essayer de créer avec ChatGPT un clone de Yourls basé sur Django/Python. Je lui avais explicitement demandé de permettre des URL courtes personnalisées et de suivre le trafic, mais il ne l’a pas vraiment pris correctement en compte dans la logique ni dans le modèle de données. Pour corriger ça ensuite, il a fallu lui redonner des instructions précises.
Les outils d’IA ressemblent à un développeur junior qui fait le travail. Mais en beaucoup plus rapide.
Si on ne sait pas ce qu’on fait, on ne fait qu’accélérer la vitesse à laquelle on commet des erreurs.
Récemment, je devais ajouter un préfixe de nom de table aux alias de colonnes dans une requête SELECT. Comme il n’y avait pas de fonctionnalité pour ça, j’ai donné à ChatGPT la définition du schéma et la requête, et je lui ai demandé d’écrire la longue liste d’environ 40 colonnes sélectionnées.
Je n’ai pas trouvé de bonne façon d’automatiser ça dans plusieurs SGBDR ; c’était possible avec des expressions régulières ou d’autres manipulations de texte, mais expliquer le problème et recevoir la sortie voulue était agréablement simple.
À part ça, j’utilise les LLM comme une forme d’autocomplétion. Ça a aussi pour effet d’inciter à choisir de bons noms de fonctions, parce qu’avec ce niveau d’information, le LLM donne souvent un point de départ raisonnable. C’est particulièrement utile avec des API ou des langages que je n’ai pas beaucoup utilisés, quand le problème que je rencontre a déjà été résolu des milliers de fois. Je n’utilise presque plus StackOverflow.
C’est pour ça que j’ai acheté Copilot et que j’utilise aussi beaucoup ChatGPT. Les LLM font partie de mes outils préférés, avec une bonne autocomplétion façon IntelliSense, la génération de spécifications OpenAPI ou de code EF/JPA, les migrations de base de données et créations de tables à partir de modèles ER, les conteneurs, et les IDE intelligents comme JetBrains.
Les entreprises voudront plus de code, plus vite, et j’ai l’impression que dans ce tourbillon, il y aura moins de gens qui sauront vraiment ce qu’ils font.
L’article complet est ici : https://gitclear-public.s3.us-west-2.amazonaws.com/Coding-on...
Avant même que les outils d’assistance par « IA » arrivent sur le marché, il y avait déjà un retour de bâton contre le code DRY et, malheureusement, c’était une tendance qui prenait de l’ampleur quand j’utilisais Twitter entre 2019 et 2022
Certains jeunes développeurs ont une attitude vis-à-vis du code très différente de celle qu’on m’a enseignée. Ils méprisent énormément le Gang of Four et les design patterns, et semblent ignorer que leurs frameworks préférés en sont justement remplis. Ils parlent avec sarcasme de principes comme DRY, et surtout SOLID
Sur des endroits comme Twitter, plus un propos est sarcastique et tape sur le camp d’en face, plus il génère d’engagement. C’est une tendance assez inquiétante
J’éprouve moi aussi un profond mépris pour ce qui se passe dans les bases de code d’entreprise. Quoi qu’en disent les gourous de SOLID, empiler des couches d’indirection via des classes n’est pas acceptable. Les bonnes pratiques, DRY et SOLID servent juste d’excuses
Ce que je ne supporte pas, c’est qu’on traite une liste arbitraire de principes issue de la pensée orientée objet à la Java comme s’il s’agissait de vérités sur la modélisation logicielle. Je suis aussi lassé de la énième discussion sur la manière dont il faudrait comprendre SOLID
Les gens ne se disputent pas autant à propos du théorème CAP, parce que ce n’est pas un assemblage arbitraire d’idées formant un acronyme élégant
DRY peut aussi être abusé, et la réaction vise simplement l’attitude consistant à le traiter comme quelque chose de parfait
Par exemple, le principe important de DRY n’était pas de ne pas répéter du code, mais de ne pas répéter des idées. Pour chaque concept d’un système, il devrait idéalement y avoir une source unique de vérité, et un seul endroit à comprendre ou à modifier quand on traite ce concept
C’est pourquoi copier-coller une quantité non négligeable de code au lieu de créer une abstraction pertinente est souvent mauvais. En même temps, c’est aussi un avertissement : dès qu’on répète une idée, on crée une dette permanente liée à la nécessité de synchroniser ses différentes représentations. Cela vaut pour des migrations de base de données qui définissent un schéma et des classes ORM séparées, pour une API backend et un client frontend, pour les valeurs d’un formulaire et l’état interne dans une UI en retained mode, ou encore pour des invariants de modèle de données exprimés à la fois dans les types et dans les tests unitaires
Ceux qui disent que fusionner de force des idées différentes simplement parce qu’elles ont par hasard une implémentation similaire crée un risque de maintenance à l’avenir n’ont pas tort. Mais ils attaquent un homme de paille qui n’a jamais été le propos initial de DRY
Le problème, maintenant, est de savoir où et quand les nouveaux développeurs apprennent correctement ces principes. Certains ont une formation universitaire, mais ce n’est pas le cas de tout le monde, et les cursus académiques en informatique n’ont pas forcément vocation à enseigner beaucoup de compétences pratiques de développement
Quand j’ai commencé, les seniors formaient concrètement et substantiellement les juniors, mais avec la culture actuelle des changements fréquents d’emploi et la réticence à embaucher des juniors comme investissement de long terme, cela semble beaucoup moins courant. Les cours formels sont chers pour un individu, mais presque négligeables à l’échelle d’une entreprise ; pourtant, très peu de nouveaux développeurs y sont effectivement envoyés par leur employeur
Il existe aussi des livres qui valent la peine d’être lus, mais je ne sais pas si les personnes dans la vingtaine en 2024 ont envie de s’attaquer à ce vieux format consistant en de l’encre imprimée sur des morceaux d’arbres découpés. Les développeurs en progression aujourd’hui semblent apprendre beaucoup de ces idées via des blogs et YouTube ; on y trouve d’excellentes ressources, mais le problème reste toujours de les dénicher au milieu de contenus mal compris ou emballés de manière douteuse
Donc, quand apparaît un outil magique capable de produire en un battement de cœur 12 lignes de code qui fonctionnent à peu près, il n’est pas surprenant que de jeunes développeurs trouvent ce code excellent tout en ignorant presque tout de ses problèmes plus profonds. Il est difficile d’imputer cela à quelqu’un en particulier, mais c’est clairement un problème, et j’aimerais savoir quoi faire