Le commit git comme découverte scientifique : comment Autoresearch transforme le versionnage en laboratoire de recherche
Dans le développement logiciel traditionnel, un commit git signifie « ce code fonctionne ». Dans l’autoresearch de Karpathy, un commit git signifie autre chose : « ce changement a amélioré le modèle de façon mesurable ».
Chaque commit est une petite découverte scientifique. Chaque git reset est une hypothèse qui n’a pas abouti. Le git log devient un journal de recherche, écrit automatiquement par un agent IA.
C’est le contrôle de version repensé comme outil de recherche.
La décision binaire
L’utilisation de git dans autoresearch est d’une élégante simplicité :
- L’agent modifie
train.py - L’entraînement tourne 5 minutes
- La validation loss est mesurée
- Si amélioré :
git commit— le changement est conservé - Si non amélioré :
git reset— le changement n’a jamais existé
Pas de pull requests. Pas de code review. Pas de conflits de merge. Juste une décision binaire : ce changement a-t-il amélioré les choses ou non ?
Ça crée un historique linéaire et propre d’améliorations. Chaque commit dans le log représente un pas en avant validé. Pas de bruit — pas de commits « WIP », pas de commits « fix typo », pas de chaînes « revert revert ». Juste une séquence de changements qui ont chacun amélioré le modèle de façon mesurable.
Le git log comme journal de recherche
Après une session nocturne d’autoresearch, le git log se lit comme un carnet de recherche :
Chaque message de commit (écrit par l’agent IA) décrit ce qui a été changé et quel effet ça a eu. Le diff montre exactement quel code a été modifié. L’amélioration de la validation loss est enregistrée.
C’est radicalement plus auditable que la recherche ML traditionnelle. Au lieu des notes d’un chercheur disant « j’ai essayé d’ajuster le learning rate, ça semblait aider », vous avez un diff exact, une mesure exacte et un résultat reproductible.
Mémoire entre les sessions
Git donne à autoresearch quelque chose dont les agents IA ont désespérément besoin : une mémoire persistante.
Quand vous démarrez une nouvelle session autoresearch, l’agent peut lire l’historique git pour comprendre ce qui a été essayé avant. Il peut voir quelles directions ont produit des améliorations et lesquelles n’en ont pas produit. Ça empêche l’agent de ré-essayer des expériences échouées et l’aide à construire sur ce qui a fonctionné.
C’est Markdown plus git qui fonctionnent ensemble : le fichier program.md fournit la direction stratégique (quoi essayer), et l’historique git fournit le contexte tactique (quoi a été essayé).
L’effet composé
Parce que chaque commit réussi devient la nouvelle baseline, les améliorations se composent. L’agent ne repart pas de zéro chaque nuit — il part du meilleur résultat atteint jusqu’ici.
Dans la course de deux jours de Karpathy, environ 20 améliorations se sont accumulées. Chacune était petite, mais ensemble elles ont réduit le temps d’entraînement de GPT-2 de 11 %. L’agent a trouvé des optimisations dans le scaling de l’attention, la régularisation et les hyperparamètres qui se construisaient les unes sur les autres.
C’est la puissance de l’approche basée sur git : elle crée naturellement un cliquet. Le progrès est verrouillé en tant que commits. Les échecs sont rejetés. Le codebase n’avance que.
Ce qui est annulé
Les expériences échouées — les opérations git reset — sont tout aussi intéressantes que les succès. Dans une session nocturne typique, environ 70-80 % des expériences sont annulées.
Ces expériences annulées ne sont pas du gaspillage. Ce sont des résultats négatifs qui informent les futures décisions de l’agent. Avec une mémoire cross-agent et un historique git partagé, un système autoresearch distribué peut apprendre des échecs de l’ensemble de l’essaim.
Git comme base de données d’expériences
La recherche ML traditionnelle utilise des outils de suivi d’expériences — MLflow, Weights & Biases, Neptune — pour logger les hyperparamètres, les métriques et les artefacts.
Autoresearch remplace tout ça par git. L’historique des commits EST le log des expériences. Les diffs SONT les changements d’hyperparamètres. Les messages de commits SONT les descriptions des expériences.
Cette simplification est puissante. Pas de base de données d’expériences séparée à maintenir. Pas de dashboard à configurer. Pas de schéma à définir. Juste git, que tout développeur connaît déjà.
Le pattern plus large
Le pattern git-comme-journal-de-recherche fonctionne au-delà de l’entraînement ML :
- Optimisation de code : Chaque commit représente un changement qui a rendu le code plus rapide
- Couverture de tests : Chaque commit représente un changement qui a amélioré la couverture de tests
- Correction de bugs : Chaque commit représente un correctif qui a résolu un test qui échouait
- Optimisation de contenu : Chaque commit représente un changement qui a amélioré une métrique mesurable
Tout domaine où vous pouvez mesurer automatiquement « mieux » et « moins bien » peut utiliser git comme tracker d’expériences.
Le rôle de l’humain : lire le log
En ingénierie agentique, la routine matinale de l’humain après une session nocturne d’autoresearch est de lire le git log.
C’est une compétence différente de l’écriture de code. Vous évaluez une série de changements générés par l’IA, comprenez pourquoi chacun a fonctionné, et décidez si la direction globale est correcte. Sur la base de cette revue, vous mettez à jour votre program.md pour orienter la session suivante.
Le git log est le canal de communication entre l’humain et l’agent. L’agent communique par des commits. L’humain communique par les mises à jour de program.md. Markdown circule dans les deux sens.
Construire une connaissance git-friendly
Écrire des fichiers program.md efficaces — le genre qui produit des historiques git propres et significatifs — nécessite de comprendre à la fois le domaine et les outils. Les meilleures instructions d’agent viennent de personnes qui ont étudié profondément l’espace du problème.
Sauvegarder du matériel de référence en Markdown propre crée une base de connaissances dans laquelle vous pouvez puiser pour écrire des instructions d’agent. Documentation, articles de recherche et bonnes pratiques, tous dans le format qui se déverse naturellement dans un program.md et finalement dans un historique git de découvertes.
Save convertit n’importe quelle page web en Markdown propre — construisant la bibliothèque de connaissance qui alimente des instructions d’agent IA efficaces et la recherche autonome. Essayez Save gratuitement.
## Continue reading
Autoresearch pour tous : comment lancer 100 expériences IA pendant votre sommeil
L'autoresearch de Karpathy tourne 100+ expériences ML en une nuit sur un seul GPU. Voici comment ça marche, ce qu'il vous faut, et pourquoi un script Python de 630 lignes est en train de changer la recherche IA.
Comment rédiger un bon program.md : guide pratique pour les instructions d'agents IA
program.md est le fichier qui programme les agents IA dans l'autoresearch de Karpathy. Voici comment en écrire un qui obtient des résultats — avec structure, exemples et bonnes pratiques.
L'Autoresearch de Karpathy & PROGRAM.md : l'IA qui fait des expériences pendant que vous dormez
L'autoresearch d'Andrej Karpathy permet à des agents IA de faire tourner 100+ expériences de ML la nuit, guidés par un seul fichier Markdown appelé program.md. Voici comment ça fonctionne et pourquoi c'est important.
De README.md à PROGRAM.md : Markdown est désormais un langage de programmation
README.md était pour les humains. AGENTS.md est pour les assistants de code. PROGRAM.md est pour la recherche autonome. Markdown a évolué de la documentation vers le langage de programmation des agents IA.
Written by
Jean-Sébastien Wallez
I've been making internet products for 10+ years. Built Save on weekends because I wanted my own reading library in clean markdown for Claude and Obsidian. Write here about web clipping, AI workflows, and the small things that make a personal knowledge base actually useful.