Comment j'utilise les grands modèles de langage (LLM) en tant qu'ingénieur logiciel en 2026

Par Sean Goedecke

Comment j'utilise les grands modèles de langage (LLM) en tant qu'ingénieur logiciel en 2026, par Sean Goedecke

Il y a un peu plus d'un an, j'ai écrit un article intitulé « Comment j'utilise les grands modèles de langage (LLM) en tant qu'ingénieur logiciel ». Voici un bref résumé de l'usage que j'ai fait de l'IA l'année dernière :

- Saisie semi-automatique intelligente avec Copilot
- Petites modifications tactiques dans des domaines que je ne maîtrise pas bien (toujours vérifiées par un expert)
- Écrire beaucoup de code de recherche à usage unique
- Poser beaucoup de questions pour en savoir plus sur de nouveaux sujets (par exemple, le moteur de jeu Unity)
- Corrections de bugs en dernier recours, au cas où le système pourrait trouver la solution immédiatement
- Relecture globale de longs documents de communication en anglais

Voici quelques tâches pour lesquelles je n’ai explicitement pas utilisé l’IA l’année dernière :

- Rédiger des PR complètes à ma place dans des domaines que je connais bien
- Rédiger des ADR ou d’autres communications techniques
- Effectuer des recherches dans de grandes bases de code et découvrir comment les choses sont faites

Février 2025, c’était il y a longtemps. À l’époque, le meilleur modèle était le premier modèle de raisonnement, l’o1 d’OpenAI. Les agents fonctionnaient plus ou moins, mais se retrouvaient souvent bloqués ou déstabilisés par la compaction. Qu’est-ce qui a changé depuis ?

Les agents sont performants désormais

Le plus grand changement est que j’utilise désormais des LLM pour produire des PR complètes dans des domaines que je connais bien. Il y a un an, je demandais très occasionnellement à un agent d’apporter des modifications à un seul fichier s’il s’agissait d’une modification simple que je n’avais pas envie de taper moi-même. Parfois, je copiais une fonction que j’avais écrite dans une fenêtre de chat LLM pour obtenir un retour. Mais maintenant, je commence chaque modification en demandant à un agent de résoudre le problème, et je pousse généralement la PR après une seule révision.

Fin 2025, j’utilisais beaucoup de fenêtres VSCode ouvertes. Début 2026, je suis passé à des onglets de terminal avec la CLI Copilot, en particulier lorsque je devais apporter des modifications à plusieurs dépôts en même temps. Aujourd’hui, j’utilise beaucoup l’application GitHub Copilot (des dizaines de sessions par jour).

Cela reflète une évolution : alors qu'auparavant je devais corriger l'agent ligne par ligne au fur et à mesure, je ne procède désormais à une révision qu'à la toute fin. Les premiers agents se trompaient souvent et étaient incapables de se rattraper ; il était donc utile de surveiller leur raisonnement, d'intervenir pour les interrompre et de les remettre sur la bonne voie. D'après mon expérience, les agents actuels vont trop vite pour que je puisse le faire, et de toute façon, ils corrigent eux-mêmes leurs erreurs la plupart du temps.

Parfois, je n’ai même pas besoin d’apporter de modifications et je peux simplement valider le changement tel quel, bien que ce soit rare : à défaut d’autre chose, je passe généralement en revue le texte pour supprimer certains commentaires superflus et autres « LLM-ismes ».

Je passe beaucoup de temps à parcourir et à évaluer les modifications proposées par l’agent. La plupart du temps, je les rejette en bloc, simplement parce que je me dis « euh, ce n’est pas ce que j’avais en tête ». En moyenne, cette première évaluation me prend environ trente secondes. Si la modification me semble correcte après cela, je l'examine de plus près pour m'assurer que je la comprends bien et qu'elle fonctionne correctement. Pour les tâches difficiles, je rejette souvent cinq ou six (voire plus !) tentatives de l'agent avant d'en accepter une comme suffisamment bonne pour être exploitée, ou bien j'abandonne et j'effectue la modification à la main.

