Le tokenmaxxing ne paie qu’avec de gros skills et de vrais tests

Le tokenmaxxing consiste à payer chaque petit travail en plus qui rend un résultat plus complet, au lieu de s’arrêter là où un humain se fatiguerait. Garry Tan dit que ça l’a amené à 400x le code qu’il écrivait en 2013. Je fais tourner le même genre d’installation, et ce qui vaut la peine d’être copié n’est pas la dépense. Ce sont les skills qui portent votre jugement et les tests qui rattrapent ce qui en sort. Sans ces deux-là, vous obtenez une facture plus grosse et plus de code bâclé.

Garry dirige Y Combinator, et il a raconté l’histoire dans un épisode spécial de Lightcone en mai. Après 13 ans loin du code, il s’y est remis en janvier avec Claude Code. Depuis, il a publié en open source gstack, son ensemble de skills pour Claude Code, qui comptait 138 528 étoiles GitHub quand j’ai regardé aujourd’hui. L’autre face de ce mot est dans ma note ne comptez pas les tokens, comptez ce qu’ils ont acheté : lisez-les ensemble.

Trois versions du même blog

Son meilleur chiffre vient d’une plateforme de blog qu’il a construite trois fois. Posterous, sa première startup YC, a pris environ 4 millions de dollars, six ou sept personnes et un an et demi. Twitter l’a rachetée et fermée, alors lui et son cofondateur l’ont réécrite sous le nom de Posthaven, pour environ 100 000 dollars, deux personnes et peut-être trois mois.

En janvier, il l’a écrite une troisième fois pour Garry’s List, son site sur la politique californienne. Ça a pris environ 200 dollars de Claude Max et probablement cinq jours, et cette version parcourt aussi le web, fait de la recherche approfondie et un RAG complet.

Le hic, c’est qu’à la troisième fois il savait exactement ce qu’il faut à une plateforme de blog. C’est ma lecture, pas la sienne, et elle compte. Réécrire ce qu’on a déjà conçu deux fois, c’est le cas le plus favorable pour n’importe quel outil.

Vingt sources, pas une

Le mot vient de la façon dont Garry’s List écrit ses articles. Une personne clique sur un lien, lit un titre et passe à autre chose. Son pipeline va chercher la recherche via les API de Perplexity et de Grok, prend 20 sources au lieu d’une et les recoupe : ces 13-là disent ceci, ces sept-là ne sont pas d’accord. Tout ça entre dans le prompt principal.

Il appelle cette habitude « boil the ocean », faire bouillir l’océan. Si un travail en plus rend le résultat plus complet, payez-le. Il estime un article à l’équivalent de 5 à 10 dollars d’appels à Opus, pour un travail qu’une personne ferait en épluchant des dizaines d’articles et des livres entiers.

Il ne pense pas que ça supprime les gens. Quelqu’un doit encore apporter l’envie, et la sienne, ce sont les collégiens de San Francisco qui ne pouvaient pas faire d’algèbre. Aucun modèle n’a choisi ce sujet pour lui.

Le jugement va dans le Markdown

Un harness, c’est la boucle centrale : il prend votre demande, la donne au modèle et exécute ce que le modèle réclame. YC en réécrivait sans cesse pour ses agents internes, jusqu’à se demander pourquoi, puisque Claude Code existe déjà. Leur associé Pete Koomen a donné son nom à l’idée : thin harness, fat skills, un harness mince et de gros skills. Arrêtez d’écrire la boucle et passez votre temps sur le Markdown.

Son test, c’est un organisateur de mariages. Ce que vous écririez en langage courant pour former le prochain organisateur va dans le Markdown. Appeler 20 salles est une vraie action, donc c’est du code, un appel à Twilio. L’essentiel de la douleur de l’ingénierie d’agents, dit-il, vient de ce qu’on met du jugement dans le code, qui est fragile et ne comprend pas les cas particuliers.

Mince ne veut pas dire sans importance. Quelqu’un autour de la table raconte que tout ce qui dépasse un simple script échoue de son côté avec OpenClaw, sur le même Opus 4.7 qui marche dans Claude Code. Alors prenez une bonne boucle, et n’écrivez pas la vôtre.

