- Les ingénieurs logiciels ont globalement deux positions très différentes vis-à-vis des LLM
- Pour certains, c’est une technologie révolutionnaire qui bouleverse l’industrie
- Pour d’autres, ce n’est qu’un mirage survendu
- L’auteur explique qu’à titre personnel, il utilise les LLM de façon utile et présente sa manière de les exploiter efficacement
Écriture de code de production
- Il utilise en permanence la fonctionnalité d’autocomplétion de Copilot lorsqu’il écrit du code
- La plupart des suggestions d’autocomplétion concernent du boilerplate répétitif, comme les arguments de fonction ou les types
- Dans son domaine principal de travail (par exemple Ruby on Rails), il estime que le code qu’il écrit lui-même est meilleur
- Dans les domaines où son expertise métier est plus faible, il accepte davantage la logique proposée par Copilot
- Par exemple lorsqu’il doit faire de petits changements tactiques en Golang ou en C
- Avec l’aide de Copilot, il repère rapidement la syntaxe et les styles de code idiomatiques des langages qu’il maîtrise moins
- Comme il manque d’expertise, il fait systématiquement relire le résultat par un spécialiste du domaine
- Cela permet d’atteindre en partie le niveau d’un « stagiaire intelligent », mais un processus de vérification reste indispensable
Écriture de code à usage unique
- Il utilise les LLM beaucoup plus activement lorsqu’il écrit du code à usage unique qui ne sera pas déployé en production
- Dans le cas d’un code exécuté une seule fois à des fins de recherche puis jeté, les besoins de maintenance sont faibles
- Exemple : récupérer des données publiques depuis une API, les classer, puis appliquer des expressions régulières pour faire une validation simple
- Dans ce cas, il dit avoir pu aller 2 à 4 fois plus vite grâce aux LLM
- Les LLM sont très efficaces pour écrire du code qu’on utilise une fois puis qu’on jette
Apprendre un nouveau domaine
- Il considère que c’est le cas d’usage le plus utile, en utilisant les LLM comme un professeur particulier à la demande
- Par exemple, lorsqu’il a commencé à apprendre Unity, il a enchaîné les questions à des modèles comme ChatGPT-4o
- Il peut poser non seulement des questions du type « Comment X fonctionne ? », mais aussi des questions de suivi comme « Quel est le lien entre X et Y ? »
- Il s’en sert aussi pour vérifier sa compréhension, avec des questions comme « Est-ce que ce que j’ai compris est correct ? »
- Pendant l’apprentissage, il copie-colle directement ses notes pour les faire relire
- Préoccupations autour des hallucinations
- Depuis GPT-3.5, il a le sentiment que les hallucinations ne sont généralement plus aussi marquées
- La plupart des domaines qu’il apprend au quotidien étant déjà bien établis, le risque de réponse erronée était faible
- Jusqu’à présent, il dit ne jamais avoir appris de fausse information via un LLM
Débogage de dernier recours
- Lorsqu’il est vraiment bloqué, il montre à Copilot ou Claude l’intégralité du fichier et le message d’erreur pour demander de l’aide
- Dans la plupart des cas, les LLM se trompent et ne proposent pas de solution satisfaisante
- Malgré tout, il est arrivé plusieurs fois que le LLM pointe quelque chose qu’il avait raté, ce qui lui a fait gagner du temps
- Comme les performances ne sont pas à la hauteur des attentes, il ne multiplie pas les tentatives et ne pose en général la question qu’une seule fois
Correction des fautes et erreurs de logique
- Il ne demande pas au LLM de rédiger entièrement à sa place ses textes (ADR, résumés techniques, documentation interne, etc.)
- Il estime pouvoir écrire plus clairement lui-même et n’apprécie pas le style caractéristique des LLM
- Il lui arrive toutefois de soumettre un brouillon au LLM pour une relecture grammaticale ou la correction des fautes
- Le LLM repère bien les erreurs d’orthographe et propose parfois des points de vue intéressants
- Plutôt que de demander des suggestions de réécriture en boucle, il cherche surtout un retour global, en une seule passe
Résumé
- Périmètre d’usage des LLM
- « autocomplétion intelligente » avec Copilot
- petits changements tactiques dans des domaines mal maîtrisés (avec relecture indispensable par un expert)
- écriture de code de recherche à usage unique
- questions en continu pour apprendre de nouvelles technologies ou de nouveaux domaines
- tentative de résolution de bugs en dernier recours lorsqu’il est bloqué
- correction globale de l’orthographe, des coquilles et des erreurs de logique dans des brouillons de documents en anglais
- Ce pour quoi il n’utilise pas encore les LLM
- déléguer l’écriture d’une Pull Request complète dans un domaine qu’il connaît bien
- rédiger entièrement des documents techniques comme des ADR
- comprendre une architecture complexe dans une grande codebase
6 commentaires
C’est ça... un staff engineer... ?
On dirait bien un staff engineer chez GitHub.
Moi non plus, je n’ai pas l’impression que cela corresponde au niveau d’un staff engineer… J’aurais plutôt tendance à dire que ça relève simplement du niveau assistant.
Il y a une erreur de traduction dans le titre : ce n’est pas « comme un staff engineer », mais « en tant que staff engineer ».
👍!!
Avis Hacker News
En tant que « staff engineer », les LLMs sont très mauvais pour écrire du code idiomatique ou enseigner, et font surtout perdre plus de temps en revue de code. Utiliser des LLMs pour écrire du code comporte le risque d’apprendre de mauvaises pratiques et de devenir dépendant d’un volume de code, de boilerplate et de résultats non déterministes. Les LLMs peuvent être utiles pour générer des idées ou explorer des informations peu fiables, mais s’appuyer sur eux pour générer du code est une folie.
Pour corriger des bugs, il existe une méthode consistant à utiliser Copilot en joignant le fichier complet et en collant le message d’erreur pour demander de l’aide. Les modèles de « reasoning » donnent des résultats bien meilleurs ; en collant toute la codebase et en expliquant le message d’erreur, ils trouvent souvent la cause racine du problème.
Les LLMs sont utiles pour le code boilerplate ou l’autocomplétion, mais ils ont des limites sur les tâches complexes, car ils ne comprennent pas la logique métier. En revanche, ils sont très utiles pour rédiger rapidement des documents d’entreprise.
J’ai travaillé chez GitHub et j’ai directement participé à Copilot.
Si l’on utilise un langage à typage statique et un bon IDE, la fonction de « smart auto complete » peut être moins utile. L’autocomplétion d’Intellij donne l’impression de lire dans les pensées dans la plupart des cas.
Réflexion sur les raisons pour lesquelles les ingénieurs logiciel ont des sentiments négatifs à l’égard des LLMs. Beaucoup de gens ont tendance à juger selon des critères absolus, ce qui limite leur capacité à utiliser efficacement les outils.
Manière d’utiliser l’IA pour la maintenance de projets Python. Elle aide à convertir en Python des approches venant d’autres langages.
L’expérience d’utiliser ChatGPT pour écrire du code utilitaire a été bonne. En revue de code, il signale souvent des problèmes mineurs, mais il reste utile lorsqu’il trouve des pistes d’amélioration.
Après être passé de VSCode à Cursor, le mode agent avec Sonnet est impressionnant. Lorsqu’un développeur expérimenté le guide, cela peut fortement améliorer la productivité.
Les LLMs servent à corriger les fautes de frappe et les erreurs logiques dans les documents. Graphite Reviewer est réglé pour se concentrer sur les vrais bugs et les vraies erreurs. L’IA n’est pas parfaite, mais elle est utile comme outil de correction de code.