Recherche de bogues

Je compte encore plus sur les LLM pour la recherche de bogues que pour apporter des modifications. En 2025, j’avais l’habitude de soumettre occasionnellement un bogue à un LLM, juste au cas où il serait capable de trouver rapidement une explication. Désormais, je soumets tous les bugs à un LLM (généralement en ouvrant une nouvelle session d’agent et en y collant le rapport de bug), car il est capable de diagnostiquer correctement 80 % des problèmes tout seul. Les agents actuels sont vraiment doués pour traquer les bugs, en particulier quand on leur donne une vue d’ensemble sur plusieurs dépôts.

Je reste toutefois meilleur dans ce domaine. La semaine dernière encore, j’ai eu affaire à un bug délicat qui a nécessité environ quatorze sessions d’agent avant qu’un d’entre eux ne parvienne enfin à le résoudre. Que faisais-je entre et autour de ces sessions ?

- Rechercher des informations contextuelles supplémentaires sur le bug (dans les logs, sur Slack, etc.) et les communiquais aux agents
- Construire mon propre modèle mental du problème, bien sûr
- Mettre en place ma propre reproduction du bug (en parallèle des efforts des agents)
- Répondre aux sessions des agents par « non, votre théorie ne peut pas être correcte à cause de X » (ou simplement interrompre et relancer la session avec cet indice supplémentaire)

Au final, c’est un agent qui a détecté le bug. Mais je considère tout de même que c’est moi qui l’ai trouvé, car à ce stade, j’avais suffisamment restreint l’espace de recherche pour que la session n° 14 de l’agent ait un problème nettement plus facile à résoudre que la session n° 1. En d’autres termes, l’expertise humaine reste très importante pour l’investigation des bugs.

Rédaction

Je rédige presque toujours moi-même la description de mes pull requests, car les LLM ont tendance à en faire trop et peinent à exprimer « l’idée centrale » qui sous-tend une modification. Rédiger la description à la main montre également aux relecteurs que j’ai moi-même examiné la modification et que je ne leur demande pas d’être les premiers à lire le diff. Je ne rédige pas la description de la pull request uniquement lorsque la modification est mineure et que la description générée par l’agent tient en une seule phrase. Dans ce cas, je ne touche à rien.

Je n’utilise toujours pas les LLM pour rédiger des messages Slack, des ADR, des tickets, etc. Je pense avoir une meilleure idée de ce qu’il est important de communiquer, et je veux montrer qu’un être humain réfléchit au contenu.

Je n'utilise toujours pas les LLM pour rédiger des articles de blog, même si je passe chaque brouillon par un LLM pour obtenir des commentaires. Les modèles OpenAI étaient autrefois très mauvais dans ce domaine et ne sont devenus acceptables que très récemment avec GPT-5.5. Les modèles OpenAI et Anthropic tentent toujours d'édulcorer mes arguments, mais j'ai accepté cela comme faisant partie du « style maison » des LLM et j'ignore simplement cette partie des commentaires.

Tests et configuration

Une autre chose que je fais désormais est d’essayer de confier autant que possible les tâches de test et de configuration aux agents. En 2025, il m’arrivait parfois de demander à un LLM de générer un script de test de commandes curl que je pouvais exécuter sur mon serveur de développement. En 2026, je demande simplement à un agent d’aller tester ma modification, puis je lis le journal de ce qu’il a fait.

Je ne teste pas le travail sur l’interface utilisateur de cette manière, en partie parce que c’est plus fastidieux et en partie parce que je ne fais pas confiance aux agents pour être sensibles aux aspects subtils de l’apparence et de la convivialité d’une modification.

Les agents écrivent des tests unitaires exhaustifs sans qu’on leur demande, mais je leur demande parfois de mettre en place des tests d’intégration plus larges pour une modification. En général, je considère désormais que le code de test ne coûte pas cher : si je me demande si un test serait utile, je l'ajoute simplement (à condition de savoir qu'il ne sera pas instable). Bien sûr, les LLM produisent parfois du code de test étrange et insatisfaisant — je le lis pour repérer les erreurs grossières — mais je l'examine avec un œil plus indulgent que pour mon code de production réel.