C’est la partie où je vis déjà. Claude Code et OpenClaw sont mes harness, et une trentaine de skills à moi portent les procédures. Le skill qui a enregistré ma fiche sur cet épisode, ce sont 124 lignes de Markdown qui décident de ce qui entre dans la note, à côté d’un script Python de 441 lignes et d’une vérification navigateur de 80 lignes qui font les appels d’API, valident les données et prennent les captures.

gstack a commencé dans Apple Notes

Il n’avait pas prévu gstack. Lassé de taper les mêmes instructions dans Claude Code, il les a mises dans Apple Notes puis les a publiées, et environ 200 000 personnes les ont vues. C’est maintenant une chaîne de revues, et chacune travaille sur le plan avant que quoi que ce soit soit construit.

Deux de ses astuces sont minuscules. Avant tout travail, il demande un diagramme ASCII des flux de données, des entrées et sorties, des parcours utilisateur et des messages d’erreur. Une fois que Claude l’a dessiné, dit-il, le travail sort plus complet. La revue CEO ajoute une question : qu’est-ce qui est plus ambitieux et apporte 10x la valeur pour seulement 2x l’effort ?

Aucun de mes skills ne demande de diagramme ASCII. C’est la chose la moins chère à essayer sur sa liste.

La chaîne s’arrête aussi pour poser des questions. gstack s’appuie sur AskUserQuestion, parce que c’est là que la personne apporte ce qu’elle est vraiment en train de construire. « Je ne veux jamais être entièrement hors de la boucle, dit-il. Je veux juste que la machine fasse ce que je n’ai pas envie de faire. »

C’est bâclé tant que rien ne le rattrape

Il a heurté ce que tout le monde heurte. Ça marche pour 80 % des cas, puis de vrais utilisateurs y touchent et tout s’écroule. Écrire des tests à la main n’a jamais été amusant, alors il faisait toujours le minimum. Maintenant la machine s’en moque, donc il vise 80 à 90 % de couverture, après avoir constaté que 100 %, c’était trop. Le code d’agent non testé, dit-il, est 10x pire que le code humain, parce que vous n’avez aucune idée de ce qui va se passer.

Ensuite, les tests à la main sont devenus le goulot d’étranglement. Il avait 15 fonctionnalités qui attendaient qu’il clique dedans, et le MCP Claude in Chrome prenait 2 à 3 secondes par tour. Alors il a enveloppé Playwright, de Microsoft. C’est aujourd’hui browse, un démon HTTP de longue durée avec 70 commandes, et son skill de QA lit ce qui a changé sur la branche et teste toute modification d’interface ou de données dans un vrai navigateur.

Je suis arrivé au même endroit par un autre chemin. Mes skills apportent leurs propres vérifications Playwright, et cette note a dû en passer une dans Chromium et WebKit à 320, 390 et 1280 px avant d’être publiée.

Ce que j’ajouterais, c’est un vrai blocage. « La machine s’en moque, elle le fera, tout simplement » : ça marche dans les deux sens. Deux de mes sessions d’agent ont lancé un pkill avec des options après le motif pour arrêter un serveur de test. macOS les lit comme d’autres motifs, et Docker Desktop s’est arrêté les deux fois, emportant tous les conteneurs de mon Mac mini.

Celui-là est donc devenu un hook. Trois d’entre eux passent avant une commande Bash : l’un refuse cette forme de pkill, l’autre refuse de prendre le port d’une autre appli, et le dernier refuse une pull request sans issue. Un skill demande. Un hook refuse.

J’ai aussi l’exemple inverse. Le 25 octobre, un agent a lancé les tests de mon appli de films dans son conteneur en production. L’environnement du conteneur les a pointés vers la vraie base de données, et le drop_all des tests a supprimé toutes les tables. Une sauvegarde a rendu ce qu’elle contenait. La règle contre ça n’est encore qu’écrite, et c’est un manque.

Les 400x sont de l’arithmétique, pas de la valeur

Il s’est fait troller pour avoir compté des lignes de code, alors il a publié le calcul. Un script compte les lignes logiques de ses dépôts : 5 143 sur toute l’année 2013, et 1 233 062 sur les 108 premiers jours de 2026. Par jour, ça fait 14 contre 11 417, soit 810x. Puis il suppose que le code d’IA est deux fois plus verbeux et divise par deux : voilà les 408x que l’épisode arrondit à 400x.

