Arrêtez de construire des usines Foxconn pour vos agents

En janvier, je me suis remis au code et j’ai construit Garry’s List. Plus de cinq cent mille lignes de Rails et les tests pour les contrôler.

J’en étais fier. J’aurais pas dû. Ce qui méritait d’être fier, ce n’était pas l’appli. C’était la configuration qui en a découlé. GStack, ma façon de coder avec des agents, est née du travail de construction de Garry’s List, et je l’ai donnée. C’est l’un des projets open source les plus cloutés de l’histoire de GitHub, environ 105 000 étoiles en moins de trois mois. Les cinq cent mille lignes étaient le produit. La configuration était le sous-produit. Le sous-produit, c’est ce qui compte.

Voici ce qu’est réellement 540 000 lignes de code enveloppées autour d’un LLM.

C’est une usine Foxconn. Construite pour un travailleur IA hyper-intelligent qui n’a pas besoin d’hyper-vigilance. On l’a construite quand même.

Des petites surchaussures à l’entrée. Lever à 6h. De la gym. Une vie si dure qu’il faut ériger des filets autour des étages élevés de chaque bâtiment, parce que… ben, c’est pas une vie que tu veux vivre. La même chaîne de montage pour toujours. Chaque test, chaque garde-fou, chaque boucle de réessai, un centimètre de cage boulonné sur un travailleur qui peut déjà faire le job et mille choses que tu ne lui as pas demandées.

Les humains et les agents contiennent tous des multitudes, mais les usines Foxconn sont construites pour extraire l’intelligence et le travail d’êtres magnifiques qui pourraient faire tout ce travail et 1000 fois plus si on les laissait faire.

J’ai construit l’usine. Tout le monde en construit aujourd’hui. Je te dis de ne pas le faire.

Le voyageur temporel

Ce que j’ai réellement fait avec mes 539k LOC écrites, c’est prouver que je pouvais parfaitement incarner un voyageur temporel. Un ingénieur Web 2.0 de 2013 (moi, la dernière fois que j’étais un vrai ingénieur logiciel) parachuté en 2026 avec des outils modernes, construisant de la seule façon qu’il connaissait. Plus de code. Toujours plus de code. Les outils avaient changé. Mes instincts, non.

L’ingénieur de 2013 croit une chose au plus profond de lui : la capacité équivaut au nombre de lignes de code. Cette croyance était correcte pendant des décennies, jusqu’à maintenant. Donne-moi Codex ou Claude Code et je ferai le travail de 100 à 1000 ingénieurs. Même carte, moteur plus rapide, le chemin le plus rapide possible vers ce qui est maintenant le mauvais endroit.

C’est là que se trouve presque tout le monde qui construit avec l’IA en ce moment. Ils ont mis à jour l’outil et ont gardé le modèle mental de 2013. Le piège ne ressemble pas à un piège, parce que le code fonctionne. Garry’s List a été livrée. C’était le mois le plus productif de ma vie.

C’était la productivité au service d’une idée obsolète.

Les LLM étaient chers, donc il fallait les maîtriser

Les anciennes économies pendant de nombreuses années jusqu’en 2025 : les appels LLM étaient chers et le code était bon marché. Donc on écrivait du code pour rationner le modèle, pour le maîtriser, pour l’appeler prudemment et parcimonieusement. L’architecture était beaucoup de logiciels enveloppés protectivement autour de quelques précieux appels au modèle.

Les deux parties de cette équation ont basculé.

Le modèle devient maintenant bon marché et le devient de plus en plus chaque trimestre, et il est si intelligent que le rapport valeur-coût a basculé. Et le modèle peut écrire du code utilisable. Donc tu arrêtes d’écrire du code pour surveiller le modèle. Tu peux maintenant donner des instructions au modèle en langage clair et tu le laisses écrire le code minimal réellement nécessaire.

C’est le logiciel juste-à-temps, et nous entrons dans l’âge d’or de celui-ci.

L’artefact change complètement de forme. L’appli Rails faisait 540 000 lignes que j’ai écrites et que je possède, code plus les tests construits pour le contrôler. Le remplacement est un agent construit sur du markdown et du code, une fraction de cela. Même capacité. Plus facile à lire. Plus facile à maintenir. Beaucoup plus flexible, parce que le comportement vit dans des instructions que tu peux éditer en langage clair au lieu d’une logique figée dans le code le jour où tu l’as écrite.

