Résumé
- Aperçu de l’étude
- Cette étude évalue l’impact de l’IA générative sur la productivité des développeurs logiciels à travers trois expériences contrôlées randomisées menées chez Microsoft, Accenture et une entreprise anonyme de fabrication électronique du Fortune 100.
- Les expériences ont été réalisées dans le cadre du travail quotidien de chaque entreprise, en fournissant à des développeurs sélectionnés aléatoirement GitHub Copilot, un assistant de codage basé sur l’IA.
- Menée auprès de 4 867 développeurs logiciels au total, l’étude a constaté une hausse de 26,08 % du nombre de tâches terminées chez les développeurs utilisant des outils d’IA (erreur standard : 10,3 %).
- Les développeurs les moins expérimentés ont notamment montré des taux d’adoption et des gains de productivité plus élevés.
Le résumé de GN⁺
- Cette étude montre que l’IA générative peut améliorer de manière significative la productivité des développeurs logiciels.
- Elle est particulièrement utile aux développeurs les moins expérimentés, ce qui suggère que les outils d’IA peuvent contribuer à atténuer la courbe d’apprentissage.
- Des outils d’IA comme GitHub Copilot peuvent jouer un rôle important dans l’amélioration de l’efficacité du développement logiciel.
- Parmi d’autres projets offrant des fonctionnalités similaires figurent TabNine et Kite.
1 commentaires
Avis de Hacker News
Je me demande parfois si la baisse de qualité des effectifs IT ne vient pas du fait que les entreprises empilent de plus en plus de rôles sur une seule personne afin de réduire les effectifs.
Avant, le développement, les opérations et la sécurité étaient chacun des rôles dédiés ; quand le DevOps est apparu, certaines entreprises l’ont compris non pas comme une intégration des équipes, mais comme le fait qu’on pouvait se contenter de 2/3 des effectifs ; puis avec le DevSecOps, elles ont estimé qu’un tiers des rôles d’origine suffisait, et que les développeurs pouvaient aussi faire les opérations et la sécurité applicative.
Je ne critique pas le shift-left ni les modèles opérationnels intégrés en eux-mêmes ; je dis que c’est le résultat logique de ces modèles quand les dirigeants pensent pouvoir toucher de plus gros bonus en réduisant les coûts via des suppressions de postes.
Désormais, un développeur junior arrive dans un environnement de n microservices absurdement complexe, doit apprendre la base de code existante, cinq pipelines CI/CD, et même le rôle de DBA, tout en tenant un rythme de releases régulier.
Est-ce vraiment étonnant qu’il utilise ChatGPT pour essayer de suivre ? Et cela continuera tant que les entreprises IT n’arrêteront pas de réduire les effectifs pour « faire monter la ligne » au lieu d’adopter de bonnes stratégies business.
Ce que les MBA ratent, à mon avis, c’est le phénomène des contraintes excessives. Quand on découpe le rôle général de « développeur » en « développement, opérations, sécurité », une foule de détails apparaissent sur la manière dont chaque rôle doit être exercé. Même si on les regroupe ensuite en DevSecOps, ces détails restent, si bien qu’une personne ne devient pas trois fois plus efficace : elle se retrouve avec trois fois plus de travail.
Pour revenir correctement en arrière, il faut assouplir les contraintes et laisser cette personne juger de la manière d’accomplir le travail.
La conclusion qui en découle est que la taille des organisations ne peut pas diminuer, seulement augmenter. Plus il y a d’employés, plus les postes se spécialisent ; et si on les supprime, la fonction cesse tout simplement d’être assurée. À ce niveau de spécialisation, les employés restants ont du mal à absorber de nouvelles responsabilités en modifiant un peu leur fiche de poste.
Au final, il faut abandonner l’ancienne organisation et repartir avec une nouvelle structure plus petite ; c’est aussi une raison d’être de l’écosystème private equity / capital-risque / startups. La loi de Gall va dans le même sens : https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
À l’inverse, quand on regarde les nouvelles startups qui émergent aujourd’hui, on voit de plus en plus de personnes vraiment talentueuses. Dans un environnement où le financement est plus serré, il faut des gens réellement solides pour lancer une entreprise, et ces gens recrutent à leur tour d’excellents profils.
Le secteur tech actuel ressemble beaucoup plus à la période 2004-2008, quand presque tous ceux qui s’intéressaient aux startups s’y lançaient parce qu’ils aimaient hacker des problèmes techniques.
D’après mon expérience avec Cursor, c’est excellent pour ce qu’un ingénieur moyen peut faire, mais médiocre pour les tâches plus avancées ; et il faut aussi être capable de comprendre très vite le code des autres.
Cela permettra sans doute à des ingénieurs techniques avancés qui ne se concentrent pas sur le frontend ou le développement d’apps web de recruter beaucoup moins de développeurs web juniors qu’avant. C’est un peu comme la disparition des webmasters lorsque des frameworks et des outils sont apparus pour produire rapidement du HTML/CSS de base pour des pages web.
Si l’on dit que les profils « DevSecOps » font trois fois le travail qu’ils devraient faire, il faut aussi regarder ce qu’ils font d’autre. Ils peuvent réserver leurs déplacements, faire leurs notes de frais et leurs rapports, ventiler leurs heures de travail par catégorie métier, gérer leurs congés, organiser des réunions, préparer des présentations avec des graphiques faits maison, voire réaliser 80 % de la préparation des achats auprès de fournisseurs externes.
Ces tâches ne figurent pas dans leur fiche de poste, entravent leur vrai travail et grignotent de manière disproportionnée leur capacité à l’accomplir. Autrefois, chacune de ces tâches avait un spécialiste dédié, qui pouvait la traiter pour beaucoup moins cher et avec une efficacité dix fois supérieure.
Les spécialistes comme les assistants, les services graphiques internes ou les équipes finance apparaissaient dans les états financiers. Supprimer ces rôles ne fait pas disparaître le travail : il est simplement réparti en petits morceaux entre tout le monde, au nom de l’amélioration de la « productivité » par les logiciels bureautiques en libre-service.
Résultat : tout le monde ralentit de façon disproportionnée, mais ceux qui ne regardent que les chiffres voient seulement l’argent économisé sur les salaires des postes supprimés. Le ralentissement apparaît comme une sensation floue et générale de baisse de productivité, une mystérieuse maladie des coûts qui touche tout le monde.
À mon sens, il n’y a rien de mystérieux : il n’y a pas de gain de productivité, mais au contraire une perte. Simplement, comme on transforme des coûts clairs et visibles en coûts diffus et difficiles à calculer, il devient facile de se convaincre qu’on économise de l’argent.
La compétence clé qui manque, c’est la capacité à comprendre le métier de l’entreprise. Même avec des compétences de développement correctes, si elles sont combinées à une bonne compréhension des objectifs business, elles peuvent rester pertinentes alors qu’une partie des développeurs purs est remplacée par l’IA.
En treize ans dans une entreprise du secteur bancaire, j’ai vu la complexité augmenter fortement, accompagnée d’une bureaucratie absurde. Je peux encore faire le travail nécessaire, mais je n’ai pas les accès. Et je ne peux pas les obtenir.
Une tâche simple est devenue une négociation en dix étapes avec une équipe obscure à Pune ; il faut les relancer dix fois et escalader avant qu’ils reconnaissent qu’ils ont effectivement quelque chose à faire.
Les processus sont devenus tellement absurdes que lorsqu’on lance quelque chose, on ne sait pas si cela prendra deux jours ou trois mois. Toutes les apps tombent assez vite en panne si elles ne sont pas maintenues en continu, à cause d’une nouvelle intervention réseau, d’une mise à jour Unix non validée, ou de l’une des innombrables choses qui finiront forcément par arriver.
Au final, les pousse-papiers et les gens moyens même dans leur cœur de métier se sont incrustés dans les processus et ont gagné ; les métiers reçoivent une IT de faible qualité, les projets prennent du retard et dépassent les budgets. Cela renforce encore l’image de l’IT comme un « mal nécessaire, médiocre mais qu’il faut supporter ».
Maintenant, j’ai décroché mentalement ; il me suffit que le travail soit un moyen de vivre. Mon attention et mon accomplissement sont du côté de cette « vie ».
Ce que l’on mesure est important. Cette étude n’a regardé que l’utilisation de Copilot
Je suis un ingénieur expérimenté, et Copilot est non seulement inutile pour moi, mais il me gêne. Je passe la majeure partie de mon temps à comprendre le domaine du problème, à cerner les contraintes et les possibilités de l’environnement dans lequel je me trouve, et à réfléchir au code que je vais écrire
Quand je commence effectivement à taper du code, je sais déjà ce que je vais écrire ; l’autocomplétion « utile » de Copilot ne fait donc que me distraire. Elle dégrade nettement mon flux de travail
À l’inverse, l’IA est extrêmement utile dans les étapes qui précèdent le codage proprement dit. Parfois, un prompt bien construit à partir d’une réflexion faite en amont suffit à obtenir une ébauche, puis il est très utile de travailler en binôme avec un LLM pour obtenir rapidement des réponses aux petits problèmes inattendus qui surgissent ensuite
Donc, contrairement à ce rapport, je pense qu’un développeur expérimenté qui utilise bien l’IA peut en tirer un bénéfice plus important qu’un développeur moins aguerri
Mais utiliser Claude Sonnet 3.5 avec Cursor ou Continue.dev améliore radicalement les choses. On peut contrôler explicitement le contexte, par exemple sélectionner 6 ou 7 fichiers à injecter, et avec les excellentes capacités de Claude en plus, cela change complètement la donne
Selon la tâche, on gagne facilement un facteur 2 à 5. Une tâche qui aurait pu prendre une demi-journée peut être transformée en moins d’une heure en une centaine de lignes de code prêtes pour la production, tests compris
Je dis cela avec 26 ans d’expérience, dont des rôles de principal/staff/lead depuis 2012. En revanche, je ne m’attendrais pas à la même amélioration chez quelqu’un qui n’a pas encore un niveau senior. Il faut en effet expliquer assez précisément ce que l’on veut, puis prendre une première solution qui fonctionne généralement et la raffiner environ six fois pour arriver à une forme idéale et bien décomposée
Par exemple, quand j’écris de l’IaC pour AWS, il y a beaucoup de choses à vérifier. Si je demande à l’IA, j’obtiens très vite une réponse et des exemples. Si j’apprends l’IaC d’un nouveau service, je consulterai la documentation AWS, mais quand il me faut juste une réponse rapide ou une piqûre de rappel, l’IA est bien plus rapide
Plus on s’appuie sur des patterns fonctionnels, plus l’effet est important : concevoir des monades, limiter les entrées-sorties aux frontières et utiliser du fluent programming
Pour référence, c’est mon expérience en Java. J’utilise Java depuis 3,5 ans et je m’appuie beaucoup sur les fonctionnalités Java 8+. Quand on utilise beaucoup les génériques dans le code de bibliothèque, les LLM ont davantage de marge pour faire systématiquement les bons choix
Avec des conceptions plus rapides et plus bricolées, on ne bénéficie pas autant de ces gains. J’aimerais beaucoup entendre davantage de retours de vrais utilisateurs de programmation fonctionnelle comme Haskell, OCaml, F# ou Scala
Il était utile pour écrire le boilerplate des tests unitaires, en particulier des tests table-driven, mais pas au point de justifier un abonnement payant
Il était très utile lorsque je travaillais dans un langage que je ne maîtrisais pas bien, ou sur des tâches répétitives où je pouvais facilement juger si le code généré était correct
En revanche, il devient faible lorsque ce que je veux faire est très clair et ressemble à une implémentation standard, mais avec quelque chose d’un peu plus nouveau. Cela arrive souvent avec des opérations comme « reduce » ou des procédures plus ambiguës
En tant qu’ingénieur plateforme, je passe d’un univers à l’autre — Bash, Python, navigateur, JS pur, TS, Node, GitHub Actions, workflows Java Jenkins, Docker, etc. — et il m’aide à reposer mon cerveau et à me remettre en jambes quand je change de domaine
Je me demande si l’étude inclut la dette technique que des développeurs moins expérimentés ont introduite avec l’IA, et que des développeurs plus expérimentés ont ensuite dû gérer. C’est parce que j’ai personnellement beaucoup vécu ce genre de choses dans l’une des entreprises mentionnées dans l’étude.
J’ai aussi constaté moi-même que les développeurs qui s’intéressent moins à la technologie elle-même, mais beaucoup à la livraison, montrent davantage d’intérêt pour l’IA. Les PM aiment bien ce genre de profils, mais
Ce que nous avions demandé, c’était une petite modification d’environ 5 lignes et un test. Mais nous voilà maintenant avec non seulement une nouvelle dette, mais aussi du code dont personne ne peut expliquer pourquoi il a été complètement changé, dont une partie n’est qu’un changement pour le plaisir de changer, et même du code totalement étranger aux yeux des personnes qui maintiennent ce code.
Je vois ça régulièrement chez les personnes qui utilisent ces outils sans être des ingénieurs seniors. Au final, on refuse ce type de PR et on demande de recommencer, et le gain de temps qu’on pensait avoir obtenu au départ disparaît.
Cela ne veut pas dire que ces outils sont inutiles, mais les gens les utilisent sans comprendre ce que produit la sortie, ni les effets à long terme que cela peut avoir sur la base de code.
Le jour où j’ai perdu une partie de mon âme, c’est quand j’ai demandé à un développeur si je pouvais lui faire un retour sur le schéma de BD, qu’il a dit oui, puis qu’après quelques minutes il m’a coupé avec un « oui, X ne m’intéresse pas vraiment ».
Pas intéressé ? Je suis en train de lui dire, en tant qu’expert du domaine, ce qui pourrait être amélioré, comment le faire et pourquoi il faut le faire, et ça ne l’intéresse pas.
Le cloud a été une erreur. Il a ancré chez les gens l’idée qu’il n’est pas nécessaire de rechercher l’efficacité et l’optimisation, puisqu’on peut scale up/out à tout moment. Je ne parle même pas de microbenchmarks, mais de choses très simples du genre « est-ce qu’il ne vaudrait pas mieux utiliser cette structure de données plutôt que celle-là ? »
Nous l’utilisons aussi en interne, et je pense que la dette technique est une menace énorme qui est mal évaluée.
C’est très utile pour appliquer en rafale à du code des API et des patterns qu’on ne connaît pas bien, mais si l’on ne fait pas attention, cela produit énormément de duplication de code et de boilerplate difficile à gérer.
Il y a deux grands biais à l’origine de cela. D’abord, les données d’entraînement du modèle ressemblent à des exemples façon StackOverflow, sans prise en compte du contexte ni des contraintes. Ensuite, il a tendance à copier et répéter plutôt qu’à examiner la base de code existante et proposer des refactorings.
Le premier point s’atténue en finissant par faire son travail : relire et éditer ce que le LLM a craché.
Le second pourrait être atténué si les diffs et l’historique des commits entraient dans les données d’entraînement, mais ce jeu de données est beaucoup plus difficile à traiter et à étiqueter. Certains changements sont bons, comme des refactorings, mais d’autres peuvent être des bugs corrigés dans des commits ultérieurs, et les messages de commit sont en pratique des mensonges, donc il n’y a pas de distinction claire. Personne n’écrit « introduction d’un bug ».
En plus, les merge, rebase et squash modifient ou suppriment le sens de l’historique, ou y ajoutent du bruit, ce qui rend tout encore plus flou.
J’aime la technique et j’écris aussi du logiciel pour le plaisir, mais travailler avec l’IA est objectivement plus amusant. Ma productivité augmente énormément et, surtout, la procrastination disparaît.
Quand je suis bloqué ou que je n’ai pas envie de commencer une tâche, je me mets à discuter avec Aider et, sans m’en rendre compte, j’ai terminé une tâche que je n’aurais pas faite ce jour-là sans IA.
Grâce à cela, je publie désormais toutes les deux semaines des projets publics ou privés qui m’auraient auparavant pris des mois, voire des années. Avoir à côté de soi une équipe de développeurs rapides et expérimentés coûte au maximum quelques dollars par jour.
Avant de tirer des conclusions, il faut examiner l’article un peu plus en profondeur. L’étude elle-même aurait sans doute pu mieux résumer ses résultats.
Le résumé et la conclusion ne présentent qu’un seul taux comme résultat : une hausse de productivité de 26,08 % ; cela fait beaucoup de décimales. En creusant un peu, on trouve des chiffres de 27 à 39 % pour les juniors, et de 8 à 13 % pour les seniors.
En regardant encore plus finement, les écarts sont importants non seulement selon l’expérience, mais aussi selon l’entreprise. Chez Microsoft, en dehors des pull requests, les autres indicateurs de résultat comme les commits, les builds et le taux de réussite des builds ne semblent pas statistiquement significatifs. L’augmentation des PR semble significative chez Microsoft, mais pas chez Accenture, et même là, cela pourrait ne concerner que les juniors.
Le résumé et la conclusion doivent synthétiser, certes, mais les résultats varient tellement selon les variables que je ne sais pas s’il est pertinent de donner un chiffre global unique comme synthèse. D’autant plus que la significativité statistique semble très irrégulière.
Accenture est une entreprise qui collabore avec de grandes organisations comme Microsoft et fait du co-marketing avec elles. Son pool d’environ 300 développeurs ne pèse presque pas sur l’échantillon global, et comme l’entreprise met en place des départements marketing/conseil autour des workflows IA, il est difficile de la supposer objective.
La troisième entreprise anonyme n’était pas réellement dans un essai contrôlé randomisé ; il est donc difficile de dire comment agréger ses résultats avec ceux des RCT. Par ailleurs, d’autres grandes entreprises tech ont sans doute mené des expériences similaires et voulu connaître l’efficacité, donc on peut supposer qu’il existe d’autres données que celles incluses dans les résultats.
Pourquoi avoir choisi ces entreprises dans un ensemble d’échantillons plus large ? Probablement parce que Microsoft et Accenture ont un intérêt à l’adoption, et que la troisième entreprise a été choisie par p-hacking.
En particulier, la phrase du résumé disant que « chaque expérience individuelle est bruitée, mais qu’en combinant les trois expériences » est un très mauvais signal. C’est pratiquement reconnaître que, prises séparément, les entreprises n’ont pas de résultat statistiquement significatif, mais qu’en combinant ces trois groupes, cela devient significatif. Ce n’est pas de la science.
Les développeurs juniors peuvent travailler sur des tâches que les LLM réussissent plus facilement, ou commettre l’erreur d’accepter un premier jet parce qu’il a l’air LGTM, ce qui peut faire paraître leur débit plus élevé.
Utiliser des modèles de génération de code demande aussi une compétence, et cette compétence est la même que celle nécessaire pour déléguer du travail à d’autres personnes et intégrer les solutions de plusieurs auteurs dans un système cohérent.
Ce n’est que mon intuition, mais je pense que le codage assisté par LLM nuit à la progression des développeurs. Il peut probablement augmenter la productivité jusqu’à un certain niveau, mais ce niveau correspond peut-être à de la répétition ennuyeuse pour un senior, alors qu’il fait partie du processus de formation pour un junior.
D’après mon expérience, les LLM ne servent pas seulement à produire du code boilerplate simple : on les appelle aussi quand un développeur junior rencontre une tâche assez courante qu’il ne comprend pas encore suffisamment. Le processus d’expérimentation, d’apprentissage et de compréhension est alors largement remplacé par le LLM, et la véritable compétence devient l’ajustement du prompt jusqu’à ce que cela ait l’air de fonctionner.
Hier soir, j’ai configuré un RAID Linux pour la première fois. Ce n’est pas extrêmement difficile, mais il faut utiliser plusieurs outils — mount, umount, fstab, blkid, mdadm, fdisk, lsblk, mkfs, etc. — et le processus peut diverger des étapes exactes du guide en cours de route, si bien que se contenter de tutoriels ou de documentation n’est pas particulièrement utile.
J’ai posé des dizaines de questions sur chaque outil et chaque étape ; auparavant, j’aurais simplement copié-collé en priant.
Il y a deux jours, j’ai aussi réussi à récupérer toutes les données d’un SSD défaillant en apprenant via ChatGPT. Même si 20 % peut être faux, c’était vraiment appréciable d’aborder une compétence totalement nouvelle avec un « guide » bien meilleur que la moyenne de l’Internet ouvert.
Pour quelqu’un qui aime apprendre, cela donne l’impression de porter des bottes de sept lieues par rapport au fait de fouiller sans fin dans les déchets d’Internet. Bien sûr, comme pour tout le reste sur Internet, il faut se méfier de ce que dit l’IA, mais cela réduit énormément la pénibilité.
J’ai la même intuition et j’irais même jusqu’à dire que c’est une opinion forte et étayée. Je pense que le secteur en paiera le prix dans quelques années.
Le pipeline d’approvisionnement en « développeurs logiciel juniors qui ont du feeling » va fortement se tarir, remplacé par un flot de « développeurs logiciel juniors dépendants de l’IA ». Il existe un profond fossé entre ces deux catégories.
Évidemment, cela aura des effets en cascade sur le nombre de développeurs intermédiaires qui ont du feeling, puis de développeurs seniors qui ont du feeling.
En revanche, ceux qui veulent comprendre tout le code qu’ils écrivent sont susceptibles d’aller étudier les parties qu’ils ne connaissent pas dans ce que le LLM a produit.
C’est en tout cas comme cela que je m’en sers. Et, pour donner un contre-exemple à l’hypothèse, il arrive que le LLM utilise des fonctions ou des composants de bibliothèque que je ne connaissais pas, ce qui me fait gagner beaucoup de temps quand j’apprends un nouveau langage ou toolkit. Pour moi, cela accélère l’apprentissage plutôt que de le ralentir.
Mais pour ceux qui auraient réussi de toute façon, c’est comme poser des questions sur StackOverflow et recevoir des réponses immédiates, sans jugement : c’est un cadeau énorme.
Ce ne sera pas toujours correct, mais StackOverflow ne l’était pas non plus. Au bout du compte, comme toujours, cela dépend de la personne.
Il y a 50 ans, combien de développeurs d’aujourd’hui auraient su utiliser le langage machine, qui était pratiquement indispensable pour construire quelque chose ?
Les LLM sont peut-être en train de passer d’une béquille d’abstraction supplémentaire à un pilier d’abstraction solide.
Ce qui est le plus intéressant dans cette étude, c’est que, lorsqu’on segmente par niveau d’expérience, les développeurs dont l’ancienneté est supérieure à la médiane ne montrent pas d’augmentation statistiquement significative sur ce mauvais indicateur indirect qu’est la « productivité ». Les intervalles de confiance à 95 % descendent largement dans le négatif pour tous les indicateurs, et ne penchent que légèrement du côté positif.
Cela correspond aussi à mon expérience. Copilot est utile pour réduire certaines tâches ennuyeuses et permettre de consacrer son cerveau à des questions plus profondes, mais ce n’est pas le bouleversement du monde dont parlent certains développeurs juniors.
Il se trompe aussi souvent de manière subtile, d’une façon qu’un développeur peu expérimenté pourrait ne pas voir. Je dois m’arrêter et ajuster la plupart de ce qu’il génère, et un développeur moins aguerri risque fort de ne pas savoir comment faire ces ajustements.
Après quelques années d’utilisation, j’ai maintenant une assez bonne intuition de quand utiliser Copilot et quand ne pas l’utiliser, donc je pense que l’effet net est positif, mais cela n’a pas toujours été le cas.
Je me demande aussi si une partie de l’apparente baisse de « productivité » des développeurs seniors ne vient pas de l’augmentation de productivité des juniors dans l’entreprise. Si les juniors créent davantage de PR, avec plus d’erreurs, ce qui augmente le temps de revue, les gains de productivité des seniors peuvent diminuer en proportion.
Le gain de productivité de 26 % correspond globalement aussi à mon expérience. Une dimension à examiner davantage, selon moi, est de savoir si l’on travaille avec une nouvelle technologie ou avec une technologie déjà familière. L’IA m’est beaucoup plus utile dans les langages ou frameworks que j’essaie d’apprendre.
Je ne retiens pas bien les bizarreries et pièges des langages auxiliaires, comme la formule exacte de guillemets nécessaire pour écrire une condition en Bash. Par conséquent, par le passé, j’écrivais très peu de scripts Bash d’automatisation, et je ne faisais l’effort que pour des tâches suffisamment fréquentes. Même chose pour traiter du JSON avec jq ou parser avec AWK.
Maintenant, grâce aux LLM, je crée beaucoup plus de scripts Bash, et c’est devenu si facile que je les utilise plus souvent aussi pour documenter des processus. Ce qui était auparavant un README statique étape par étape est désormais accompagné d’un script Bash interactif qui demande des entrées à l’utilisateur.
En général, je vois beaucoup de programmeurs seniors expliquer pourquoi les outils d’IA ne fonctionnent pas. Les juniors, eux, les utilisent simplement, sans préjugés.
Les cas utiles étaient au nombre de quatre. Premièrement, les questions sur des frameworks/langages que je n’utilise pas souvent mais pour lesquels il existe beaucoup de contenu d’exemple, comme Qt ou CSS.
Deuxièmement, les questions très spécifiques que j’aurais auparavant cherchées sur Google Search ou StackOverflow. Par exemple, pour une question comme « la façon la plus efficace d’obtenir l’utilisation CPU et RAM de Windows avec Python », il indique plutôt des bibliothèques ou des exemples que de produire directement du code à copier-coller.
Troisièmement, du code boilerplate que je sais déjà écrire, mais qui fait gagner un peu de temps et réduit les fautes de frappe. Avec le plugin CoPilot pour PyCharm, si j’écris mon intention en commentaire dans un fichier, il complète les quelques lignes suivantes. Là encore, les résultats sont meilleurs quand c’est très court et précis. Si cela devient plus long, il faut trop d’allers-retours avec CoPilot, et cela ne vaut plus la peine.
Quatrièmement, comme moyen de chercher rapidement dans la documentation.
Certains disent que c’est utile pour écrire des tests unitaires, mais cela n’a pas été mon cas. En tout cas pas pour le type de tests unitaires que je veux.
Si je devais le quantifier, je dirais que la productivité augmente d’environ 5 à 10 %. C’est beaucoup moins que d’utiliser un IDE complet comme PyCharm au lieu de Notepad, ou un bon client git plutôt que de taper directement des commandes git dans le CLI. Autrement dit, ce n’est qu’un outil de productivité parmi d’autres ; je n’irais pas jusqu’à dire que c’est « révolutionnaire ».
J’ai utilisé Cursor pendant environ 10 jours sur un énorme projet Ruby on Rails, une stack que j’utilise depuis plus de 13 ans.
Je n’ai pas obtenu de gain de productivité au-delà de ce que GitHub Copilot m’apportait déjà. J’estime le gain de Copilot à environ 25 %.
En revanche, pour lancer pour la première fois un nouveau projet, par exemple en Node.js dans un dossier vide, c’est étrangement puissant. Avec seulement des prompts, on peut créer en environ 5 minutes une API qui traite des requêtes à partir d’un schéma OpenAPI et expose ce schéma OpenAPI via swagger.
Mais comme je démarre rarement de nouveaux projets de zéro, je vais probablement revenir à Copilot et au VSCode de base.
Cela permet aux gens de créer plus de PR. Waouh, impressionnant. Qui s’en soucie ?
Le nombre d’éléments qui passent la QA augmente-t-il ? Les choses créées avec l’aide de l’IA ont-elles moins de bugs découverts après la QA ? Sont-elles plus faciles à étendre ou à modifier plus tard, ou bien leur conception est-elle rigide et peu flexible ?
Un outil qui transforme les développeurs en singes codeurs dont on ne connaît pas la qualité n’est pas ce que je cherche. Je veux un outil qui aide les développeurs à trouver les bugs ou défauts de conception dans ce qu’ils font, ou qui les aide à écrire des tests bien conçus.
Compter uniquement le nombre de PR ne dit rien d’utile. Au contraire, cela réveille mon intuition selon laquelle plus il y a de code par unité de temps, plus la qualité moyenne baisse.
Copilot : « Bien sûr, je m’en occupe ! Voici les nouveaux commits ! »
Développeur senior : « Pourquoi ? Le changement est atomique. Si la direction ressort un indicateur idiot comme le nombre de changements mensuels, je leur dirai poliment d’aller se faire voir. »
C’était probablement Copilot basé sur GPT-3.5.
Microsoft : septembre 2022–3 mai 2023
Accenture : juillet 2023–décembre 2023
Entreprise anonyme : octobre 2023–?
La mise à jour GPT-4 de Copilot Chat date du 30 novembre 2023 : https://github.blog/changelog/label/copilot/
Pour moi, l’IA a redonné vie à la documentation. Les nouveaux frameworks manquent cruellement de documentation. Les derniers bons docs que j’ai vus, c’était dans des livres sur DOS. J’ai l’impression que les développeurs d’aujourd’hui n’ont même plus vraiment idée de ce qu’est une bonne documentation
Cela dit, l’IA peut proposer quelque chose de différent à chaque fois, donc le jugement doit toujours revenir à un développeur expérimenté. Au final, l’IA remplace la documentation et la saisie au clavier
Pour un projet public, la documentation fait désormais partie des données d’entraînement des LLM ; il est donc devenu bien plus important qu’elle soit rigoureuse et exacte. Parce que beaucoup de développeurs obtiendront leurs réponses via ce système
Pour un projet privé, on peut mettre la documentation dans un jeu de données de fine-tuning ou dans un système RAG pour obtenir le même effet
Ça explique peut-être pourquoi rien n’est documenté
Du coup, dans les faits, cela force aussi les développeurs à mieux documenter leur code
Pas forcément une documentation live moderne, n’importe quoi ferait l’affaire. J’aimerais voir ce qui était si excellent autrefois et que nous avons perdu, pour essayer d’en intégrer une partie dans ma propre documentation