Im März 2026 veröffentlichte Andrej Karpathy, Mitgründer von OpenAI und ehemaliger Leiter der KI-Abteilung bei Tesla, ein Framework namens AutoResearch. Das Prinzip ist einfach: Man beschreibt in einer Textdatei, was untersucht werden soll, startet das System vor dem Schlafen und wacht mit rund 100 abgeschlossenen Machine-Learning-Experimenten auf, geordnet nach Performance. Drei Wochen nach dem Release: 65.000 GitHub-Sterne. Diese Adoptionsgeschwindigkeit spiegelt wider, wofür das Projekt steht, nicht nur, was es technisch leistet.
Was AutoResearch tatsächlich tut
AutoResearch setzt einen KI-Agenten auf ein einzelnes Trainingsskript an. Der Agent modifiziert das Skript, führt ein fünfminütiges Trainingsexperiment durch, misst das Ergebnis anhand der Validierungsmetrik val_bpb (Bits per Byte, ein Maß für die Effizienz von Sprachmodellen) und entscheidet dann, ob die Änderung übernommen oder verworfen wird. Verbessert sich der Score, wird die Änderung zur neuen Baseline. Wenn nicht, setzt der Agent zurück und probiert etwas anderes. Dieser Zyklus läuft kontinuierlich und erzeugt rund 12 Experimente pro Stunde, über Nacht also etwa 100.
Das feste Fünf-Minuten-Zeitbudget pro Experiment ist eine bewusste Designentscheidung. Es macht Ergebnisse über Läufe hinweg vergleichbar, verhindert, dass der Agent unverhältnismäßig viel Zeit auf eine einzelne Hypothese verwendet, und passt zum Kostenrahmen einer einzigen H100-GPU, die über Nacht läuft. Die Beschränkung zwingt das System zur Effizienz statt zur Erschöpfungssuche.
Die Drei-Datei-Architektur
Das System ist um drei Dateien herum aufgebaut, jede mit einer klar definierten Rolle:
- prepare.py ist unveränderlich. Sie übernimmt die Datenvorbereitung und wird nie angefasst. Das hält das experimentelle Fundament stabil, sodass Ergebnisunterschiede tatsächliche Modellunterschiede widerspiegeln und keine Änderungen in der Datenpipeline.
- train.py ist die Arbeitsfläche des Agenten. Als Basis-Trainingsskript gestartet, wird sie über Hunderte von Iterationen verändert, erweitert und verfeinert. Bis zum Morgen kann sie erheblich anders aussehen als zu Beginn.
- program.md wird vom Menschen geschrieben. Hier legt man die Forschungsstrategie fest: welche Ansätze erkundet werden sollen, welche Einschränkungen gelten, welche Hypothesen zu testen sind. Das ist das Einzige, was der Mensch schreiben muss.
Die Einfachheit ist gewollt. Änderungen auf eine einzige Datei (train.py) zu beschränken bedeutet, dass jede Modifikation nachvollziehbar bleibt. Der Diff zwischen der Morgenversion und dem Ausgangspunkt zeigt klar, was der Agent getan hat. Das ist schwerer zu erreichen, wenn Agenten gleichzeitig viele Dateien anfassen.
Die Forschungsstrategie schreiben, nicht den Code
Karpathys Beschreibung der menschlichen Rolle verdient ein direktes Zitat: "You are not writing the code directly 99% of the time. You are orchestrating agents." Die Aufgabe besteht darin, program.md zu schreiben, was er den "research org code" nennt, also die übergeordnete Strategie, die vorgibt, was der Agent verfolgen soll.
Das ist eine bedeutsame Verschiebung gegenüber der verbreiteten Vorstellung von KI-Coding-Tools. Die gängige Rahmung positioniert KI als Assistenten, der hilft, Code schneller zu schreiben. AutoResearch dreht das um: Der Agent schreibt den Code, führt die Experimente durch und wertet die Ergebnisse aus. Der Mensch liefert die Forschungsrichtung. Das eigentliche Arbeitsergebnis des Menschen ist das Strategiedokument, nicht die Implementierung.
Ob diese Rahmung über ML-Forschung hinaus verallgemeinert werden kann, bleibt offen. Innerhalb iterativer Experimente, bei denen es darum geht, einen großen Raum möglicher Ansätze zu durchsuchen und herauszufinden, was funktioniert, passt sie jedoch präzise. Der Agent durchsucht diesen Raum um ein Vielfaches schneller als jedes menschliche Team.
Die Zahlen im Überblick
Karpathy setzte AutoResearch zwei Tage lang auf ein persönliches Projekt an und berichtete von rund 700 autonomen Code-Änderungen. Davon führten etwa 20 zu additiven Verbesserungen, die sich zu messbarem Fortschritt summierten. Der kumulative Effekt: ein Effizienzgewinn von 11 % auf dem Time-to-GPT-2-Leaderboard, einem Benchmark, der misst, wie effizient ein Modell GPT-2-Niveau erreicht.
Eine Trefferquote von rund 3 % klingt niedrig. Doch der Vergleich macht es greifbar: 700 Experimente manuell durchzuführen würde Monate dauern. Der Agent erledigt das über Nacht. Die Ökonomie verändert sich grundlegend, wenn ein gescheitertes Experiment fünf Minuten GPU-Zeit kostet statt Tage menschlicher Arbeit.
Ein fairer Vergleichsmechanismus
Das feste Fünf-Minuten-Budget löst zugleich ein subtiles Problem der ML-Forschung: Wie vergleicht man Ansätze, die sich in ihrer Rechenkomplexität unterscheiden? Benötigt eine Technik doppelt so viel Compute, würde ein längerer Trainingslauf sie besser aussehen lassen als sie ist. Durch konstante Zeit stellt AutoResearch sicher, dass Verbesserungen auf echten algorithmischen Vorteilen beruhen und nicht auf der Strategie, schlicht mehr Rechenleistung einzusetzen.
Designentscheidungen mit Gewicht
Mehrere AutoResearch-Designentscheidungen stammen aus produktiven ML-Systemen:
Diese Beschränkungen machen das System nachvollziehbar. Ein leistungsfähigerer Agent mit weniger Einschränkungen würde vielleicht schneller Ergebnisse produzieren, aber schwerer verständliche. AutoResearch tauscht etwas rohe Leistung gegen Interpretierbarkeit, was entscheidend ist, wenn man aus den Entdeckungen des Agenten wirklich lernen will.
Das größere Signal: selbstverbessernde KI
Bedeutsamer als das Tool selbst ist Karpathys Einordnung dessen, wofür AutoResearch steht. Er nennt es den Beginn der "self-improvement loopy era of AI": Systeme, in denen KI-Agenten die Forschung betreiben, die zukünftige KI-Systeme besser macht. Der Kreislauf lautet: bessere Agenten führen bessere Experimente durch, finden bessere Trainingstechniken, erzeugen bessere Modelle, die wiederum bessere Agenten werden.
Über rekursive Selbstverbesserung wird seit Jahrzehnten theoretisiert. Das Neue ist Infrastruktur, die auf eine einzige GPU passt und in einem Nachmittag einzurichten ist, zumindest in einem begrenzten Anwendungsbereich. AutoResearch demonstriert ein konkretes Stück dieses Kreislaufs: KI-getriebene experimentelle Suche, die messbare Verbesserungen in der KI-Trainingseffizienz erzeugt.
Die Implikationen reichen über ML-Forschung hinaus. Jeder Bereich mit einer klaren Evaluierungsmetrik, einem veränderbaren Artefakt und einem großen Suchraum möglicher Ansätze kommt als Kandidat für dieses Muster in Frage: Software-Optimierung, Wirkstoffentwicklung, Materialwissenschaft, Finanzmodellierung. Der Engpass ist in jedem Fall die Kosten von Experimenten. Wer diese Kosten senkt, verändert, was überhaupt machbar ist.
Community-Erweiterungen
Innerhalb weniger Tage nach der Veröffentlichung hatte die Community AutoResearch auf Hardware portiert, die im ursprünglichen Design nicht vorgesehen war:
- macOS mit Apple Silicon via MLX, wodurch es ohne Cloud-GPU-Kosten für Nutzer mit M-Series-Macs zugänglich wird
- Windows mit RTX-GPUs über Community-Forks, die die Trainingspipeline auf CUDA auf Consumer-Hardware anpassen
- AMD-GPUs über ROCm-basierte Anpassungen für Nutzer außerhalb des NVIDIA-Ökosystems
Die Breite dieser Community-Adaptionen zeigt echtes Interesse weit über die ML-Forschungsgemeinschaft hinaus. Entwicklern ohne ML-Hintergrund steht damit ein Einstieg in Trainingsoptimierungsexperimente auf Hardware offen, die sie bereits besitzen.
Kriterien für Teams
AutoResearch ist ein Forschungswerkzeug. Teams können den Zyklus adaptieren: einen Kandidaten generieren, testen, Fehlschläge festhalten und die nächste Iteration gegen diese Fehlschläge laufen lassen.
Die Rolle des Menschen verschiebt sich
Wenn der Agent die Experimente durchführt, liegt der menschliche Wert darin, die richtigen Fragen zu stellen. Eine gute program.md zu schreiben setzt voraus zu verstehen, welche Ansätze es wert sind, erkundet zu werden, welche Einschränkungen relevant sind und wie Erfolg tatsächlich aussieht. Das ist anspruchsvollere Arbeit als Code zu schreiben, und sie erfordert Domänenwissen und Urteilsvermögen. Die Arbeit verlagert sich von der Implementierung zur Ausrichtung.
Nächtliche Rechenkapazität wird verschwendet
Die meisten Teams, die Cloud-Infrastruktur betreiben, haben über Nacht ungenutzte GPU-Kapazität. AutoResearch macht das Argument, dass diese Kapazität produktive experimentelle Arbeit leisten könnte statt unbenutzt zu bleiben. Die Frage für jedes Team mit einem klaren Optimierungsziel und einer messbaren Metrik ist, ob das gleiche Muster auf das eigene Problem anwendbar ist.
Nachvollziehbarkeit muss eingeplant werden
Die Einzeldatei-Beschränkung in AutoResearch ist ein Nachvollziehbarkeitsmerkmal. Wenn Agenten beliebige Dateien anfassen können, erfordert das Verstehen ihrer Handlungen erheblichen Reverse-Engineering-Aufwand. Systeme zu entwerfen, in denen Agentenaktionen begrenzt und auditierbar sind, wird wichtiger, je mehr Autonomie zunimmt. Teams, die Agenten-produzierte Arbeit vertrauen und iterieren können, sind jene, die Interpretierbarkeit von Anfang an eingeplant haben.
Einstieg
AutoResearch ist verfügbar unter github.com/karpathy/autoresearch. Das Repository enthält Setup-Anleitungen, Beispiel-program.md-Dateien und Dokumentation zur Anpassung an verschiedene Trainingsaufgaben. Mit Zugang zu einer H100 oder einer community-unterstützten GPU ist die Hürde für das erste Nachtexperiment gering.
Die interessantere Frage ist, was man eigentlich untersuchen würde. AutoResearch liefert den Mechanismus. Die Forschungsrichtung kommt, wie immer, aus dem Verständnis, welche Probleme es wert sind, gelöst zu werden.
webvise arbeitet mit Teams zusammen, die KI in ihre Entwicklungs- und Forschungsabläufe integrieren. Wer darüber nachdenkt, wie autonome Agenten in die eigenen Prozesse passen, findet in einem praktischen Gespräch Orientierung für den konkreten Kontext.
Die Praktiken von webvise sind an den ISO 27001- und ISO 42001-Standards ausgerichtet.