Note de la rédaction : Alors que de plus en plus de gens débattent pour savoir si « l'IA va remplacer les programmeurs », Garry Tan, président de YC, soulève en réalité une autre question : si l'IA peut déjà accomplir la majorité du travail de programmation, pourquoi continuons-nous à la gérer comme on gère un logiciel ordinaire ?
Début de cette année, Garry Tan a passé plusieurs mois à écrire un projet, Garry's List, en Rails et avec des agents d'IA, qui contient 540 000 lignes de code. Une fois le projet terminé, il en a tiré une conclusion en apparence paradoxale : ces 540 000 lignes de code en elles-mêmes ne sont pas importantes ; ce qui a vraiment de la valeur, c'est le GStack qui s'est cristallisé pendant le développement – un nouveau type de framework de développement construit autour des workflows d'agents d'IA.
De son point de vue, l'industrie du logiciel a développé une sorte d'inertie collective ces dernières années : les développeurs ajoutent sans cesse des tests, des validateurs, des mécanismes de relance, des tâches en arrière-plan et toutes sortes de logiques de contrôle, enveloppant le modèle de couches successives. Cette approche avait sa raison d'être à une époque où les modèles étaient chers et leurs capacités limitées, mais maintenant que les LLM sont capables d'accomplir un grand nombre de tâches de manière autonome, ces systèmes ressemblent plutôt à la construction d'une « usine Foxconn » pour un travailleur super-intelligent – utilisant une multitude de règles et de processus pour contraindre un agent déjà compétent.
Avec la baisse rapide des coûts des modèles et l'amélioration continue de leurs capacités, l'accent du développement logiciel se déplace peut-être de « l'écriture de plus de code » vers « la conception de davantage de capacités ». L'auteur propose de construire des « skill packs » (packs de compétences, modules de capacités testables et réutilisables) en Markdown, permettant à l'Agent de générer automatiquement le code, les tests et le système d'évaluation, transformant ainsi des workflows complexes en actifs de capacités reproductibles à intérêts composés. Il donne même un exemple : un travail d'évaluation de hackathon qui prenait autrefois plusieurs jours peut désormais être accompli par un Agent en quelques dizaines de minutes.
Dans un sens, cet article ne parle pas de programmation, mais de la fin de la logique d'industrialisation du logiciel. Quand le code n'est plus la ressource la plus rare, le cœur de la compétitivité des ingénieurs commence aussi à se déplacer : déterminer ce qui vaut la peine d'être construit, comment définir le problème, et comment cristalliser l'expérience en capacités réutilisables devient plus important que d'écrire davantage de code. La conclusion ultime de l'auteur est : les meilleurs ingénieurs du futur ne seront pas nécessairement ceux qui écrivent le plus de code, mais peut-être ceux qui en écrivent le moins, tout en libérant le plus d'intelligence.
Voici l'article original :
En janvier de cette année, j'ai recommencé à écrire du code et j'ai réalisé Garry's List. Le code Rails et les tests écrits pour le contraindre représentent plus de 500 000 lignes.
J'en étais fier à l'époque. Mais je n'aurais pas dû. Ce qui méritait vraiment d'être fier, ce n'était pas cette application, mais la façon de travailler que j'ai découverte en la construisant. GStack, ma façon de programmer avec des Agents, a en fait émergé pendant la construction de Garry's List. Je l'ai ensuite rendu open source. Il fait maintenant partie des 100 projets open source les plus étoilés de l'histoire de GitHub, atteignant environ 105 000 étoiles en moins de trois mois.
Les plus de 500 000 lignes de code étaient le « produit ». Cette façon de travailler était le « sous-produit ». Et ce qui compte vraiment, c'est ce sous-produit.
Alors, au fond, c'est quoi, 540 000 lignes de code construites autour d'un LLM ?
C'est une usine Foxconn. Une usine construite pour un travailleur IA hautement intelligent. Un travailleur qui n'avait pas besoin d'être surveillé de près, mais pour lequel nous l'avons quand même construite.
Il faut mettre des sur-chaussures pour entrer. Se lever à 6h du matin. Faire des exercices collectifs. Rester jour après jour sur la même chaîne de montage. La vie est si dure qu'il faut installer des filets de sécurité sur tous les immeubles de grande hauteur, parce que – ce n'est pas une vie qu'on souhaiterait mener. Chaque test, chaque garde-fou, chaque boucle de relance, c'est un tour de vis supplémentaire dans la cage de ce travailleur. Un travailleur qui aurait pu faire ce travail tout seul, et même mille autres choses auxquelles vous n'avez même pas pensé.
Les humains et les Agents ont tous deux un potentiel infini, mais la logique de l'usine Foxconn, c'est d'extraire l'intelligence et le travail d'une vie qui pourrait être belle. Ils pourraient faire ce travail, et même 1000 fois plus, si seulement nous les y autorisions.
J'ai construit de telles usines. Aujourd'hui, presque tout le monde en construit. Et maintenant, je veux vous dire : arrêtez de le faire.
Le voyageur temporel
Ce que j'ai vraiment prouvé avec 539 000 lignes de code, c'est que je pouvais parfaitement me faire passer pour un voyageur temporel.
Un ingénieur Web 2.0 de 2013, c'est-à-dire moi la dernière fois que je pouvais vraiment me qualifier d'ingénieur logiciel, jeté en 2026, avec des outils modernes en main, mais construisant toujours un logiciel de la seule façon qu'il connaissait : plus de code. Toujours plus de code.
Les outils ont changé, mais mes réflexes n'ont pas changé.
L'ingénieur de 2013 croit profondément en une chose : la capacité est égale au nombre de lignes de code. Cette croyance était juste pendant des décennies, jusqu'à aujourd'hui.
Si vous me donnez Codex ou Claude Code, je peux accomplir le travail de 100 voire 1000 ingénieurs. Mais c'est toujours la même carte, avec juste un moteur plus rapide, fonçant à toute vitesse vers une destination qui est maintenant erronée.
C'est exactement la position où se trouvent presque tous les constructeurs d'IA aujourd'hui. Ils ont mis à niveau leurs outils, mais ils ont conservé le modèle mental de 2013.
Ce piège ne ressemble pas à un piège, parce que le code fonctionne bien. Garry's List a bien été mis en ligne. Ce mois-là, j'ai eu l'impression de vivre la période la plus productive de ma vie.
Mais c'était une productivité au service d'une idée dépassée.
Les LLM étaient chers, alors il fallait les « domestiquer »
L'ancienne économie, valable jusqu'aux alentours de 2025, était : les appels aux LLM sont chers, et le code est bon marché.
Donc, vous écriviez du code pour économiser des appels au modèle, le contraindre, le domestiquer, l'appeler avec précaution. L'architecture de l'époque était : beaucoup de logiciel pour envelopper quelques précieux appels de modèle.
Mais les deux côtés de cette équation se sont inversés.
Les modèles deviennent bon marché, et chaque trimestre encore plus bon marché. En même temps, les modèles sont suffisamment intelligents, le rapport valeur/coût s'est inversé. Les modèles peuvent aussi écrire du code utilisable.
Donc, vous n'avez plus besoin d'écrire du code pour « surveiller » le modèle. Vous pouvez dire en langage naturel au modèle quoi faire, et le laisser n'écrire que le code minimal vraiment nécessaire.
C'est le logiciel just-in-time (généré à la volée), et nous entrons dans son âge d'or.
La forme de l'artefact logiciel a aussi radicalement changé. Cette application Rails, ce sont 540 000 lignes de code que j'ai écrites et que je possède, ainsi que les tests pour la superviser. Son remplacement, c'est un Agent constitué de Markdown et d'un peu de code, dont l'échelle est une fraction de la première.
Capacités identiques. Plus facile à lire. Plus facile à maintenir. Et bien plus flexible. Parce que le comportement réside dans des instructions que vous pouvez éditer en langage naturel, et non pas figé dans une logique écrite un jour dans du code.
Nous écrivions du code pour surveiller quelque chose, mais maintenant, cette chose est plus intelligente que ce code.
À l'intérieur de l'usine Foxconn : même les filets de sécurité sont en place
Si vous avez écrit du code récemment, vous avez probablement construit ce genre d'usine sans le savoir.
Vous pouvez parcourir votre base de code et compter combien de lignes n'existent que parce que vous ne faites pas confiance au modèle pour accomplir son travail. Dans ma base de code, il y avait environ 262 000 lignes de code applicatif, et environ 276 000 lignes de tests pour le superviser. Le comité d'audit était plus grand que l'entreprise elle-même.
Certains nettoyeurs vérifient des entrées que le modèle aurait pu traiter lui-même. Certains validateurs vérifient des sorties que le modèle aurait pu détecter lui-même. Des boucles de relance enveloppent des appels de modèle, alors que le modèle pourrait déjà se rétablir tout seul. Chaque ligne de code comme ça, c'est un pari : ce travailleur va forcément échouer.
Vous avez aussi écrit des paris similaires. Nous l'avons tous fait.
127 tâches en arrière-plan, dont 33 tâches planifiées. Ce n'est pas une capacité, c'est mettre 33 réveils pour un travailleur LLM qui maintenant arrive généralement à l'heure.
À l'époque où je construisais « l'usine Foxconn », Claude et moi avons écrit un fichier de 1778 lignes. Son seul but était de remettre en question les faits énoncés par le modèle.
Il décomposait chaque affirmation faite par le modèle, l'envoyait en parallèle à cinq sources différentes pour vérification, puis lui attribuait un score. Les affirmations simples passaient d'abord par un seuil de triage léger, pour éviter que tout ne passe par le processus complet. Si le premier tour ne donnait aucun résultat, on relançait. Et puis il y avait les plans de secours des plans de secours.
Dans un épisode de Rick et Morty, Rick construit un petit robot sur la table du petit-déjeuner. Le robot démarre, lève la tête et demande : Quelle est ma mission ? Rick répond : Tu passes le beurre. Le robot pousse le plat de beurre, baisse les yeux vers ses mains et dit : Oh mon Dieu. Et puis il reste assis là. Ce robot avait aussi un potentiel infini. Il a été construit pour passer le beurre. Mes 276 000 lignes de tests, c'était ce plat de beurre.
Quand vous construisez un logiciel avec la méthode « usine Foxconn » façon 2023, vous construisez une cage. Si vous n'y prenez pas garde, vous allez devenir vous-même le gardien de cette prison pour agents d'IA.
Le Markdown est maintenant du programme
Quand je dis Markdown, je ne parle pas de prompt.
Un prompt, c'est éphémère. Vous entrez une phrase, obtenez un résultat, et puis il s'évapore.
Je parle de construction. De construction versionnée, testable, réutilisable.
Le Markdown, c'est la couche d'instruction : l'intention, la compétence, le jugement, les explications sur la façon dont le travail doit être accompli. Le TypeScript, c'est une fine couche de logique déterministe. Elle ne s'occupe que des quelques choses qui doivent vraiment être faites par du code : les E/S, et les parties qui ne doivent absolument pas halluciner.
Surtout, vous devez tester le Markdown comme vous testeriez du code.
Dans mon système, cette boucle ne nécessite qu'un mot : skillify it.
Je commence par créer quelque chose avec l'Agent, jusqu'à ce que ça fonctionne. Puis je dis : « skillify it ». Ensuite, l'Agent écrit :
La documentation de la compétence en Markdown ;
Le code minimal dont elle a besoin ;
Les tests unitaires pour ce code ;
L'évaluation LLM de la compétence ;
Les tests d'intégration couvrant la compétence et le code ;
Un resolver permettant à l'Agent d'appeler automatiquement cette compétence dans les scénarios pertinents ;
Et l'évaluation du resolver lui-même.
L'ensemble, c'est un skill pack (pack de compétences). C'est une unité de capacité réutilisable, qui génère des intérêts composés.
Ce qui est vraiment magique, ce sont les tests : la couverture de la skill permet qu'elle survive aux changements sans être cassée. C'est la différence avec le vibe coding (coder à l'instinct). Le vibe coding, c'est juste un ressenti. Le skill pack a des tests.
Nous commençons tout juste à explorer en temps réel les primitives système de l'ingénierie d'agents, comme l'invention de la pile, du tas, des registres et de l'architecture de von Neumann aux premiers temps des CPU.
Je pense que le skill pack est l'une de ces primitives. Le harness (cadre d'exécution) en est une autre.
La plupart des gens ne s'en rendent pas encore compte, car ils mesurent toujours le logiciel en nombre de lignes de code.
Vous pouvez vraiment construire des trucs fous
Ce n'est pas un argument de jouet.
Ce que cet Agent peut faire dépasse déjà ce que faisait l'application Rails de plus de 500 000 lignes, et le nouveau code n'est qu'une fraction de celui-ci.
Un exemple concret : l'évaluation d'un hackathon.
Un samedi il y a deux semaines, nous avons organisé un hackathon GStack/GBrain, avec 85 soumissions. J'ai téléchargé le Google Drive contenant tous les projets, puis j'ai dit : commence.
L'Agent a analysé la qualité du code de chaque dépôt, a fait des recherches approfondies sur chaque participant, a regardé et fait des captures d'écran de chaque vidéo de démo, a noté les interfaces, et a classé les 85 équipes. Enfin, il m'a indiqué les 5 applications les plus remarquables parmi cette fournée.
Évaluer un hackathon, autrefois un travail fastidieux de plusieurs jours, est devenu une affaire d'environ 30 minutes.
Je n'ai pas écrit de code. J'ai fait faire la tâche par OpenClaw, je l'ai guidé. Une fois terminé, j'ai dit : skillify it.
C'est ainsi devenu un tarball que n'importe qui peut réutiliser pour toujours, applicable à n'importe quelle feuille de hackathon.
Je dis maintenant « skillify » presque tous les jours. J'ai plus de 350 skill packs. Presque toutes les tâches que je dois traiter dans ma vie personnelle et professionnelle, mon Agent peut maintenant les faire.
C'est un exemple de l'inversion.
Avant, une telle capacité aurait été un véritable projet logiciel : nécessitant un scraper, un pipeline de notation, un traitement vidéo, un module de recherche, un système de classement. Maintenant, c'est devenu du Markdown plus un peu de code, construit par un Agent en un après-midi, et réutilisable par tous.
Au fait, le gagnant de ce hackathon a effectivement écrit du code que j'ai finalement polie et fusionnée dans la branche main. Maintenant, GStack peut tester des applications iOS sur simulateur et appareil réel, et cette fonctionnalité complète a été réalisée par une seule personne en moins de 8 heures pendant le hackathon.
Tokenmaxxing
Il y a un ticket d'entrée ici, mais presque personne n'est prêt à le payer : vous devez être prêt à dépenser de l'argent en tokens.
Peter Steinberger a créé OpenClaw, mon harness préféré. Il a dit qu'il était prêt à dépenser environ 1 million de dollars par an en tokens.
La plupart des gens reculent en entendant ce chiffre. Mais ils ne devraient pas, car l'or est ici : si vous êtes prêt à le faire, vous pouvez vivre en 2028. Et les autres mettront des années à rattraper.
C'est aussi pourquoi OpenAI a décidé d'offrir 2 millions de dollars de crédits token à chaque entreprise de YC, sous la forme d'un SAFE sans plafond.
Quand vous pouvez transformer l'intelligence brute en tokens, puis les tokens en résultats réellement utilisables par les utilisateurs, qui répondent à de vrais besoins et pour lesquels les utilisateurs sont prêts à payer, quelque chose de magique se produit.
Si vous êtes fondateur, vous devez pousser cette capacité au maximum. C'est aussi pourquoi j'insiste tant sur le skillify, car c'est une méthode qui apporte vraiment de bons résultats.
Durant l'ère précédente, nous pensions toujours que les appels LLM étaient trop chers, qu'il fallait les rationner. Nous les avons rationnés.
Mais maintenant, c'est précisément cet instinct qui ralentit les gens.
Si vous êtes prêt à tokenmaxer, à laisser l'Agent consommer librement des tokens, à le faire tourner en continu, vous obtenez un avantage du premier arrivé similaire au début d'Internet en 1994, sauf que le coût cette fois est payé en tokens.
Cela exclura plus de 99,99 % des organisations qui mégotent encore sur une ressource dont le prix s'effondre, et donnera l'avantage à la poignée de personnes qui ont vraiment compris.
Quelques dizaines de milliers à quelques centaines de milliers de dollars par an, voire moins pour certains, vous permettent aujourd'hui de fonctionner comme le monde entier devra le faire dans quelques années.
Vous pouvez vivre en 2026 comme on vivra en 2028. Cet investissement anticipé en vaut la peine. Parce que 100 000 dollars de tokens aujourd'hui, ça pourrait ne coûter que 10 000 dollars l'an prochain, 1000 dollars l'année d'après, et peut-être 100 dollars fin 2028.
Si vous disiez à n'importe quel entrepreneur de l'histoire : vous pouvez investir un capital à six chiffres pour vous projeter de deux à trois ans dans le futur, et maintenir cet avantage pendant plusieurs années, sur 100 fondateurs qualifiés, 100 prendraient ce marché.
La seule chose qui bloque, c'est cet instinct de 2013 : qui vous dit que les appels de modèle sont trop chers, qu'on ne peut pas les laisser libres.
Mais ils ne sont plus chers. C'est l'ancienne économie. L'inversion a eu lieu.
Esalen, pas Foxconn
Si 540 000 lignes de code de contrôle consistent à construire une usine Foxconn pour le travailleur, alors la solution, c'est de construire son contraire.
Il y a un endroit appelé Esalen, au sommet des falaises de Big Sur. Les gens y vont pour être démontés, remontés, lâcher leurs armures, et revenir davantage eux-mêmes.
Pas de chaîne de montage. Pas de contremaître. Pas de coup de sifflet à 6h du matin. De la liberté, pas du contrôle.
Construisez ce genre de chose.
Construisez un endroit comme YC : où nous vous aidons à créer votre entreprise, à résoudre de vrais problèmes, à trouver le product-market fit.
Construisez les endroits qui laissent les travailleurs libres, que ces travailleurs soient humains ou IA.
C'est tout l'esprit.
Faites les choses qui libèrent les Agents. Faites les entreprises qui libèrent le potentiel humain.
Dans le travail du savoir, l'usine est un mode d'échec. Le vrai but, c'est de créer des institutions qui libèrent les gens. Maintenant, ce but s'applique aussi aux Agents.
OpenClaw, c'est comme une Ferrari à laquelle vous devez apporter votre propre clé. Le modèle est le moteur, pas la voiture entière. Nous sommes encore au moment Apple I, à souder sur des planches à pain.
Il a été publié brut. Vous devez encore le terminer vous-même.
Ce que j'ai rendu open source – GBrain, le moteur de recherche, les skill packs – ce n'est pas encore un produit complet prêt à l'emploi.
Certains disent qu'OpenClaw n'est pas sûr. Ils ne comprennent pas que sa puissance vient précisément de sa liberté. Ne vous précipitez pas pour visser des garde-fous de sécurité sur une chose en laquelle vous avez confiance, avant d'avoir réellement rencontré un problème. La clé que vous tenez dans vos mains prouve justement qu'elle n'est pas encore enfermée dans une cage.
Les systèmes de contrôle sont raffinés parce que le contrôle exige un contrôle total, l'usine Foxconn. Les systèmes de liberté sont bruts parce qu'ils croient que vous allez les terminer.
Vous devez choisir lequel vous construisez. Puis regardez en arrière la quantité de code que vous avez écrite.
Ce que tout cela signifie vraiment
540 000 lignes de code Rails, c'était moi qui prouvais que je pouvais encore jouer au plus haut niveau dans le vieux jeu.
Mais ce niveau appartient au Web 2.0, à il y a dix ans.
Je pouvais toujours jouer aussi bien qu'avant, je pouvais même devenir un ingénieur 1000x. Mais je construisais des usines Foxconn. Du vieux code. Un vieux jeu.
Et le nouveau jeu, on n'y joue pas du tout avec le nombre de lignes de code.
Résultat, mes haters avaient raison. Si vous lisez cet article, amis anonymes, je vous salue.
Quand vous pouvez transformer directement l'intention en systèmes exécutables, testables, réutilisables, le goulot d'étranglement n'est plus la quantité de choses que vous pouvez construire, mais ce que vous voulez vraiment, et si cela vaut la peine d'être construit.
Les ressources rares deviennent la clarté, le goût et le jugement.
L'ingénieur qui écrit le moins de code est souvent celui qui construit le plus de choses.
Il m'a fallu écrire 540 000 lignes de code pour apprendre ça. Vous n'avez pas besoin de refaire le chemin.
