Écrire du code n’a désormais plus grand coût

• La chute brutale du coût d’écriture du code est en train d’ébranler l’ensemble des habitudes d’ingénierie
• Par le passé, produire du code avait un coût élevé, ce qui a façonné une culture de développement efficace centrée sur la conception, l’estimation et la planification
• Avec l’arrivée des agents de codage, un seul développeur peut désormais mener plusieurs tâches en parallèle (implémentation, refactorisation, tests, documentation)
• Cependant, produire du « bon code » exige toujours des standards de qualité élevés et le jugement du développeur
• D’où l’émergence d’un enjeu central : construire de nouvelles habitudes de développement, à l’échelle individuelle comme organisationnelle

---

Évolution du coût d’écriture du code

• Autrefois, écrire quelques centaines de lignes de code propre et testé demandait plus d’une journée
  • Les développeurs évaluaient donc la valeur et la priorité des fonctionnalités en fonction d’un temps et d’un coût limités
  • La conception du projet, l’estimation du calendrier et la planification des fonctionnalités s’organisaient toutes autour d’une « utilisation efficace du temps de codage »
• L’introduction des agents de codage a fait chuter brutalement le coût de saisie du code, remettant en cause les anciens critères de décision
  • Un ingénieur peut exécuter plusieurs agents en parallèle et mener des travaux de développement simultanés
  • Ce changement pousse à réexaminer l’ancienne logique d’évaluation de la valeur par rapport au temps passé

Le « bon code » reste coûteux

• Produire du nouveau code est devenu presque gratuit, mais créer du « bon code » reste coûteux
• Un bon code doit réunir les conditions suivantes
  • Fonctionner correctement et atteindre son objectif sans bug
  • Passer par des procédures de vérification qui prouvent qu’il est fiable
  • Se concentrer sur une résolution adaptée du problème et traiter les cas d’erreur de manière prévisible
  • Conserver une structure simple et minimale afin d’améliorer la maintenabilité et la compréhension
  • Garder les tests et la documentation à jour
  • Tenir compte des possibilités d’évolution futures sans ajouter de complexité inutile
  • Répondre à des qualités non fonctionnelles comme l’accessibilité, la sécurité, la scalabilité et la maintenabilité
• Les agents de codage peuvent aider sur une partie de ce processus, mais la responsabilité finale de l’assurance qualité reste celle du développeur

La nécessité de nouvelles habitudes de développement

• Dans un environnement d’ingénierie orientée agents (agentic engineering), les anciennes habitudes de développement ne sont plus suffisantes
• Les individus comme les organisations doivent définir de nouvelles méthodes de travail et de nouveaux critères de jugement
• À l’échelle de l’industrie, ces bonnes pratiques (best practices) sont encore en train de se constituer
• L’approche proposée consiste à lancer une session d’agent asynchrone pour expérimenter, même quand on a l’impression que « cela ne vaut pas le temps investi »
  • Dans le pire des cas, on vérifie 10 minutes plus tard et cela se termine simplement en gaspillage de tokens

Place de cet article dans le guide Agentic Engineering Patterns

• Cet article fait partie de « Principles », le premier chapitre du guide Agentic Engineering Patterns
• Le chapitre suivant porte sur la compréhension du code (Understanding code) avec Linear walkthroughs
• La section Testing and QA abordera ensuite des sujets comme Red/green TDD et First run the tests
• Un ou deux chapitres seront ajoutés chaque semaine ; l’ensemble ressemblera à un livre, mais sous la forme d’un « guide »

[GN⁺]

Avis Hacker News

