Titre original : Thin Harness, Fat Skills
Auteur original : Garry Tan
Traduction : Peggy, BlockBeats
Note de l'éditeur : lorsque « un modèle plus puissant » devient la réponse par défaut dans l'industrie, cet article propose un jugement différent : ce qui crée réellement un écart de productivité de 10 fois, 100 fois ou même 1000 fois, ce n'est pas le modèle lui-même, mais l'ensemble du design systémique construit autour du modèle.
L'auteur de cet article, Garry Tan, est actuellement président et CEO de Y Combinator, et s'investit depuis longtemps dans l'IA et l'écosystème des startups. Il a proposé le cadre « fat skills + thin harness », décomposant l'application de l'IA en compétences, cadre d'exécution, routage de contexte, répartition des tâches et compression des connaissances.
Dans ce système, le modèle n'est plus l'ensemble des capacités, mais simplement une unité d'exécution dans le système ; ce qui détermine réellement la qualité de la sortie, c'est comment vous organisez le contexte, consolidez le processus, et comment vous délimitez la frontière entre « jugement » et « calcul ».
Plus important encore, cette méthode ne reste pas au niveau conceptuel, mais est validée dans des scénarios réels : face aux milliers de tâches de traitement et de correspondance de données des entrepreneurs, le système réalise, à travers un cycle de « lire - organiser - juger - écrire », une capacité proche de celle des analystes humains, tout en s'auto-optimisant de manière continue sans avoir à réécrire le code. Ce type de « système capable d'apprendre » transforme l'IA d'un outil unique à une infrastructure avec un effet de capitalisation.
Ainsi, le rappel central donné par l'article devient clair : à l'ère de l'IA, l'écart d'efficacité ne dépend plus de l'utilisation du modèle le plus avancé, mais de la construction d'un système capable d'accumuler des compétences de manière continue et d'évoluer automatiquement.
Voici le texte original :
Steve Yegge a déclaré que ceux qui utilisent des agents de programmation AI « sont de 10 à 100 fois plus efficaces que ceux qui écrivent du code avec uniquement des outils de curseur et de conversation, soit environ 1000 fois plus efficaces que les ingénieurs de Google en 2005. »
Note : Steve Yegge est un ingénieur logiciel influent dans la Silicon Valley, blogueur technique et commentateur sur la culture d'ingénierie, connu pour ses articles techniques percutants, longs et au style personnel marqué. Il a été ingénieur senior chez Amazon, Google, puis a rejoint Salesforce avant de se tourner vers des startups et des domaines liés à l'IA ; il est également l'un des promoteurs précoces du projet Dart.
Ce n'est pas une exagération. Je l'ai vu de mes propres yeux et l'ai vécu. Mais lorsqu'une telle différence est évoquée, les gens ont tendance à attribuer cela à une mauvaise direction : un modèle plus puissant, un Claude plus intelligent, plus de paramètres.
En réalité, les personnes qui améliorent leur efficacité de 2 fois et celles qui l'améliorent de 100 fois utilisent le même modèle. La différence ne réside pas dans « l'intelligence », mais dans « l'architecture », et cette architecture est si simple qu'elle peut être écrite sur une carte.
Le Harness (cadre d'exécution) est le produit lui-même.
Le 31 mars 2026, Anthropic a accidentellement publié le code source complet de Claude Code sur npm - un total de 512 000 lignes. Je l'ai lu en entier. Cela a validé ce que j'ai toujours dit chez YC (Y Combinator) : le véritable secret n'est pas dans le modèle, mais dans « la couche qui enveloppe le modèle ».
Contexte du référentiel de code en temps réel, cache de Prompt, outils conçus pour des tâches spécifiques, réduction des contextes redondants autant que possible, mémoire de conversation structurée, sous-agents fonctionnant en parallèle - tout cela ne rendra pas le modèle plus intelligent. Mais cela peut fournir le « bon contexte » au modèle au « bon moment », tout en évitant d'être submergé par des informations non pertinentes.
Cette couche « enveloppante » s'appelle le harness (cadre d'exécution). Et la question que tous les bâtisseurs d'IA devraient vraiment poser est : quelles choses devraient être mises dans le harness, et quelles devraient rester à l'extérieur ?
En réalité, la question a une réponse très concrète - que j'appelle : mince cadre (thin harness), compétences denses (fat skills).
Cinq définitions
Le goulot d'étranglement n'est jamais dans l'intelligence du modèle. Le modèle sait en fait depuis longtemps comment raisonner, synthétiser les informations et écrire du code.
Ils échouent parce qu'ils ne comprennent pas vos données - votre schéma, vos conventions, la forme que prend précisément votre question. Et ces cinq définitions visent précisément à résoudre ce problème.
1. Fichier de compétence (skill file)
Le fichier de compétence est un document markdown réutilisable, servant à enseigner au modèle « comment faire quelque chose ». Attention, il ne s'agit pas de lui dire « quoi faire » - cette partie est fournie par l'utilisateur. Le fichier de compétence fournit le processus.
Le point clé que la plupart des gens négligent est que les fichiers de compétence fonctionnent en réalité comme un appel de méthode. Ils peuvent recevoir des paramètres. Vous pouvez les appeler avec différents paramètres. Le même processus, mais avec des paramètres différents, peut démontrer des capacités complètement différentes.
Prenons un exemple, il existe une compétence appelée /investigate. Elle comporte sept étapes : définir l'étendue des données, construire une chronologie, effectuer une diarisation pour chaque document, synthétiser, argumenter des deux côtés, citer des sources. Elle reçoit trois paramètres : TARGET, QUESTION et DATASET.
Si vous le dirigez vers un scientifique en sécurité et 2 100 000 courriels d'expertise, il se transformera en analyste de recherche médicale, pour juger si un lanceur d'alerte a été réprimé.
Si vous le dirigez vers une société écran et aux documents de déclaration de la Commission électorale fédérale des États-Unis (FEC), il deviendra alors un enquêteur juridique pour suivre les contributions politiques de style action concertée.
C'est toujours la même compétence. Toujours les mêmes sept étapes. Toujours le même fichier markdown. La compétence décrit un processus de jugement, et ce qui le réalise dans le monde réel, ce sont les paramètres passés lors de l'appel.
Ce n'est pas de l'ingénierie de prompt, mais du design logiciel : sauf qu'ici, markdown est utilisé comme langage de programmation, et le jugement humain comme environnement d'exécution. En fait, markdown est même plus adapté pour encapsuler des capacités que le code source rigide, car il décrit des processus, des jugements et des contextes, qui sont justement le langage que le modèle « comprend » le mieux.
2. Harness (cadre d'exécution)
Le harness est cette couche de programme qui fait fonctionner le LLM. Il ne fait que quatre choses : faire tourner le modèle dans une boucle, lire et écrire vos fichiers, gérer le contexte, et exécuter des contraintes de sécurité.
C'est tout. C'est « thin (mince) ».
Le modèle inverse est : gros harness, compétences maigres.
Vous en avez sûrement déjà vu un : plus de 40 définitions d'outils, juste la description prend la moitié de la fenêtre de contexte ; un outil God-tool polyvalent qui prend 2 à 5 secondes pour un aller-retour MCP ; ou encore, chaque endpoint de l'API REST est encapsulé en un outil distinct. Le résultat est que la consommation de tokens triple, les délais triplent et le taux d'échec triple également.
La véritable meilleure pratique est d'utiliser des outils conçus pour un objectif, rapides et à fonction étroite.
Par exemple, un Playwright CLI, chaque opération de navigateur ne prend que 100 ms ; alors qu'un Chrome MCP prend 15 secondes pour faire une capture d'écran → trouver → cliquer → attendre → lire. Le premier est 75 fois plus rapide.
Les logiciels d'aujourd'hui n'ont plus besoin d'être « raffinés jusqu'à l'obésité ». Ce que vous devez faire, c'est construire uniquement ce dont vous avez réellement besoin, et rien de plus.
3. Résolveur (Resolver)
Le résolveur est essentiellement une table de routage de contexte. Lorsque le type de tâche X apparaît, il charge en priorité le document Y. Les compétences disent au modèle « comment faire » ; les résolveurs disent au modèle « quand charger quoi ».
Par exemple, un développeur a modifié une prompt. Sans résolveur, il pourrait directement déployer après modification. Avec un résolveur, le modèle lira d'abord docs/EVALS.md. Ce document stipule : exécutez d'abord la suite d'évaluation, comparez les scores avant et après ; si la précision diminue de plus de 2 %, revenez en arrière et examinez les raisons. Ce développeur ne savait même pas qu'il existait une suite d'évaluation. Le résolveur a chargé le bon contexte au bon moment.
Claude Code intègre un résolveur. Chaque compétence a un champ de description, le modèle va automatiquement faire correspondre l'intention de l'utilisateur avec la description de la compétence. Vous n'avez pas besoin de vous souvenir si la compétence /ship existe - la description elle-même est le résolveur.
Pour être franc : mon ancien CLAUDE.md comptait pas moins de 20 000 lignes. Toutes les bizarreries, tous les modèles, toutes les leçons que j'ai apprises y étaient intégrées. C'était absurde. La qualité de l'attention du modèle a clairement diminué. Claude Code m'a même dit de l'éliminer.
La solution de réparation finale n'est probablement que de 200 lignes - en conservant seulement quelques pointeurs de documents. La documentation nécessaire est alors chargée par le résolveur au moment clé. Ainsi, 20 000 lignes de connaissances peuvent toujours être utilisées à la demande, sans polluer la fenêtre de contexte.
4. Latent et déterministe (latent space et deterministic)
Dans votre système, chaque étape appartient soit à cette catégorie, soit à cette autre catégorie. Et confondre ces deux est l'erreur la plus courante dans la conception d'agents.
· L'espace latent est l'endroit où se trouve l'intelligence. Le modèle lit, comprend, juge et décide ici. Ce qui est traité ici : jugement, synthèse, reconnaissance de modèles.
· Déterministe, c'est l'endroit où se trouve la fiabilité. Les mêmes entrées produisent toujours les mêmes sorties. Les requêtes SQL, le code compilé, les opérations arithmétiques appartiennent à ce côté.
Un LLM peut vous aider à organiser les sièges pour un dîner de 8 personnes, en tenant compte de la personnalité et des relations sociales de chacun. Mais si vous lui demandez d'organiser les sièges pour 800 personnes, il va sérieusement inventer une liste de sièges « qui semble raisonnable, mais est en réalité complètement erronée ». Parce que ce n'est plus un problème que l'espace latent devrait traiter, mais une question déterministe qui a été forcée dans l'espace latent - un problème d'optimisation combinatoire.
Les pires systèmes mettent toujours le travail au mauvais endroit de chaque côté de cette ligne de démarcation. Les meilleurs systèmes, quant à eux, traceraient très froidement la limite.
5. Diarisation (documentation / image thématique)
Cette étape de diarisation est la clé pour que l'IA tire une valeur du travail intellectuel réel.
Cela signifie que le modèle lit tous les matériaux pertinents sur un sujet, puis écrit une image structurée. En une page, il condense les jugements de dizaines, voire de centaines de documents.
Ce n'est pas quelque chose qu'une requête SQL peut produire. Ce n'est pas non plus quelque chose qu'un pipeline RAG peut produire. Le modèle doit vraiment lire, tenir compte des informations contradictoires dans son esprit, remarquer ce qui a changé, quand cela a changé, puis synthétiser ces éléments en une intelligence structurée.
C'est la différence entre les requêtes de base de données et les briefs d'analystes.
Cette architecture
Ces cinq concepts peuvent être combinés en une architecture simple à trois niveaux.
· La couche supérieure est constituée de compétences denses : des processus écrits en markdown, contenant des jugements, des méthodologies et des connaissances de domaine. 90 % de la valeur est dans cette couche.
· La couche intermédiaire est un harness CLI mince : environ 200 lignes de code, entrée JSON, sortie texte, par défaut en lecture seule.
· La couche inférieure est votre système d'application : QueryDB, ReadDoc, Search, Timeline - ce sont des infrastructures déterministes.
Le principe central est directionnel : pousser « l'intelligence » autant que possible vers les compétences ; faire descendre « l'exécution » autant que possible vers les outils déterministes ; garder le harness mince.
Le résultat de cela est : chaque fois que la capacité du modèle augmente, toutes les compétences deviennent automatiquement plus fortes ; tandis que le système déterministe sous-jacent reste toujours stable et fiable.
Système capable d'apprendre
Voici un système réel que nous construisons actuellement chez YC, pour montrer comment ces cinq définitions fonctionnent ensemble.
En juillet 2026, Chase Center. Startup School a attiré 6000 fondateurs. Chacun avait des matériaux de candidature structurés, des réponses à des questionnaires, des transcriptions de conversations 1:1 avec des mentors, et des signaux publics : publications sur X, enregistrements de soumissions GitHub, et historique d'utilisation de Claude Code (qui peut refléter leur vitesse de développement).
La méthode traditionnelle est : une équipe projet de 15 personnes lit chaque demande, juge par intuition, puis met à jour un tableau.
Cette méthode fonctionne encore à une échelle de 200 personnes, mais échoue complètement à 6000. Personne ne peut contenir autant d'images dans son esprit et réaliser : les trois meilleurs candidats pour l'infrastructure d'agent AI sont un fondateur d'outils de développement à Lagos, un entrepreneur de conformité à Singapour, et un développeur d'outils CLI à Brooklyn - et ils décrivent tous le même point douloureux avec des énoncés complètement différents dans différentes conversations 1:1.
Le modèle peut le faire. Voici comment :
Enrichment (information enrichie)
Il existe une compétence appelée /enrich-founder qui va extraire toutes les sources de données, faire de l'enrichissement d'informations, de la diarisation, et marquer la différence entre « ce que le fondateur dit » et « ce qu'il fait réellement ».
Le système déterministe de base est responsable : requêtes SQL, données GitHub, tests de navigateur d'URL de démonstration, collecte de signaux sociaux, requêtes CrustData, etc. Une tâche planifiée s'exécute une fois par jour. Les portraits de 6000 fondateurs restent toujours à jour.
La sortie de la diarisation peut capturer des informations que la recherche par mots-clés ne peut absolument pas découvrir :
Fondateur : Maria Santos Société : Contrail (contrail.dev) Autobiographie : "L'agent AI de Datadog" Ce qu'il fait réellement : 80 % des soumissions de code se concentrent sur le module de facturation → En fait, il s'agit d'un outil FinOps déguisé en outil d'observation.
Cette différence entre « discours vs comportement réel » doit être lue en même temps que l'historique des soumissions GitHub, les documents de candidature et les enregistrements de conversation, puis intégrée dans l'esprit. Aucune recherche de similarité d'embedding ne peut accomplir cela, et le filtrage par mots-clés non plus. Le modèle doit lire complètement, puis juger. (C'est précisément la tâche qui devrait être placée dans l'espace latent !)
Correspondance (Matching)
C'est l'endroit où « compétence = appel de méthode » déploie sa puissance.
La même compétence de correspondance, appelée trois fois, peut produire des stratégies complètement différentes :
/match-breakout : traiter 1200 personnes, regroupement par domaine, 30 personnes par groupe (embedding + attribution déterministe)
/match-lunch : traiter 600 personnes, correspondances « fortuites » inter-domaines, 8 personnes par table et sans répétitions - le LLM génère d'abord le thème, puis un algorithme déterministe organise les sièges.
/match-live : traiter les participants en temps réel sur site, effectuer des correspondances 1:1 dans les 200 ms basées sur l'embedding des plus proches voisins, et exclure les personnes déjà rencontrées
Et le modèle peut faire des jugements que les algorithmes de clustering traditionnels ne peuvent pas accomplir :
« Santos et Oram appartiennent tous deux à l'infrastructure AI, mais ne sont pas en concurrence - Santos est axé sur l'attribution des coûts, Oram sur l'orchestration. Ils devraient être placés dans le même groupe. »
« Kim a écrit lors de sa candidature qu'il s'agissait d'outils pour développeurs, mais la conversation 1:1 montre qu'il travaille sur l'automatisation de la conformité SOC2. Cela devrait être reclassé dans FinTech / RegTech. »
Cette reclassification est quelque chose que l'embedding ne peut pas capturer. Le modèle doit lire l'image entière.
Boucle d'apprentissage (learning loop)
Après l'événement, une compétence /improve lira les résultats de l'enquête NPS, effectuera une diarisation sur les retours « passables » - pas des critiques négatives, mais ceux qui sont « presque bons » - et extraira des modèles.
Ensuite, il proposera de nouvelles règles et les écrira dans la compétence de correspondance :
Lorsque les participants disent « infrastructure AI », mais que plus de 80 % de leur code est un module de facturation :
→ Classé comme FinTech, et non AI Infra
Lorsque deux personnes du même groupe se connaissent déjà :
→ Réduire le poids de la correspondance
Prioriser l'introduction de nouvelles relations
Ces règles seront écrites dans le fichier de compétence. Elles entreront automatiquement en vigueur lors de la prochaine exécution. Les compétences se « réécrivent elles-mêmes ». Lors de l'événement de juillet, les évaluations « passables » représentaient 12 % ; lors de l'événement suivant, elles ont chuté à 4 %.
Le fichier de compétence a appris ce que signifie « passable », et le système s'est amélioré sans que personne n'ait à réécrire le code.
Ce modèle peut être appliqué à n'importe quel domaine :
Recherche → Lecture → Diariser → Compter → Synthétiser
Ensuite : enquête → investigation → diariser → réécrire la compétence
Si vous voulez demander quel est le cycle le plus précieux en 2026, c'est celui-ci. Il peut être appliqué à presque tous les scénarios de travail intellectuel.
Les compétences sont mises à niveau de manière permanente
Récemment, j'ai posté une instruction pour OpenClaw sur X, qui a suscité bien plus de réactions que prévu :
Prompt : vous ne devez pas effectuer de travail unique. Si je vous demande de faire quelque chose que vous ferez à nouveau à l'avenir, vous devez : d'abord traiter manuellement 3 à 10 échantillons et me montrer les résultats ; si je l'approuve, écrivez-le comme un fichier de compétence ; s'il doit s'exécuter automatiquement, ajoutez-le dans les tâches planifiées. Le critère est : si je dois poser la question une deuxième fois, cela signifie que vous avez échoué.
Ce contenu a obtenu des milliers de likes et plus de deux mille sauvegardes. Beaucoup pensent qu'il s'agit de techniques d'ingénierie de prompt.
En réalité, ce n'est pas le cas, c'est l'architecture mentionnée précédemment. Chaque compétence que vous écrivez est une mise à niveau permanente du système. Elle ne va pas se dégrader, ne va pas s'oublier. Elle s'exécutera automatiquement à 3 heures du matin. Et lorsque la prochaine génération de modèles sera publiée, toutes les compétences deviendront instantanément plus puissantes - la capacité de jugement de la partie latente augmentera, tandis que la partie déterministe restera stable et fiable.
C'est la source de l'efficacité 100 fois dont parle Yegge.
Ce n'est pas un modèle plus intelligent, mais : compétences denses, cadre mince (Thin Harness, Fat Skills), et la discipline de tout solidifier en capacité.
Le système va croître de manière exponentielle. Construisez-le une fois, et il fonctionnera à long terme.
[Lien vers l'article original]