AutoResearch : 700 expériences IA dirigées par un seul fichier Markdown

TL;DR : AutoResearch est un outil open-source de Karpathy qui lance des centaines d'expériences IA en boucle, sans intervention humaine. L'agent modifie du code, teste, garde si ça s'améliore, annule sinon, et recommence. 54 000+ stars GitHub en 10 jours. L'idée clé pour les Vibe Coders : le pattern repose sur un fichier program.md qui dirige tout. C'est du File Engineering poussé à son maximum, exécuté par un Agent Harness. Et ce pattern s'applique bien au-delà du Machine Learning.

---

AutoResearch : outil open-source qui permet à un agent IA de lancer des expériences en boucle autonome. L'agent propose une modification, teste sur une métrique fixe, garde le changement s'il y a amélioration, annule sinon, et recommence. ~12 expériences/heure, ~100 en une nuit. Le système repose sur 3 fichiers : un évaluateur verrouillé, un sandbox modifiable et un fichier Markdown de direction.

Le constat : un fichier Markdown, 700 expériences

Si tu as lu les deux derniers articles (File Engineering et Agent Harness), tu connais les deux piliers du Vibe Coding en 2026 : structurer tes fichiers .md pour donner le bon contexte à l'IA, et construire une infrastructure qui maintient la cohérence sur la durée.

La bonne nouvelle : Andrej Karpathy vient de publier un outil open-source qui met les deux en pratique. La mauvaise nouvelle : il l'a fait en lançant 700 expériences IA autonomes pendant 2 jours... dirigées par un seul fichier Markdown.

L'outil s'appelle AutoResearch. Plus de 54 000 stars GitHub en 10 jours. Et la logique qu'il introduit s'applique à n'importe quel projet avec de l'IA. Pas besoin d'être data scientist.

---

1. Le concept : itération autonome en boucle

Comment ça marche

AutoResearch est simple dans son design. Un agent IA tourne en boucle et exécute le même cycle :

