Pourquoi écrire du code en 2026
(softwaredoug.com)- Le rôle de l’ingénieur logiciel s’est étendu au-delà de la production de code pour englober la construction et la maintenance d’une usine logicielle, mais pour comprendre et améliorer les systèmes, il reste nécessaire de manipuler directement le code
- En guidant les agents avec des prompts,
AGENTS.mdet des bases de connaissances, puis en protégeant les résultats par des tests, du linting, des systèmes de types et des évaluations, même des modèles peu performants peuvent produire des changements suffisamment exploitables - Coder soi-même permet de penser dans l’environnement d’exécution sans passer par l’anglais, et de ressentir concrètement les vulnérabilités, les tests faibles ou les exceptions inutiles qu’une simple revue de code passive peut facilement laisser passer
- Les agents ressemblent davantage à des stagiaires tout juste arrivés qu’à des compilateurs : ils suivent prudemment le code existant et les exigences imprécises, et peuvent amplifier jusqu’aux erreurs ponctuelles humaines en ajoutant des wrappers et des couches d’indirection
- Les humains doivent tester eux-mêmes les approches, établir les patterns, puis laisser les agents les répéter afin de conserver le sentiment de propriété et le jugement tout en profitant de la productivité de l’automatisation
L’usine logicielle où travaillent les agents
- Les ingénieurs logiciels maintiennent non seulement le logiciel, mais aussi une chaîne d’assemblage qui permet à n’importe qui de demander des changements par prompt et de les déployer immédiatement
- Ils mettent proactivement en place l’infrastructure permettant aux agents de réussir grâce aux prompts, aux skills, à
AGENTS.mdet aux bases de connaissances - Ils protègent a posteriori les résultats avec des tests, du linting, des systèmes de types, des évaluations et de l’évaluation automatisée à l’aide d’autres IA
- Ils mettent proactivement en place l’infrastructure permettant aux agents de réussir grâce aux prompts, aux skills, à
- Avec suffisamment de contraintes et un contexte à jour, même un modèle peu intelligent peut produire des changements utilisables sans sortir des rails, au point qu’il peut sembler inutile pour un humain de lire ou d’écrire directement le code
- Pourtant, même avec un agent doté d’une intelligence de niveau Fable, coder soi-même permet de penser directement dans l’environnement d’exécution, sans la couche intermédiaire de l’anglais
- Se contenter de lire passivement les diffs et les patches produits par les agents rend difficile une connexion profonde avec l’architecture du système
- Manipuler directement le code permet de ressentir ce qui casse lorsqu’on ajoute des fonctionnalités par-dessus
- Nettoyer le code et documenter des principes d’architecture cohérents, sans multiplier les exceptions, rend aussi l’usine logicielle plus stable
- Repérer et corriger les faiblesses de la stratégie de test pendant le débogage permet de bloquer toute une nouvelle catégorie de bugs
- Coder soi-même n’est pas la seule façon de comprendre un logiciel, et il n’est pas nécessaire de s’accrocher à un travail manuel extrême, comme avec une aiguille aimantée et une main sûre
- Même si l’essentiel du code réel est généré par l’IA, coder directement reste un outil utile
Préserver sa capacité de réflexion et son sentiment de propriété en codant soi-même
- Si l’on se cantonne au rôle de centaure inversé, chargé uniquement de lire et d’approuver le code, la concentration et le sentiment de propriété diminuent, du code de faible qualité passe plus facilement la revue, et les ajustements fins deviennent plus difficiles
- Sans attention aux détails, les vulnérabilités s’accumulent et, à long terme, le code de faible qualité nuit aussi aux agents
- Lorsque les humains testent eux-mêmes une approche puis font répéter aux agents les patterns établis, ils restent impliqués dans le résultat et continuent à se l’approprier
- L’anglais est un langage trop peu spécifié pour représenter précisément le calcul
- Pour le travail algorithmique, il faut concevoir et raisonner en étapes exécutables
- Selon le contexte, on peut ajuster le niveau de précision nécessaire en choisissant soit un langage bas niveau offrant un grand espace de conception, soit un langage haut niveau avec un environnement de calcul plus contraint
- Traiter les agents de codage comme des compilateurs peut conduire à considérer qu’un code très mal écrit peut malgré tout être déployé
- Les agents ressemblent davantage à de nouveaux stagiaires qu’à des compilateurs
- Ils lisent du code existant qui peut être incomplet et de mauvaise qualité, puis génèrent de nouveaux changements à partir de descriptions imprécises
- Les humains ne peuvent pas déléguer tels quels leur pensée et leurs goûts à une cohorte de stagiaires ; ils doivent donc rester impliqués plutôt que simples consommateurs
- Les agents ont du mal à suivre spontanément la règle du scout, qui consiste à laisser le code dans un meilleur état que lorsqu’ils l’ont trouvé, et il est aussi lourd de leur en confier la responsabilité
- Ils tendent à rendre le changement en cours aussi sûr que possible, en préservant de façon conservatrice les décisions existantes
- Dans une base de code, après qu’un humain a utilisé sans y penser le stockage local du navigateur pour une partie de l’état, alors que le reste était stocké dans une base de données backend, l’agent a tenté de préserver cette décision en ajoutant des wrappers et des couches d’indirection, ce qui a environ triplé le nombre de lignes de code
- Ce conservatisme peut amplifier une mauvaise décision humaine ponctuelle
- Supprimer et explorer directement le code aide à parvenir à une meilleure architecture que lorsqu’on ne donne des instructions qu’en anglais
- Plus on prête attention au code, plus on renforce sa capacité de réflexion, son sens d’auteur et sa capacité à piloter l’usine logicielle
- Dans une usine logicielle, les détails comptent, des patterns d’architecture aux algorithmes et aux performances
- Les agents ont accru le besoin d’évaluations, de mesures et de garde-fous, et poussent à ajouter la CI tôt même dans les projets personnels, plutôt qu’après coup
- L’état du développement logiciel s’en trouve nettement amélioré, mais chaque chaîne d’assemblage conserve malgré tout des points faibles
- Même dans une usine automobile, il arrive qu’il faille démonter la chaîne d’assemblage, plonger dans les détails du moteur à combustion interne pour obtenir 10 % d’amélioration, ou passer la journée à observer des tests de plaquettes de frein afin de comprendre pourquoi un problème de terrain n’a pas été détecté plus tôt
- Dans le logiciel aussi, pour relier les détails à la structure d’ensemble, il ne faut pas tracer de frontières arbitraires autour de ce que l’on peut manipuler directement
2 commentaires
Parce qu'il n'y a pas de tokens ;_;
Avis sur Hacker News
Il semble évident que si l’on ne sait pas écrire du code, on ne peut pas non plus le relire, mais certaines personnes et certaines entreprises estiment qu’il suffit que Claude l’écrive et que Codex le relise. Pourtant, si l’on demande un résultat en langage de haut niveau comme Python ou Java, et non en assembleur ou en binaire compilé, c’est au fond parce que les humains doivent pouvoir lire le code.
Il y a une contradiction à vouloir que les développeurs lisent le code, le déboguent et raisonnent à son sujet, tout en refusant de leur fournir l’entraînement nécessaire pour développer cette capacité.
On peut se demander si le secteur pourra continuer à progresser en confiant toute la création aux LLM.
Cela ne signifie pas qu’un côté vaut mieux que l’autre : des personnes qui accordent moins d’importance aux détails peuvent aussi diriger le monde, et le niveau de granularité nécessaire peut varier selon les problèmes.
Le compilateur aide le LLM à écrire du code qui compile et s’exécute réellement, alors que s’il produisait directement du langage machine, il y aurait de fortes chances que cela ne s’exécute pas du tout. Bien sûr, si l’on ne sait pas du tout écrire de code, la relecture devient beaucoup plus difficile.
« Comment appelle-t-on, dans le secteur, une spécification de projet suffisamment exhaustive et précise pour générer un programme ? Du code » — CommitStrip
S’il est bien écrit, l’essentiel du code devrait exprimer la logique métier sous-jacente de la manière la plus simple possible. Il n’est peut-être pas nécessaire de relire toutes les couches de support, mais si l’on n’a pas lu le code, il est difficile de prétendre connaître complètement la logique métier.
https://softwaredoug.com/blog/2026/07/04/write-code-not-specs
La question importante est de savoir qui paiera pour l’écriture manuelle de code. Les clients ne paient pas pour l’écriture ou la génération de code en tant que telle, mais pour la résolution de problèmes ; l’entreprise qui résout le problème avec le moins de coût et de frictions emporte donc le marché, et il est difficile d’ignorer l’avantage des outils d’IA qui compressent les délais.
Je suis dans ce secteur depuis les années 1990, et il y a toujours eu beaucoup de développeurs médiocres produisant des résultats moyens. On romantise excessivement le code écrit à la main, mais en pratique les bases de code deviennent souvent difficiles à maintenir avec le temps et se remplissent de bugs ; les projets mal exécutés ne sont pas du tout un phénomène nouveau.
Aujourd’hui, on a l’impression d’essayer de construire une usine logicielle avec les deux mains attachées.
Pour rester concentré et comprendre, il ne suffit pas d’observer un agent à distance et de lire passivement le code : il faut faire l’expérience du code soi-même. En fin de compte, cela signifie qu’il faut entraîner son propre modèle mental.
Quand on code, l’inconscient porte beaucoup de jugements du type « ça a l’air correct » ; cela ne se développe que par la répétition et une concentration profonde, et la simple relecture de code ou de documentation atteint vite ses limites. Avec un tel modèle mental, on peut parfois identifier immédiatement la cause d’un incident de production à partir d’un simple message d’erreur, alors qu’avec du code généré il faut chercher longtemps par une réflexion consciente et lente.
Pour que les LLM soient vraiment utiles, il faudrait pouvoir supposer qu’ils prennent en charge toute la maintenance du code et se comportent comme une bibliothèque externe ; sinon, les problèmes continueront inévitablement à surgir.
Je ne sais pas encore quel côté a raison, et je continue à me renseigner.
Même en 2026, le code généré par IA reste catastrophique. Que ce soit avec Fable ou avec un harnais LeetCode personnalisé Pi/opencode, les résultats sont affreux ; si vous ne savez pas distinguer la différence de qualité entre votre code et celui de l’IA, j’ai une mauvaise nouvelle.
Il était explicitement indiqué dans les règles que l’agent devait appliquer la règle du scout : lancer le profiler, vérifier la couverture de code, faire une revue critique, rédiger un rapport et proposer les actions suivantes. Les LLM de pointe actuels suivent ce genre de règles bien mieux que 90 % des personnes avec qui j’ai travaillé, et je me demande si c’est vraiment une mauvaise chose.
Les agents sont conservateurs et peuvent amplifier une erreur ponctuelle humaine. Il existe de nombreuses façons de résoudre cela, et chacun raisonne différemment : on peut donc travailler sans lire le code, ou au contraire le lire et l’écrire soi-même, mais les bénéfices tirés de la précision d’un code qui ne passe pas par un LLM restent importants.
La raison pour laquelle je dois écrire le code moi-même, c’est que sinon le LLM produit beaucoup trop de code. Il faut comprendre entièrement le problème et le généraliser pour éviter qu’un “Hello World” se retrouve avec 10 000 lignes et 5 couches d’abstraction.
Les LLM étant des prédicteurs de tokens, plus il y a de problèmes à résoudre, plus ils ont tendance à générer de tokens de code.
Comme ce sont des humains qui portent le problème à résoudre, si l’on ne comprend pas le problème, un LLM peut tomber dans le problème X/Y et résoudre quelque chose sans rapport avec le besoin réel. Les LLM abstraient mieux les éléments non essentiels, comme les bibliothèques ou les langages de haut niveau, mais le cœur du problème doit toujours être exprimé formellement.
Le vibe coding, qui consiste à ajouter des contraintes une par une jusqu’à obtenir le résultat voulu, reste au fond une programmation lâche et informelle. Il vaut mieux confier au LLM la périphérie du problème, et écrire et comprendre soi-même le cœur.
En apparence, il avait parfaitement répondu à la demande, mais le code était inutile et bancal. Les entreprises qui vendent des tokens à l’usage ont une incitation économique à créer des solutions façon machine de Rube Goldberg, qui résolvent vaguement le problème tout en consommant un maximum de tokens ; et on en consomme encore davantage plus tard, lorsqu’il faut gérer cet énorme code mêlé de nouveaux bugs, pas seulement au moment de la génération.
C’est amusant de voir des gens qui se moquaient du code copié-collé s’enthousiasmer maintenant pour du code mal rafistolé.
Vu les progrès réalisés depuis ChatGPT 3.5 en novembre 2022, je me demande si, dans quatre ans, nous serons encore en train de relire du code. Même sans être un extrémiste de l’IA, si le rythme actuel se maintient, il est très possible que le génie logiciel et le développement tels qu’on les connaît aujourd’hui aient disparu d’ici 5 à 10 ans.
Il ne restera peut-être aux humains que la conception d’UI, tout le reste étant abstrait et le vrai travail étant pris en charge par l’IA.
Le Web est déjà assez en désordre ; qu’on nous laisse au moins, dans la situation actuelle, pouvoir blâmer les humains incompétents.
Indépendamment de la pression des KPI, j’écris le code moi-même chaque fois que j’en ai l’occasion, et je n’attends de l’IA qu’une sorte d’autocomplétion de code plus intelligente.
J’écris du code moi-même parce que j’aime coder et que cela me rend réellement heureux. Il n’y a aucune raison d’abandonner ce qu’on aime.