Le vibe coding et l’agentic engineering se rapprochent plus que je ne le voudrais
(simonwillison.net)- Le vibe coding et l’agentic engineering étaient à l’origine distingués par les critères de revue de code et de responsabilité, mais à mesure que la fiabilité des agents de codage augmente, la frontière devient floue dans le travail réel en production
- Le vibe coding consiste à à peine regarder le code et à l’accepter si le résultat souhaité est obtenu ; cela peut être utile pour des outils personnels, mais cela semble irresponsable pour des logiciels qui engagent les données et l’expérience d’autres personnes
- Des agents comme Claude Code gèrent désormais correctement et de manière répétée des endpoints d’API JSON, des requêtes SQL, des tests et de la documentation, ce qui conduit à ne plus relire chaque ligne de code générée ; cela crée un risque fondé sur une confiance accordée à une entité sans réputation ni responsabilité, contrairement à une équipe humaine
- On peut maintenant créer en 30 minutes un dépôt avec 100 commits, un bon README et une suite complète de tests, ce qui rend la qualité difficile à juger sur l’apparence seule ; le vrai critère devient alors de savoir si quelqu’un a réellement utilisé ce logiciel de façon continue
- Les outils d’IA ne remplacent pas l’expérience des ingénieurs logiciel, ils l’amplifient ; si la production de code passe de 200 à 2 000 lignes par jour, le goulet d’étranglement se déplace vers la conception, la validation, l’exploitation et l’usage réel
La frontière entre vibe coding et agentic engineering
- En écoutant le podcast Heavybit High Leverage Ep. #9 consacré aux outils de codage IA, on en vient à constater que le vibe coding et l’agentic engineering se rapprochent de plus en plus dans le travail concret
- Auparavant, dans Not all AI-assisted programming is vibe coding (but vibe coding rocks), l’auteur distinguait clairement le vibe coding d’une programmation assistée par IA plus responsable, qu’il a ensuite commencé à appeler agentic engineering
- Le vibe coding se caractérise par le fait de presque ne pas regarder le code : un utilisateur, qui peut même ne pas savoir programmer, demande le résultat souhaité, l’accepte si cela fonctionne, puis redemande autre chose si ce n’est pas le cas
- Pour un outil personnel, où les bugs ne nuisent qu’à soi-même, le vibe coding peut être utile ; mais lorsqu’on construit un logiciel qui engage les données et l’expérience d’autres personnes, cela paraît irresponsable
- L’agentic engineering consiste, pour un ingénieur logiciel professionnel qui comprend les contraintes de sécurité, de maintenabilité, d’exploitation et de performance, à utiliser au maximum de ses capacités les outils d’IA
- L’objectif n’est pas de produire plus vite un résultat de moindre qualité, mais de construire plus vite des systèmes de production de meilleure qualité
- Le problème, c’est qu’à mesure que les agents de codage deviennent plus fiables, on finit par ne plus relire chaque ligne de code générée, même pour des tâches de niveau production
Une confiance qui pousse à sauter la revue de code
- Quand on demande à Claude Code de créer un endpoint d’API JSON, d’exécuter une requête SQL et de renvoyer le résultat en JSON, on finit par avoir la conviction qu’il va correctement le faire
- Même si on lui demande d’ajouter des tests automatisés et de la documentation, on s’attend à un résultat correct, et il arrive alors qu’on ne relise pas le code produit
- Si l’on n’a pas relu le code, un sentiment de culpabilité demeure quant au fait qu’il soit vraiment responsable de l’utiliser en production
- On peut voir cela comme la manière dont, lorsqu’on est engineering manager dans une grande organisation, on utilise les logiciels d’autres équipes
- Si une autre équipe fournit un service de redimensionnement d’images, on ne lit généralement pas chaque ligne de code qu’elle a écrite
- On lit la documentation, on essaie de redimensionner des images, puis on déploie sa fonctionnalité
- Ce n’est qu’en cas de bug ou de problème de performance qu’on va regarder le dépôt Git
- La plupart du temps, on traite ce service comme une boîte noire à moitié
- On commence à traiter les agents de la même manière, mais contrairement à une équipe humaine, Claude Code n’a ni réputation professionnelle ni responsabilité (
accountability) - Une équipe humaine peut se construire une réputation en produisant de bons logiciels, et subit la pression qu’un mauvais résultat nuise à cette réputation professionnelle
- Claude Code ne peut pas avoir ce type de réputation, mais il gagne de la confiance en traitant correctement, de façon répétée, des tâches simples qui correspondent à son style de prédilection
- Il y a ici un aspect de normalisation de la déviance
- Chaque fois que le modèle produit du code correct sans surveillance étroite, la confiance augmente
- Et le risque d’excès de confiance au mauvais moment, avec des dégâts à la clé, augmente aussi
Il devient plus difficile d’évaluer un logiciel
- Autrefois, s’il y avait 100 commits, un bon README et des tests automatisés dans un dépôt GitHub, il était facile de juger qu’un projet avait reçu beaucoup de soin et d’attention
- Aujourd’hui, on peut créer en 30 minutes un dépôt Git avec 100 commits, un magnifique README et des tests couvrant toutes les lignes de code
- Un tel dépôt peut avoir exactement la même apparence, en surface, qu’un projet ayant réellement bénéficié d’un long travail soigné
- Il est possible qu’il soit effectivement aussi bon, mais c’est difficile à savoir de l’extérieur, et le même problème se pose pour ses propres projets
- Plus que la qualité des tests et de la documentation, le critère jugé décisif est de savoir si quelqu’un a effectivement utilisé ce logiciel
- Même si le résultat a été vibe codé, s’il a été utilisé tous les jours pendant les deux dernières semaines par la personne qui l’a créé, il a bien plus de valeur qu’un résultat généré à la va-vite et à peine exécuté
Le goulet d’étranglement se déplace de l’écriture du code vers d’autres étapes
- Si l’on passe d’une situation où l’on produisait 200 lignes de code par jour à une situation où l’on peut en produire 2 000, d’autres parties du cycle de vie du développement logiciel commencent à se casser
- Le cycle de vie classique du développement logiciel avait été conçu en supposant un rythme de quelques centaines de lignes de code par jour
- Ce déplacement des goulets d’étranglement affecte non seulement les étapes en aval, mais aussi celles en amont
- Dans la présentation de Jenny Wen, l’idée est que les processus de design existants reposent sur l’hypothèse qu’il faut “bien verrouiller le design”
- Parce que si l’on remet quelque chose de mauvais aux ingénieurs et qu’ils passent 3 mois à le construire, c’est une catastrophe
- Comme le design mène à un travail coûteux, on met en place un processus de design étendu
- Mais si construire ne prend plus 3 mois, alors le coût d’une erreur baisse fortement, et le processus de design peut prendre bien plus de risques
Pourquoi cela ne signifie pas, selon lui, la fin de la carrière d’ingénieur logiciel
- Les conversations avec les agents ressemblent à une sorte de “moon language” difficile à comprendre pour la plupart des gens
- L’une des raisons pour lesquelles cela ne signifie pas, selon lui, la fin de la carrière d’ingénieur logiciel, malgré le fait que les ordinateurs puissent désormais écrire du code eux-mêmes, est que ces outils amplifient l’expérience existante
- Une personne qui sait ce qu’elle fait peut aller beaucoup plus vite avec des outils d’IA
- Plus on utilise les outils d’IA, plus on constate à répétition que fabriquer du logiciel reste extrêmement difficile
- Même avec tous les outils d’IA disponibles, ce que l’on cherche à accomplir reste difficile
- Dans un tweet, Matthew Yglesias écrivait : “Après cinq mois, je me rends compte que je n’ai pas envie de faire du vibecode. Je préférerais que des entreprises logicielles gérées de manière professionnelle utilisent l’assistance IA au codage pour fabriquer davantage de produits logiciels, meilleurs et moins chers, puis me les vendre”, et l’auteur dit être d’accord
- Cela se résume à une analogie : on peut peut-être réparer soi-même la plomberie de sa maison après avoir regardé suffisamment de vidéos YouTube sur la plomberie, mais on préfère malgré tout faire appel à un plombier
Les risques du SaaS et du développement en interne
- Même face à la menace que les entreprises puissent cesser d’utiliser du SaaS pour créer leurs propres solutions, le même critère reste valable : on préfère les logiciels dont le fonctionnement a été validé par un usage réel
- Pour un projet personnel, on préfère au moins un outil que son créateur a lui-même utilisé pendant plusieurs semaines
- À l’échelle d’une version enterprise, cela devient le critère suivant : on ne veut pas adopter un CRM s’il n’a pas déjà été utilisé avec succès pendant six mois par au moins deux autres grandes entreprises
- Avant d’accepter le risque, on veut une solution qui a réellement prouvé qu’elle fonctionne
1 commentaires
Avis Hacker News
Le vibe coding et les LLM n’ont pas créé des organisations d’ingénierie ou des ingénieurs sans discipline, ils n’ont fait que révéler et accélérer des problèmes existants
Beaucoup d’ingénieurs ont des standards et des pratiques de codage laxistes, voire inexistants, et beaucoup d’équipes ont aussi des critères faibles pour déployer du code en production
Ce n’est pas un phénomène nouveau : cela signifie simplement que des individus et des équipes qui n’ont jamais vraiment respecté de standards dans le cycle de vie du développement logiciel peuvent désormais produire beaucoup plus de code et concrétiser plus facilement leurs idées
Je n’ai jamais vu un collègue devenir un bon ingénieur simplement parce qu’il écrivait du code plus vite
Les meilleurs ingénieurs que j’ai connus étaient ceux qui, grâce à leur expérience et à leur jugement prudent, partageaient avec l’équipe des intuitions essentielles qui orientaient le système dans la bonne direction
« Claude, construis-moi un système. Mais fais-le bien. Merci ! »
Avant, quand une codebase commençait à résister au développement de nouvelles fonctionnalités, on corrigeait le goulot d’étranglement du moment puis on repoussait le reste jusqu’au prochain point de friction
On développait les fonctionnalités en refactorant un peu au passage, mais les modèles de pointe repoussent encore plus loin le moment où « ça devient un problème »
Comme ils peuvent absorber jusqu’à un certain point l’amas de code qu’on leur donne, cela se manifeste plutôt par plus de régressions ou plus d’exigences oubliées par le LLM, sans forcément donner à l’humain l’impression que le travail devient plus difficile
Puis arrive un moment où tout est tellement cassé qu’il faut réparer, mais toute la codebase est devenue une stratification fractale de décisions que je n’ai jamais prises, et il devient difficile de tout démêler
Comme on n’édite plus directement le code, on perd aussi cette réaction physique du type « ajouter ça de cette manière crée trop de tension », ce qui rend plus difficile de trouver la percée de refactorisation
On peut toujours refactorer le code, et on peut forcer un agent à écrire de petits morceaux et fichiers modulaires
Que le code soit écrit par un agent ou par un humain, une bonne ingénierie reste une bonne ingénierie
Pour l’instant, un humain doit au minimum comprendre et piloter l’architecture, et les agents peuvent beaucoup aider pour l’exploration et les propositions
À moins que j’aie raté des progrès de ces dernières semaines, j’ai l’impression que l’IA n’est pas devenue plus fiable ; c’est plutôt que ses erreurs sont devenues plus subtiles
Si le code ne compile pas, c’est facile à repérer, et même s’il compile mais ne fonctionne pas, c’est encore relativement facile à détecter
Mais s’il compile et fonctionne tout en étant faux sur certains cas limites, ou en introduisant des vulnérabilités de sécurité, ou encore en traînant de la dette technique et des décisions d’architecture douteuses, c’est bien plus difficile à trouver, et la charge de revue ne diminue pas du tout
En fait, un code plausible est mentalement plus lourd à revoir qu’un code manifestement mauvais
Il suffit de lui faire écrire plusieurs tests d’abord, de vérifier que le code y correspond, et de lui demander d’organiser correctement le code
Mais en ce moment, l’enthousiasme venu d’en haut est tellement fort qu’il y a une pression pour les appliquer partout à grande échelle, et s’y opposer est si décourageant et limitant pour la carrière que cela use mentalement
À chaque fois qu’on pointe un problème évident, il surgit autant de solutions de contournement, puis d’autres problèmes apparaissent rapidement dans ces contournements, générant sans fin de nouvelles solutions
À un moment, tout cela finit par ressembler à du travail au service de la machine elle-même
Dans beaucoup d’entreprises, on dirait que le véritable objectif s’est brouillé et qu’il ne reste plus que le LLM lui-même
Je ne sais pas si ceux qui misent l’avenir de leur entreprise sur cette vision et l’exécutent disposent d’une sortie de secours confortable pour éviter les conséquences, ou si c’est simplement toute rationalité qui est jetée par-dessus bord
On peut sans doute atténuer les problèmes avec de sains principes d’ingénierie, mais je me demande quelle efficacité réelle on obtient au regard de la charge cognitive, du temps développeur, de l’argent et des ressources finies
Dans la phrase « que se casse-t-il quand on peut produire 2 000 lignes par jour au lieu de 200 », utiliser le nombre de lignes de code comme mesure de la production d’ingénierie est embarrassant
Revoir 200 lignes et en revoir 2 000, ce n’est pas du tout la même charge de travail
J’ai ensuite reconstruit le même programme dans ma tête en utilisant ChatGPT seulement comme moteur de recherche et autocomplétion, et j’ai obtenu le même résultat en 1 500 lignes
Honnêtement, l’écart d’effort n’était pas non plus énorme, mais l’approche écrite à la main bénéficiait peut-être du fait que j’avais déjà réfléchi à ce que je voulais construire grâce à la première version faite en vibe coding
Utiliser le nombre de lignes de code comme variable d’entrée de la revue logicielle a donc du sens
Littéralement parce qu’il faut lire chaque ligne
En revanche, comme mesure unique de la productivité développeur, c’est catastrophique, et c’est là que commencent les problèmes
Cela reste néanmoins utile parce que c’est presque la seule métrique immédiatement intuitive et comparable entre plusieurs entreprises, équipes, langages et contextes applicatifs
Même dans la même équipe travaillant sur le même produit, un changement de 1 000 lignes peut être réglé rapidement, alors qu’un correctif d’un bug d’une seule ligne peut demander plusieurs jours de débogage
C’est pour cela qu’il est difficile de comparer des PR, des fonctionnalités ou des story points hors contexte ; s’il existait une métrique standard de productivité développeur, tout le monde l’utiliserait, mais c’est intrinsèquement difficile
Pour ce type de comparaison, il est utile de supposer que le contexte reste le même
Par exemple, si une équipe d’une entreprise donnée travaillant sur un produit donné avec une stack technique donnée et un processus qualité donné produisait N1 lignes hier et N2 lignes aujourd’hui avec l’IA, alors l’écart entre N1 et N2 finit, avec le temps, par approximer l’impact réel
Les études rigoureuses sur la productivité du développement assisté par IA ont d’ailleurs, dans l’ensemble, mesuré les choses sous forme de tests A/B en comparant les PR d’un même groupe avant et après usage de l’IA
Pour moi, la différence tient à la qualité et à la rigueur du pipeline
Le vibe coding consiste à tenter une ou quelques fois, vérifier rapidement le résultat, puis l’utiliser jusqu’à ce que ça casse
C’est adapté aux preuves de concept légères ou aux applications à faible risque pour soi-même, sa famille ou une petite équipe
L’ingénierie agentique, elle, s’intéresse à un ensemble de préoccupations plus large : exactitude fonctionnelle, performance, infrastructure, résilience/disponibilité, scalabilité, maintenabilité
Elle repose sur un pipeline à plusieurs étapes qui gère le flux de travail, avec éventuellement des phases comme intake du projet, sélection, spécification, découpage en epics, découpage en stories, codage, documentation, déploiement
Chaque étape mêle des portes de qualité déterministes, comme la réussite des tests ou des seuils de performance, et des revues adversariales sur la valeur métier, l’exhaustivité des spécifications, l’élégance du code ou la rigueur et la simplicité du langage omniprésent
Là aussi, c’est un curseur
Parfois, on n’a pas envie de faire des entretiens, brûler des tokens, passer trois revues adversariales, estimer la valeur et rédiger des spécifications détaillées juste pour livrer une fonctionnalité ; on jette simplement le ticket dans le système
J’utilise Opus, GPT-5.5 et des modèles plus petits tous les jours, mais je ne leur confie pas l’ensemble du travail
Même en investissant pas mal d’efforts pour définir et affiner les spécifications, ils continuent de faire beaucoup de choses stupides qui ne passeraient jamais une revue de PR humaine
Si j’avais fait confiance à leur production, ou construit un gros pipeline agentique me donnant un faux sentiment de stabilité, j’aurais facilement pu laisser tout cela se déverser dans la codebase
Dans dix ans, ce sera peut-être mieux, mais aujourd’hui le vibe coding et les pipelines d’ingénierie agentique me semblent être deux variations sur le même thème : déléguer l’ensemble à des LLM
Ce matin encore, je me suis dit que je pouvais confier des modifications dans un fichier unique à Opus on Max, mais j’ai dû corriger des erreurs ou des oublis à presque chaque itération
Le code proposé aurait globalement fonctionné, mais il était trop complexe et il faisait régresser des parties que j’avais déjà simplifiées à la main
Si l’on multiplie cela par des milliers de commits d’agents, la codebase se dégrade très vite
Les équipes de développement se retrouvent en difficulté quand elles essaient de construire sans le bon processus de conception, de test et de revue
C’était déjà vrai avant le codage par agents, mais ça l’est encore plus maintenant, et les équipes qui comprendront comment utiliser les agents dans ce processus seront celles qui réussiront le mieux
N’avez-vous pas remarqué que les agents de codage s’approchent souvent énormément de la solution dès le premier essai, mais que faire passer les 10 % ou 5 % restants demande un travail énorme ?
Si l’on change la manière d’aborder le problème, l’agent peut combler cet écart
Il y a dix ans, on s’arrêtait de coder toutes les 10 à 15 minutes pour refactorer, tester et analyser, afin de vérifier que tout était parfait
Parce qu’un bug contaminait ensuite tout le reste du code
Les agents de codage ne savent pas faire cela, et continuent en traînant bugs et mauvaise architecture
Instinctivement, on voudrait les arrêter en cours de route, mais c’est impossible pour plusieurs raisons
À la place, comme le coût est très faible, il faut identifier le point où l’agent s’est trompé pour la première fois, corriger le prompt, puis tout supprimer et relancer depuis zéro au lieu de corriger le code
Il suffit de répéter cela jusqu’à ce que le prompt produise un code parfait
Certains diront que cela demande encore beaucoup de travail humain, mais c’est précisément le point
Les humains restent nécessaires et, utilisée de cette façon, l’outil permet d’écrire du code 10 fois plus vite
On peut obtenir assez vite « quelque chose qui marche », mais il faut beaucoup plus de temps pour évaluer d’autres options, peaufiner, tester et acquérir de la confiance
L’idée générale est juste, mais personne ne sait où se situe la frontière
L’année à venir sera probablement celle où tout le monde cherchera cette limite, ce qui explique aussi qu’on entende si souvent dire qu’« il faut réinventer GitHub »
Dans beaucoup de cas, investir pour mécaniser cette toute dernière partie n’a tout simplement pas de sens économiquement
Je pense que les fournisseurs de LLM ont choisi la mauvaise approche dès le départ
Ils auraient dû se concentrer sur le fait de compléter le travail humain plutôt que de le remplacer, et ils semblent en tirer une leçon coûteuse
Il aurait peut-être mieux valu repartir de zéro, mais au moment de commencer je ne savais pas encore à quoi devait ressembler l’architecture souhaitée
Ce n’est pas parce que les LLM ont du mal à faire entrer une fonctionnalité dans l’architecture existante qu’on peut jeter toute la codebase en fonctionnement et repartir de zéro
C’est un excellent texte, écrit par quelqu’un d’intelligent, humble et qui continue d’apprendre
J’ai aimé la phrase : « Il y a beaucoup de raisons pour lesquelles je ne crains pas que le fait que les ordinateurs puissent écrire leur propre code signifie la fin de la carrière d’ingénieur logiciel. En partie parce que ces outils sont des amplificateurs de l’expérience existante. Si vous savez ce que vous faites, vous pouvez aller beaucoup plus vite »
J’ai aussi aimé : « En utilisant ces outils, on nous rappelle sans cesse à quel point ce que nous faisons est difficile. Construire du logiciel est férocement difficile. Même avec tous les outils d’IA du monde, ce que nous essayons d’accomplir ici reste vraiment difficile »
L’observation selon laquelle le travail en amont change lui aussi est juste
Les outils côté design évoluent particulièrement vite, au point qu’il ne semble plus valable de supporter le coût de traduction lié à Figma
La partie inquiétante, c’est qu’on accumule dans la codebase des couches de complexité IA, jusqu’à ce que plus aucun humain ne comprenne le code et qu’il devienne très coûteux pour les derniers modèles de le déchiffrer et de le modifier
Bientôt, la réutilisation du code pourrait disparaître, et on pourrait finir par brûler de l’argent à réinventer la roue en permanence
Quand je faisais des applis Android à leurs débuts, il fallait absolument utiliser l’IDE, et il fallait écrire une quantité absurde de boilerplate juste pour afficher une alerte « Hello World » après avoir cliqué sur un bouton, c’était littéralement vidant pour l’âme
Répétez après moi : la plupart des logiciels passent la majeure partie de leur vie en phase de maintenance
Par conséquent, la plus grande partie de l’argent qu’un logiciel rapporte est gagnée pendant cette phase de maintenance
L’industrie, après presque 100 ans, n’a toujours pas compris cela
Alan Kay avait 100 % raison quand il disait que la révolution informatique n’avait pas encore eu lieu
Malgré toutes les avancées actuelles, nos outils restent globalement au niveau de l’âge de pierre
Mon grand espoir, c’est que l’IA nous accélère jusqu’au point où elle brisera complètement et irréversiblement le paradigme existant, pour qu’enfin on puisse faire quelque chose de nouveau, de différent et de meilleur
Alors pour l’instant, mettons un jetpack IA sur le cycle de vie du développement logiciel et voyons jusqu’où ça nous mène
Allons vite, et cassons vraiment les choses
Observation pertinente et qui me parle aussi
Je devais mettre en place un pipeline assez simple de téléchargement par lots → transformation → endpoint d’API, et j’avais écrit un prompt assez détaillé, mais en laissant volontairement beaucoup de détails d’implémentation comme la source de données ouverts
Opus 4.7 a produit quelque chose à environ 90 % conforme à ce que j’aurais fait, avec beaucoup plus de méthodes utilitaires et de validation étape par étape
C’était très bien, et cela m’a laissé plus de temps pour réfléchir à des problèmes plus difficiles
Je suis surtout développeur Python, mais j’utilise régulièrement d’autres langages backend qui me sont familiers sans être à mon meilleur niveau, comme Rust ou Go
Avec environ 13 ans d’expérience fortement concentrée sur un langage et une formation plus formelle sur d’autres, il devient beaucoup plus facile d’orchestrer les LLM
La charge d’apprentissage de la syntaxe, des composants de base, du gestionnaire de paquets, des tests, etc., n’est pas si importante comparée à l’ancienne manière de programmer
J’ai récemment aidé un collègue non développeur qui automatisait du reporting avec Claude cowork/code
Il comprenait bien la partie business intelligence, mais avait du mal à formuler les bases nécessaires pour vibe coder un wrapper pyautogui qui ouvre une session RDP et remplit des valeurs dans une abstraction MS Access posée sur une base de données fournisseur
En tant que métier, les développeurs semblent tranquilles pour les 5 à 10 prochaines années