La mort du code a été exagérée
(stevekrouse.com)Introduction — l’illusion de la spécification en anglais
- Texte inspiré par l’idée que « une spécification suffisamment détaillée, c’est du code ». Une spécification en anglais semble intuitivement précise, mais dès qu’on essaie de l’implémenter, son ambiguïté apparaît
- « Tout est vague tant qu’on n’a pas essayé de le rendre précis » — Bertrand Russell
- Comme l’écriture, la programmation est une activité itérative qui s’affûte au fur et à mesure qu’on la pratique (cet essai aussi est passé par d’innombrables brouillons)
Vibe coding — pourquoi ça marche, et pourquoi c’est dangereux
- Comme l’IA convertit de mieux en mieux et de plus en plus vite l’anglais en code exécutable, il devient possible de produire du code à partir d’un simple « ressenti » au niveau de l’anglais
- On réagit au résultat produit par l’IA — « déplace le bouton là-bas, rends-le plus bleu » — dans un processus qui devient progressivement plus précis
- L’expression « vibe coding » est parfaite pour cette raison : on conserve un vibe au niveau du langage naturel, tandis que le résultat de l’IA aiguise la pensée
- Problème central : le vibe donne l’illusion d’une abstraction précise. Quand les fonctionnalités se multiplient ou que l’échelle augmente, l’abstraction fuit, et des bugs imprévus peuvent ruiner une journée entière
Cas concret — l’app de vibe coding de Dan Shipper
- L’application d’éditeur de texte créée par Dan Shipper en vibe coding devient virale → les serveurs tombent
- Cause : la « collaboration en temps réel (live collaboration) » semble intuitivement simple, alors qu’en pratique c’est un cauchemar de complexité
- Nous avons tous utilisé Google Docs ou Notion, donc « collaboration en temps réel » donne l’impression d’être une notion précisément spécifiée. Il est pourtant extrêmement difficile de comprendre à l’avance pourquoi ce n’est pas le cas
- L’auteur lui-même a vécu, il y a 10 ans, le cauchemar d’une complexité imprévue en construisant un éditeur collaboratif. Qu’est-ce qui était difficile ? Il ne s’en souvient même plus ! C’est une partie du problème : la complexité est ennuyeuse, on n’a pas envie d’y penser, et il est difficile de se rappeler les détails et les edge cases
- Exemple : le flowchart classique de Slack pour décider s’il faut envoyer une notification — ce niveau de complexité se cache derrière une formulation aussi simple que « envoyer une notification »
Abstraction — le seul outil pour traiter la complexité
- Limite fondamentale du cerveau humain : il ne peut traiter que 7±2 éléments à la fois
- Le seul moyen d’en traiter plus de 7 : compresser plusieurs éléments en un seul. Comme on peut répéter ce processus récursivement à l’infini, l’humain peut gérer une complexité infinie. Cette étape de compression, c’est précisément l’abstraction
- « Le but de l’abstraction n’est pas d’être vague, mais de créer un nouveau niveau sémantique dans lequel on peut être absolument précis » — Dijkstra
- Exemple de Sophie Alpert, qui a refactoré le célèbre flowchart de notifications de Slack en une forme beaucoup plus simple grâce à une abstraction intelligente
- Ce qu’il y a de meilleur dans la programmation : créer des abstractions toujours meilleures pour dompter la complexité, comme ReactJS ou TailwindCSS l’ont fait chacun dans leur domaine
- Si un éditeur de texte collaboratif est fondamentalement complexe, cela signifie simplement qu’il faut continuer à chercher de meilleures abstractions
AGI — le bon code ne disparaîtra pas pour autant
- Si l’on se projette à 1 an, 2 ans, 5 ans, 10 ans ou 100 ans : l’IA deviendra toujours meilleure, plus rapide et moins chère, jusqu’au moment où l’intelligence machine deviendra indiscernable de l’intelligence humaine (AGI)
- Un monde avec l’AGI peut ressembler à un monde du vibe. Si l’on pouvait disposer de 100 génies du niveau de Kapasi pour 1 000 $/mois, pourquoi se soucier de détails pénibles ?
- « C’est vraiment une idée absurde. » Ce genre de pensée n’existe qu’avant l’arrivée de la technologie, quand elle reste à l’état abstrait
- Si l’on avait accès à un tel niveau d’intelligence, 0 % des gens l’utiliseraient pour produire davantage de slop. Évidemment que non
- La confusion vient du fait qu’on pense à tort que le code ne sert qu’à produire du logiciel. Le code lui-même est aussi un artefact essentiel. Bien écrit, il peut être de la poésie
- « Personne ne parle de “vibe writing”, non ? » — personne ne croit que ChatGPT remplacera les grands romanciers ou journalistes. Pour le code, c’est pareil, mais on se laisse tromper par le caractère « magique » du code exécutable
- L’IA produit du code médiocre (de moins en moins). Nous le savons tous. Si nous l’utilisons, c’est malgré ce mauvais code, pas à cause de lui
- Citation de Simon Willison : « l’IA devrait nous aider à produire un meilleur code »
- La première chose à faire à l’arrivée de l’AGI : résoudre les problèmes d’abstraction les plus difficiles, créer de meilleures abstractions pour mieux comprendre et dompter la complexité
- Dire que le besoin de bon code disparaîtra à mesure que l’IA devient plus intelligente ? C’est exactement comme dire qu’on va utiliser ChatGPT pour produire encore plus de slop
- Cas concret : Opus 4.6 a résolu d’un seul coup un problème non résolu dans la création par Val Town de son framework React full-stack (vtrr). Une démo d’application full-stack mono-fichier en 50 lignes en est le résultat
Conclusion — le code ne fait que commencer
- On dirait que 99 % de la société est d’accord avec l’idée que « le code est mort ». Hier encore, j’ai entendu le podcasteur Sam Harris affirmer avec assurance que « tout le monde s’accorde à dire que le code est mort, plus personne n’a besoin d’apprendre à coder »
- « C’est triste. C’est comme dire “le storytelling est mort” après l’invention de l’imprimerie. Bande d’idiots, le code ne fait que commencer. L’IA sera une bénédiction immense pour la programmation. »
- Citations de clôture :
- « Il ne faut pas considérer comme un fardeau l’obligation d’utiliser des symboles formels, mais comme un privilège le fait de pouvoir le faire. Grâce à cela, les étudiants peuvent désormais accomplir ce que seuls des génies pouvaient faire autrefois » — Dijkstra
- « Le fait de pouvoir utiliser sa langue maternelle “naturellement” signifie seulement qu’on peut facilement produire des phrases dont l’absurdité n’est pas évidente » — Dijkstra, « On the foolishness of natural language programming »
- « Il existe deux façons de concevoir un logiciel : l’une consiste à le rendre si simple qu’il n’a manifestement aucun défaut, l’autre à le rendre si complexe qu’il n’a manifestement aucun défaut » — Tony Hoare
- « La quantité de sens compressée dans un petit espace par les symboles algébriques facilite le raisonnement que nous menons grâce à eux » — Charles Babbage
8 commentaires
Avant même de parler d’édition collaborative, rien que le fait d’implémenter correctement un éditeur utilisé seul déborde déjà de complexités inattendues : gestion du curseur, pile d’annulation/rétablissement, saisie IME, etc. Comme le souligne l’article, il y a peu de logiciels qui révèlent aussi bien que les éditeurs le piège des « spécifications qui semblent intuitivement précises ». Au fond, si cela paraît simple, ce n’est pas parce que ça l’est, mais parce que cette complexité a été bien abstraite et masquée.
En fait, si Anthropic a aussi choisi de créer un compilateur C pour sa démo, c’est sans doute parce qu’un compilateur repose sur des spécifications précises et sur des cas de test bien préparés. En même temps, cela donne aussi l’impression d’être extrêmement difficile.
J’ai créé quelques compilateurs, et je travaille encore sur l’un d’eux en ce moment ; du point de vue du vibe coding, j’ai aussi essayé de faire un éditeur, mais le compilateur m’a semblé plus simple. Comme vous l’avez écrit, j’ai l’impression que les spécifications sont moins précises et qu’il y a davantage de variables dues aux utilisateurs. C’est aussi plus difficile à tester.
Les spécifications deviennent certes plus importantes, mais j’ai toujours pensé qu’il était impossible de tout écrire en détail et de couvrir toutes les situations. Je pense qu’il vaut encore mieux affiner les spécifications au fil du travail, un peu comme du code ; cela dit, je me dis qu’on pourrait peut-être faire en sorte que plusieurs agents s’en chargent entre eux. Mais au final, sans intervention humaine, il sera difficile de sortir du cadre des situations et des connaissances apprises ; je me demande donc si des situations et des fonctionnalités totalement nouvelles ne resteront pas hors de portée.
Cela me rappelle l’époque où les robots aspirateurs sont apparus pour la première fois : on disait qu’il fallait faire un « simple rangement » en enlevant les objets au sol pour le robot. Écrire des spécifications détaillées pour l’IA représente aussi un travail considérable, et on a l’impression de travailler pour l’IA.
Les IDE et les PR sont tous morts, mais le code, lui, a ressuscité ?
Le code est la spécification la plus exacte sur le plan logique dans un système simple.
Mais le piège, c’est que le monde réel est un système complexe… au final, seules les données restent malgré tout la spécification la plus précise.
Je pense qu’il faut voir si cela peut être remplacé par d’autres méthodes de validation. Plus on est proche du front, plus on peut probablement vérifier que cela fonctionne bien rien qu’avec de l’E2E via le comportement du navigateur. En revanche, plus le code est proche du back et de l’infrastructure, plus la revue de code me semble indispensable. Sinon, il sera difficile de valider des effets de bord invisibles, comme des transactions qui s’ouvrent et se ferment ou des appels d’API qui partent.
Les navigateurs regorgent de problèmes que même les tests E2E ne parviennent pas à détecter.
Qu’est-ce qu’il peut bien y avoir ?