Je confie également à un agent les tâches de configuration locales fastidieuses qui impliquent de bricoler les paramètres sur ma machine. Par exemple, si mon installation nvm ne bascule pas correctement ma version de Node, j’ouvre souvent un agent Copilot CLI et lui demande de trouver la solution. Cela remplace plus ou moins directement une recherche Google sur le problème, et c’est beaucoup plus rapide puisque l’agent peut exécuter lui-même les commandes bash triviales pour diagnostiquer et résoudre le problème.

Résumé

Le principal changement au cours des quinze derniers mois, c’est que les agents sont désormais vraiment performants. Ils sont passés d’un outil que j’utilisais occasionnellement et avec méfiance à quelque chose que j’utilise constamment et avec un minimum de supervision.

Le cœur de mon travail reste le même : livrer des projets, faire preuve de discernement, influencer la politique des entreprises technologiques. Mais je dispose désormais d’un éventail beaucoup plus large de petites tâches que je suis prêt à accepter, ce qui inclut pratiquement tout ce que je peux confier à un agent en étant sûr que le résultat sera plus ou moins correct.

Avant, je passais beaucoup de temps à repousser le travail, soit en le déléguant, soit en disant simplement « désolé, je n’ai pas le temps de faire ça maintenant ». Désormais, je peux dire « oui » beaucoup plus souvent (du moins lorsqu’il s’agit de modifications mineures à faible risque)¹.

Dans l’ensemble, voici à quoi me sert désormais l’IA :

- Rédiger (ou rédiger une ébauche, selon la complexité) chaque modification de code que j’apporte

- Rechercher et corriger les bugs, soit de manière autonome pour la plupart d’entre eux, soit avec ma participation étroite pour les plus délicats

- Effectuer des recherches dans de grandes bases de code, car les agents actuels sont désormais suffisamment performants pour donner la bonne réponse presque tout le temps (et lorsqu’ils se trompent, la lecture de l’explication montre clairement qu’ils ont omis quelque chose)

- Effectuer des tests manuels et configurer ou dépanner la machine locale

- J’utilise toujours l’IA pour poser de nombreuses questions afin d’approfondir des sujets, ainsi que pour la relecture

Voici ce pour quoi je n’utilise toujours pas l’IA :

- Rédiger tout type de communication publique à ma place (descriptions de PR, ADR, messages), à l’exception des PR insignifiants de deux lignes

- Écrire du code que je ne relis pas attentivement

- Tester tout type d’interface utilisateur

À mon avis, la compétence principale en matière d’IA consiste actuellement à confier autant de travail que possible aux agents IA, sans aller trop loin. Beaucoup de gens sous-utilisent les agents : ils ne leur permettent pas d’enquêter sur les bugs ou de tester leurs modifications, ou ne leur confient pas suffisamment de tâches simples. D’autres les surutilisent : ils les utilisent pour rédiger des messages qui devraient être écrits à la main, ou leur confient des modifications radicales qui nécessitent une révision humaine minutieuse. Depuis mon dernier article, la balance a penché davantage du côté des agents, mais trouver le juste équilibre reste aussi délicat que jamais.

Source : How I use LLMs as a staff engineer in 2026

Et vous ?

Pensez-vous que cette présentation est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Je ne sais pas si mon métier existera encore dans dix ans, par Sean Goedecke

Il existe une meilleure façon de coder avec l'IA, par Namanyay Goel

Pourquoi le « Vibe Coding » est en voie de disparition : nous quittons l'ère du codage informel assisté par l'IA pour entrer dans la discipline plus rigoureuse de l'ingénierie des agents
Selon Andrej Karpathy

Nous pleurons notre métier : Le pire avec ces outils d'IA, c'est qu'ils fonctionnent, ils peuvent écrire du code mieux que vous ou moi, par Nolan Lawson