L’IA exige plus, et non moins, de discipline d’ingénierie
(charitydotwtf.substack.com)- L’amélioration de la qualité de génération de code par l’IA n’est pas un signal pour abandonner la revue de code, mais pour exiger une discipline de validation et d’exploitation encore plus forte dans un environnement où le code peut être régénéré rapidement et à faible coût
- Après Opus 4.5 fin 2025, l’IA est devenue capable de produire, au moins sur des schémas courants, un code proche de celui d’un ingénieur logiciel intermédiaire, plus vite et à moindre coût, avec l’appui des agentic harness, de l’usage d’outils, du function calling et de MCP
- À mesure que le coût de production du code se rapproche de zéro, les lignes de code cessent d’être un actif précieux à préserver pour devenir davantage un cache régénérable qui matérialise la compréhension du moment
- De la même manière que l’immuable infrastructure a conduit à remplacer les serveurs en cours d’exécution plutôt qu’à les corriger, le code applicatif à l’ère de l’IA met davantage l’accent sur la validation du comportement, les characterization tests, le capture/replay, le découpage du trafic et l’observability que sur la modification elle-même
- Les systèmes non déterministes exigent une discipline d’ingénierie — traces, evals en production, boucles de feedback rapides — plutôt que de s’en remettre à des humains comme barrières qualité, et l’IA ne supprime pas le fait que le logiciel a toujours besoin de techniciens et de discipline
En 2025, l’économie de la production de code s’est renversée
- Pendant la majeure partie de 2025, considérer que le code généré par IA était du « slop » et qu’il le resterait était une position raisonnable et dominante
- Après Opus 4.5 en novembre 2025, l’IA est devenue capable de générer, du moins sur des schémas fréquents, un code d’une qualité comparable à celle d’un ingénieur logiciel intermédiaire, bien plus vite et à moindre coût
- Opus 4.5 n’est pas tant une cause unique qu’un point de bascule
- Un agentic harness est une structure de code qui place un LLM dans une boucle avec des outils
- Ces harnesses ont pris une forme réaliste au milieu de 2025, avec des signes avant-coureurs remontant à fin 2024
- L’accumulation du tool use, du function calling et de MCP tout au long de 2025 a débouché sur une utilisabilité générale en fin d’année
- Lors du premier changement, le scepticisme du type « je le croirai quand je le verrai » pouvait être toléré, mais face à un nouveau changement au même rythme, il devient difficile de conserver la même posture
Le code passe d’actif précieux à produit régénérable
- Le changement clé de 2025 est le renversement de l’économie de la production de code
- Produire du code est passé d’une activité difficile, longue et coûteuse à quelque chose de quasiment instantané et bon marché
- Les lignes de code sont passées d’un objet à réutiliser et entretenir à quelque chose qu’on peut jeter puis recréer
- Il existe aussi une vision selon laquelle le véritable livrable d’une équipe d’ingénierie logicielle est une compréhension partagée
- Cette compréhension est stockée comme un cache dans la tête des personnes, puis écrite sur disque via les commits GitHub et les déploiements en production
- Mais la mémoire humaine s’oublie facilement, s’émousse avec la répétition et laisse échapper les petits détails
- Les modèles mentaux dérivent constamment du monde que les utilisateurs rencontrent réellement
- Du point de vue SRE, le véritable livrable d’une bonne équipe logicielle se trouve en production
- « Only prod is prod »
- La production ne doit pas être traitée comme l’endroit où l’on va après le développement, mais comme une étape du développement
Phoenix Architecture et l’analogie avec l’immuable infrastructure
- Honeycomb a publié un AI mandate en août 2025, estimant qu’en tant qu’entreprise de devtools, elle devait s’attaquer aux problèmes difficiles des technologies les plus récentes
- Les Phoenix Architectures de Chad Fowler relient l’ère du code généré par IA à l’immuable infrastructure
- Chad Fowler est la personne qui a forgé l’expression « immutable infrastructure » en 2013
- Relocating Rigor est un texte mentionné par Martin Fowler dans un résumé de meetup Thoughtworks
- L’idée centrale de The Death and Rebirth of Programming est qu’il ne faut pas réparer ce qui tourne, mais le remplacer
- immutable infrastructure, services stateless, conteneurs, déploiements blue-green et infrastructure as code partagent tous le même postulat
- L’IA étend ce postulat de l’infrastructure au code applicatif
- Quand le coût de réécriture baisse, les corrections sur place deviennent risquées, la mutation accumule de l’entropie et le remplacement la remet à zéro
- The Deletion Test invite à imaginer la suppression de toute l’implémentation
- Si cette suppression fait peur, c’est moins à cause du code lui-même que parce qu’on ne sait pas quels comportements sont nécessaires, quels échecs sont inacceptables, quels invariants doivent toujours être respectés ni selon quels critères juger l’exactitude d’une nouvelle version
- Ne pas savoir quel bug a corrigé un edge case oublié relève du même problème
- Ce n’est pas un problème de code, mais un problème d’évaluation
- Le code devient précieux lorsqu’il est le seul endroit où réside la connaissance
- Par le passé, comme le travail de production de code était le goulet d’étranglement, il était rationnel de traiter le code comme un actif durable
- Quand la régénération devient facile, le code fonctionne plutôt comme une vue matérialisée d’une compréhension utile dans l’instant, mais jetable lorsqu’elle devient obsolète
Il faut pouvoir régénérer le code comme on régénère des serveurs
- Le passage des serveurs animaux de compagnie artisanaux au bétail de l’immuable infrastructure a laissé une leçon : la mutabilité est l’ennemie de la compréhension
- Corriger un artefact en cours d’exécution sur place crée de la dérive
- La dérive rend le système plus difficile à maintenir
- Chez Honeycomb, un cron tue chaque mardi le nœud Kafka le plus ancien
- Cette pratique permet d’avoir confiance dans le fait que les processus de bootstrap et de rééquilibrage sont répétables
- Les données sont régénérables, et les engagements importants se trouvent ailleurs
- Si l’on ne peut pas régénérer le code de la même manière, c’est le signe qu’on ne le comprend pas assez bien
- On ne sait pas quelles promesses ont été faites
- On ne sait pas quelles dépendances vont casser
- On le découvre le plus souvent en les cassant
- Les migrations longues et douloureuses, les réécritures, le remplacement de legacy code et le strangler fig sont des cas où les lignes de code portaient trop de responsabilités
- Le code y empaquetait à la fois l’intention des développeurs, les attentes des utilisateurs, les comportements implicites et explicites, ainsi que les traces d’anciens bugs
Les lignes de code ne sont pas les seules à devoir être revues
- Comme le coût de maintenance et de modification des lignes de code était élevé, les autres artefacts n’ont pas suffisamment mûri
- Il manque des artefacts pour comprendre et discuter l’évolution de l’architecture
- L’architecture elle-même est souvent seulement déduite, de manière floue, à partir du code
- La direction idéale se rapproche d’un mode où l’on discute et valide des diagrammes d’architecture, puis où le code est régénéré à partir de ces changements
- On ne peut pas affirmer que tout le code contournera la compréhension humaine pour être généré par l’IA à partir d’une spécification
- L’ensemble des possibilités dépend de ce qu’est, ou peut devenir, une spec
- Toute personne ayant vécu une migration de base de données douloureuse sait qu’il est difficile d’extraire et de formaliser les attentes des utilisateurs sous une forme rejouable et automatisable
- Les outils n’existent pas encore, mais les idées correspondantes existent déjà
- On y trouve les behavioral tests, les characterization tests, le capture/replay et les traffic splitters venus de l’exploitation et de la QA
- Ces techniques consistent moins à définir ce qui devrait être correct qu’à observer et encoder ce qui se passe réellement
- L’observability, au bon sens du terme, en fait partie
Les humains ne sont pas de bons garde-barrières qualité pour la validation
- Le code non déterministe en production force à faire ce qu’il aurait déjà fallu faire auparavant
- instrumentation de traces
- tests et evals en production
- traitement de la production non comme l’après-développement, mais comme une phase de développement
- Le cerveau humain n’est pas adapté à la validation
- Il est moins performant que les machines pour vérifier en continu des différences répétitives et triviales
- Si l’on réduit le rôle humain à une capacité de barrière qualité, la qualité logicielle devient fragile
- Les humains peuvent encore longtemps garder un rôle dans la créativité, l’inspiration ou les sauts logiques, mais il est difficile d’en faire l’instance qui bat les machines en matière de validation
La conclusion de l’ère de l’IA est le retour de la discipline
- Si le discours sur l’IA des deux dernières années a semblé étrange et inquiétant à beaucoup d’ingénieurs, c’est parce que certaines voix de l’IA donnaient l’impression de dire que le logiciel n’était plus un problème d’ingénierie
- « SaaS is dead »
- « Making AI great at coding was the strategy that unlocks everything else »
- Adam Jacob est présenté comme quelqu’un qui anticipe une transformation majeure des emplois du logiciel
- Si 2025 a été l’année du vibe coding, 2026 ressemble à un retour de la discipline
- Le fait que l’IA puisse générer des lignes de code au niveau d’un ingénieur logiciel intermédiaire a élargi de manière instable l’éventail des futurs possibles
- Les connaissances présentes dans les têtes ne sont pas utilisables par l’IA tant qu’elles ne sont pas encodées dans le système
- Très peu d’équipes logicielles travaillent avec des boucles de feedback rapides et courtes
- La proportion est avancée autour de 5 %, et clairement en dessous de 10 %
- Les outils d’IA peuvent rapprocher cette façon de travailler plus qu’auparavant
- Un scénario où l’IA seule, sans discipline d’ingénierie, produirait un immense retour sur investissement n’est pas, à court terme, le principal sujet d’inquiétude
- Beaucoup d’équipes vont essayer, mais ce qui a de la valeur est soutenu par la durabilité, non par la simple jetabilité
- Les utilisateurs ne veulent pas se connecter à Slack chaque jour pour découvrir des boutons et des menus subtilement modifiés
- Ils ne veulent pas non plus que les transactions financières ne se finalisent que dans la plupart des cas
- Le déterminisme ne disparaît pas
- L’IA n’est pas magique, et le logiciel reste de l’ingénierie
- La technologie a besoin de techniciens
- À l’avenir, les artefacts à examiner ne se limiteront pas aux lignes de code, mais s’étendront à d’autres types d’artefacts d’ingénierie
1 commentaires
Commentaires sur Hacker News
Il est désormais bien plus difficile de distinguer ceux qui comprennent réellement le système et utilisent efficacement l’IA de ceux qui ne comprennent rien et se contentent de faire du copier-coller depuis un LLM
Avant 2025, les personnes peu performantes ou simplement capables de tenir sans vraiment contribuer restaient relativement visibles, car leur apport était faible, mais désormais tous les ingénieurs produisent à la chaîne des PR, revues de code, documents de conception technique, etc. à l’apparence crédible
Cela tient aussi beaucoup à la pression exercée par les dirigeants pour utiliser l’IA au maximum, et du point de vue de chaque ingénieur, c’est aussi une réponse de théorie des jeux où produire le plus possible devient avantageux
Nous sommes en train d’être totalement submergés par des documents et du code qui ont l’air plausibles, et nous finissons par dépendre à nouveau de l’IA pour absorber ce volume
Le contrecoup de cette période risque de prendre la forme d’une dette technique étrange, particulièrement marquée par son ampleur
Les LLM aiment produire beaucoup et ajouter des choses, mais les ingénieurs vraiment compétents obtiennent davantage de résultats business avec moins de code et moins de pièces mobiles
J’entends souvent : « Nous voulons utiliser l’IA pour automatiser le processus, mais la documentation du processus est incomplète, donc nous espérons que l’IA nous aidera »
Même quand on explique qu’on ne peut pas créer des résultats à partir de rien, toutes les discussions sur l’IA reviennent finalement au même point
La solution proposée pour produire la documentation à injecter dans cette automatisation par IA consiste encore à utiliser l’IA, ce qui ressemble à un ouroboros : l’IA crée la documentation, l’IA la résume pour l’ingérer, puis l’IA l’explique
Il se passera la même chose avec le code : l’IA produira des milliers de lignes, puis une autre IA les expliquera
De nos jours, grâce aux LLM, il est beaucoup trop facile d’avoir l’air travailleur si l’on ne regarde que le volume de contribution
La différence, c’est qu’une personne incompétente peut désormais produire littéralement plusieurs ordres de grandeur de plus qu’un ingénieur prudent et expérimenté
Les PR ne sont pas un filtre parfait, mais c’est l’un des rares filtres que nous ayons encore, et il est généralement assez clair de voir qui fait vraiment des efforts et qui n’en fait pas
Les questions d’algorithmique en entretien auront bien totalement éliminé les gens qui prétendent avoir des connaissances systèmes, n’est-ce pas ?
Je suis d’accord avec l’idée que « ce n’est pas un problème de code, mais d’évaluation » et que « le code ne devient précieux que lorsque la connaissance ne vit que dans le code »
Passer la journée à lire du code écrit par l’IA est pénible, et c’est une façon atroce de liquéfier le cerveau précisément au moment où un humain doit être le plus compétent
Dans la programmation manuelle, il existe une boucle de feedback productive et satisfaisante : lire du code, l’écrire, puis le corriger jusqu’à ce qu’il compile, s’exécute ou produise le comportement voulu
Le code IA ne se contente pas de prendre en charge la moitié de cette boucle, il rend aussi le « clic » final moins gratifiant. On ne peut jamais être sûr de ne pas avoir un peu triché pour arriver jusque-là
Faire du code généré par IA le seul artefact durable de la programmation est une impasse pour l’industrie
Ce que Charity désigne comme l’espace de travail intéressant, et ce qu’il faudrait préserver correctement, ce sont les diagrammes d’architecture et les spécifications
À mon avis, c’est encore plus proche des prompts, plans Markdown et consignes rédigés directement par des humains
Il faut se concentrer sur ce que nous avons réellement produit nous-mêmes en tant qu’humains, car c’est ce qui fonde la boucle essentielle : « Est-ce que l’IA a suivi mes instructions ? », et cela donne aussi plus de levier en revue de code
Au moment d’arriver à la PR, on aura probablement déjà donné suffisamment d’éléments à Claude pour pouvoir régénérer le code, et pourtant la valeur par défaut actuelle de l’industrie consiste à jeter toute cette session et à ne déployer que le code. C’est à l’envers
De gros blocs de code sont en pratique impossibles à relire pour un humain, mais dès qu’un LLM est impliqué, beaucoup semblent l’oublier
Chaque jour, des tas énormes de code arrivent pour revue, c’est vraiment usant
Malgré tout, l’IA me paraît meilleure, parce que si l’on écrit les règles, elle a au moins tendance à les suivre
Beaucoup de développeurs offshore, eux, répètent les mêmes erreurs jour après jour
On dirait que notre entreprise doit simplement recruter de meilleurs développeurs offshore
Avant, une partie du modèle mental que je me construisais d’un système venait directement du fait de coder ; maintenant, il se forme davantage via la revue de code
Il devient plus difficile de comprendre et de mémoriser les détails du système, ce qui n’a rien de surprenant si l’on pense qu’on retient mieux les informations qu’on a soi-même « générées » que celles qu’on a seulement lues
J’essaie d’appliquer à l’extension de la revue de code des leçons tirées de la pédagogie, et si cela vous parle, j’aimerais bien en discuter
En solution bricolée, on pourrait demander à Claude d’écrire un résumé de session comme partie du message de commit, mais j’aimerais savoir s’il existe des outils plus structurés et d’un niveau plus élevé
Si l’on veut du code vérifiable conforme à un plan bien conçu, il faut en pratique écrire du pseudo-code et laisser l’IA le traduire
Dans ce cas, on peut se demander pourquoi on fait écrire le code à l’IA dès le départ
Personnellement, je trouve plus de plaisir à planifier, écrire et déboguer moi-même. C’est aussi ce qui m’a fait aimer la programmation au départ
Je pense vraiment beaucoup à ça ces derniers temps
Une grande partie de mon intuition sur le développement logiciel repose sur 25 ans d’expérience accumulée autour de la question « combien de temps faut-il pour écrire tel code ? »
Quand je me demande s’il faut ajouter une validation pour un edge case qui ne casse pas tout mais rend les choses un peu sales si quelqu’un tombe dessus, je peux choisir de l’ignorer si cela demande quelques heures de code en plus
Mais si un simple prompt suffit, pourquoi ne pas le faire ?
Pour rendre une nouvelle fonctionnalité plus facile à comprendre, un explorateur d’API dédié serait utile, mais auparavant l’investissement n’aurait sans doute pas été justifiable
En revanche, si cela prend 10 minutes avec Codex, c’est une autre histoire, et c’est d’ailleurs ce qui s’est passé : https://tools.simonwillison.net/datasette-extras-explorer#ur... avec un lien aussi dans les notes de version https://docs.datasette.io/en/latest/changelog.html#extra-sup...
À plus grande échelle, il y a aussi des projets que je n’aurais même pas envisagés auparavant. J’avais bien besoin d’une bibliothèque personnalisée pour parser des requêtes SQLite
SELECT, mais pas au point d’y consacrer plus d’une semaineMais maintenant c’est devenu possible : https://github.com/simonw/sqlite-ast
Dire qu’il y a de la valeur à pouvoir produire plus vite des lignes de code rend certaines personnes très en colère, et elles regardent ça de haut
Bien sûr, mesurer la production au « nombre de lignes de code » est idiot
Mais mesurer le nombre de lignes de code validées qui livrent de la valeur n’est pas idiot, et désormais on peut en produire plus vite
Google a de la valeur parce qu’il aspire des données pour générer des revenus publicitaires, et parce que ses dépenses sont faibles par rapport à ses revenus
Tous ces « paris » ? Amusant, et alors, qu’est-ce que ça a donné ?
L’ingénierie pour l’ingénierie n’a aucune valeur pour l’économie, donc c’est sans intérêt
La vérité froide que personne n’a envie d’entendre, c’est que ce qui peut exister dans l’économie à un moment donné est limité, et que seules survivent les choses qui ont de la valeur et sont économiquement viables
Beaucoup s’en moquent, mais d’autres y tiennent
J’ai bien aimé ce texte, et comme beaucoup d’autres commentaires ne semblent pas être du même avis, je vais donner mon point de vue.
Quand j’arrive sur une nouvelle codebase, comment devenir utile le plus vite possible ? Je vais directement voir les personnes et la documentation rédigée par des humains.
Je cherche à comprendre quel problème ce système essayait de résoudre à l’origine, quelle était sa conception initiale, quels sont ses plus gros problèmes, et qui l’utilise aujourd’hui.
Une fois qu’on sait ça, il devient beaucoup plus facile de lire le code, parce qu’on peut deviner pourquoi il a été construit de cette façon.
Ce billet de blog a aussi été populaire : https://blog.gpkb.org/posts/just-send-me-the-prompt/
Charity semble regarder un problème très ancien et s’attendre à ce qu’une nouvelle technologie mène à une nouvelle solution.
Je ne pense pas non plus que la génération actuelle d’outils soit la fin de l’histoire du développement logiciel avec l’IA.
Je ne dis pas non plus qu’il suffit de balancer un document de conception dans Claude code et de partir. Les documents de conception ne sont pas complets non plus ; lors de l’onboarding, il faut aussi parler à des gens, lire d’anciens tickets et des post-mortems.
En production, on fait maintenant de l’infrastructure as code parce qu’on déteste ne pas pouvoir comprendre pourquoi l’infrastructure est dans son état actuel.
Une codebase aussi a pour état par défaut « il est difficile de savoir pourquoi elle est dans son état actuel », et c’est un problème observé depuis avant “Programming as Theory Building”.
Donc, comme pour l’infrastructure, je m’attends à ce que le développement logiciel évolue lui aussi vers des outils qui rendent plus clair le « pourquoi le code est dans son état actuel ».
Quand on rejoint une nouvelle codebase, commencer par des humains et de la documentation écrite par des humains est la bonne approche, mais beaucoup d’équipes d’ingénierie n’ont aucune documentation de ce type.
Les décisions sont prises dans la tête d’un ingénieur ou dans des chats non conservés, les spécifications n’étaient que quelques lignes dans un ticket supprimé pendant un rangement, ou bien ont disparu lors d’un changement d’outil de suivi.
Il n’y a ni carte de la codebase ou des fonctionnalités, ni ADR, ni observabilité digne de ce nom.
Il ne reste que le code ; il faut donc le lire pour comprendre ce qui se passe, puis demander à l’ingénieur qui a récemment commit sur une zone précise s’il se souvient pourquoi cela a été fait ainsi.
Et quand quelqu’un modifie quelque chose, l’autre bout de la codebase, qu’on croyait sans rapport, peut se casser.
Oui, l’IA demande plus de rigueur, mais en théorie cette rigueur est bien plus facile à apprendre que de devenir un bon ingénieur.
Il y a 20 ans, pour écrire du bon code C scalable, il fallait soit être un génie, soit être totalement dévoué à la technique elle-même.
Il fallait connaître sur le bout des doigts une multitude d’outils comme ASan, LSan, UBSan, TSan et GDB, et si on devait lire directement les fichiers DWARF, c’était encore pire.
En pratique, c’était difficile à maîtriser en peu de temps, et en parallèle il fallait aussi apprendre la conception de systèmes, qui est une compétence presque orthogonale.
Aujourd’hui, il suffit de connaître les pièges du langage et du framework utilisés, de demander au LLM de les tester, de disposer de l’infrastructure permettant de vérifier qu’il a assez testé, puis de lire les vrais tests et l’implémentation.
Lire et comprendre du Rust est bien plus facile que déboguer les erreurs quasi magiques qui surgissent pendant le développement en Rust.
Il est aussi plus facile de reconnaître qu’un scénario donné nécessite un test Loom et de construire un outil qui détecte s’il a effectivement été écrit.
Même si on continue à utiliser C ou Zig, il est bien plus facile de savoir quand employer chaque outil et de le détecter que d’apprendre chaque outil séparément.
Lire du SQL n’est pas difficile, et presque la moitié des personnes métier peuvent le faire. Python est à peine un peu plus difficile, et même Rust devient compréhensible avec un guide de lecture de 50 pages — un coût très faible comparé à dix ans d’essais et d’erreurs.
Je ne vois pas clairement le chemin qui mène de « les LLM fonctionnent de manière inconnue » à « donc il faut plus de rigueur », puis à « tout va bien ».
Je suis d’accord pour dire que tout va bien, mais je ne pense pas que ce raisonnement suive une trajectoire évidente.
Quiconque a la volonté de faire en sorte que ça marche, et prend un peu de temps pour comprendre ce qui fait échouer les choses, peut accomplir énormément avec les LLM.
Les LLM rendent le coût de construction de choses complexes presque nul, donc ils vont au contraire rendre la situation bien plus complexe.
L’ingénierie a toujours été une affaire de rigueur et de capacité à faire marcher les choses, mais auparavant il fallait posséder tout un ensemble de compétences préalables pour avoir de la valeur.
La plupart de ces prérequis ont désormais disparu, et c’est bien plus facile qu’avant.
La rigueur reste nécessaire, mais comparée à dix ans passés à rouler dans le feu, la rigueur ne coûte pas cher.
Je viens justement de passer une semaine à relire cette PR d’environ 200 lignes : https://github.com/ncruces/wasm2go/pull/37
Elle a été soumise par un utilisateur expérimenté, qui a probablement consulté un LLM de pointe.
Et malgré ça, quelque chose sonnait faux. Je ne comprenais pas, et je n’avais aucune intention de merger sans comprendre.
Je soupçonnais aussi que c’était faux d’une manière qui causerait des problèmes plus tard.
Je l’ai donc revue de quatre façons : comprendre et améliorer, refaire avec un meilleur algorithme, éviter le problème en le corrigeant en amont, ou tout réécrire depuis zéro de façon compatible avec ma propre compréhension.
Je m’attendais à ce que la réponse soit la deuxième ou la troisième, mais même si la deuxième était la bonne réponse, l’utiliser aurait obligé à refaire le projet depuis le début, et la troisième — j’espérais vraiment qu’elle fonctionne — n’a pas marché.
Au final, j’ai mélangé la première et la quatrième, et même si je ne suis pas encore totalement certain, maintenant je comprends le problème et la solution.
Il est évident que je pense que mon approche est meilleure.
J’ai quand même fait relire les deux versions par un LLM après avoir retiré les commentaires.
Le LLM a répondu que la PR d’origine était clairement meilleure, puis quand je lui ai expliqué pourquoi ce n’était pas le cas, il a répondu que j’avais raison.
Si j’ajoute les commentaires et que je réessaie, les LLM disent que ma version est meilleure, parce que j’ai effectivement trouvé le vrai problème.
Mais je ne sais pas s’ils disent que ma version est meilleure parce que je les ai orientés pour qu’ils me répondent cela.
En lisant ce texte, j’ai l’impression qu’il a oublié l’adage « tous les modèles sont faux ».
C’est aussi une erreur fréquente chez les amateurs de RPG « réalistes » et « simulés ».
Si l’on modélise quelque chose de manière suffisamment complète, le modèle devient tout simplement la chose elle-même.
Pour créer un modèle d’un lieu qui inclut tous les détails d’un lieu réel, il faut un modèle à l’échelle 1:1, ce qui finit par être une copie de ce lieu.
Un prompt, c’est-à-dire un plan, suffisamment complet pour reproduire de façon fiable 100 % des fonctions d’un système est probablement le code source de ce système lui-même.
Je me suis souvent demandé si une grande partie de l’IT et de la programmation ne consistait pas simplement à assembler des morceaux bien compris.
Il y a 8 ans, je me demandais pourquoi on ne pouvait pas remplacer LLVM par un système bien plus simple, et les optimisations manuelles par un simple « optimiseur » IA.
Je pensais qu’il suffisait de l’entraîner à transformer du code simplement compilé en code « optimisé », mais à l’époque le consensus était qu’un système d’IA avait du mal à produire du code correct de manière assez fiable pour être utilisable.
Si l’IA ne peut même pas remplacer ce code bas niveau, alors les problèmes de haut niveau devraient évidemment être encore beaucoup plus loin.
Et pourtant, les gens utilisent l’IA pour des problèmes de haut niveau.
Mon hypothèse, c’est qu’une grande partie de l’ingénierie numérique moderne est en mode plug and play.
Je me souviens qu’avant 2023, sur HN, tout le monde encensait l’idée que réduire le nombre de lignes de code était l’indicateur senior le plus puissant.
C’est juste que le courant est trop fort pour gagner une course à contre-courant du déluge de lignes de code générées par les LLM.
Et je ne suis pas non plus d’accord avec l’hypothèse du texte selon laquelle les LLM peuvent écrire du bon code.
Ils écrivent du code qui fonctionne, mais on dirait qu’il a été écrit par un demogorgon, et ça me donne un peu la nausée quand je le regarde.
C’est mauvais, mais mauvais d’une manière qu’aucun humain n’écrirait jamais.
Ce n’est pas le même malaise que lorsqu’on lit du code spaghetti écrit par un junior ; c’est une autre forme d’horreur, comme si un œuf de Cthulhu était en train d’éclore quelque part dans mes entrailles.
Je me souviens qu’une senior dans une ancienne boîte n’avait pratiquement fait que supprimer du code depuis son arrivée jusqu’à devenir manager.
Ce texte n’était pas agréable à lire.
Les phrases en elles-mêmes et chaque paragraphe pris séparément étaient corrects, mais l’ensemble semblait décousu et, j’ose le dire, dénué de sens.
Il y avait vraiment beaucoup de mots, mais en réalité très peu de choses étaient dites.
Par exemple, dire qu’en 2025 l’économie de la production de code s’est inversée n’est pas exact.
Si auparavant le processus de fabrication était strictement additif, comme l’impression 3D, aujourd’hui c’est plutôt comme si on y avait ajouté une approche soustractive façon fraisage CNC.
La « forme » requise n’a pas vraiment changé, et si l’on se soucie de certaines tolérances, l’effort humain non plus.
Il faut toujours valoriser le produit, le réutiliser, l’entretenir et le curatorier autant que le marché l’exige.
Je ne suis pas non plus d’accord avec l’idée que « les lignes de code ne sont pas un livrable idéal à relire ».
Qu’est-ce que « idéal » veut dire ici ?
Quand j’étais enfant, dans tous les examens, la règle était « montrez votre raisonnement ».
La raison, c’est qu’il ne s’agit pas seulement du produit à livrer demain, mais aussi d’améliorer les modèles mentaux et les processus de pensée de la génération suivante.
Le langage était vraiment difficile à suivre, et le propos central du texte ne sautait pas aux yeux.
Quand je lis ce genre de texte, je deviens encore plus sceptique face à l’idée que les emplois d’ingénieur logiciel vont disparaître.
Le travail d’un ingénieur logiciel en 2026 est déjà différent de celui de 2020, sans parler de celui de 1990, alors pourquoi faudrait-il croire à ce faux dilemme selon lequel le travail en 2026 restera identique ou disparaîtra entièrement ?
Quand je travaillais chez Google il y a très longtemps, l’idée de tout relire dans le code était nouvelle pour moi.
Avant cela, chez MS, le code était gravé sur des CD et mis dans des boîtes, si bien que l’essentiel n’était relu qu’à la fin du projet, au moment le plus risqué.
Entre 2000 et 2004, la façon dont les ingénieurs logiciel passaient leur temps a radicalement changé, et je pense que c’était mieux, parce que cela augmentait la compréhension partagée et favorisait la collaboration.
Si l’IA écrit le code et que les humains passent plus de temps à la revue, ce n’est pas forcément une mauvaise chose.
Mais si le code produit par l’IA devient suffisamment bon, on finira par considérer la revue approfondie comme optionnelle.
À ce moment-là, le travail de l’ingénieur logiciel deviendra très différent d’avant, et il ne passera ni beaucoup de temps à écrire du code ni beaucoup de temps à le relire.
Les IDE pourraient même disparaître comme le dodo.
L’accent pourrait se déplacer vers la définition des objectifs et des tests pour empêcher l’équipe de codage IA de partir hors sujet.
Les ingénieurs logiciel qui comprennent bien où va le projet pourraient aussi passer plus de temps sur l’architecture, parce qu’on n’aura pas envie que l’IA réécrive sans arrêt tout un tas de choses dès que la cible évolue de façon raisonnable.
On pourrait aussi passer plus de temps à explorer : construire d’une manière, puis d’une autre, puis encore d’une autre, comparer, et générer de nouvelles idées à partir d’approches différentes.
Je n’ai pas de meilleures prédictions que les autres, mais je m’oppose fermement à l’idée que le rôle va disparaître, et je suis en faveur de l’idée qu’il va évoluer, comme cela s’est déjà produit plusieurs fois. Peut-être simplement jamais aussi vite qu’aujourd’hui.
Je ne pense pas que l’affirmation « on a traité le code comme quelque chose de permanent parce que le travail de production du code était le goulot d’étranglement » soit juste.
Si le code a été traité comme quelque chose de permanent, c’est parce qu’on le considérait comme la source de vérité.
Les ordinateurs n’exécutent pas la documentation, ils exécutent le code.
Si un document d’exigences contredit le code, par défaut on considérait que c’était le document d’exigences qui avait tort.
On ne peut pas séparer le code de la spécification. Parce que le code est la spécification.