Marco Patzelt
Back to Overview
9. März 2026

Karpathys autoresearch: Warum Grenzen Autonomie ermöglichen

Karpathys autoresearch führt 126 ML-Experimente über Nacht aus ohne zu hängen. Sieben Designmuster zeigen, wie begrenzte Autonomie tatsächlich funktioniert.

Andrej Karpathy hat gerade autoresearch open-sourced — ein Repo, das einen KI-Agenten ML-Experimente autonom über Nacht durchführen lässt, ohne menschliches Eingreifen. Es hat bereits über 15.000 Stars. Das Konzept klingt einfach: Gib einem Agenten ein Trainingsskript, eine einzelne GPU und eine klare Metrik, dann lass ihn endlos iterieren.

Aber das Interessante ist nicht, was es tut. Sondern warum es nicht hängenbleibt.

Jeder, der agentic Systems gebaut hat, kennt den Fehlermodus. Der Agent wird verwirrt, verliert den Kontext, fragt nach Klärung oder dreht sich in kaputten Zuständen. Ich habe das in meinen eigenen Projekten gesehen — Agenten, die für 3 Iterationen großartig funktionieren, dann bei Iteration 4 den Faden verlieren. Karpathys Design eliminiert diese Fehlermodi nicht durch ein besseres Modell, sondern durch strukturelle Einschränkungen.

Das ist der Teil, der es wert ist, genauer hinzuschauen.

Das Setup: Drei Dateien, sonst nichts

Das Repo reduziert LLM-Training auf drei Dateien:

  • prepare.py — Datenvorbereitung, Tokenizer, Evaluierungsrahmen. Nur lesbar. Der Agent kann sie nicht anfassen.
  • train.py — Modellarchitektur, Optimizer, Trainingsschleife. Die einzige Datei, die der Agent bearbeitet.
  • program.md — der Prompt. Anweisungen für den Agenten. Das ist es, woran der Mensch iteriert.

Die Aufgabe des Agenten: train.py modifizieren, ein 5-Minuten-Trainingsexperiment durchführen, prüfen ob der Validierungsverlust sich verbessert hat, behalten oder verwerfen, wiederholen. Wie Karpathy es auf X beschrieb: "Jeder Punkt ist ein kompletter LLM-Trainingslauf, der genau 5 Minuten dauert. Der Agent arbeitet in einer autonomen Schleife auf einem Git-Feature-Branch und sammelt Git-Commits."

Sieben Muster, die Stillstand verhindern

Was das Ganze zum Laufen bringt, ist kein einzelner cleverer Trick. Es sind sieben Designentscheidungen, die jeweils einen spezifischen Fehlermodus beseitigen.

1. Festes 5-Minuten-Zeitbudget

Jedes Experiment ist schnell fertig. Bei etwa 12 Experimenten pro Stunde bekommt der Agent konstantes Feedback. Keine langen Wartezeiten, keine mehrdeutigen "trainiert er noch?"-Zustände. Der Agent weiß immer, was passiert ist, und kann entscheiden, was er als nächstes versucht.

Das sehe ich immer wieder in meiner eigenen Agentenarbeit: Kurze Feedbackschleifen schlagen lange. Jedes Mal. Ein Agent, der 45 Minuten auf ein Ergebnis wartet, hat 45 Minuten Zeit abzudriften. Ein Agent, der alle 5 Minuten ein Ergebnis bekommt, bleibt geerdet.

2. Einzelne Datei als Scope

Der Agent modifiziert nur train.py. Keine Multi-Datei-Orchestrierung, kein Dependency-Management, keine Config-Dateien verstreut über Verzeichnisse. Das eliminiert eine ganze Klasse von Fehlermodi, bei denen Agenten den Überblick über ihre Änderungen verlieren.

Ich habe darüber schon geschrieben — Umgebungsdesign ist wichtiger als Modellintelligenz. Karpathy wendet das gleiche Prinzip an. Er hat den Agenten nicht schlauer gemacht. Er hat die Umgebung einfacher gemacht.

3. Eine eindeutige Metrik

val_bpb (Validation Bits per Byte) — niedriger ist besser. Der Agent muss nie mehrdeutige Ergebnisse interpretieren oder konkurrierende Metriken abwägen. Jedes Experiment produziert eine einzige Zahl, die über Behalten oder Verwerfen entscheidet.