1. L'agent lit les instructions et les résultats précédents
2. Il propose une hypothèse (modification de code, d'architecture, de paramètres)
3. Il implémente le changement
4. Il lance un test de 5 minutes (budget temps fixe)
5. Il mesure le résultat sur une métrique définie
6. Si la métrique s'améliore : le changement est gardé (commit Git)
7. Si la métrique ne s'améliore pas : le changement est annulé (git reset)
8. Retour à l'étape 1

C'est le ratchet loop (boucle à cliquet). Le système ne peut qu'avancer, jamais reculer. Chaque amélioration validée s'empile sur la précédente.

À 5 minutes par expérience : 12 expériences par heure. En une nuit : ~100 expériences. En deux jours : ~700.

Les résultats concrets

Karpathy a pointé AutoResearch sur son entraînement GPT-2 (son propre codebase nanochat, déjà bien optimisé). Sur 700 expériences, l'agent a trouvé ~20 améliorations réelles. Résultat : le temps d'entraînement est passé de 2,02h à 1,80h (-11%). L'agent a trouvé des optimisations que Karpathy lui-même avait ratées.

Tobi Lütke (CEO de Shopify) a adapté la méthode pour un modèle de query expansion. Il a dit à un agent IA de lire le repo AutoResearch et de construire une version pour son projet. Il est allé dormir. Le lendemain : un modèle 0,8 milliard de paramètres qui bat un modèle de 1,6 milliard après 37 expériences en 8 heures.

Un modèle deux fois plus petit qui surpasse le plus gros. Pas grâce à un meilleur algorithme. Grâce à 37 itérations automatisées pendant qu'il dormait.

---

2. Le contrat 3 fichiers : une architecture qui s'applique à tout

L'architecture

Ce qui rend AutoResearch intéressant pour les Vibe Coders, c'est l'architecture, pas le Machine Learning. Elle repose sur un contrat entre 3 fichiers, chacun avec des règles strictes :

• prepare.py (l'évaluateur verrouillé) : définit la métrique de succès. Personne ne peut le modifier, ni l'humain ni l'agent. Le juge impartial.
• train.py (le sandbox de l'agent) : c'est le code que l'agent peut modifier librement. Tant que le résultat compile et produit un score, tout est permis.
• program.md (la direction humaine) : écrit en Markdown, c'est le seul fichier que l'humain touche. Il définit les priorités, les contraintes et les directions de recherche.

La division du travail est nette. L'humain fixe le cap via program.md. L'agent exécute en modifiant train.py. Et prepare.py tranche, sans favoritisme.

program.md EST du File Engineering

Si tu as lu le guide File Engineering, tu reconnais la logique immédiatement. program.md est un fichier .md qui donne à l'IA le bon contexte au bon moment. Il définit :

• Les métriques de baseline à battre (val_bpb: 0.997900, VRAM max : 45 Go)
• Les commandes exactes pour lancer et évaluer les expériences
• Les règles de gestion d'échec (corriger les typos, skip les idées cassées, kill après 10 min)
• La directive clé : "NEVER STOP. Once the experiment loop has begun, do NOT pause to ask the human."
• La philosophie de design : "All else being equal, simpler is better."

Exactement ce qu'Anthropic décrit dans ses bonnes pratiques : un fichier concis, chirurgical, avec des degrés de liberté calibrés. Pas une encyclopédie. Un document de direction.

La différence avec un prompt classique : ce fichier a dirigé 700 expériences sur 2 jours. Aucun prompt ne tient aussi longtemps. Un fichier .md bien structuré, si.

Le ratchet loop EST un Agent Harness

Le ratchet loop est l'illustration directe de ce que j'ai décrit dans l'article Agent Harness :

• Git comme mémoire : chaque expérience est un commit. L'agent lit son propre historique Git + results.tsv pour décider quoi tester ensuite. La gestion de "RAM" du Harness.
• Budget temps fixe (5 min) : pas de dérive possible. Un garde-fou structurel contre le model drift.
• Décision binaire : amélioration = on garde. Pas d'amélioration = on annule. Zéro jugement humain.
• results.tsv comme dataset : chaque expérience (réussie ou échouée) enrichit le journal. Le principe "The Harness is the Dataset" en action : l'avantage compétitif est dans les trajectoires capturées.

File Engineering + Agent Harness, ce ne sont pas des concepts théoriques. AutoResearch tourne en production et produit des résultats mesurables.

---

3. Le pattern appliqué à tes projets : 3 exemples concrets

Le contrat 3 fichiers n'est pas réservé au Machine Learning. Il s'applique à tout projet où tu peux définir :

1. Un évaluateur automatique (ta métrique de vérité, verrouillée)
2. Un sandbox modifiable (ce que l'agent peut toucher)
3. Un fichier de direction (ton program.md en Markdown)

La condition : le cycle doit être rapide (minutes, pas jours) et la métrique doit être mesurable automatiquement. Voici 3 applications concrètes.

Exemple 1 : Optimisation de System Prompts

Le cas : tu as une IA conversationnelle (un chatbot produit, un assistant, un coach) avec un system prompt qui définit son comportement. Tu veux améliorer la pertinence des réponses sans passer des semaines à itérer manuellement.

Le contrat 3 fichiers :

• Évaluateur (verrouillé) : un set de 50 paires question/réponse attendue. Un LLM juge (différent du modèle testé) score chaque réponse de 0 à 100 sur la pertinence, la concision et la fidélité au ton. Le score global est la moyenne.
• Sandbox (modifiable) : le system prompt. L'agent peut reformuler les instructions, réorganiser les sections, ajouter ou supprimer des exemples few-shot.
• Direction (direction.md) :

## Objectif
Améliorer le score moyen de pertinence du system prompt.
Baseline actuelle : 72/100.

## Contraintes
- Ne pas dépasser 800 tokens (coût par requête)
- Conserver le tutoiement et le ton coaching
- Ne pas modifier le set d'évaluation

## Approches à tester
- Réduire les instructions redondantes
- Ajouter des exemples de réponses attendues (few-shot)
- Restructurer par type de question (tactique, matériel, entraînement)
- Tester des niveaux de détail différents dans les consignes

Pourquoi ça marche : le cycle est ultra-rapide (quelques secondes par évaluation, pas 5 minutes), la métrique est automatisable (LLM juge), et le sandbox est bien défini (un seul fichier). En une nuit, l'agent teste des dizaines de variantes. Le lendemain matin : un prompt optimisé et un historique Git complet de chaque variante testée avec son score.

Sur Sam Tennis, c'est le premier cas que je vais tester. Le system prompt du coach IA fait 600 tokens. J'ai déjà les données de test (les questions les plus fréquentes des utilisateurs via PostHog). Le setup prend une heure. L'optimisation tourne toute la nuit.

Exemple 2 : Quality Ratchet sur ton code

Le cas : ton application a des problèmes de performance. Tu veux réduire le bundle size et améliorer le temps de chargement sans casser les fonctionnalités existantes.

Le contrat 3 fichiers :

• Évaluateur (verrouillé) : ta suite de tests + mesure du bundle size + temps de chargement. Le script retourne un verdict binaire : tests passent ET bundle_size < baseline ET load_time < baseline.
• Sandbox (modifiable) : les composants que tu veux optimiser. L'agent peut refactorer, supprimer du code mort, remplacer des imports lourds.
• Direction (direction.md) :

## Objectif
Réduire le bundle size sans casser les tests.
Baseline : bundle 2.4 MB, load time 3.2s, 47 tests passing.

## Contraintes
- Tous les tests doivent passer (non négociable)
- Ne pas modifier les fichiers de test
- Ne pas changer l'API publique des composants

## Approches à tester
- Tree-shaking des imports inutilisés
- Remplacement de librairies lourdes par des alternatives légères
- Lazy loading des composants non-critiques
- Simplification des composants sur-engineerés

Pourquoi ça marche : les tests existants sont le juge impartial (prepare.py). L'agent ne peut pas tricher : si un test casse, le changement est annulé. Et chaque optimisation est isolée et réversible grâce à Git.

C'est ce que les agents Cursor font déjà de manière informelle quand tu leur demandes d'optimiser du code. La différence : ici, c'est systématisé. Pas de validation manuelle. Pas de "est-ce que ça te va ?". Juste : les tests passent et le bundle a diminué, ou pas.

Exemple 3 : Scoring IA pour un produit

Le cas : tu as un produit qui utilise l'IA pour scorer ou classer des éléments (des CVs, des produits, des leads, des contenus). Tu veux améliorer la précision du scoring sans tout re-labeler manuellement.

Le contrat 3 fichiers :

• Évaluateur (verrouillé) : un set de 100 éléments annotés manuellement avec le score attendu. La métrique est la corrélation entre le score IA et le score humain.
• Sandbox (modifiable) : le prompt de scoring + les critères de pondération. L'agent peut reformuler les critères, ajuster les poids, ajouter des instructions spécifiques.
• Direction (direction.md) :

## Objectif
Améliorer la corrélation scoring IA / scoring humain.
Baseline : corrélation 0.73.

## Contraintes
- Le prompt ne doit pas dépasser 1200 tokens
- Les critères doivent rester interprétables (pas de boîte noire)
- Ne pas modifier le set d'évaluation annoté

## Approches à tester
- Affiner la pondération entre expérience, compétences et formation
- Ajouter des critères négatifs (red flags explicites)
- Tester chain-of-thought vs scoring direct
- Varier le nombre d'exemples few-shot (0, 2, 5)

Pourquoi ça marche : tu as déjà les données annotées (tes premiers utilisateurs les ont générées). Le cycle est rapide. Et le résultat est directement déployable en production. Sur ResumeRank, c'est le cas idéal : un prompt de scoring, un set de CVs annotés par des recruteurs, et une métrique claire (corrélation avec le jugement humain).

Le point commun des 3 exemples

Dans chaque cas, la structure est identique :

1. Verrouille ta métrique (c'est ton prepare.py)
2. Définis ce que l'agent peut toucher (c'est ton train.py)
3. Écris ta direction en Markdown (c'est ton program.md)
4. Lance l'agent et va dormir

La difficulté n'est jamais technique. Elle est dans la qualité de l'évaluateur. Si ta métrique est biaisée ou gameable, l'agent va optimiser la mauvaise chose. Le même problème que les benchmarks IA trompeurs de l'article Agent Harness : un score qui monte sur le papier ne garantit pas un produit meilleur en production.

---

4. Les limites : le plafond de créativité

Ce qu'AutoResearch ne peut pas faire

Le ratchet loop a une contrainte structurelle : il ne peut qu'avancer. Chaque changement doit immédiatement améliorer la métrique. L'agent ne peut jamais faire un pas en arrière pour préparer un gain plus important.

Les chercheurs humains font ça en permanence : "Ça va empirer avant de s'améliorer." Le ratchet n'a pas cette capacité. Résultat : l'agent finit par tourner en rond autour d'un optimum local, proposant des micro-variations de ce qui a déjà marché.

Karpathy l'a reconnu sur Hacker News : l'agent se comporte de façon "peureuse et prudente" sur les problèmes ouverts. Un effet du RLHF (l'entraînement par feedback humain) : le modèle est récompensé pour les réponses safe, pas pour les expérimentations audacieuses.

L'évaluation est le vrai goulot

Quand un agent lance 100 expériences par nuit, le bottleneck n'est plus le code. C'est l'évaluation.

Si ton set de test est trop petit ou pas représentatif de la production, l'agent va overfitter : optimiser pour le test, pas pour la réalité. L'immutabilité de prepare.py, qui garantit l'équité du système, est aussi son angle mort : le même set de validation utilisé 100 fois de suite accumule le risque de sur-apprentissage.

C'est exactement le problème que j'ai rencontré sur Sam Tennis : sans données PostHog fiables, impossible de savoir si les modifications amélioraient réellement l'expérience utilisateur. Les métriques doivent refléter la réalité de la production, pas une approximation statique.

La leçon pour les Solo Builders : avant d'automatiser l'itération, investis dans ton évaluation. Tes métriques PostHog, tes suites de tests, tes données annotées. Sans ça, l'automatisation ne sert à rien.

La créativité reste humaine

Karpathy cartographie une progression : Vibe Coding (l'humain prompte, l'IA code) → Agentic Engineering (l'humain orchestre des agents) → Independent Research (l'humain fixe la direction, l'agent exécute seul).

AutoResearch opère au troisième niveau. Mais la conclusion de l'article source est sans ambiguïté : "Writing a good program.md requires having done the research yourself." Tu dois savoir quelles directions valent la peine d'être explorées. L'agent exécute la partie méthodique. Le jugement sur la direction reste humain.

Même leçon que le File Engineering : la qualité du fichier .md dépend de l'expertise de celui qui l'écrit. L'IA amplifie ce que tu sais. Elle ne remplace pas ce que tu dois savoir.

---

Conclusion : La logique qui connecte tout

Oublie le Machine Learning. Ce qui compte dans AutoResearch, ce sont deux compétences que les Solo Builders devraient maîtriser en 2026 :

1. Le File Engineering : un fichier .md bien structuré peut diriger un agent IA pendant des heures sans intervention
2. L'Agent Harness : l'infrastructure (ratchet loop, Git comme mémoire, métrique verrouillée) produit des résultats que le modèle seul ne peut pas atteindre

Le contrat 3 fichiers (évaluateur + sandbox + direction) s'applique partout. Que tu optimises un system prompt, un scoring IA ou les performances de ton code, la structure est la même : verrouille ta métrique, définis le sandbox, écris ta direction, lance l'agent.

Ce qui va faire la différence entre ceux qui utilisent l'IA et ceux qui la maîtrisent, c'est la qualité de l'évaluation. Si ta métrique tient la route pour 100 expériences en une nuit, tu es prêt.

À très vite, Guillaume 👋

---

Questions fréquentes

C'est quoi AutoResearch ?

AutoResearch est un outil open-source créé par Andrej Karpathy en mars 2026. Il permet à un agent IA (Claude Code, Cursor) de lancer des expériences en boucle autonome : proposer une modification, tester, garder si ça s'améliore, annuler sinon, recommencer. Le projet a dépassé les 54 000 stars GitHub en 10 jours.

Est-ce que j'ai besoin de savoir faire du Machine Learning pour appliquer le pattern ?

Non. Le concept original d'AutoResearch vise l'entraînement de modèles, mais le pattern (évaluateur verrouillé + sandbox modifiable + direction en Markdown) s'applique à n'importe quel projet IA. Optimiser un system prompt, améliorer un scoring, réduire la taille d'un bundle : le cycle propose/teste/garde est le même. Ce qui compte, c'est d'avoir une métrique automatisable et un sandbox bien défini.

Quel lien entre AutoResearch, File Engineering et Agent Harness ?

Les trois concepts forment un tout. Le File Engineering, c'est structurer des fichiers .md pour diriger l'IA. L'Agent Harness, c'est l'infrastructure qui maintient la cohérence sur la durée. AutoResearch montre que les deux fonctionnent ensemble : un fichier program.md (File Engineering) dirige un ratchet loop (Agent Harness) pendant des centaines d'expériences sans intervention humaine.

Par où commencer pour appliquer ce pattern à mon projet ?

Choisis un élément que tu veux optimiser (system prompt, scoring, performance). Définis une métrique mesurable automatiquement. Crée un set de test verrouillé que l'agent ne peut pas modifier. Écris un fichier direction.md avec l'objectif, les contraintes et les approches à tester. Lance un agent Cursor dessus. Tu n'as pas besoin d'AutoResearch lui-même : le contrat 3 fichiers suffit.

---

Pour aller plus loin

• File Engineering : Le Guide d'Anthropic qui change tout
• Agent Harness : Pourquoi ton infrastructure compte plus que ton modèle
• Guide Cursor 2026 : de l'idée au code
• Guide PostHog : comprendre tes utilisateurs
• AutoResearch sur GitHub (Karpathy)

---