Le coding agentique est un piège
(larsfaye.com)- Le coding agentique est une approche où l’humain définit les exigences et le plan, tandis que plusieurs agents de codage réalisent l’implémentation, mais sa structure tend à creuser en permanence la distance entre le code généré/commité et les personnes
- Cette approche ne fonctionne que si des développeurs expérimentés l’examinent de manière critique au niveau de l’architecture, mais la surutilisation de l’IA peut engendrer une dette cognitive (cognitive debt) qui affaiblit précisément les compétences nécessaires à cette supervision
- Comme dans le paradoxe de la supervision étudié par Anthropic, utiliser Claude efficacement exige des capacités de développement suffisantes pour le superviser, et l’usage d’agents de codage peut justement affaiblir ces capacités
- Les LLM ont tendance à être utilisés pour augmenter le volume de code produit dans un temps donné plutôt que pour favoriser la compréhension profonde et la concision, et ils peuvent combler des exigences ambiguës par des suppositions ou des hallucinations, générant davantage de revue, de corrections et de consommation de tokens
- Les pannes de Claude et la variabilité du coût des tokens révèlent la dépendance fournisseur et l’incertitude des coûts ; il peut être plus judicieux d’utiliser l’IA non comme orchestrateur remplaçant l’implémentation, mais comme outil d’aide à la planification, à la documentation, à la recherche et à une délégation limitée afin de réduire la dette de compréhension
Compromis structurels
- Les agents de codage sont utiles et puissants, mais ils impliquent déjà des compromis qu’il faut évaluer de façon quantitative et pratique
- Pour atténuer l’ambiguïté liée à la non-déterminisme de l’IA, la complexité des systèmes autour augmente
- Les compétences de nombreux développeurs peuvent s’atrophier
- Comme lors d’une panne de Claude Code, une panne chez un fournisseur donné peut immobiliser toute une équipe
- Le coût des salariés est fixe, mais celui des tokens peut continuer à varier et à augmenter
- Pour que cette approche réussisse, il faut des développeurs expérimentés capables de penser de façon critique au niveau architectural et de repérer les problèmes dans des milliers de lignes de code généré avant qu’ils ne prennent de l’ampleur
- Mais les outils d’IA peuvent nuire à la pensée critique et à la clarté cognitive nécessaires à cela, et la dette cognitive (cognitive debt) peut s’aggraver
Pas simplement une nouvelle abstraction
- L’idée selon laquelle il s’agirait simplement de « faire monter les programmeurs à un niveau d’abstraction supérieur » est insuffisante
- Une ambiguïté plus élevée ne signifie pas automatiquement un niveau d’abstraction plus élevé
- Quand FORTRAN, les compilateurs et les langages de haut niveau sont apparus, on a aussi vu des réactions inquiètes à propos des bugs, de l’instabilité, de la baisse d’efficacité et d’une augmentation du « magique »
- Mais autrefois, les inquiétudes relevaient surtout de préoccupations normatives ou théoriques sur ce que l’on risquait de perdre en adoptant de nouvelles technologies, alors que les outils d’IA montrent déjà des effets concrets après seulement quelques années d’existence
- Ces effets ne se limitent pas aux développeurs juniors et apparaissent aussi chez des développeurs ayant plus de 10 ans d’expérience
- Les développeurs juniors, repoussés du travail direct sur le code vers un rôle de relecture de code généré, se retrouvent face à une courbe d’apprentissage plus raide
- La revue de code est importante, mais elle ne représente que la moitié de l’apprentissage ; quand disparaît la friction liée au fait d’écrire et de déboguer du code soi-même, la capacité d’apprentissage s’affaiblit fortement
- Comme ce phénomène demande du temps pour être étudié, les preuves anecdotiques sont aussi importantes pour comprendre la situation en temps réel, mais il existe également des éléments à l’appui, comme le rapport du MIT Media Lab et cet article lié à Microsoft
Pourquoi ce changement est différent
- Quand des développeurs C++ sont passés à Java ou Python, ils ne disaient pas souffrir de « brouillard cérébral », et quand des administrateurs système sont passés à AWS, ils n’avaient pas l’impression de perdre leur compréhension du réseau
- Le fait qu’un ingénieur senior passe à des fonctions de management, code moins et finisse par devenir un peu « rusty » avec le temps n’a rien de nouveau
- Dans le parcours classique, des ingénieurs ayant accumulé pendant des décennies du code, de la friction et de la résolution de problèmes évoluaient vers des rôles traitant davantage de décisions d’architecture que de syntaxe
- Aujourd’hui, des développeurs se retrouvent à monter vers des workflows de plus haut niveau où ils doivent gérer des agents d’IA sans avoir cette expérience de long terme
- Le problème est que ces workflows exigent les mêmes compétences que celles acquises par des décennies d’expérience
- Les ingénieurs seniors eux-mêmes n’y échappent pas
- Simon Willison explique que, malgré près de 30 ans de carrière, sans « modèle mental solide » de ce qu’une application peut faire et de son fonctionnement, il devient de plus en plus difficile de raisonner à mesure que l’on ajoute des fonctionnalités
Le paradoxe de l’orchestrateur expérimenté
- Une récente étude d’Anthropic traite du « paradoxe de la supervision » comme l’un des risques liés à l’usage fréquent d’agents de codage
- L’idée centrale est que, pour utiliser Claude efficacement, il faut de la supervision, et que pour superviser Claude, il faut précisément les compétences de développement que la surutilisation de l’IA peut affaiblir
- Sandor Nyako, qui dirige 50 ingénieurs chez LinkedIn, a observé cette atrophie des compétences se diffuser dans l’organisation et a demandé à ses équipes de ne pas utiliser l’IA pour les « tâches qui exigent pensée critique ou résolution de problèmes »
- Selon lui, développer ses compétences suppose de traverser des difficultés et de muscler sa capacité à réfléchir profondément aux problèmes, et sans pensée critique il devient difficile de remettre en question l’exactitude de l’IA
- Le seuil à partir duquel on peut parler de « surutilisation » reste flou, mais des recherches fondées sur des données et des témoignages anecdotiques montrent que les compétences peuvent se dégrader rapidement en quelques mois
- L’usage d’agents de codage crée donc une contradiction : il affaiblit les compétences mêmes qui sont nécessaires pour bien les piloter
Les LLM accélèrent la mauvaise partie
- Il n’était pas indispensable d’écrire du code plus vite à tout prix
- En particulier, il n’était pas nécessaire de produire plus vite du code que l’on ne comprend pas totalement, ni de grandes quantités de code impossibles à relire dans un délai raisonnable
- Avant l’IA, les bonnes priorités d’un développeur étaient en général les suivantes
- Comprendre le code et sa relation avec l’ensemble de la base de code
- Vérifier qu’il respecte des standards documentés et efficaces
- Minimiser le nombre de lignes nécessaires pour atteindre l’objectif tout en conservant la lisibilité
- Prendre en compte le temps de traitement
- Le coding agentique et les LLM inversent de fait ces priorités
- Les capacités et usages actuels tendent à privilégier la vitesse en augmentant la quantité de code générée dans un temps donné
- La vitesse est un sous-produit naturel d’un haut niveau de maîtrise, mais si on la force, elle entraîne une baisse de précision
- On peut utiliser les LLM pour renforcer la compréhension profonde et la concision, mais l’adoption forcée et la surchauffe organisationnelle centrée sur la consommation de tokens montrent que, dans la pratique, l’usage ne prend pas cette direction
Coder, c’est aussi planifier
- Certains développeurs planifient et réfléchissent mieux à travers le code
- Penser et travailler en codant n’est pas une répétition mécanique sans intérêt ; c’est un processus qui pousse à réfléchir, au niveau technique, à la sécurité, aux performances, à l’expérience utilisateur et à la maintenabilité
- Dans une interview sur le Spec Driven Development, Dax, créateur d’OpenCode, explique que lorsqu’il travaille sur quelque chose de nouveau ou de difficile, il découvre ce qu’il faut faire en tapant lui-même le code
- Il préfère se faire une idée concrète en manipulant directement les types, les interactions entre fonctions et la structure des dossiers, plutôt que de rédiger d’abord une énorme spécification
- Ce que dit une personne n’est pas toujours exactement ce qu’elle veut vraiment, et les LLM remplissent l’ambiguïté avec des hypothèses ou des hallucinations
- Cela entraîne davantage de relecture, davantage de corrections par des agents, davantage de consommation de tokens et une coupure plus grande avec le résultat produit
- À l’inverse, même avec des prompts très clairs et structurés, les LLM peuvent produire des méthodes hallucinées
- Les LLM ne sont pas des compilateurs, mais des moteurs de prédiction du token suivant ; on ne peut pas remplacer un système déterministe par un système probabiliste en espérant que l’ambiguïté tombe à zéro
- Même des développeurs seniors très favorables à l’IA commencent à voir cette coupure comme un problème grandissant
Dépendance fournisseur et incertitude des coûts
- Lors des pannes de Claude, des publications ont montré que certains développeurs et certaines équipes d’ingénierie se sont retrouvés à l’arrêt
- Certains workflows et certaines capacités de codage ont déjà atteint un niveau de dépendance très élevé à l’égard d’un fournisseur d’IA spécifique
- Des compétences qui pouvaient autrefois être mises en œuvre avec un simple clavier et un éditeur de texte exigent désormais un abonnement auprès d’un fournisseur de modèles d’IA
-
Le coût des tokens est difficile à prévoir
- Les fournisseurs de modèles sont massivement subventionnés, et les modèles eux-mêmes reposent sur une base en constante évolution
- Les lancements de nouveaux modèles répètent un même schéma : benchmarks élevés, emballement, puis plaintes après usage réel disant qu’ils ont été « nerfés »
- S’y ajoutent des plaintes selon lesquelles il faut brûler 2 à 3 fois plus de tokens pour accomplir la même tâche
- Le coût des salariés est connu, mais celui des tokens est difficile à prévoir au jour, au mois ou à l’année
- Si toute l’équipe adopte le coding agentique comme mode par défaut, le budget doit rester extrêmement flexible
- Primeagen affirme que, si l’on adopte un workflow entièrement agentique, « le fournisseur de modèles vous possède pratiquement »
- On risque ainsi de créer une structure industrielle où il faut payer le coût de consommation des tokens pour accomplir des tâches qui relevaient auparavant de la pensée critique et de la résolution de problèmes
- Ce n’est plus seulement une dépendance à un fournisseur de produit, mais presque une dépendance de l’ensemble du secteur à l’égard de fournisseurs pour ses propres capacités techniques
- Les fondations financières et intellectuelles peuvent vaciller à tout moment, et les LLM locaux ne sont pas encore prêts à absorber un tel niveau d’usage
- Il ne s’agit pas d’une théorie : le sujet est déjà documenté, et les fournisseurs de modèles eux-mêmes le mettent en avant
- Une autre étude d’Anthropic indique que les compétences de débogage ont chuté de 47 %
- Si l’on introduit l’IA de façon agressive dans le travail, en particulier en ingénierie logicielle, on peut obtenir des résultats rapides au prix d’un manque de développement des compétences essentielles de débogage lorsque des problèmes surviennent
Une approche qui réduit le rôle de l’IA
- Les LLM peuvent être des outils puissants pour apprendre et développer ses compétences
- Ils peuvent aider à explorer des concepts et des techniques plus profondément et plus largement, et permettre d’expérimenter de nouvelles idées avec moins d’effort qu’auparavant
- Les outils de génération de code ne sont pas nouveaux en soi
- Emmet, l’autocomplétion et les snippets étaient déjà des outils pour écrire moins de code à la main et en générer davantage
- COBOL aussi cherchait à faire tenir plus d’instructions avec moins d’écriture grâce à des mots de style anglais comme
MOVEetWRITE - Le slogan de jQuery était lui aussi « write less, do more »
- Les LLM peuvent être vus comme un ajout supplémentaire à cette lignée d’outils de génération de code
- La différence essentielle tient à l’usage des LLM et des agents de codage comme processus d’assistance
- Il est possible d’utiliser l’IA pour le brainstorming en phase de planification tout en restant activement impliqué dans l’implémentation, sans sacrifier les compétences individuelles à la productivité
- En ne déléguant que lorsque c’est nécessaire, on peut bénéficier d’un gain de productivité tout en réduisant la dette de compréhension
Manière de les utiliser au quotidien
- Utiliser les LLM pour générer des spécifications et des plans, mais laisser l’implémentation sous conduite humaine
- Cela inverse le workflow d’« orchestration », avec selon la tâche une part de code écrit directement allant de 20 % à 100 %
- Lors de l’usage du modèle, écrire souvent du pseudo-code afin de réduire la distance entre la demande et le code généré
- Utiliser le modèle pour du code temporaire, de la documentation conversationnelle et de la recherche
- S’en servir comme d’un outil de délégation responsable pour poser des questions, itérer, refactorer et clarifier l’approche
- Ne jamais générer plus de code que ce que l’on peut relire en une seule fois
- Si c’est trop à relire, ralentir, découper le travail et, si nécessaire, refactorer soi-même pour comprendre de manière globale le résultat final
- Ne pas confier à un LLM ou à un agent une implémentation que l’on n’a jamais réalisée soi-même ou que l’on serait incapable de faire seul
- L’exception concerne les usages éducatifs ou les tutoriels, et le résultat est souvent ensuite jeté
- En résumé, il faut utiliser l’IA comme l’ordinateur de bord de Star Trek, et non comme Data
Mieux travailler plutôt que seulement plus vite
- Les gains de productivité des modèles existent réellement
- En parallèle, la friction et la compréhension qui naissent d’un contact direct et fréquent avec le travail sont elles aussi réellement importantes
- Les tentatives de démocratiser le code sans le comprendre ont échoué à plusieurs reprises
- Pour comprendre le code, il faut s’y confronter directement
- Si l’on cesse de rester impliqué dans le code et d’en écrire, on peut perdre cette compréhension et ce lien
- En perdant cette compréhension, on affaiblit aussi sa capacité à mieux piloter les agents, et l’étape du codage avec IA devient alors une transition étrange, inutilement stressante et coûteuse
Cela pourrait être une expérience de plus grande ampleur
- La dynamique actuelle ressemble à une nouvelle expérience à grande échelle que nous menons sur nous-mêmes sans en comprendre suffisamment les effets de long terme
- Lors de l’adoption des réseaux sociaux, nous n’en comprenions pas non plus les implications à long terme, et de nombreux problèmes sont apparus ensuite, notamment des troubles de l’attention à grande échelle
- Cette fois, ce qui est en jeu est plus risqué
- Jeremy Howard, créateur de fast.ai, affirme que ceux qui misent tout sur les agents d’IA garantissent leur propre inutilité
- Si l’on externalise toute réflexion aux ordinateurs, on cesse de développer ses capacités, d’apprendre et de devenir plus compétent
1 commentaires
Avis Hacker News
Après avoir travaillé ces dernières années avec le coding agentique, j’ai appris davantage sur les langages, systèmes et outils que j’utilise qu’en 35 ans de programmation manuelle
Ma capacité à choisir les systèmes, techniques et approches reste largement supérieure à celle de l’outil, mais ces outils ressemblent à des stagiaires très érudits qui connaissent énormément de détails disparates. Ils manquent d’expérience et font des erreurs avec enthousiasme, mais au moins au début ils acceptent le feedback et passent à l’action. En revanche, ils n’ont pas vraiment compris ni internalisé les choses, donc ils les oublient souvent
Prétendre qu’il faut tout savoir sur tout ce sur quoi on travaille est très naïf. Dès qu’on travaille dans plus de deux équipes, il y a beaucoup de parties qu’on ne comprend pas complètement, et sur une vieille base de code, presque tout peut paraître étranger. Dans un énorme monorepo accumulé sur des décennies, on a déjà de la chance si on comprend vraiment même la partie pour laquelle tout le monde vous considère comme l’expert
Ceux qui tiennent ce genre de discours me semblent généralement soit très juniors, soit presque seuls à travailler, soit comme s’ils étaient restés 20 ans sur le même projet. Personne qui travaille dans une équipe ou une grande organisation ne peut prétendre connaître toute la base de code, et c’est pareil pour quelqu’un qui programme de manière agentique. Malgré tout, on peut poser des questions à l’agent et obtenir des réponses, et comme j’ai passé ma vie à lire du code écrit par d’autres, je peux aussi lire du code écrit par un LLM. Que le mauvais code ait été écrit par une machine ou par un humain m’importe peu, et au moins la machine prend mon feedback et agit en conséquence
J’ai vu beaucoup d’équipes logicielles se retrouver bloquées sur un problème pourtant mineur dès qu’il fallait des compétences supplémentaires en langage bas niveau, assembleur, algorithmes moins courants ou protocoles réseau
À l’inverse, on peut aussi se retrouver bloqué non pas faute de savoir interpréter ce qu’on voit, mais parce qu’on utilise quelque chose de boîte noire, comme une bibliothèque propriétaire ou un OS propriétaire, et qu’on ne peut pas fouiller à l’intérieur ni vérifier son fonctionnement réel
Donc même si c’est très rarement nécessaire, je pense qu’il doit toujours être possible de tout découvrir sur tout ce avec quoi on travaille
L’important, c’est de ne pas avoir peur d’apprendre le reste du système, et de garder un index
Par-dessus tout, il faut pouvoir comprendre rapidement n’importe quel sujet. C’est ce qui permet d’avoir une vision large. Quand il le faut, on creuse en profondeur, et quand il le faut, on balaie à haut niveau, pour choisir le bon niveau selon le problème
Il y a longtemps, à l’université, on enseignait aux étudiants en informatique l’ingénierie au sens large. Quand j’ai demandé : “Mais quand aurai-je besoin de chimie industrielle ou de systèmes de contrôle analogiques ?”, on m’a répondu : “Vous n’en aurez probablement jamais l’usage. Mais vous pourrez les comprendre assez vite pour coder, puis les oublier ensuite. Notre rôle est de vous donner des bases solides”
Cela s’applique tel quel aux grandes bases de code
Des outils comme git-ai [0] capturent les sessions LLM, relient chaque modification de fichier à une action précise de l’agent et permettent à l’agent d’interroger, pour un fragment de code donné, la conversation autour de ce fragment, c’est-à-dire ce que l’utilisateur a demandé dans le prompt, quel était le raisonnement du LLM qui a produit ce code, etc. Cela peut changer l’équilibre, mais ce n’est pas encore largement utilisé
[0] https://usegitai.com/
En tant que développeur senior avec plus de 25 ans d’expérience, j’ai récemment été balancé dans une réunion du type “tu peux venir 5 minutes ?”, et je déteste vraiment ce genre de réunion où l’on vous aspire au milieu sans aucun contexte
Les questions ont fusé immédiatement, sans introduction, et portaient sur une intégration externe parmi des dizaines d’autres. Pire encore, cette partie utilisait sa propre terminologie, différente de la nôtre
Comme nous nous sommes fortement appuyés sur des modèles pour construire ces intégrations, j’ai eu énormément de mal à comprendre les questions. C’était un travail extrêmement ennuyeux, réalisé à partir de volumineuses spécifications externes
Je reste persuadé que sans modèle, ces intégrations n’auraient probablement jamais été terminées, même en y consacrant 10 fois plus de temps. Mais maintenant je réfléchis sérieusement à re-documenter les points “aha” pour éviter que ce genre de moment pénible ne se reproduise
Je ne m’étais jamais senti aussi ignorant et embarrassé en réunion, et tout ce que je pouvais dire, c’était : “Je vais vérifier ça et vous répondre, ça aussi, et ça aussi”
La dette cognitive est bien réelle, et personnellement elle me fait encore plus mal que la dette technique. La dette technique est partagée par toute l’équipe, alors que la dette cognitive est individuelle, et si c’est moi qui l’ai créée, je devrais mieux la connaître
À l’avenir, je considérerai qu’un travail n’est pas terminé tant que je n’aurai pas créé une petite liste Markdown de termes façon flashcards de 5 minutes, du type “qu’est-ce que c’est”, “qu’est-ce que ça veut dire”
En tant que senior, vous êtes précisément censé mettre un coup d’arrêt à ce genre de comportement quand il ne vous convient pas. Vous en avez l’autorité. Il suffit de dire : “Question intéressante. Pour donner mon point de vue, j’ai besoin de plus de contexte. Pouvez-vous m’expliquer brièvement l’architecture du système, ou me dire quel problème concret vous essayez de résoudre avec cette approche ?”
Dans ce genre de situation, répondre “Pour traiter correctement cette question, je dois revoir la documentation et le code” est parfaitement acceptable, et même plutôt diplomatique
Les réunions où l’expertise n’est pas perçue comme quelque chose à construire mais simplement comme un moyen de valider un biais de confirmation créatif ne sont pas agréables
Pour repérer les problèmes dans le code généré, les développeurs doivent y prêter attention. Beaucoup de développeurs, surtout dans les grandes entreprises, sont déjà largement désengagés de leur travail et cherchent seulement le moyen de fermer des tickets avec l’effort minimum et de transférer la responsabilité ailleurs
Ces développeurs, même s’ils en ont les capacités, ne feront probablement pas l’effort de comprendre suffisamment le code généré pour détecter les problèmes que l’agent a laissés passer. Surtout dans le contexte actuel de culte de la vitesse piloté par l’IA
Le code généré a l’air plausible sur le plan linguistique, mais il imite souvent des idiomes courants de manière incohérente sans même s’en rendre compte, si bien que de vrais bugs peuvent s’y cacher accidentellement d’une façon qu’un humain normal, voire même un mauvais programmeur, aurait du mal à imaginer
Les LLM n’ont pas d’évaluation interne, donc le reviewer doit en tenir compte ligne par ligne, et reconstruire depuis zéro les justifications implicites et la connaissance tacite que le LLM n’avait pas au départ. On peut alors se laisser entraîner vers de faux problèmes et gaspiller un temps précieux
À ce stade, l’investissement devient souvent plus important que si l’on avait tout écrit soi-même dès le départ
Peut-être que les entreprises achètent aujourd’hui de la junk AI, et qu’à l’étape suivante on leur promettra la “solution”. Le capitalisme fonctionne exactement comme prévu
J’ai l’impression que cet article passe un peu à côté du cœur du sujet
Il y a bien une perte de compétences quand on utilise beaucoup l’IA
Mais je veux aussi reconnaître l’éléphant gênant dans la pièce. L’IA rend les gens beaucoup trop rapides. Je ne veux pas dire qu’une production rapide est mauvaise en soi, mais que les livrables et le code vont plus vite que la compréhension globale et l’expérience qui devraient les soutenir. On récompense davantage ceux qui savent parler de valeur business que ceux qui construisent en prenant des décisions sûres fondées sur une connaissance profonde
L’IA est utile et peut produire de bonnes solutions, mais au fond elle ne sait pas ce qu’elle fait, et même dans le meilleur des cas elle a besoin d’un pilote solide
Nous sommes dans le bourbier du développement piloté par le business, et les mauvaises décisions ne subissent pas une sanction réputationnelle assez sévère
Autrement dit, je ne suis pas certain que la perte de compétences soit un problème si grave. C’est peut-être simplement le signe que la nature de notre métier change. On entre peut-être dans une époque où savoir concevoir une bonne architecture sera plus valorisé que réciter la norme C++ de mémoire et utiliser correctement des centaines de fonctionnalités
Dans un développement classique, on passe plus de temps à alterner entre “veut-on vraiment construire ça ?” et “qu’est-ce qui pourrait mal se passer si on fait ça ?”, idéalement avant l’approbation de la PR, le merge ou le déploiement. Une partie de cela se déplace vers “on verra plus tard qui se plaindra”. Comme on dit, mieux vaut une once de prévention qu’une livre de remède
En plus, ce code n’était pas du C++ idiomatique pour le projet concerné, et le LLM ignorait complètement des API déjà existantes. Ça se corrige, et les mainteneurs auraient dû l’attraper, mais le volume de code généré oblige tout le monde à dépenser beaucoup trop d’énergie
Ces billets de blog sont presque certainement écrits avec une aide IA, et ce sujet revient dans les commentaires ici et partout sur Internet depuis des années. L’atrophie technique est une inquiétude sérieuse, et tous ceux qui sont sceptiques vis-à-vis de l’IA le répètent depuis 2022, mais certaines personnes et certains endroits semblent tout simplement s’en moquer
À partir du moment où l’on ne fait plus que tirer le levier de la machine à déchets sans aucune compréhension du code, il n’est pas absurde que son manager demande pourquoi on devrait vous payer plus de 50 000 dollars par an
Utiliser l’IA pour aller plus vite, c’est optimiser la mauvaise chose. Partout où j’ai travaillé, “écrire du code” était la partie qui prenait le moins de temps par rapport à tout le reste nécessaire pour livrer une fonctionnalité
Prenons une fonctionnalité qu’on pourrait coder en une journée. D’abord, il faut tout planifier selon le rituel maison, qu’il s’agisse d’Agile ou de Waterfall, découper le travail, créer les tickets JIRA et décider qui va faire quoi. Rien que ça peut prendre plusieurs jours ou plusieurs semaines. Ensuite, il faut rédiger un document de conception avec la proposition technique et obtenir les reviews des collègues et de l’équipe ; pour une vraie fonctionnalité, cela peut encore prendre une semaine. Si plusieurs équipes sont concernées, il faut aussi leur accord et un consensus sur le design, donc ajoutons encore une semaine. Dans certaines entreprises, il faut même une approbation formelle avant de commencer, ce qui peut rajouter quelques jours selon l’agenda et la disponibilité des validateurs
Ensuite, on écrit le code en une journée et on fait passer les tests
Puis viennent les code reviews, de nombreux allers-retours avec l’équipe, plusieurs itérations et parfois des reviews supplémentaires. Encore quelques jours ou quelques semaines. Dans une plus grande entreprise, il faut aussi passer toutes sortes de reviews d’autres services : juridique, vie privée, performance, accessibilité, QA, etc. Même en parallèle, ajoutons prudemment 2 semaines. Enfin, on déploie en staging et il faut un certain temps de maturation auprès des dogfooders internes pour avoir confiance dans le fonctionnement. Encore 1 semaine. La fonctionnalité est alors prête à passer de staging à la production, mais dans une entreprise sérieuse, on ne pousse rien à 100 % de la prod immédiatement. On augmente progressivement le trafic, on surveille les retours et les métriques au cas où il faudrait rollback. Le rollout complet peut encore prendre 2 semaines
Au final, sur une fonctionnalité qui prend environ deux mois entre la conception et la mise en production, on fait tout un foin pour réduire de 1 jour à 5 minutes la seule partie qui prenait une journée
Quand on construit un logiciel, il faut se souvenir qu’il constitue un instantané de la compréhension du problème. Il dit à tout le monde, y compris à soi-même dans le futur, quelque chose sur l’approche, la clarté et la pertinence de la solution face au problème du moment. Il faut donc choisir avec soin ce qu’on veut lui faire dire
La formule selon laquelle on se démène pour réduire de 1 jour à 5 minutes la seule partie d’une fonctionnalité de deux mois est très juste
Dans les entreprises stables, ce genre de travail occupait une part non négligeable du quotidien de tous les ingénieurs. Qu’on appelle ça “platform engineering” ou autrement, cet espace est mort
Et des idées techniquement risquées qu’on n’essayait pas auparavant parce que le rapport risque/effort/récompense n’était pas favorable deviennent désormais accessibles. Ce n’est pas seulement “aller plus vite” : la vitesse à laquelle on peut tester quelque chose change la nature même du processus d’ingénierie
Si les software engineers deviennent suffisamment peu coûteux, une grande partie de la nécessité de ces processus disparaît. Les entreprises qui ont déjà ce type de processus auront du mal, parce qu’il est extrêmement difficile de casser cette bureaucratie, mais celles qui n’en ont pas au départ ou peuvent s’en débarrasser bénéficieront d’un avantage concurrentiel important
Ce n’est pas nouveau. Les startups ont toujours rivalisé avec les entreprises établies par leur vitesse d’exécution. Ce qui est nouveau, c’est la capacité à maintenir cette vitesse plus longtemps
Les reviews juridique, vie privée, performance, accessibilité et QA sont aussi dans la ligne de mire. Si une entreprise peut transférer la responsabilité légale liée à ces reviews à un prestataire externe, elle le fera
[0] Mettons de côté, pour l’instant, l’ironie du fait qu’une bonne partie de ce processus finit justement par retomber sur les employés à qui il était censé faire gagner du temps
Il y a beaucoup de procédures prétentieuses de ce genre dans la big tech, mais les petites boîtes peuvent bouger vite et de façon plus rugueuse
La qualité du code dépend au final de vous
Rien ne vous empêche de travailler de manière itérative avec l’agent jusqu’à obtenir un code de qualité identique à celui que vous auriez écrit vous-même
Ces articles sont assez frustrants. Mais le coût des tokens mentionné par l’auteur est, lui, bien réel et préoccupant
J’utilise les outils IA pour brainstormer des approches et parfois générer du code, mais c’est moi qui fais la vraie saisie. Du coup, je risque moins d’oublier avec le temps les mécanismes et les langages de programmation
Honnêtement, si tout se résumait à prompt un LLM pour qu’il écrive du code puis à le relire, je ne pense pas que je voudrais être mainteneur open source. Cela ne me semblerait pas du tout gratifiant
Dans un vrai emploi rémunéré, je me demande en revanche comment ma façon d’utiliser les LLM changerait. Si je suis développeur logiciel, c’est parce que j’aime cette technologie en elle-même. J’aime l’acte de construire, utiliser mon cerveau pour transformer des idées en code. Si le métier ne consistait plus qu’à prompt un LLM, je ne sais pas si je voudrais continuer. Au minimum, je commencerais probablement à regarder d’autres reconversions
J’utilise cette méthode pour le code que je dois maintenir. Malgré tout, le modèle glisse souvent beaucoup d’informations erronées, donc on se fait parfois avoir. En général, ce sont des choses qui étaient vraies autrefois mais ne le sont plus aujourd’hui
Pour des scripts jetables ou faciles à vérifier, je le laisse générer, mais je lui demande d’éviter la surconception ou la tentative de couvrir tous les cas limites. Pour les scripts, il est souvent plus simple à comprendre de laisser les étapes échouer clairement avec une erreur plutôt que de tout masquer
J’évite des langages comme PowerShell, que je trouve difficiles à lire, et je préfère générer des choses assez courtes pour tenir à l’écran et être lues et comprises entièrement. Python, Bash et Batch sont les langages de script que j’utilise le plus
Je rejette encore plus de 50 % des suggestions de l’IA. Soit elles sont trop banales, soit elles déplacent du code sans raison, soit elles sont tout simplement fausses
Ce qui est drôle, c’est que cette technologie semble n’être qu’une de deux choses
Soit une technologie pour managers qui permet de déléguer sans expertise, sans savoir si le résultat est faux ou carrément impossible, soit une technologie pour codeurs qui ont l’expertise mais vont justement la perdre peu à peu
Donc à part les VC et les actionnaires jusqu’au trimestre prochain, je ne vois pas bien pour qui c’est fait
Un peu hors sujet, mais je trouve amusant que l’article dise que le Spec Driven Development est l’avenir
Techniquement, c’est déjà ce qu’on faisait à l’époque du Waterfall. Le temps des bons documents me manque un peu. Depuis 10 ans, voire plus, on reçoit souvent des tickets JIRA d’une seule ligne, sans presque aucune précision, au point qu’il faut fréquemment appeler les gens
Pour l’instant, j’évite encore de travailler avec l’IA. Je veux bien essayer quelques modèles locaux pour expérimenter, mais je refuse de payer pour des choses bricolées à partir du travail des autres. Et jusqu’ici, les modèles locaux m’ont déçu