pi-autoresearch : l’open source qui généralise l’idée d’« expérimentation autonome par IA » de Karpathy

Résumé en une ligne

On essaie une idée → on mesure → si ça s’améliore, on garde, sinon on jette → et on recommence à l’infini.

pi-autoresearch est une extension du terminal AI coding agent pi, un projet qui généralise le concept d’autoresearch de Karpathy pour l’appliquer à n’importe quel problème d’optimisation.

D’abord, c’est quoi pi ?

pi est un agent de coding IA qui fonctionne dans le terminal. Contrairement aux outils basés sur un IDE comme Cursor ou Windsurf, il a été conçu de façon terminal-native, ce qui permet de l’utiliser tel quel dans un environnement en SSH ou sur un serveur headless.

Les caractéristiques clés de pi sont son système d’Extension et de Skill :

• Extension — ajoute de nouveaux outils à l’agent. En plus des outils de base comme la lecture/écriture de fichiers ou l’exécution de commandes, on peut y brancher des outils personnalisés comme des plugins.
• Skill — enseigne des schémas de travail spécifiques. Il définit des workflows du type « dans telle situation, utilise ces outils dans cet ordre ».

Avec une seule ligne, pi install <github-url>, on peut installer des Extension et Skill créés par la communauté, ce qui permet d’étendre librement les capacités de l’agent. pi-autoresearch est justement un package Extension+Skill construit sur ce système.

Contexte : l’autoresearch de Karpathy

En mars 2026, l’idée présentée par Karpathy avec autoresearch était simple :

• donner à un agent IA un unique code d’entraînement LLM (train.py)
• lui faire modifier le code, puis lancer 5 minutes d’entraînement
• si la validation loss s’améliore, keep, sinon discard
• répéter toute la nuit → au réveil, on retrouve le log des expériences + un meilleur modèle

Avec une conception extrêmement minimaliste (3 fichiers, 1 GPU, 1 métrique), le projet visait avant tout à prouver le concept selon lequel « l’agent peut jouer de façon autonome le rôle d’un chercheur ». Il avait toutefois une limite de naissance : réservé aux GPU NVIDIA et applicable uniquement à l’entraînement de LLM.

Ce que pi-autoresearch fait différemment

1. Aucune limite de domaine

Au-delà de la loss d’entraînement de LLM, tout ce qui peut être mesuré peut devenir une cible d’optimisation : vitesse d’exécution des tests, taille du bundle, temps de build, score Lighthouse, etc. C’est rendu possible par la séparation propre à pi entre « l’infrastructure (Extension) » et « la connaissance métier (Skill) ».

• Vitesse des tests — seconds ↓ — pnpm test
• Taille du bundle — KB ↓ — pnpm build && du -sb dist
• Entraînement LLM — val_bpb ↓ — uv run train.py
• Lighthouse — perf score ↑ — lighthouse --output=json

2. Pas de perte de mémoire au redémarrage

Les agents IA ont une fenêtre de contexte limitée ; pendant une longue expérimentation, le contexte peut être réinitialisé ou le processus peut tomber. pi-autoresearch préserve entièrement l’état de la session dans deux fichiers :

• autoresearch.jsonl — log append-only de toutes les expériences
• autoresearch.md — résumé de l’objectif, des essais tentés, des impasses et des résultats clés

Même un nouvel agent sans aucune mémoire peut reprendre exactement la session précédente simplement en lisant ces deux fichiers. C’est en pratique un modèle de « mémoire externe pour agent ».

3. Distinguer les vraies améliorations du bruit

Un benchmark ne donne pas forcément le même résultat d’une exécution à l’autre, même avec le même code. Après au moins 3 essais, le système calcule automatiquement un score de confiance basé sur le MAD (Median Absolute Deviation) pour montrer visuellement si l’amélioration est réelle ou si elle relève du bruit.

• 🟢 ≥ 2.0× — forte probabilité que l’amélioration soit réelle
• 🟡 1.0–2.0× — au-delà du bruit, mais faible
• 🔴 < 1.0× — dans la plage du bruit, relance recommandée

Cela dit, le système ne rejette pas automatiquement une expérience : la décision finale reste déléguée à l’agent.

4. Empêcher qu’une optimisation casse la cohérence

Si l’on ajoute autoresearch.checks.sh, alors après le benchmark, les vérifications de cohérence comme les tests, le typecheck et le lint se lancent automatiquement. Cela bloque au niveau du système le piège classique du « c’est plus rapide, mais les tests sont cassés ».

5. Organiser les résultats en PR propres

Quand les expériences sont terminées, le skill autoresearch-finalize regroupe les essais conservés en changesets logiques et les sépare dans des branches git indépendantes. Comme il garantit qu’aucun fichier ne se chevauche, chaque branche peut être revue et fusionnée indépendamment.

Workflow

1. /autoresearch optimize unit test runtime  
   → définition de l’objectif, de la commande et de la métrique → mesure de la baseline → démarrage de la boucle  
  
2. Boucle autonome (répétition infinie)  
   → modification du code → git commit → benchmark → vérification de cohérence  
   → amélioration ? keep / régression ? revert → enregistrement dans le .jsonl → répétition  
  
3. /skill:autoresearch-finalize  
   → organisation des essais conservés en branches indépendantes → review et merge  

Contrôle des coûts

Comme la boucle autonome consomme des tokens en continu, le projet fournit deux garde-fous : le paramétrage des limites de clé API et maxIterations (nombre maximal d’expériences par session).

Pourquoi c’est intéressant

Si l’autoresearch de Karpathy constituait une preuve de concept intrigante du type « l’IA expérimente toute seule », pi-autoresearch cherche à en faire un outil générique utilisable dans de vrais contextes de développement. Le fait qu’il soit construit sur l’architecture Extension/Skill de pi abaisse aussi la barrière d’entrée : une simple commande d’installation permet de l’ajouter immédiatement à un workflow pi existant.

Le plus marquant, c’est la manière méthodique dont il traite des problèmes très concrets : préservation de l’état de session, validation statistique de la confiance, protection de la cohérence et workflow Git native. L’idée d’un workflow où l’on lance les expériences la nuit et où l’on relit les PR le matin mérite clairement qu’on la suive de près.