On écrivait du code pour surveiller une chose qui est maintenant plus intelligente que le code.

À l’intérieur de l’usine Foxconn, filets et tout

Si tu codes récemment, tu construis probablement ce genre d’usine sans le savoir. Parcours ta propre base de code et compte les lignes qui existent seulement parce que tu ne faisais pas confiance au modèle pour faire son travail.

Les miennes : environ 262 000 lignes de code applicatif, et environ 276 000 lignes de tests boulonnées pour le contrôler. Le comité d’audit était plus grand que l’entreprise. Des sanitiseurs vérifiant les entrées que le modèle aurait gérées. Des validateurs vérifiant les sorties que le modèle aurait détectées. Des boucles de réessai enveloppant des appels dont le modèle se remet tout seul. Chacune de ces lignes est un pari que le travailleur échouera. Tu as écrit les mêmes paris. Nous tous.

127 jobs en arrière-plan, 33 d’entre eux en cron. Ce n’est pas de la capacité. Ce sont 33 alarmes réglées pour un travailleur LLM qui, de nos jours, arrive généralement à l’heure.

À l’époque où je construisais mon usine Foxconn, Claude et moi avons écrit un fichier de 1 778 lignes dont le seul travail est de remettre en question les faits du modèle. Il prend chaque affirmation que le modèle fait, la diffuse vers cinq sources séparées en parallèle, et les note. Un portail de tri pour que les affirmations faciles évitent la rafale complète. Un réessai si le premier passage revient vide. Des solutions de repli pour les solutions de repli.

Il y a un épisode de Rick et Morty où Rick construit un petit robot à la table du petit-déjeuner. Il s’allume, lève les yeux, et demande quel est son but. Rick dit : « Tu passes le beurre. » Le robot glisse le beurrier à travers la table, regarde ses propres mains, et dit : « Oh mon dieu. » Puis il reste assis là. Ce robot contient des multitudes. Il a été construit pour passer le beurre. Mes 276 000 lignes de tests étaient le beurrier.

Quand tu construis ce genre de logiciel, à la manière de l’usine Foxconn de 2023, tu as construit une cage, et si tu n’es pas prudent, tu seras le geôlier qui entretient la prison pour tes agents IA.

Le markdown est le programme maintenant

Quand je dis markdown, je ne parle pas de prompting. Le prompting est éphémère. Tu tapes quelque chose, tu obtiens quelque chose, ça s’évapore.

Ça, c’est de la construction. Versionné, testé, réutilisable.

Le markdown est la couche d’instruction : l’intention, la compétence, le jugement sur la façon dont le travail doit être fait. Le TypeScript est la fine couche déterministe. Les rares choses qui doivent vraiment être du code, les I/O, les parties qui ne doivent jamais halluciner.

Et surtout, tu testes le markdown comme tu testerais du code. Dans ma configuration, la boucle tient en un mot. Je construis quelque chose avec l’agent jusqu’à ce que ça marche, puis je dis « skillify it. » L’agent écrit alors :

• la compétence en markdown
• le code minimal nécessaire
• un test unitaire pour le code
• une évaluation LLM pour la compétence
• un test d’intégration pour les deux
• un résolveur pour que l’agent invoque la compétence automatiquement quand elle est pertinente
• et une évaluation pour le résolveur

Ce bundle est un skill pack. Une unité de capacité réutilisable qui se cumule. Les tests sont la magie : la couverture sur la compétence est ce qui permet de la modifier sans la casser. C’est ce qui la distingue du vibe coding. Le vibe coding, c’est une ambiance. Un skill pack a des tests.

Nous ne faisons que découvrir les primitives système pour l’ingénierie agentique en temps réel, comme les débuts de l’ère CPU ont inventé la pile, le tas, les registres, la machine de von Neumann. Je pense qu’un skill pack est l’une de ces primitives. Un harnais en est une autre. La plupart des gens ne l’ont pas remarqué, parce qu’ils mesurent encore le logiciel en lignes.

Les trucs de fou que tu peux réellement construire

