Automatische Forschung Mit Claude Code: Die Karpathy-Schleife, Die Läuft Während Du Schläfst
Andrej Karpathy hat am 7. März 2026 ein 630 Zeilen langes Python-Skript auf GitHub gepusht. Er ging schlafen. Als er aufwachte, hatte sein KI-Agent über 100 Machine-Learning-Experimente durchgeführt, 20 Optimierungen entdeckt, die tatsächlich funktionierten, und die Ergebnisse in einem sauberen Protokoll zusammengefasst — alles ohne einen einzigen menschlichen Tastendruck über Nacht. Das Repo erreichte innerhalb von fünf Tagen 25.000 Sterne. Shopify-CEO Tobi Lutke richtete es auf ihre Template-Engine und erzielte 53 % schnelleres Rendering aus 93 automatisierten Commits. Und plötzlich hatte ein Konzept, das in KI-Forschungskreisen kursierte — die autonome Verbesserungsschleife — einen Namen, den sich jeder merken konnte: Auto Research. Ich verfolge das Ganze von meinem Claude Code Terminal aus. Und was mich am meisten begeistert, sind nicht die ML-Experimente. Es ist das, was passiert, wenn man dasselbe Muster — eine Sache ändern, das Ergebnis messen, beibehalten oder verwerfen, wiederholen — auf Geschäftsprobleme richtet. Landingpage-Conversions. E-Mail-Betreffzeilen. Werbetexte. Preisseitenlayouts. Alles, woran eine Zahl hängt. Das ist die Version, die Jack Roberts kürzlich in einem detaillierten Walkthrough vorgestellt hat, und es ist die Version, die ich in den letzten zwei Wochen getestet habe. Die Ergebnisse sind nicht so dramatisch wie die von Karpathy — ich trainiere keine Sprachmodelle über Nacht. Aber ich beobachte, wie Claude autonom meine Conversion-Texte durch eine strukturierte Schleife verbessert, die wöchentlich läuft, ohne dass ich sie anfasse. Und die Zinseszins-Mathematik dahinter ist wirklich erstaunlich. Hier erfährst du, wie das gesamte System funktioniert, wie ich meines eingerichtet habe und welche konkreten Fehler ich gemacht habe, damit du sie nicht wiederholst.
Das Mentale Modell: Warum 1 % Sich zu 37x Aufzinsen
Bevor du auch nur eine Zeile Code anfasst, musst du verinnerlichen, warum dieser Ansatz funktioniert — denn der Instinkt, den die meisten Menschen haben, ist falsch. Die meiste Optimierung passiert in Schüben. Man überarbeitet eine Landingpage alle sechs Monate. Man schreibt E-Mail-Sequenzen einmal pro Quartal um. Man aktualisiert Werbetexte, wenn die Performance einbricht. Zwischen diesen Schüben? Nichts ändert sich. Man fährt dieselben Texte, dasselbe Layout, dieselben Überschriften wochen- oder monatelang. Auto Research dreht dieses Modell um. Statt großer seltener Änderungen macht man kleine kontinuierliche. Und die Mathematik der kontinuierlichen Verbesserung ist kontraintuitiv. Eine tägliche Verbesserung von 1 % — über ein Jahr aufgezinst — ergibt keinen Gewinn von 365 %. Sie ergibt einen Gewinn von 37x. Das ist 1,01 hoch 365. James Clear hat das in Atomic Habits populär gemacht, aber Karpathy hat es in ein technisches Muster verwandelt. Die Auto-Research-Schleife ist der Mechanismus, der Zinseszins-Verbesserung mechanisch statt ehrgeizig macht. Das Gegenteil ist ebenso brutal. Ein täglicher Rückgang von 1 % summiert sich zu einem Verlust von 97 %. Stillstand ist nicht neutral — es ist langsame Erosion, während Wettbewerber um dich herum iterieren. Die 37x-Zahl ist theoretisch. Du wirst nicht ewig tägliche Verbesserungen von 1 % bei einer einzelnen Metrik aufrechterhalten. Abnehmende Grenzerträge sind real. Aber das Muster der kontinuierlichen automatisierten Iteration? Das ist der Durchbruch. Selbst eine durchschnittliche Verbesserung von 0,1 % pro Iteration, zweimal pro Woche, produziert über ein Quartal hinweg spürbare Gewinne. Und der entscheidende Punkt: die KI übernimmt die Iteration, nicht du. Die WD-40-Geschichte veranschaulicht das perfekt. Das Produkt erhielt seinen Namen, weil es 40 Versuche brauchte, um die richtige Wasserverdrängungsformel zu finden. Vierzig Iterationen. Die meisten Menschen hätten nach fünf aufgegeben. Auto Research beseitigt die menschliche Tendenz, zu früh aufzugeben, indem es jede Iteration nahezu kostenlos macht. Das ist die Theorie. So sieht das tatsächliche System aus.
Drei Komponenten, Eine Schleife: Die Auto-Research-Architektur
Das Auto-Research-Framework — egal ob du es auf ML-Training wie Karpathy oder auf Geschäftsmetriken wie ich anwendest — reduziert sich immer auf drei Komponenten: Eine Sache zum Ändern. Eine einzelne Variable oder ein Element, das du Claude verändern lässt. Eine Überschrift. Der Text eines CTA-Buttons. Eine E-Mail-Betreffzeile. Die Reihenfolge der Vorteile auf einer Preisseite. Nicht fünf Dinge gleichzeitig — eine Sache. Isolation ist wichtig, denn wenn du drei Variablen änderst und die Performance steigt, weißt du nicht, welche Änderung es verursacht hat. Eine Metrik zum Messen. Eine objektive, quantitative Zahl, die dir sagt, ob die Änderung geholfen oder geschadet hat. Conversion-Rate. Klickrate. Absprungrate. Öffnungsrate. Kein "Bauchgefühl." Kein "fühlt sich besser an." Eine Zahl. Eine Methode zum Ablesen der Ergebnisse. Ein Weg, wie Claude tatsächlich auf die Leistungsdaten zugreifen kann, ohne dass du sie manuell in einen Prompt kopierst. Hier scheitern die meisten Leute, und ich zeige dir im Implementierungsteil die Lösung, die ich gefunden habe. Die Schleife selbst ist denkbar einfach:
1. Claude liest aktuelle Leistungsdaten (die "Kontrolle")
2. Claude generiert eine Variante (den "Herausforderer")
3. Du setzt den Herausforderer ein
4. Warte, bis genügend Daten gesammelt sind
5. Claude liest die neuen Leistungsdaten
6. Wenn Herausforderer > Kontrolle → Herausforderer wird neue Baseline
7. Wenn Kontrolle > Herausforderer → zurücksetzen, anderen Ansatz versuchen
8. Wiederhole ab Schritt 1
Das ist A/B-Testing-Logik, aber mit der KI, die die Schritte 1, 2, 5, 6, 7 und 8 autonom abwickelt. Deine Aufgabe schrumpft auf Schritt 3 (die Änderung deployen) und Schritt 4 (warten). Und mit den richtigen Tools — zum Beispiel der Browser-Automatisierung von Claude Co-work — kann sogar das Deployment automatisiert werden. Karpathys originales Repo implementiert das für ML-Training. Seine drei Dateien entsprechen direkt diesem Framework:
prepare.py— Feste Datenvorbereitung und Utilities. Der Agent fasst das nie an. Es ist das stabile Fundament.train.py— Die einzige Datei, die der Agent bearbeitet. Enthält die Modellarchitektur, Hyperparameter, Optimizer und Trainingsschleife. Alles darf verändert werden.program.md— Die Anweisungsdatei. Sagt dem Agenten, was optimiert werden soll, wie Erfolg gemessen wird und welche Einschränkungen zu beachten sind. Der Agent modifizierttrain.py, führt einen 5-minütigen Trainingszyklus durch, prüft, ob sich der Validierungsverlust verbessert hat, behält oder verwirft die Änderung und wiederholt. In zwei Tagen führte Karpathys Agent 700 Experimente durch und fand 20 echte Optimierungen. Als diese 20 Anpassungen auf ein größeres Modell angewendet wurden, verbesserte sich die Trainingsgeschwindigkeit um 11 %. Die Geschäftsversion folgt derselben Struktur — andere Dateien, dasselbe Muster. Lass mich dir zeigen, wie ich es angepasst habe.
Deine Auto-Research-Umgebung Einrichten
Ich beschreibe das Setup, das ich tatsächlich verwende, nicht ein theoretisches Ideal. Manches davon ist improvisiert. Es funktioniert.
Schritt 1: Definiere Deine Metrik und Erstelle eine Geschäftskontextdatei
Wähle eine Metrik. Ich habe die Klickrate auf einen Landingpage-CTA-Button gewählt, weil die Feedback-Schleife schnell ist (ich habe genug Traffic für wöchentliche Messungen) und die Variable isoliert ist (Buttontext und umgebender Kontext).
Erstelle dann eine business.md-Datei, die Claude den nötigen Kontext gibt, um intelligente Entscheidungen zu treffen. Das ist der Teil, den die meisten Menschen überspringen, und es ist der Teil, der am meisten zählt. Ohne Geschäftskontext generiert Claude generische Marketingtexte. Mit Kontext generiert Claude Texte, die tatsächlich zu deiner Zielgruppe passen.
Hier ist eine vereinfachte Version meiner Datei:
# Business Context
## Who We Are
Ramlit Limited — software development agency serving B2B clients.
Primary service: custom web application development.
Average project size: $15K-$50K.
## Target Audience
- CTOs and engineering leads at mid-size companies (50-500 employees)
- Evaluating build-vs-buy for internal tools
- Pain points: slow development cycles, technical debt, unreliable freelancers
## Current Landing Page Performance
- Monthly visitors: ~2,400
- Current CTA click-through rate: 3.2%
- Primary CTA: "Get a Free Quote"
- Traffic sources: 60% organic, 25% referral, 15% direct
## Brand Voice
Professional but direct. No buzzwords. Results-focused.
Reference tone: ramlit.com existing copy.
## Constraints
- Do not change the core value proposition
- Do not use urgency tactics ("limited time", "act now")
- Keep CTA under 6 words
- All changes must maintain professional tone
Je spezifischer deine Kontextdatei, desto intelligenter werden Claudes Vorschläge. Ich habe das aus meiner Arbeit an selbstverbessernden KI-Systemen gelernt — die Qualität des Kontextdokuments bestimmt direkt die Qualität des KI-Outputs. Generischer Kontext produziert generische Ergebnisse.
Schritt 2: Richte Deine Datenpipeline Ein
Hier wird es ernst — und hier scheitern die meisten Auto-Research-Setups. Karpathys Version hat es leicht. Die Metrik (Validierungsverlust) wird vom Trainingsskript selbst berechnet. Der Agent führt das Skript aus, liest die Ausgabe und weiß sofort, ob sich die Leistung verbessert hat. Sauber, abgeschlossen, keine externen Abhängigkeiten. Geschäftsmetriken sind nicht so ordentlich. Deine Conversion-Daten liegen in Google Analytics. Oder Stripe. Oder einem Plattform-Dashboard ohne API. Diese Daten in ein Format zu bringen, das Claude lesen kann, ist die erste echte technische Herausforderung. Ich habe drei Ansätze getestet: Option A: Direkte API-Integration. Wenn deine Analytics-Plattform eine API hat (Google Analytics 4, Mixpanel, Amplitude), kannst du ein Skript schreiben, das die relevante Metrik abruft und in eine Datei schreibt, die Claude lesen kann. Das ist der sauberste Ansatz, erfordert aber etwas Setup.
# Example: Pull GA4 data into a metrics file
from google.analytics.data_v1beta import BetaAnalyticsDataClient
from google.analytics.data_v1beta.types import RunReportRequest
import json
from datetime import datetime
client = BetaAnalyticsDataClient()
request = RunReportRequest(
property=f"properties/YOUR_PROPERTY_ID",
dimensions=[{"name": "pagePath"}],
metrics=[
{"name": "screenPageViews"},
{"name": "conversions"},
],
date_ranges=[{"start_date": "7daysAgo", "end_date": "today"}],
)
response = client.run_report(request)
# Format for Claude consumption
metrics = {
"date_pulled": datetime.now().isoformat(),
"period": "last_7_days",
"landing_page": "/services",
"pageviews": int(response.rows[0].metric_values[0].value),
"conversions": int(response.rows[0].metric_values[1].value),
"conversion_rate": round(
int(response.rows[0].metric_values[1].value)
/ int(response.rows[0].metric_values[0].value) * 100, 2
)
}
with open("metrics/current_performance.json", "w") as f:
json.dump(metrics, f, indent=2)
Option B: Browser-Automatisierung mit Claude Co-work. Wenn keine APIs verfügbar sind — und bei einer überraschenden Anzahl von Plattformen sind sie es nicht — kann Claude Co-work Dashboard-Daten direkt scrapen. Ich habe das in meinem Beitrag über geplante Aufgaben mit Claude Co-work behandelt. Du richtest eine geplante Aufgabe ein, die dein Analytics-Dashboard öffnet, die relevanten Zahlen liest und sie in eine Datei oder Notion-Seite schreibt.
Option C: Manuell unterstützt (die ehrliche Version). Die ersten zwei Wochen habe ich einfach jeden Montagmorgen die Zahlen in eine metrics.json-Datei kopiert. Dauerte 90 Sekunden. Nicht glamourös. Aber es ließ mich die Schleife selbst validieren, bevor ich Zeit in Automatisierung investierte. Lass perfekte Infrastruktur dich nicht davon abhalten, anzufangen.
Ich begann mit Option C und wechselte nach dem ersten Monat zu Option B, als ich bestätigt hatte, dass die Schleife echte Gewinne produzierte. Wenn du gerade erst anfängst, mach es genauso. Automatisiere die Datenpipeline nachdem du bewiesen hast, dass die Optimierungsschleife funktioniert.
Schritt 3: Erstelle Deine Programmdatei
Das ist dein program.md — die Anweisungssammlung, die Claude sagt, wie die Schleife laufen soll. Hier ist die Struktur, die ich verwende:
# Auto Research: Landing Page CTA Optimization
## Objective
Improve the click-through rate on the /services landing page CTA.
## Current Baseline
- Control CTA: "Get a Free Quote"
- Control CTR: 3.2% (last 7 days, from metrics/current_performance.json)
## Rules
1. Read the current metrics from metrics/current_performance.json
2. Read the business context from business.md
3. Analyze why the current CTR might be underperforming
4. Generate ONE challenger variant — a new CTA copy and 2-3 sentences
of surrounding context
5. Explain WHY you expect the challenger to outperform (hypothesis)
6. Write the challenger to variants/challenger_[date].md
7. After deployment and data collection, compare challenger vs control
8. If challenger wins: update baseline in this file
9. If control wins: log the failed hypothesis and try a different approach
## Change Constraints
- CTA must be under 6 words
- Surrounding copy changes limited to the 3 sentences nearest the CTA
- No urgency language, no discount offers
- Maintain professional B2B tone
## Experiment Log
| Date | Variant | Hypothesis | Result | CTR |
|------|---------|-----------|--------|-----|
| Baseline | "Get a Free Quote" | — | Control | 3.2% |
Das Experimentprotokoll am Ende ist entscheidend. Es gibt Claude ein Gedächtnis über Iterationen hinweg. Ohne das Protokoll könnte der Agent dieselbe Änderung zweimal vorschlagen oder aus früheren Fehlschlägen nicht lernen. Jedes Mal, wenn die Schleife läuft, liest Claude das Protokoll, sieht, was ausprobiert wurde, was funktioniert hat und was nicht — und generiert dann eine Variante, die auf diesem angesammelten Wissen aufbaut.
Schritt 4: Konfiguriere die Schleifenfrequenz
Wie oft sollte die Schleife laufen? Das hängt von deinem Traffic und deiner Feedback-Geschwindigkeit ab. Für meine Landingpage mit ~2.400 monatlichen Besuchern geben mir wöchentliche Iterationen genügend Daten, um aussagekräftige Unterschiede zu messen. Hochfrequentierte Seiten (10.000+ tägliche Besucher) könnten täglich laufen. E-Mail-Kampagnen könnten pro Versand laufen. Die wichtigste Einschränkung: Du brauchst genügend Daten zwischen Iterationen, um Signal von Rauschen zu unterscheiden. Wenn du eine CTA-Änderung testest und nur 50 Personen sie sehen, bevor die nächste Iteration startet, sind deine Daten bedeutungslos. Warte auf statistische Signifikanz — oder zumindest auf praktische Signifikanz. Ich habe meines als wöchentliche geplante Aufgabe in Claude Co-work eingerichtet. Jeden Montag um 8:00 Uhr liest Claude die neuesten Metriken, vergleicht mit der Kontrolle der Vorwoche und generiert den nächsten Herausforderer, wenn die Daten schlüssig sind. Wenn du neugierig auf die Planungsmechanik bist, gehe ich die exakte Claude Co-work-Konfiguration in meinem Leitfaden zur Automatisierung geplanter Aufgaben durch. Die Kurzversion: Du erstellst eine geplante Aufgabe im Co-work-Panel, richtest sie auf dein Projektverzeichnis und stellst die Wiederholung ein.
Was Tatsächlich Passierte, Als Ich Das Zwei Wochen Laufen Ließ
Hier höre ich auf, über Theorie zu reden, und zeige dir die Realität. Einschließlich der peinlichen Teile. Woche 1: Die Baseline Ausgangsmetriken: 3,2 % CTR bei "Get a Free Quote." 587 Seitenaufrufe. 19 CTA-Klicks. Claude las den Geschäftskontext, analysierte die Baseline und generierte seinen ersten Herausforderer:
Herausforderer-CTA: "See What We'd Build For You" Hypothese: Der aktuelle CTA impliziert eine transaktionale Verkaufsinteraktion ("Angebot"). Die Zielgruppe (CTOs, technische Leiter) befindet sich im Evaluierungsmodus, nicht im Kaufmodus. Den CTA als Einladung umzuformulieren, eine maßgeschneiderte Lösung zu sehen, reduziert die wahrgenommene Verpflichtung und steigert die Neugier. Ich tauschte den CTA-Text am Montagnachmittag. Dauerte zwei Minuten im CMS. Woche 1 Ergebnisse: 612 Seitenaufrufe. 27 Klicks. 4,4 % CTR. Eine Verbesserung von 37,5 % gegenüber der Baseline. Meine erste Reaktion war Skepsis. Eine Steigerung von 37,5 % durch das Ändern von fünf Wörtern? Das fühlte sich zu hoch an. Könnte Rauschen sein. Könnte ein anderer Traffic-Mix in dieser Woche gewesen sein. Ich notierte es und machte weiter. Woche 2: Der Übermütige Herausforderer Claude las die Ergebnisse von Woche 1, bemerkte die Verbesserung und wurde — ich vermenschliche hier — ehrgeizig. Der nächste Vorschlag: Herausforderer-CTA: "Your Custom Build Starts Here" Hypothese: Aufbauend auf dem Erfolg der Personalisierungsrahmung ("What We'd Build For You") fügt diese Variante Vorwärtsdynamik hinzu ("Starts Here") bei gleichzeitig niedriger Einstiegshürde. Das besitzanzeigende "Your" verstärkt die Eigentumspsychologie. Vernünftige Hypothese. Ich setzte sie ein. Woche 2 Ergebnisse: 591 Seitenaufrufe. 22 Klicks. 3,7 % CTR. Besser als die ursprüngliche Baseline, aber schlechter als der Herausforderer aus Woche 1. Also kehrte Claude zum Gewinner aus Woche 1 ("See What We'd Build For You") als neue Baseline zurück, protokollierte das gescheiterte Experiment und notierte im Experimentprotokoll: "Besitzanzeigende Rahmung + Aktionssprache schnitt schlechter ab als Neugier-Rahmung. Nächste Iteration sollte Variationen des Neugier-Ansatzes erkunden, statt zur Aktionssprache zu wechseln." Diese Notiz — diese selbstkorrigierende Analyse — ist das, was Auto Research von einem Menschen unterscheidet, der A/B-Tests durchführt. Ich hätte diese Synthese nicht geschrieben. Ich hätte mir die Zahl angesehen, gedacht "das hat nicht funktioniert," und wäre weitergegangen, ohne die Lektion daraus zu ziehen. Claude erfasst systematisch, warum etwas gescheitert ist, und nutzt das für den nächsten Versuch. Die Laufenden Ergebnisse Nach Zwei Wochen: | Woche | CTA | CTR | vs. Baseline | |------|-----|-----|-------------| | 0 (Kontrolle) | "Get a Free Quote" | 3,2 % | — | | 1 | "See What We'd Build For You" | 4,4 % | +37,5 % | | 2 | "Your Custom Build Starts Here" | 3,7 % | +15,6 % | | 3 (aktuell) | "See What We'd Build For You" (zurückgesetzt) | Läuft | — | Zwei Iterationen. Ein Gewinner, ein Verlierer. Das System hat aus beiden gelernt. Und meine neue Baseline liegt 37,5 % über meinem Ausgangspunkt. Stell dir jetzt vor, das läuft 26 Wochen — ein halbes Jahr — mit dem Zinseszinseffekt, bei dem jede gewinnende Variante zum neuen Boden wird. Das ist Auto Research.
Das Karpathy-Repo: ML-Experimente in Geschäftsnutzung Übersetzen
Lass mich die Lücke zwischen dem, was Karpathy gebaut hat, und dem, was du tatsächlich verwenden wirst, überbrücken, denn die Implementierungen sehen unterschiedlich aus, obwohl das Muster identisch ist.
Karpathys autoresearch-Repo konzentriert sich auf die Optimierung neuronaler Netzwerk-Trainings. Der Agent passt Architekturentscheidungen, Hyperparameter und Optimizer-Konfigurationen an — technische Entscheidungen, die eine einzelne Metrik beeinflussen: den Validierungsverlust. Die gesamte Feedback-Schleife ist in sich geschlossen. train.py läuft 5 Minuten, gibt einen Verlustwert aus, und der Agent entscheidet, ob die Änderung beibehalten wird.
Das Repo ging viral (49.800+ GitHub-Sterne zum Zeitpunkt dieses Artikels), weil es etwas demonstrierte, worüber Menschen theoretisiert hatten, was aber noch nie sauber funktioniert hatte: ein KI-Agent, der ein System durch autonome Experimente tatsächlich verbessert, nicht nur durch Prompting.
Aber wenn du keine neuronalen Netze trainierst, musst du das Muster anpassen. Hier ist die Übersetzungstabelle:
| Karpathys ML-Version | Deine Geschäftsversion |
|---|---|
train.py (Modellcode) |
Deine Landingpage / E-Mail / Werbetext |
prepare.py (Daten-Utilities) |
Deine Analytics-Pipeline (API oder Scraping) |
program.md (Agenten-Anweisungen) |
Dein program.md (Optimierungsziel + Einschränkungen) |
| Validierungsverlust | Conversion-Rate / CTR / Öffnungsrate |
| 5-Minuten-Trainingslauf | 1 Woche Traffic-Akkumulation |
| Automatische Code-Ausführung | Manuelles Deployment oder Claude Co-work-Automatisierung |
| GPU-Rechenleistung | Menschliche Geduld |
| Der größte Unterschied: Geschwindigkeit. Karpathys Agent führte 700 Experimente in 2 Tagen durch, weil jedes Experiment Minuten dauerte. Geschäftsoptimierungsschleifen laufen wöchentlich oder täglich, weil du echte Menschen brauchst, die die Daten generieren. Das bedeutet, dass dein Experimentprotokoll noch wichtiger wird — du kannst es dir nicht leisten, eine Iteration mit einer schlecht begründeten Hypothese zu verschwenden. | |
Profitipp: Karpathys Repo enthält eine program.md-Datei, die es wert ist, gelesen zu werden, selbst wenn du nie ein Modell trainierst. Die Art, wie er Einschränkungen, Erfolgskriterien und Agenten-Anweisungen strukturiert, ist eine Meisterklasse in Prompt Engineering für autonome Systeme. Ich habe sein Format direkt für meine Geschäftsoptimierungsversion übernommen. |
Das Datenproblem, Über Das Niemand Spricht (Und Mein Workaround)
Hier ist die unbequeme Wahrheit über die Anwendung von Auto Research auf Geschäftsmetriken: Der Großteil deiner wichtigen Daten liegt hinter Dashboards, die nicht für programmatischen Zugriff konzipiert wurden. Google Analytics hat eine API. Stripe hat eine API. Aber Skool? Die detaillierten Engagement-Daten von ConvertKit? Dein WordPress-Dashboard? Dein Shopify-Theme-Editor? Die Hälfte der Tools, die Gründer tatsächlich nutzen, stellen die benötigten Metriken nicht über saubere APIs bereit. Jack Roberts hat genau dieses Problem in seinem Walkthrough hervorgehoben, und seine Lösung ist die richtige: Browser-Automatisierung. Die Browser-Fähigkeiten von Claude Co-work können zu einem Dashboard navigieren, die Zahlen lesen und sie in eine Datei schreiben. Es ist nicht elegant. Es ist keine ordentliche Integration. Aber es funktioniert zuverlässig für den "Metrik ablesen"-Schritt der Schleife. Das Setup sieht folgendermaßen aus:
- Erstelle eine Co-work-Aufgabe, die zu deinem Analytics-Dashboard navigiert
- Melde dich an mit gespeicherten Zugangsdaten (oder besser: einer Sitzung, die authentifiziert bleibt)
- Lies die spezifische Metrik von der Seite — Claude kann Zahlen aus Dashboard-UIs identifizieren und extrahieren
- Schreibe die Metrik in eine JSON-Datei oder Notion-Seite, die deine Haupt-Auto-Research-Schleife liest Ich habe das mit einem Google Analytics-Dashboard und einer Notion-Datenbank getestet. Claude Co-work öffnete die GA-Seite, fand die Conversion-Rate für meine Zielseite, extrahierte die Zahl und schrieb sie in eine Notion-Tabelle. Dauerte etwa 45 Sekunden pro Durchlauf. Nicht schnell, aber für einen wöchentlichen Rhythmus? Völlig ausreichend. Für Plattformen, die komplexere Navigation erfordern — mehrere Klicks, Dropdown-Filter, Datumsbereichsauswahl — musst du in deinen Co-work-Aufgabenanweisungen expliziter sein. Beschreibe jeden Klick. Gib an, mit welchem Element interagiert werden soll. Je präziser deine Anweisungen, desto zuverlässiger die Automatisierung. Wenn du lieber jemanden hättest, der diese gesamte Datenpipeline und Auto-Research-Schleife von Grund auf aufbaut, übernehme ich genau diese Art von KI-Automatisierungsprojekten. Du kannst sehen, was ich gebaut habe, unter fiverr.com/s/EgxYmWD. Eine Alternative, die erwähnenswert ist: Google Sheets als Zwischenschicht. Du kannst ein Google Sheet einrichten, das Daten aus verschiedenen Quellen importiert (mit eingebauten Konnektoren, Zapier oder manueller Eingabe) und dann Claude das Sheet über die Google Sheets API lesen lassen. Es ist ein universeller Adapter. Unordentlich, aber universell kompatibel.
Die Richtige Metrik Wählen: Wo Auto Research Funktioniert (und Wo Nicht)
Nicht jede Metrik ist ein guter Kandidat für Auto Research. Ich habe das gelernt, indem ich zuerst das Falsche optimieren wollte. Hochwertige Kandidaten:
- Landingpage-Conversion-Raten — Schnelles Feedback, klare Metrik, isolierte Variable. Meine Top-Empfehlung für deine erste Auto-Research-Schleife.
- Öffnungsraten von E-Mail-Betreffzeilen — Jeder Versand ist ein neues Experiment. Hohes Datenvolumen, wenn deine Liste 1.000+ umfasst.
- Klickraten von Werbetexten — Plattformen wie Google Ads und Meta liefern die Metrik bereits. Du musst nur Claude Varianten generieren und Ergebnisse ablesen lassen.
- Abschlussraten der Checkout-Seite — Hoher geschäftlicher Einfluss, messbar, und kleine Text-/Layout-Änderungen können den Unterschied machen.
- Feature-Adoptionsraten in SaaS — Wenn du messen kannst, wie viele Nutzer ein Feature aktivieren, kannst du den Onboarding-Text oder die UI optimieren, die dorthin führt. Weniger geeignete Kandidaten (meide diese für Auto Research):
- SEO-Rankings — Feedback-Zyklus ist zu langsam (Wochen bis Monate). Zu viele störende Variablen. Du kannst nicht isolieren, was eine Ranking-Änderung verursacht hat.
- Markenbekanntheit — Nicht auf sinnvolle Weise quantifizierbar für Iterationsschleifen.
- NPS-Scores — Zu subjektiv und zu selten für schnelle Iteration.
- Umsatz — Zu übergeordnet. Umsatz ist ein Output vieler Inputs. Optimiere die Inputs einzeln.
- Social-Media-Engagement — Zu verrauscht. Algorithmus-Änderungen, virale Zufälle und die Stimmung des Publikums verfälschen die Daten. Die ideale Auto-Research-Metrik hat vier Eigenschaften:
- Hohes Volumen — Genügend Ereignisse pro Zyklus, um Unterschiede zu messen
- Schnelles Feedback — Ergebnisse innerhalb von Tagen verfügbar, nicht Monaten
- Isolierte Variable — Du kannst eine Sache ändern und die Auswirkung messen
- Zugängliche Daten — Du kannst die Metrik programmatisch lesen (oder per Browser-Automatisierung) Wenn deine gewählte Metrik nicht alle vier Kriterien erfüllt, wähle eine andere. Die Schleife funktioniert nur, wenn die Daten sauber, schnell und zuordenbar sind.
Die Qualität der Fragen Zählt Mehr Als die Qualität der Antworten
Das ist etwas, das Jack Roberts betont hat und das einen eigenen Abschnitt verdient, weil es die am meisten unterschätzte Erkenntnis im gesamten Auto-Research-Framework ist.
Wenn du dein program.md schreibst, gibst du Claude nicht nur Anweisungen. Du definierst den Problemraum. Und die Qualität dieser Problemdefinition bestimmt die Obergrenze dessen, was Claude entdecken kann.
Schlechte Problemdefinition:
"Verbessere die Conversion-Rate unserer Website." Gute Problemdefinition: "Verbessere die Klickrate auf den CTA der /services-Seite. Die Zielgruppe sind CTOs, die Build-vs-Buy-Entscheidungen evaluieren. Aktuelle CTR beträgt 3,2 % bei 600 wöchentlichen Seitenaufrufen. Der CTA erscheint unter einem Vorteils-Abschnitt und über einem Testimonial-Block. Der Traffic ist zu 60 % organische Suche." Der Unterschied? Die zweite Version gibt Claude genug Kontext, um intelligente Hypothesen zu bilden. Er kennt die Denkweise der Zielgruppe. Er kennt die Seitenstruktur. Er kennt die Traffic-Quelle, was auf die Suchintention hindeutet. Jedes dieser Details formt die Vorschläge, die Claude generiert. Ich habe festgestellt, dass 30 Minuten, die man in ein gründliches
business.mdundprogram.mdinvestiert, über 10 Iterationen bessere Ergebnisse produzieren als 5 Minuten für ein vages Briefing und 50 Iterationen. Kontext ist Hebelwirkung. Das verbindet sich mit einem breiteren Prinzip, das ich in meiner gesamten Claude Code-Arbeit beobachtet habe: Der Engpass ist fast nie die Fähigkeit der KI. Es ist die Fähigkeit des Menschen, das Problem präzise zu definieren. Auto Research verstärkt jedes Signal, das du ihm gibst — wenn das Signal vage ist, bekommst du vage Optimierung. Wenn das Signal präzise ist, bekommst du präzise Gewinne.
Über Eine Einzelne Metrik Hinaus Skalieren: Die Multi-Loop-Architektur
Sobald deine erste Auto-Research-Schleife läuft und Gewinne produziert, ist die natürliche Frage: Kann ich mehrere Schleifen gleichzeitig laufen lassen? Ja. Aber vorsichtig. Das Risiko bei mehreren gleichzeitigen Optimierungsschleifen sind Interaktionseffekte. Wenn du gleichzeitig deinen Landingpage-CTA und deine Hero-Überschrift und deinen Testimonial-Bereich optimierst, kann eine Änderung bei einem die Performance eines anderen beeinflussen. Deine CTA-Verbesserung könnte wie ein Rückschritt aussehen, weil die Überschriftenänderung darüber die Aufmerksamkeit der Nutzer verschoben hat. Mein Ansatz: Sequentiell, nicht parallel. Lasse eine Schleife laufen, bis sie sich stabilisiert (das heißt, die Verbesserungen plateauieren und Herausforderer die Kontrolle nicht mehr konsistent schlagen). Sperre dann diese Variable, setze die Gewinnerversion als permanent und starte eine neue Schleife für die nächste Variable. Für meine Landingpage sieht die Reihenfolge so aus:
- CTA-Text (läuft gerade)
- Hero-Überschrift (als Nächstes)
- Social-Proof-Bereich (nachdem die Überschrift stabilisiert ist)
- Reihenfolge des Vorteils-Blocks (zuletzt) Jede Schleife läuft 4-8 Wochen, bevor ich zur nächsten Variable wechsle. Geduldig? Ja. Aber es bewahrt die kausale Klarheit, die die Daten vertrauenswürdig macht. Wenn du unbedingt parallele Schleifen laufen lassen musst, tue es auf verschiedenen Seiten oder verschiedenen Kanälen. Optimiere deinen Landingpage-CTA und deine E-Mail-Betreffzeilen gleichzeitig — das sind unabhängige Systeme mit unabhängigen Metriken. Optimiere nur nicht zwei Elemente auf derselben Seite gleichzeitig.
Was Die Meisten Leute Falsch Machen Werden
Ich teste das seit zwei Wochen und spreche mit drei anderen Entwicklern, die dasselbe tun. Hier sind die Muster, die ich scheitern sehe:
Zu viele Variablen pro Iteration ändern. Die Versuchung, es "besser zu machen", indem man fünf Dinge gleichzeitig ändert, ist stark. Widerstehe ihr. Du brauchst Isolation, um zu lernen, was funktioniert. Eine Änderung. Eine Messung. Eine Entscheidung.
Statistische Signifikanz ignorieren. Wenn 50 Personen deinen neuen CTA gesehen haben und 3 geklickt haben (6 % CTR) versus 2, die den alten angeklickt haben (4 % CTR), ist das kein aussagekräftiger Unterschied. Du brauchst genügend Datenvolumen pro Iteration, um dem Ergebnis zu vertrauen. Für Seiten mit wenig Traffic bedeutet das längere Iterationszyklen — mindestens wöchentlich, zweiwöchentlich bei sehr wenig Traffic.
Subjektive Metriken verwenden. "Die Seite fühlt sich besser an" ist keine Metrik. "Der neue Text ist mehr on-brand" ist keine Metrik. Die Auto-Research-Schleife erfordert eine Zahl. Wenn du dein Ziel nicht als Zahl ausdrücken kannst, kann die Schleife nicht darauf optimieren.
Den Geschäftskontext überspringen. Auto Research ohne business.md-Datei zu betreiben ist wie einen Texter einzustellen und ihm nicht zu sagen, wer deine Kunden sind. Claude wird etwas generieren. Es wird nichts besonders Nützliches generieren.
Nach der ersten gescheiterten Iteration aufgeben. Der Woche-2-Herausforderer in meinem Test schnitt schlechter ab als der Gewinner aus Woche 1. Hätte ich dort aufgehört, hätte ich die Erkenntnis verpasst, die den Ansatz für Woche 3 geformt hat. Gescheiterte Experimente sind keine Misserfolge — sie sind Datenpunkte, die den Suchraum für die nächste Iteration einengen. Karpathys Agent führte 700 Experimente durch. Viele davon verschlechterten die Ergebnisse. Das ist der Prozess.
Das Große Ganze: Warum Das Mein Denken Über Optimierung Verändert
Vor Auto Research sah mein Optimierungsprozess so aus: eine Idee haben, sie umsetzen, Ergebnisse in zwei Wochen prüfen, vergessen zu prüfen, einen Monat später prüfen, nicht mehr wissen, was ich geändert hatte, von vorne anfangen. Nach Auto Research sieht mein Optimierungsprozess so aus: Metrik definieren, Einschränkungen definieren, Claude die Schleife laufen lassen, das Experimentprotokoll wöchentlich prüfen, nur eingreifen, wenn etwas komisch aussieht. Der Unterschied in der kognitiven Belastung ist enorm. Ich verschwende keine mentale Energie mehr für "Was soll ich als Nächstes testen?" Das ist Claudes Aufgabe. Ich verwende meine mentale Energie für "Ist das Framework korrekt definiert?" — was eine wesentlich wirkungsvollere Frage ist. Und der Zinseszinseffekt ist real. Nicht die theoretischen 37x. Aber eine Verbesserung von 37,5 % in zwei Wochen bei einer einzelnen Metrik, mit einem System, das weiter iteriert? Projiziere das sechs Monate in die Zukunft. Selbst mit abnehmenden Grenzerträgen ist die kumulative Auswirkung auf eine geschäftsrelevante Metrik — Conversions, Klicks, Anmeldungen — erheblich. Das Auto-Research-Muster ist nicht kompliziert. Drei Dateien. Eine Metrik. Eine Schleife. Das Schwierige ist nicht, es aufzubauen. Das Schwierige ist, die richtige Metrik zu wählen, präzisen Kontext zu schreiben und geduldig genug zu sein, den Zinseszinseffekt wirken zu lassen. Karpathy hat gezeigt, dass das für ML-Forschung in einem Ausmaß funktioniert, das die Branche verblüfft hat. Die Geschäftsversion ist langsamer, chaotischer und weniger dramatisch. Sie ist aber auch für jeden zugänglich, der ein Claude-Abonnement und eine Metrik hat, die ihm wichtig ist. Starte mit einer Metrik. Schreibe heute Abend deine Kontextdatei. Richte die Schleife dieses Wochenende ein. Dann lass sie laufen, während du schläfst. In sechs Monaten wirst du entweder wünschen, du hättest heute angefangen — oder du wirst froh sein, dass du es getan hast.
Häufig Gestellte Fragen
Was ist Auto Research in Claude Code?
Auto Research ist eine autonome Optimierungsschleife, bei der Claude Code iterativ Änderungen gegen eine messbare Metrik testet, Verbesserungen beibehält, Fehlschläge verwirft und wiederholt. Andrej Karpathy popularisierte das Muster im März 2026 mit seinem autoresearch GitHub-Repo, das 700 ML-Experimente in zwei Tagen durchführte. Für geschäftliche Anwendungen optimiert dasselbe Muster Conversion-Raten, Klickraten und andere quantifizierbare Metriken.
Brauche ich Programmiererfahrung, um eine Auto-Research-Schleife einzurichten?
Grundlegendes Dateimanagement und der Umgang mit einem Texteditor reichen für ein manuell unterstütztes Setup aus, bei dem du wöchentlich Metriken in eine JSON-Datei kopierst. Für vollständige Automatisierung — API-Integrationen, Browser-Scraping, geplante Aufgaben — benötigst du fortgeschrittene Python-Kenntnisse oder Vertrautheit mit den Browser-Automatisierungsfunktionen von Claude Co-work. Die program.md- und business.md-Dateien sind reines Markdown.
Wie viel Traffic brauche ich, damit Auto Research funktioniert?
Du brauchst genügend Ereignisse pro Iterationszyklus, um Signal von Rauschen zu unterscheiden. Für Landingpage-Optimierung mit wöchentlichen Zyklen sind 500+ Seitenaufrufe pro Woche ein vernünftiges Minimum. E-Mail-Optimierung benötigt 1.000+ Empfänger pro Versand. Werbetext-Testing funktioniert mit kleineren Volumen, da Werbeplattformen robuste Messung bieten. Seiten mit wenig Traffic sollten zweiwöchentliche oder monatliche Zyklen verwenden.
Kann ich Auto Research auf mehreren Metriken gleichzeitig laufen lassen?
Lasse parallele Schleifen auf unabhängigen Systemen laufen — optimiere deine Landingpage und deine E-Mail-Betreffzeilen gleichzeitig. Vermeide parallele Schleifen auf derselben Seite oder im selben Funnel, da Änderungen an einem Element die Performance eines anderen beeinflussen können, was eine Zuordnung der Ergebnisse unmöglich macht. Sequentielle Optimierung mit einer Variable zur Zeit produziert sauberere, vertrauenswürdigere Daten.
Wie hängt Karpathys autoresearch-Repo mit Geschäftsoptimierung zusammen?
Karpathys Repo optimiert das Training neuronaler Netze, indem ein KI-Agent train.py modifiziert, einen Trainingszyklus durchführt, den Validierungsverlust misst und Änderungen beibehält oder verwirft. Die Geschäftsversion nutzt dasselbe Kontrolle-vs-Herausforderer-Muster, tauscht aber ML-Training gegen Geschäftstexte, Validierungsverlust gegen Conversion-Rate und 5-Minuten-Trainingsläufe gegen wöchentliche Datenerfassung. Das Kernframework — ändern, messen, entscheiden, wiederholen — ist identisch.
Lass Uns Zusammenarbeiten
Du möchtest KI-Systeme bauen, Workflows automatisieren oder deine Tech-Infrastruktur skalieren? Ich helfe dir gerne.
- Fiverr (Individuallösungen & Integrationen): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (Enterprise-Lösungen): ramlit.com
- ColorPark (Design & Branding): colorpark.io
- xCyberSecurity (Sicherheitsdienste): xcybersecurity.io