J’aime qu’il montre le travail, parce que le même tableau contient les autres chiffres. Sur ces mêmes périodes, les lignes logiques ont été multipliées par 240, les fichiers touchés par 47 et les commits par 4,9. Et les 14 par jour étaient à temps partiel, une année où il avait un emploi.

Il concède lui-même le point, en gras : « Le délai jusqu’au premier utilisateur est la mesure qui compte, pas le nombre de lignes. » Si 80 % de ce qu’il a livré cette année est mort dans deux ans, écrit-il, la critique aura du mordant.

Les tokens sont un loyer, disent-ils

Quelqu’un autour de la table compare la dépense en tokens au loyer à San Francisco. Les fondateurs reculent devant l’appartement, et YC leur dit de le payer. Économisez sur le canapé, pas sur les modèles. Garry va plus loin, avec 500 dollars en une seule journée, tant que vous construisez quelque chose de très utile pour vous et que c’est la bonne chose.

Cette condition fait tout le travail. La règle de J.R. Storment dans ma note sur la tokenomics, c’était de compter ce que les tokens ont acheté, alors je l’ai essayée sur moi. Meterlex a relevé 4,09 milliards de tokens pour la semaine finissant le 30 octobre, et mon compte a fusionné 417 pull requests dans 46 dépôts cette semaine-là. Ça fait environ 9,8 millions de tokens par PR fusionnée.

C’est un chiffre bien propre, et il ne me dit pas grand-chose. Une PR n’est pas plus un résultat qu’une ligne. Les tokens ne sont pas non plus ce qu’ils ont l’air d’être : dans la semaine en cours au moment où j’écris, Claude Code en compte 3,87 milliards, et seulement 25,8 millions sont la sortie du modèle. Presque tout le reste, c’est du contexte en cache, relu à chaque tour.

Je peux donc vous dire ce que je brûle et je ne peux pas vous dire ce que ça a acheté. C’est le même écart que l’enquête de la Tokenomics Foundation a trouvé.

Une Ferrari avec un mécanicien de garde

Sa phrase sur OpenClaw, c’est celle que tout le monde cite. C’est comme conduire une Ferrari : elle trouve des choses qu’on n’aurait jamais crues possibles pour une machine, et elle tombe en panne au bord de la route quand on en a le plus besoin, alors mieux vaut être mécanicien. Il y voit le moment du Homebrew Computer Club, l’Apple 1 dans sa boîte en bois. En faire tourner une prend deux ou trois heures et peut-être 500 à 1 000 dollars en tokens et en cloud.

Quelqu’un autour de la table a la meilleure phrase. Peu importe que ce soit fragile, puisqu’on peut installer un autre agent à côté pour le réparer. Je le fais déjà : l’un de mes skills est un guide de dépannage d’OpenClaw pour Claude Code. Quand un agent devient sourd sur Telegram, il dit de chercher un codex app-server bloqué et de tuer celui-là, pas la passerelle.

Il prédit que tout le monde sur la planète aura une IA personnelle d’ici un an. C’est un pari, et il n’apporte aucune preuve. La question qui ouvre l’épisode tient dans tous les cas : « Aurez-vous le contrôle de vos outils, ou vos outils auront-ils le contrôle de vous ? » Si vous n’écrivez pas vos propres prompts, dit-il, vous êtes sous la ligne d’API d’un chef de produit qui ne vous connaît pas. Les prompts et la mémoire de mes agents sont des fichiers sur mon propre disque, et c’est ma réponse pour l’instant.

À essayer

L’épisode dure 41 minutes, et les démos sont le meilleur moment. Si vous n’en avez que dix, commencez au chapitre sur le harness mince.

• Tokenmaxxing: How Top Builders Use AI To Do The Work Of 400 Engineers, Y Combinator, 8 mai 2026, en anglais. Le gstack accidentel à 10:07, thin harness, fat skills à 20:59, la Ferrari à 24:35.
• gstack et le calcul derrière les 400x.
• Mes notes sur ce que les tokens achètent et sur la revue du plan plutôt que de la pull request.

La prochaine fois que vous vous apprêtez à dépenser plus de tokens, notez d’abord ce qui rattraperait un mauvais résultat. Si vous avez trouvé un meilleur chiffre que les lignes ou les PR, j’aimerais le connaître.

Texte brut: tokenmaxxing-fat-skills-real-tests.md · Flux Atom · Toutes les notes