Das ist das "probabilistische Absicht, deterministische Ausführung"-Muster, angewandt auf ML-Forschung. Das Modell entscheidet, was es versucht (probabilistisch). Die Metrik entscheidet, ob es funktioniert hat (deterministisch). Kein Raum für Selbsttäuschung.

4. Git-basierter Rollback

Fehlgeschlagene Experimente werden per git reset auf den letzten bekannten guten Zustand zurückgesetzt. Der Agent kann buchstäblich nicht in einem kaputten Zustand steckenbleiben. Das ist elegant, weil es bestehende Infrastruktur nutzt, statt eigene Rollback-Logik zu bauen.

Es ist das gleiche Prinzip hinter begrenzter Autonomie auf verschiedenen Ebenen — du gibst dem Agenten Freiheit zum Experimentieren, aber du machst es strukturell unmöglich, dass Experimente dauerhaft etwas kaputtmachen.

5. Die "NIEMALS STOPPEN"-Anweisung

Der Prompt weist den Agenten explizit an, niemals auf menschliche Bestätigung zu warten. Wenn ihm die Ideen ausgehen, soll er härter nachdenken — Papers nochmal lesen, Kombinationen früherer Beinahe-Treffer versuchen, radikale Änderungen wagen. Das überschreibt die Standardtendenz der meisten Agenten, nachzufragen und zu warten.

Newsletter

Wöchentliche Insights zu AI-Architektur. Kein Spam.

Die meisten Agentenentwickler unterschätzen, wie wichtig das ist. Das Standardverhalten eines KI-Modells ist hilfreich und vorsichtig zu sein — was normalerweise bedeutet, um Erlaubnis zu fragen. Für autonomen Betrieb muss man diesen Instinkt explizit überschreiben.

6. Strukturierte Schleife mit klaren Schritten

Die Experimentschleife ist als "LOOP FOREVER" beschriftet, mit nummerierten Schritten: Code ändern, committen, ausführen, Ergebnisse prüfen, loggen, behalten oder verwerfen. Der Agent weiß immer genau, in welchem Schritt er ist und was als nächstes kommt.

Das ist Context Engineering in seiner pursten Form. Kein Framework, keine Abstraktionsschicht. Nur eine nummerierte Liste, die dem Agenten genau sagt, was er als nächstes tun soll. Es funktioniert, weil Klarheit Raffinesse schlägt.

7. Keine externen Abhängigkeiten zur Laufzeit

Keine API-Aufrufe, keine Downloads, keine Netzwerkanfragen während der Schleife. Nichts, das blockieren, timen oder auf unvorhersehbare Weise fehlschlagen kann. Die gesamte Ausführung ist lokal.

Jede externe Abhängigkeit ist ein potenzieller Stillstandspunkt. Ich habe aufgehört zu zählen, wie viele Agentenfehler ich auf eine rate-limitierte API, einen instabilen Netzwerkaufruf oder ein Timeout zurückverfolgt habe, das den Flow unterbrochen hat. Karpathy hat sie alle entfernt.

Das Einfachheitskriterium: Geschmack als Code

Über die Vermeidung von Fehlern hinaus hat Karpathy etwas Subtiles in den Prompt eingebaut. Dem Agenten wird gesagt: Bei sonst gleichen Bedingungen ist einfacher besser. Eine 0,001 val_bpb-Verbesserung, die 20 Zeilen hacky Code hinzufügt? Wahrscheinlich nicht wert. Eine 0,001-Verbesserung durch Löschen von Code? Definitiv behalten.

Das ist ein Werturteil, eingebettet in den Prompt, das die Richtung der Forschung formt, nicht nur die Metrik. Es verhindert, dass der Agent auf Frankenstein-Architekturen mit marginalen Gewinnen konvergiert — ein häufiger Fehlermodus bei automatisierter Suche. Der Agent optimiert nicht nur. Er optimiert mit Geschmack.

Ich finde das besonders interessant, weil es genau die Art von Einschränkung ist, die einen nützlichen Agenten von einem technisch korrekten aber praktisch nutzlosen unterscheidet. Die Metrik sagt dem Agenten, was besser ist. Das Einfachheitskriterium sagt ihm, was es wert ist, verfolgt zu werden.

Ergebnisse

