pi-autoresearch: Open Source, das Karpathys Idee des „autonomen AI-Experimentierens“ verallgemeinert

Kurz zusammengefasst

Ideen ausprobieren → messen → bei Verbesserung behalten, sonst verwerfen → endlos wiederholen.

pi-autoresearch ist eine Erweiterung des terminalbasierten AI-Coding-Agenten pi und ein Projekt, das Karpathys autoresearch-Konzept so verallgemeinert, dass es auf jedes Optimierungsproblem angewendet werden kann.

Zuerst: Was ist pi?

pi ist ein AI-Coding-Agent, der im Terminal läuft. Anders als IDE-basierte Tools wie Cursor oder Windsurf ist er terminalnativ konzipiert und lässt sich daher auch in SSH-Umgebungen oder auf Headless-Servern unverändert nutzen.

Die zentralen Merkmale von pi sind das Extension- und Skill-System:

• Extension — fügt dem Agenten neue Werkzeuge hinzu. Neben grundlegenden Tools wie Dateilesen/-schreiben oder dem Ausführen von Befehlen lassen sich benutzerdefinierte Tools wie Plugins einstecken.
• Skill — bringt bestimmte Arbeitsmuster bei. Er definiert Workflows nach dem Muster „In so einer Situation nutze diese Tools in dieser Reihenfolge“.

Mit einer einzigen Zeile, pi install <github-url>, lassen sich von der Community entwickelte Extensions und Skills installieren, sodass sich die Fähigkeiten des Agenten flexibel erweitern lassen. pi-autoresearch ist genau auf diesem System aufgebaut und kommt als Extension+Skill-Paket.

Hintergrund: Karpathys autoresearch

Im März 2026 stellte Karpathy die autoresearch-Idee vor, und sie war denkbar einfach:

• Einem AI-Agenten wird eine einzelne LLM-Trainingsdatei (train.py) gegeben
• Er modifiziert den Code und trainiert ihn 5 Minuten lang
• Verbessert sich der Validierungs-Loss, wird die Änderung behalten, sonst verworfen
• Die Schleife läuft die ganze Nacht → am Morgen gibt es Experiment-Logs + ein besseres Modell

Mit einem extrem minimalistischen Aufbau (3 Dateien, 1 GPU, 1 Metrik) konzentrierte sich das Projekt darauf, das Konzept zu belegen, dass „ein Agent autonom die Rolle eines Forschers übernehmen kann“. Es hatte jedoch von Anfang an Grenzen: nur für NVIDIA-GPUs und nur auf LLM-Training anwendbar.

Was pi-autoresearch anders macht

1. Keine Domänenbeschränkung

Nicht nur LLM-Trainings-Loss, sondern alles Messbare kann zum Optimierungsziel werden, etwa Testlaufzeit, Bundle-Größe, Build-Zeit oder Lighthouse-Score. Möglich wird das durch pis Trennung von „Infrastruktur (Extension)“ und „Domänenwissen (Skill)“.

• Testgeschwindigkeit — Sekunden ↓ — pnpm test
• Bundle-Größe — KB ↓ — pnpm build && du -sb dist
• LLM-Training — val_bpb ↓ — uv run train.py
• Lighthouse — perf score ↑ — lighthouse --output=json

2. Kein Gedächtnisverlust nach Neustarts

AI-Agenten haben ein begrenztes Kontextfenster, daher kann bei langen Experimenten der Kontext zurückgesetzt werden oder der Prozess abstürzen. pi-autoresearch speichert den Sitzungszustand vollständig in zwei Dateien:

• autoresearch.jsonl — append-only-Log aller Experimente
• autoresearch.md — Zusammenfassung von Ziel, bereits Versuchten, Sackgassen und zentralen Ergebnissen

Selbst wenn ein komplett neuer Agent ohne jegliche Erinnerung eingesetzt wird, kann er durch das Lesen dieser beiden Dateien die vorherige Sitzung exakt fortsetzen. Das ist faktisch ein Muster für „externes Gedächtnis für Agenten“.

3. Echte Verbesserungen von Rauschen unterscheiden

Benchmarks liefern selbst bei identischem Code nicht immer dieselben Ergebnisse. Nach mindestens drei Durchläufen berechnet das System automatisch einen Confidence Score auf Basis von MAD (Median Absolute Deviation) und zeigt visuell, ob eine Verbesserung real oder nur Rauschen ist.

• 🟢 ≥ 2.0× — hohe Wahrscheinlichkeit, dass die Verbesserung real ist
• 🟡 1.0–2.0× — über dem Rauschen, aber geringfügig
• 🔴 < 1.0× — innerhalb des Rauschbereichs, erneute Ausführung empfohlen

Allerdings werden Experimente nicht automatisch verworfen; die endgültige Entscheidung bleibt dem Agenten überlassen.

4. Verhindert, dass Optimierung die Korrektheit kaputtmacht

Wenn autoresearch.checks.sh vorhanden ist, laufen nach einem erfolgreichen Benchmark automatisch Konsistenzprüfungen wie Tests, Type-Checks und Linting. Damit wird die klassische Falle „schneller geworden, aber die Tests sind kaputt“ auf Systemebene abgefangen.

5. Fasst Experimentergebnisse in sauberen PRs zusammen

Ist das Experiment abgeschlossen, gruppiert der Skill autoresearch-finalize die behaltenen Experimente in logische Changesets und trennt sie in unabhängige Git-Branches auf. Da sichergestellt wird, dass sich Dateien nicht überschneiden, kann jeder Branch separat geprüft und gemergt werden.

Workflow

1. /autoresearch optimize unit test runtime  
   → Ziel, Befehle und Metriken festlegen → Baseline messen → Schleife starten  
  
2. Autonome Schleife (unendlich wiederholt)  
   → Code ändern → git commit → Benchmark → Konsistenzprüfung  
   → Verbesserung? behalten / Verschlechterung? revert → in .jsonl protokollieren → wiederholen  
  
3. /skill:autoresearch-finalize  
   → behaltene Experimente in unabhängige Branches aufteilen → prüfen und mergen  

Kostenkontrolle

Da die autonome Schleife kontinuierlich Tokens verbraucht, gibt es zwei Guardrails: Limits für API-Schlüssel und maxIterations (maximale Anzahl an Experimenten pro Sitzung).

Warum das bemerkenswert ist

Wenn Karpathys autoresearch ein spannender Proof of Concept dafür war, dass „AI selbstständig experimentiert“, dann ist pi-autoresearch der Versuch, daraus ein universelles Tool für den realen Entwicklungsalltag zu machen. Weil es auf pis Extension/Skill-Architektur aufsetzt, lässt es sich mit einer einzigen Installationszeile direkt in bestehende pi-Workflows integrieren, was die Einstiegshürde deutlich senkt.

Beeindruckend ist, wie systematisch praktische Probleme gelöst werden: Sitzungszustand erhalten, statistische Verlässlichkeit prüfen, Korrektheit schützen und einen Git-nativen Workflow unterstützen. Ob der Ablauf „nachts laufen lassen, morgens PRs reviewen“ damit wirklich zur Realität wird, ist auf jeden Fall beobachtenswert.

[tensun]

Wie immer pi

[unqocn]

Ich mag pi sehr.