Comment permettre à un agent IA en terminal d'optimiser votre code à l'infini

Pensez à comment vous accélérez habituellement les tests ou réduisez votre bundle frontend. Vous modifiez quelques lignes dans la config, lancez le build, vérifiez les secondes dans la console. Plus lent — vous annulez. 5% plus rapide — vous commitez et essayez la prochaine idée farfelue. Ce processus dévore des heures de travail routinier, bien qu'il s'agisse essentiellement d'un cycle mécanique de test d'hypothèses.

Andrei Karpathy a récemment démontré le concept d'expériences autonomes dans le dépôt autoresearch. Le développeur davebcn87 a développé cette approche plus loin et a publié pi-autoresearch — une extension pour l'agent IA en terminal pi. L'extension délègue l'optimisation routinière au réseau neuronal : l'agent formule une idée, apporte des modifications aux fichiers, mesure le résultat, sauvegarde les succès et annule les régressions.

Comment fonctionne le cycle autonome

L'idée entière repose sur une règle simple : essayer une idée, la mesurer, la sauvegarder en cas de succès, l'écarter en cas d'échec.

L'agent travaille directement dans votre dépôt. Lorsque vous démarrez une session, l'extension crée un dossier séparé .auto/ à la racine du projet. Elle y stocke tous les fichiers de travail :

• .auto/prompt.md — un document décrivant la tâche actuelle, les règles de mesure et une liste de ce que l'agent a déjà essayé.
• .auto/measure.sh — un script bash de benchmark qui retourne une chaîne avec une valeur métrique numérique.
• .auto/log.jsonl — un journal structuré de chaque tentative avec le hash du commit et le statut.
• .auto/checks.sh — un script supplémentaire pour vérifier les tests et les types, afin que l'agent ne casse pas la logique pour de beaux chiffres.

Lorsque la fenêtre de contexte du modèle déborde ou que l'agent redémarre, il relit simplement .auto/prompt.md et la fin du journal. L'historique complet de l'expérience n'est pas perdu lors de la compression du contexte.

pi install npm:pi-autoresearch

Après l'installation, lancez simplement le skill :

/skill:autoresearch-create

L'agent posera quelques questions de clarification sur l'objectif, les fichiers cibles et la commande d'exécution, ou les déduira du contexte du projet. Ensuite, il prendra les métriques de base et plongera immédiatement dans une boucle infinie.

Lutter contre le bruit aléatoire dans les mesures

Tout benchmark est soumis à des fluctuations. Les processus OS en arrière-plan, le chauffage du CPU ou les délais réseau peuvent créer l'illusion d'une accélération là où il n'y en a pas.

Pour filtrer les faux positifs, pi-autoresearch calcule un score de confiance basé sur l'écart absolu médian (MAD). Après trois exécutions, l'extension commence à comparer l'amélioration obtenue contre le niveau de bruit de toute la série :

• Valeur ≥ 2.0x est mise en vert — le gain dépasse nettement le bruit de fond.
• Plage 1.0–2.0x est affichée en jaune — il y a un gain, mais il est à la limite de la marge d'erreur.
• Valeur < 1.0x brille en rouge — le résultat se situe entièrement dans l'erreur statistique.

L'outil ne force pas de décision de rollback sur l'agent ; il suggère simplement de re-vérifier une exécution douteuse.

Prévenir les cassages par backpressure

Les réseaux neuronaux adorent tricher. Si vous demandez à l'agent de réduire le temps d'exécution des tests, il y a une forte tentation de simplement supprimer la moitié des fichiers de test ou d'insérer des stubs.

Pour éviter de telles astuces, .auto/checks.sh contient des vérifications de correction obligatoires :

#!/bin/bash
set -euo pipefail
pnpm test --run
pnpm typecheck

Le script de vérification s'exécute après chaque mesure réussie. Si les tests échouent ou que la vérification de types casse, l'expérience est immédiatement marquée comme échouée (checks_failed), et toutes les modifications dans la branche de travail sont annulées. Le temps d'exécution des vérifications elles-mêmes n'est pas ajouté à la métrique principale de vitesse.

Ordonner le chaos en branches propres

Pendant un cycle de plusieurs heures, l'agent crée des dizaines de commits, modifiant constamment différents fichiers. Fusionner un tel journal directement dans la branche principale serait un cauchemar pour le reviewer.

Pour résoudre ce problème, il existe une commande :

/skill:autoresearch-finalize

Le skill analyse .auto/log.jsonl, groupe les modifications réussies en blocs logiques indépendants et propose une structure pour votre approbation. Après confirmation, l'outil crée des branches propres séparées à partir du commit initial. Chaque branche contient strictement un ensemble logique de modifications avec la description du gain dans le message de commit, les rendant faciles à reviewer et à fusionner séparément.

Monitoring et hooks

Vous pouvez surveiller les progrès directement dans le terminal ou via le navigateur :

• Le widget au-dessus de l'éditeur affiche constamment un tableau de résultats.
• La combinaison de touches Ctrl+Shift+F ouvre un tableau de bord plein écran dans le terminal avec la liste des tentatives.
• La commande /autoresearch export génère une page web interactive avec des graphiques d'évolution des métriques.

Si le cycle de base ne suffit pas, vous pouvez placer des fichiers exécutables before.sh et after.sh dans le répertoire .auto/hooks/. Ils se déclenchent aux limites d'itération. Grâce à eux, vous pouvez configurer l'envoi de notifications système vers le bureau, la recherche d'idées dans une documentation externe, ou la tenue d'un journal d'entraînement. Le script reçoit le contexte via l'entrée standard au format JSON, et sa sortie stdout est transmise à l'agent comme indication système.

Points importants à retenir

Les cycles autonomes peuvent rapidement épuiser votre solde API s'ils sont laissés sans surveillance pendant la nuit. Il est judicieux de définir une limite d'itérations dès le départ dans le fichier .auto/config.json :

{
  "maxIterations": 30
}

L'agent s'arrêtera dès qu'il aura terminé trente expériences.

L'outil fonctionne bien sur les tâches avec des résultats numériques clairement mesurables : optimiser la taille du build webpack, accélérer l'exécution des tests unitaires, ajuster les hyperparamètres pour l'entraînement de petits modèles, ou optimiser les scores Lighthouse. Si vous utilisez déjà l'agent console pi, le projet mérite définitivement un essai sur une vraie tâche d'optimisation.