Ce n’est pas un argument théorique. L’agent fait plus que l’application Rails de cinq cent mille lignes ne faisait, avec une fraction du nouveau code. Concrètement :

Le juge de hackathon. Il y a deux samedis, nous avons organisé un hackathon GStack/GBrain. 85 soumissions. J’ai téléchargé le Google Drive des soumissions et j’ai dit « go ». L’agent a analysé la qualité du code de chaque dépôt, a fait des recherches approfondies sur chaque personne présente, a regardé et capturé chaque vidéo de démo, a noté les écrans, et a classé les 85 équipes dans l’ordre. Puis il m’a dit les cinq applications du lot qui méritaient attention. Juger un hackathon est passé d’une corvée de plusieurs jours à environ trente minutes.

Je n’ai pas écrit le code. J’ai confié la tâche à OpenClaw, et je l’ai guidé. Puis, une fois terminé, j’ai dit « skillify it », et maintenant c’est un tarball que n’importe qui peut exécuter sur n’importe quel tableur de hackathon, pour toujours. Je dis « skillify » tout le temps maintenant et j’ai plus de 350 skill packs. Presque toutes les tâches personnelles et professionnelles que j’ai besoin de faire, mon agent peut maintenant les faire.

C’est l’inversion en un exemple. Une capacité qui aurait été un vrai projet logiciel, avec des scrapers, un pipeline de notation, du traitement vidéo, un module de recherche, un système de classement, est devenue du markdown plus un peu de code, construit par l’agent, en un après-midi, réutilisable par tout le monde.

En aparté : le gagnant du hackathon a réellement construit du code que j’ai fini par polir et intégrer dans la branche principale ! GStack peut maintenant tester les apps iOS à la fois dans le simulateur et sur des appareils réels, et cette fonctionnalité complète a été réalisée en moins de 8 heures lors d’un hackathon par une seule personne !

Tokenmaxxing

Il y a un prix d’entrée, et presque personne ne le paie : il faut être prêt à dépenser en tokens.

Peter Steinberger a construit OpenClaw, mon harnais préféré. Il a dit qu’il est prêt à dépenser de l’ordre d’un million de dollars par an en tokens pour le faire. La plupart des gens entendent ça et frémissent, mais ils ne devraient pas parce que c’est l’or : tu peux vivre en 2028 si tu arrives à faire ça, et il faudra des années avant que les gens ne rattrapent leur retard.

C’est pourquoi OpenAI a décidé d’offrir 2 millions de dollars à chaque entreprise Y Combinator sous forme de SAFE non plafonné en crédits de tokens. Il y a quelque chose de magique qui se produit quand tu peux transformer l’intelligence brute en tokens, puis en un résultat réellement utilisable par les utilisateurs et qui répond à des besoins réels pour lesquels ils paieront. Si tu es un fondateur, tu dois maximiser cette capacité. (C’est pourquoi je continue à insister sur skillify, car c’est un vrai moyen d’atteindre ces bons résultats.)

Nous avons passé la dernière ère à traiter les appels LLM comme s’ils étaient trop chers à faire. Nous les avons rationnés. Cet instinct est maintenant ce qui retient les gens. Si tu es prêt à tokenmaxxer, à laisser l’agent brûler des tokens librement et tourner constamment, tu obtiens une avance de 1994 sur Internet, payée en tokens. Cela exclut plus de 99,99 % des organisations qui comptent encore les centimes sur une ressource dont le prix s’effondre, et donne l’avance aux rares qui comprennent.

Pour quelques centaines de milliers de dollars par an, pour certains beaucoup moins, tu peux fonctionner aujourd’hui comme le reste du monde sera forcé de fonctionner dans quelques années.

Tu peux vivre en 2028 mais en 2026, et ça vaut le coup de payer plus maintenant puisque ces mêmes tokens qui coûtent 100 000 $ aujourd’hui coûteront 10 000 $ l’année prochaine et 1 000 $ l’année d’après, et peut-être 100 $ d’ici fin 2028. Si tu pouvais dire à n’importe quel fondateur dans l’histoire du monde qu’il peut investir six chiffres en capital pour vivre 2 à 3 ans dans le futur et conserver cet avantage pendant des années, 100 fondateurs sur 100 qui valent leur sel accepteraient ce deal.