• Je ne suis pas sûr que l’expression « le code a toujours été cher » soit juste
  En réalité, ce qui coûtait cher, ce n’était pas le code lui-même, mais tout ce qu’il y a autour — garantir la justesse, la maintenance, la coordination entre équipes, le support sur le long terme, etc. étaient les vrais postes de coût
  Si l’on multiplie les tests ou les procédures d’approbation à l’excès, c’est au contraire le processus qui finit par représenter l’essentiel du coût
  Les LLM ont fortement réduit à court terme le coût de génération de code qui fonctionne, mais à long terme ils pourraient aussi alourdir la maintenance, la sécurité et la charge de test
  Au final, on ne saura s’il y a eu une vraie transformation qu’en regardant les données sur le long terme

  • Je suis d’accord avec l’idée que « ce qui coûte cher, c’est tout ce qu’il y a autour du code »
    Autrefois, écrire quelques centaines de lignes de code coûtait déjà cher
    J’ai mis 256 lignes de JavaScript dans l’outil SLOCount des années 2000 (version WebAssembly) et il a estimé le coût à environ 6 461 $ selon les standards de l’époque
    Évidemment, il faut surtout prendre ce chiffre comme une curiosité
  • D’après mon expérience, pas seulement le code mais aussi le DevOps, l’analyse de données et le support ont été renforcés par l’IA
    Aujourd’hui, je me sens moins en train de faire le travail moi-même que comme une sorte de manager de mon propre travail
    J’ai l’impression que ma productivité a augmenté d’environ 2,5x par rapport à avant
  • Si l’on regarde le cycle de vie du développement logiciel (SDLC), le codage n’est qu’une étape
    Il faut toujours recueillir les besoins, concevoir, tester, déployer et maintenir, et la majeure partie du coût se situe encore dans la phase de maintenance
    Comme avec la loi d’Amdahl, même si le coût du codage tombe presque à zéro, le coût des autres étapes devient la limite
  • La vraie réduction des coûts vient du fait de savoir précisément ce que l’utilisateur « veut vraiment »
    Le problème, c’est que c’est difficile par nature pour les humains
  • Le code était cher avant, il l’est aujourd’hui, et il le restera
    Des qualités comme la justesse, la maintenabilité et la performance sont des coûts cachés qu’on n’acquiert qu’avec l’expérience

• Je ne suis pas d’accord avec l’idée que « le code a toujours été cher »
  En réalité, le code coûtait cher parce qu’on essayait d’écrire du « bon code »
  Si l’on baisse les standards, le code généré est rapide et bon marché, mais l’effort pour le ramener à du bon code reste le même
  Si l’on veut défendre le codage par agents, il faut l’aborder avec une autre logique

  • D’après mon expérience, quand on utilise des agents IA, il devient au contraire plus difficile d’obtenir du bon code
    Quand j’écris moi-même, je comprends la raison de chaque ligne, mais avec du code produit par l’IA, il faut vérifier chaque construction
    Le mois dernier, j’ai fait la plupart de mes tâches avec des agents, et des bugs sur des cas limites qu’un humain n’aurait probablement pas produits ont continué à apparaître
    Au final, le coût de revue devient si important que le gain à court terme disparaît
  • J’ai formulé ça avec prudence en disant que le bon code a toujours un coût
    Cela dit, grâce aux agents de codage, ce coût a beaucoup diminué
    Comme l’agent peut prendre en charge les retouches fines, on peut produire plus vite du code de meilleure qualité
  • Le code simple est bon marché, mais le code complexe reste cher
    La complexité s’accumule, donc le moment le moins coûteux pour la traiter avec soin, c’est lors de l’écriture initiale
    Aujourd’hui, le gain à court terme est grand, mais à long terme le bruit pourrait être multiplié par 10
  • L’idée clé, c’est que programmer est bon marché, mais l’ingénierie logicielle est chère
  • Ça me fait penser à la distinction d’Ousterhout entre programmation tactique et programmation stratégique
    Les LLM sont particulièrement adaptés à la programmation tactique, c’est-à-dire à l’implémentation rapide de fonctionnalités
    La gestion de la complexité à l’échelle du système devient donc encore plus importante