In Karpathys Nachtlauf (126 Experimente auf einer H100) verbesserte der Agent val_bpb von 0,9979 auf 0,9697 — eine bedeutsame Verbesserung, gefunden durch systematische Erkundung von Weight Decay, Batch-Size-Halbierung, Tiefenänderungen und Embedding-Lernraten.

Der Agent identifizierte auch korrekt Sackgassen: Weight Tying war "komplett kaputt" (+2,24 BPB), parallele Attention+MLP war schlechter, und aggressives MQA half nicht. Zu wissen, was nicht funktioniert, ist genauso wertvoll wie zu wissen, was funktioniert.

Seine Vision für die nächsten Schritte ist noch interessanter. Er beschrieb den nächsten Schritt als "asynchron massiv kollaborativ für Agenten — denkt an SETI@home-Stil." Nicht einen einzelnen Forscher emulieren, sondern eine ganze Forschungsgemeinschaft.

Was das für agentic Systems bedeutet

Das ist nicht nur ein cooles ML-Projekt. Es ist eine Referenzimplementierung eines Designmusters, auf das ich immer wieder zurückkomme: begrenzte Autonomie. Gib dem Agenten maximale Freiheit innerhalb enger, klar definierter Einschränkungen. Eine Datei, eine Metrik, festes Zeitbudget, automatischer Rollback. Die Einschränkungen sind keine Limitierungen — sie sind das, was Autonomie möglich macht.

Jedes Muster, das Karpathy nutzt, bildet direkt auf ein allgemeines Prinzip für den Bau von agentic Systems ab:

  • Festes Zeitbudget — Kurze Feedbackschleifen verhindern Abdriften
  • Einzelner Datei-Scope — Die Umgebung verengen, nicht das Modell erweitern
  • Eine Metrik — Deterministische Verifizierung, nicht mehrdeutiges Urteil
  • Git-Rollback — Sicheres Scheitern als strukturelle Garantie
  • "NIEMALS STOPPEN" — Standard-Vorsicht für autonomen Betrieb überschreiben
  • Strukturierte Schleife — Explizite Schritte schlagen implizites Reasoning
  • Keine externen Abhängigkeiten — Jeden möglichen Stillstandspunkt entfernen

Die Lektion gilt nicht nur für ML-Forschung. Sie gilt für jedes agentic System. Mach deinen Agenten nicht schlauer. Mach seine Umgebung so gut eingeschränkt, dass selbst ein mittelmäßiger Agent nicht steckenbleiben kann.

Newsletter

Wöchentliche Insights zu AI-Architektur

Kein Spam. Jederzeit abbestellbar.

Häufig gestellte Fragen

autoresearch ist ein Open-Source-Repo von Andrej Karpathy, das einem KI-Agenten ermöglicht, ML-Trainingsexperimente autonom auf einer einzelnen GPU durchzuführen, ohne menschliches Eingreifen.

Sieben strukturelle Einschränkungen: 5-Minuten-Zeitbudgets, einzelner Datei-Scope, eine eindeutige Metrik, Git-basierter Rollback, eine NIEMALS-STOPPEN-Anweisung, strukturierte Schleifenschritte und null externe Abhängigkeiten.

Begrenzte Autonomie bedeutet, einem Agenten maximale Freiheit innerhalb enger, klar definierter Einschränkungen zu geben. Die Grenzen sind keine Limitierungen — sie ermöglichen erst autonomen Betrieb ohne Stillstand.

val_bpb (Validation Bits per Byte). Niedriger ist besser. Eine einzige, eindeutige Zahl, die bestimmt, ob die Änderungen eines Experiments behalten oder per Git Reset verworfen werden.

In Karpathys Demolauf auf einer H100-GPU führte der Agent 126 Experimente über Nacht durch, jedes genau 5 Minuten lang. Das sind etwa 12 Experimente pro Stunde.

Ein Werturteil im Prompt: Bei gleichen Bedingungen ist einfacherer Code besser. Eine kleine Verbesserung durch Code-Löschung lohnt sich. Eine kleine Verbesserung durch 20 Zeilen hacky Code wahrscheinlich nicht.

Lass uns
vernetzen.

Ich schreibe über das, was ich baue. Ich baue das, was mich interessiert. Und ich bin immer offen für echte Gespräche über Systeme, Agenten oder Legacy-Architektur. Wenn dein Problem nach Klempnerei klingt — meld dich.

Schreib mir
Schreib mir