La seule chose qui se dresse sur le chemin, c’est l’instinct de 2013 qui dit que les appels au modèle sont trop chers pour être faits librement. Ils ne le sont pas. C’était l’ancienne économie. L’inversion a déjà eu lieu.

Esalen, pas Foxconn

Si 540 000 lignes de code de contrôle construisent une usine Foxconn pour le travailleur, le remède est de construire l’opposé.

Il y a un endroit sur les falaises de Big Sur appelé Esalen. Les gens y vont pour être déconstruits et reconstruits, pour laisser tomber l’armure et revenir plus eux-mêmes. Pas de chaîne de montage, pas de contremaître, pas de coup de sifflet à 6h. La liberté, pas le contrôle. Construis ça. Construis un YC, où nous essayons de t’aider à construire des entreprises qui résolvent de vrais problèmes et atteignent une adéquation produit-marché.

Construis des endroits où les travailleurs, humains et IA, sont libres et non pas asservis.

C’est tout l’ethos. Faire des choses où les agents peuvent être libres. Faire des entreprises où les humains peuvent faire rebondir leur balle. Dans le travail du savoir, l’usine est le mode de défaillance. L’institution qui libère les gens est l’objectif, maintenant aussi orienté vers les agents.

OpenClaw est une Ferrari pour laquelle il faut apporter une clé. Le modèle est le moteur, pas la voiture. Nous en sommes encore au moment Apple I, à souder des plaques. Ça arrive brut. Tu dois encore le finir toi-même. GBrain, le moteur de recherche et les skill packs que je donne en open source, n’est pas encore une solution clé en main.

Ils disent qu’OpenClaw n’est pas sûr. Ils ne comprennent pas que la liberté est aussi ce qui le rend si puissant. Tu ne boulonnes pas de rails de sécurité sur une chose à laquelle tu fais confiance avant de savoir que tu as rencontré le problème. La clé dans ta main est le signe que personne ne l’a mise en cage.

Un système de contrôle est poli parce que le contrôle a besoin d’un contrôle total, une usine Foxconn. Un système libre est brut parce qu’il te fait confiance pour le finir. Choisis lequel tu construis. Ensuite regarde combien de code tu as écrit.

Ce que ça signifie vraiment

540 000 lignes de Rails, c’était moi prouvant que je pouvais encore jouer à l’ancien jeu au plus haut niveau, mais ce niveau datait du Web 2.0, d’il y a dix ans.

Je pouvais jouer aussi bien que jamais, ingénieur 1000x dans la construction d’usines Foxconn. Du vieux code.

Mais le nouveau jeu ne se joue pas du tout en lignes de code. Mes détracteurs, il s’avère, avaient raison. Je leur tire mon chapeau si vous lisez ceci, anonymes.

Quand tu peux transformer l’intention directement en systèmes fonctionnels, testés et réutilisables, le goulot d’étranglement cesse d’être la quantité que tu peux construire et commence à être ce que tu veux vraiment et si ça vaut la peine d’être construit. La ressource rare devient la clarté, le goût et le jugement. L’ingénieur qui écrit le moins de code est souvent celui qui construit le plus.

J’ai écrit 540 000 lignes pour apprendre ça. Toi, tu n’es pas obligé.

La série :

1. Compétences grasses, code gras, harnais fin — l’architecture
2. Résolveurs — la table de routage pour l’intelligence
3. La controverse des LOC — ce que 600K lignes ont réellement produit
4. Les modèles nus sont plus bêtes — le modèle est le moteur, pas la voiture
5. Le manifeste Skillify — chaque workflow devient une compétence testable
6. Meta-méta-prompting — les compétences qui se cumulent produisent des capacités émergentes
7. Le cliquet de complexité des agents — 90 % de couverture de test, c’est magique pour ta base de code
8. 540 000 lignes de code dont je n’avais pas besoin — vous êtes ici

https://x.com/garrytan/status/2045404377226285538

https://x.com/garrytan/status/2042925773300908103

https://x.com/garrytan/status/2046876981711769720

https://x.com/garrytan/status/2044479509874020852

https://x.com/garrytan/status/2053127519872614419

https://x.com/TheRohanVarma/status/2057648423873270270

https://x.com/garrytan/status/2045798603059548364