• Générer du code est aussi peu coûteux qu’on le dit, mais la compétence qui consiste à le transformer en résultat utile est le vrai savoir-faire
  L’agentic engineering est au fond l’art de conduire des intrants bon marché vers des résultats de valeur

  • Je suis totalement d’accord avec l’idée de « conduire des intrants bon marché vers des résultats utiles »
    L’agentic engineering, ce n’est pas simplement écrire du logiciel, c’est fabriquer rapidement des outils pour résoudre un problème précis
    Mais une fois le problème résolu, l’IA en elle-même n’a plus grand intérêt
    Beaucoup de gens prennent l’IA pour une finalité, alors que la vraie valeur réside dans la résolution de problèmes
    Comme le disait Alan Watts, une fois le message reçu, il faut raccrocher
  • Ce n’est pas parce qu’on a inventé la pelleteuse qu’on devient riche en creusant des trous n’importe où
    Ce n’est pas parce qu’un outil devient bon marché que la valeur apparaît automatiquement
  • L’acte de taper du code n’est pas, en soi, ce qui crée de la valeur
    Ce qui a de la valeur, c’est la capacité à concevoir et à structurer
  • Si la sortie vient du même cerveau, qu’on l’obtienne par des instructions détaillées ou par un coup de chance du premier coup, la qualité sera similaire
    Au fond, la qualité des décisions est ce qui compte
  • Lever 100 millions de dollars ne signifie pas qu’une idée est bonne
    Le financement n’est pas une preuve de valeur

• Je reste sceptique face à l’affirmation selon laquelle « le code a toujours été cher »
  La définition même d’un code propre et testé reste floue
  Si l’on pousse trop loin les tests, les coûts explosent, et les procédures d’approbation organisationnelles sont aussi un gros facteur de coût
  Les LLM réduisent les coûts à court terme, mais peuvent augmenter les coûts de maintenance à long terme

  • Le code a toujours été cher
    Quand j’étais stagiaire, je travaillais à bas prix dans une startup, mais les incidents, la corruption de données et la dette technique se sont accumulés
    En apparence, c’était peu coûteux, mais les coûts cachés étaient énormes
    Grâce aux LLM, on a l’impression aujourd’hui de pouvoir obtenir du code de bonne qualité à bas coût, mais je suis encore en phase d’adaptation
  • Du point de vue d’une startup, il fallait autrefois embaucher des développeurs pendant plus de six mois pour sortir un produit
    Aujourd’hui, produire une v1 coûte peu, mais les décisions complexes d’un produit mature restent très coûteuses

• La valeur économique d’un logiciel réside dans l’information contenue dans le code
  Écrire le code n’est qu’un processus de mise en correspondance de cette information, et c’est la qualité de l’information qui détermine la vraie valeur
  Écrire du code plus vite n’améliore pas la qualité de l’information
  C’est comme en conseil : ce n’est pas parce qu’on produit des slides plus vite qu’elles ont plus de valeur

  • Cette idée rejoint le thème récent de la dette cognitive (cognitive debt)
    Si la vitesse d’implémentation devient trop élevée, le modèle mental du développeur se désaligne du code
    Article lié : Cognitive Debt by Simon Willison
  • En utilisant des agents de codage, j’ai aussi vécu l’expérience inverse, où la qualité du mapping entre l’information et le code s’est au contraire améliorée
    Parce que je pouvais itérer rapidement sur le refactoring
  • Au final, le goulot d’étranglement reste le processus de transmission de l’intention à la machine
    L’IA comprendra de mieux en mieux le contexte, mais en contrepartie il faudra renoncer davantage au jugement humain
    Le jour où la machine comprendra pleinement l’intention, l’humain sera écarté de la boucle

• Le cœur de toutes les méthodologies de développement, c’est le fait que les exigences changent toujours
  Un bon code est donc un code « facile à modifier »
  On peut douter que les agents LLM actuels produisent ce genre de code
  Tant qu’on ne pourra pas leur faire entièrement confiance, ils risquent de rester au niveau du prototype

  • Le vrai goulot d’étranglement n’est pas l’écriture du code, mais le coût de transmettre clairement l’intention
    Si les spécifications sont floues, les tests comme la validation de la valeur deviennent difficiles
  • Même les ingénieurs humains ne modifient pas du code avec une sécurité de 100 %
    Même avec des tests, on n’a souvent qu’environ 70 % de confiance
  • J’encadre finement les LLM et je leur fais souvent faire des modifications de fonctionnalités et des corrections de bugs
    C’est plus rapide que de coder moi-même, et le résultat reste du code maintenable
  • Tous mes commits sont déjà générés à 100 % par des agents
    Si l’on explicite un code propre et de bonnes pratiques, on peut obtenir des résultats tout à fait maintenables
    Au final, c’est Garbage in, garbage out
  • Mais certains ont l’impression que les LLM sont bons jusqu’au niveau de la démo, puis s’effondrent au moindre petit changement

• Comme je l’expliquais dans mon texte (The Final Bottleneck),
  la vitesse d’écriture du code a augmenté, mais les étapes suivantes ne suivent pas
  Ce n’est pas seulement une question d’habitudes : toute la structure de responsabilité, la conception des langages et l’architecture des systèmes doivent évoluer

  • Il est difficile pour toutes les entreprises de travailler d’une façon entièrement nouvelle
    Si la productivité avait vraiment été multipliée par 10, les startups auraient déjà bouleversé le marché
  • Si les LLM deviennent suffisamment petits et peu coûteux, on entrera dans une époque où ils seront intégrés dans les applications pour adapter le code à chaque utilisateur
  • Certains se demandent aussi : pourquoi faudrait-il écrire du code aussi vite ?
    Ce n’est pas parce qu’on peut faire quelque chose qu’on doit forcément le faire
  • Les développeurs open source doivent ouvrir la voie vers une époque où même les non-développeurs deviennent des builders
    Des approches comme les AI evals (measure-first-optimize-last, ai-evals.io) vont dans ce sens
  • « Faut-il vraiment continuer à déployer à cette vitesse ? »
    La frénésie de fonctionnalités n’est souhaitée par personne

• Chaque ligne de code est une dette (liability)
  À l’ère où les LLM déversent du code, cette dette explose
  L’outil en soi n’est pas mauvais, mais une structure où des programmes irresponsables réécrivent la codebase est dangereuse

  • Pendant des décennies, nous avons construit des mécanismes de validation, de revue et de rollback autour du déploiement de code
    Dire que « le code est bon marché » signifie que sa génération coûte moins cher, pas que le coût d’approbation du déploiement a disparu
    Si l’on saute l’étape du jugement, ce n’est pas un gain de productivité mais un vide de contrôle (control gap) qui apparaît
    Donner une passe-partout parce que c’est rapide, c’est dangereux
  • L’écriture comme la maintenance restent coûteuses
    Ni l’une ni l’autre ne sont devenues vraiment bon marché

• Moi aussi, je suis presque entièrement d’accord avec cet avis
  Écrire du code est devenu moins cher, mais le coût de revue et de validation reste élevé
  En particulier dans un monorepo de plusieurs millions de lignes, l’essentiel est d’améliorer la testabilité
  J’apprécie que ce type de discussion apporte un peu d’équilibre dans l’ambiance surchauffée de Twitter

  • J’ai fait la même observation
    Le churn de code est devenu plus facile, mais la validation de la qualité devient le nouveau défi
    Les gros volumes de modifications générés par les LLM produisent des échecs subtils, et ce flux ne s’arrête pas

• Le code n’est pas bon marché
  Il y a aussi le coût des tokens, et la structure réelle des coûts reste encore incertaine
  Comme des startups sans revenus monopolisent la chaîne d’approvisionnement des GPU, on manque de données

  • L’écriture est devenue moins chère, mais la maintenance reste la même
    Plus le nombre de LOC augmente, plus la dette augmente aussi
    La distance entre l’idée et l’exécution s’est raccourcie, mais le code lui-même reste une responsabilité
  • Les modèles locaux montrent la borne basse du coût
    Aujourd’hui c’est peu cher grâce aux subventions implicites, mais cela pourrait encore baisser si les coûts du matériel, de l’électricité et du personnel diminuent