Ich liess Claude Code 48 Stunden in einem Ralph Loop laufen. Das ist passiert.

Letzten Monat beschloss ich, die Grenzen autonomer KI-Entwicklung zu testen. Das Setup: ein echtes Kundenprojekt, ein detailliertes PRD und Claude Code, das 48 Stunden lang in einem Ralph Loop lief.

Das ist kein synthetischer Benchmark. Es ist das, was passierte, als ich die KI auf eine echte Codebasis mit echten Anforderungen losliess. Das Gute, das Schlechte und die Erkenntnisse.

Das Setup

Das Projekt

Ein Schweizer Logistikunternehmen brauchte ein internes Tool zur Verwaltung ihrer Lageroperationen. Die Anforderungen umfassten:

• Inventarverwaltung mit Barcode-Scanning
• Optimierung der Kommissionierung
• Echtzeit-Bestandsüberwachung
• Integration mit ihrem bestehenden ERP-System
• Rollenbasierte Zugriffskontrolle
• Reporting- und Analyse-Dashboard

Kein triviales Projekt. Das PRD hatte 47 einzelne Aufgaben in diesen Bereichen.

Die PRD-Struktur

Ich strukturierte das PRD mit klaren Abschlusskriterien für jede Aufgabe:

## Aufgabe 15: Kommissionier-Algorithmus implementieren

### Anforderungen
- [ ] Routenoptimierungsalgorithmus für Kommissionierung erstellen
- [ ] Lager-Durchquerungsdistanz minimieren
- [ ] Teilauftragserfüllung unterstützen
- [ ] Prioritätsaufträge behandeln
- [ ] Alle Kommissionierentscheidungen für Audit loggen

### Akzeptanzkriterien
- Algorithmus beendet in <100ms für Aufträge bis 50 Artikel
- Routenoptimierung reduziert durchschnittlichen Weg um >30% vs naiver Ansatz
- Alle Grenzfälle haben Testabdeckung

### Tests
- test_picking_basic.py
- test_picking_edge_cases.py
- test_picking_performance.py

Jede Aufgabe hatte diese Struktur: Anforderungen, Akzeptanzkriterien und spezifizierte Tests.

Die Loop-Konfiguration

#!/bin/bash
MAX_ITERATIONS=200
LOG_FILE="ralph_log_$(date +%Y%m%d_%H%M%S).txt"
ITERATION=0

while [ $ITERATION -lt $MAX_ITERATIONS ]; do
  echo "=== Iteration $ITERATION um $(date) ===" | tee -a $LOG_FILE

  # Abschluss prüfen
  PENDING=$(grep -c "\- \[ \]" docs/prd.md)
  DONE=$(grep -c "\- \[x\]" docs/prd.md)
  echo "Aufgaben: $DONE erledigt, $PENDING offen" | tee -a $LOG_FILE

  if [ $PENDING -eq 0 ]; then
    echo "Alle Aufgaben erledigt!" | tee -a $LOG_FILE
    exit 0
  fi

  # Claude Code ausführen
  claude --print "
  Lies docs/prd.md. Finde die erste Aufgabe mit unerledigten Anforderungen.

  1. Verstehe die Aufgabenanforderungen und Akzeptanzkriterien
  2. Lies relevanten bestehenden Code bevor du Änderungen machst
  3. Implementiere die Anforderungen
  4. Schreibe oder aktualisiere Tests wie spezifiziert
  5. Führe Tests mit pytest aus
  6. Wenn Tests bestehen, markiere Anforderungen als erledigt und committe
  7. Wenn Tests fehlschlagen, analysiere und behebe

  Sei gründlich. Lies vor dem Schreiben. Teste vor dem Committen.
  " 2>&1 | tee -a $LOG_FILE

  ITERATION=$((ITERATION + 1))
  sleep 5
done

Ich startete es Freitagabend und liess es übers Wochenende laufen.

Stunde für Stunde: Was wirklich passierte

Stunden 0-6: Starker Start

Die ersten sechs Stunden waren beeindruckend. Claude Code:

• Richtete die Projektstruktur ein
• Erstellte das Datenbankschema
• Implementierte grundlegende CRUD-Operationen für Inventar
• Fügte Authentifizierung mit JWT hinzu
• Baute die initialen API-Endpoints

Nach Stunde 6 waren 12 Aufgaben erledigt. Der Code war sauber, Tests liefen durch, und Commits waren gut strukturiert.

Wichtige Beobachtung: Die KI arbeitete methodisch. Sie las bestehenden Code bevor sie Änderungen machte. Sie führte Tests nach jeder Modifikation aus. Der frische Kontext bei jeder Iteration bedeutete, dass sie keine Verwirrung mitschleppte.

Stunden 6-18: Stetiger Fortschritt

Der mittlere Abschnitt war, wo der Grossteil der Arbeit passierte:

• Auftragsverwaltungssystem
• Generierung von Picklisten
• Echtzeit-Bestandsaktualisierungen via WebSocket
• Initiale Dashboard-Komponenten

Nach Stunde 18 waren 28 Aufgaben erledigt. Das Tempo hatte sich verlangsamt—Aufgaben wurden komplexer—aber der Fortschritt war konstant.

Erster signifikanter Fehler bei Stunde 14: Die KI steckte beim Kommissionier-Algorithmus fest. Sie generierte ständig Lösungen, die grundlegende Tests bestanden, aber den Performance-Benchmark (<100ms für 50 Artikel) nicht schafften. Sie iterierte 8 Mal bevor ich es bemerkte.

Menschliche Intervention #1: Ich fügte einen Hinweis zum PRD hinzu: "Erwäge einen Traveling-Salesman-Approximationsalgorithmus wie Nearest Neighbor." Nächste Iteration, gelöst.

Stunden 18-30: Die Komplexitätswand

Hier wurde es interessant. Die verbleibenden Aufgaben beinhalteten:

• ERP-Integration (externe API-Aufrufe)
• Komplexe Geschäftslogik (Prioritätsbehandlung, Teilerfüllung)
• Querschnittsbelange (Audit-Logging, Berechtigungen)

Hängen bei Stunde 22: Die ERP-Integrationsaufgabe. Die KI konnte den Authentifizierungsablauf ohne die tatsächliche API-Dokumentation nicht herausfinden. Sie machte vernünftige Annahmen, aber sie waren falsch.

Menschliche Intervention #2: Ich fügte die ERP-API-Dokumentation zur Codebasis hinzu. Die KI las sie in der nächsten Iteration und implementierte die Integration korrekt.

Hängen bei Stunde 26: Berechtigungssystem. Die Anforderungen waren komplex:

• Lagermanager können alles Inventar sehen
• Kommissionierer können nur ihre zugewiesenen Zonen sehen
• Admins können Systemeinstellungen ändern
• Auditoren haben Nur-Lese-Zugriff auf alles

Die KI implementierte etwas, aber es entsprach nicht den Anforderungen. Die Tests, die sie schrieb, liefen durch, aber die Tests validierten die Anforderungen nicht wirklich korrekt.

Menschliche Intervention #3: Ich schrieb die Tests um, um die Berechtigungslogik richtig zu validieren. Die KI korrigierte dann die Implementierung entsprechend.

Stunden 30-42: Verfeinerung und Grenzfälle

Mit den Hauptfunktionen erledigt fokussierten sich die verbleibenden Aufgaben auf:

• Behandlung von Grenzfällen
• Fehlermeldungen und Benutzer-Feedback
• Performance-Optimierung
• Dokumentation

Diese Phase lief reibungslos. Die KI war hervorragend bei:

• Fehlerbehandlung zu bestehendem Code hinzufügen
• Docstrings und Kommentare schreiben
• Datenbankabfragen basierend auf Testergebnissen optimieren
• API-Dokumentation generieren

Nach Stunde 42 waren 41 von 47 Aufgaben erledigt.

Stunden 42-48: Die letzten sechs

Die verbleibenden 6 Aufgaben erforderten menschliches Urteilsvermögen:

1. Dashboard-Layout-Entscheidungen - Wo sollte jedes Widget hin? Die KI traf Entscheidungen, aber es war nicht, was der Kunde wollte.
2. Klärung von Geschäftsregeln - "Prioritätsaufträge sollten zuerst behandelt werden" - aber was ist Priorität? Das PRD war nicht spezifisch genug.
3. ERP-Grenzfälle - Das ERP gab manchmal fehlerhafte Daten zurück. Die KI konnte das aus der Dokumentation nicht antizipieren.
4. Performance-Tuning - Die Analytics-Abfragen waren langsam. Die KI optimierte, aber die echte Lösung erforderte Verständnis der Datenmuster des Kunden.
5. Report-Format - "Export nach Excel" - aber welche Spalten? Welche Reihenfolge? Welche Formatierung?
6. Finale Integrationstests - Einige Workflows schlugen fehl, wenn sie auf Arten kombiniert wurden, die Unit-Tests nicht abdeckten.

Diese 6 Aufgaben brauchten noch 4 Stunden fokussierte Arbeit von mir zum Abschliessen.

In Zahlen

Kostenanalyse

• Claude API-Kosten: ~CHF 160
• Menschliche Zeit (6 Stunden zu meinem Stundensatz): ~CHF 1.100
• Gesamt: ~CHF 1.260

Traditionelle Schätzung für dieses Projekt: 2-3 Wochen Entwicklerzeit, ungefähr CHF 14.000-23.000.

Kostenreduktion: 90%+

Erkenntnisse

1. PRD-Qualität ist alles

Die Aufgaben, die reibungslos abgeschlossen wurden, hatten präzise Anforderungen. Die Aufgaben, die stecken blieben, hatten Mehrdeutigkeiten.

Schlechte Anforderung: "Prioritätsaufträge angemessen behandeln" Gute Anforderung: "Aufträge mit priority=true müssen vor allen Nicht-Prioritätsaufträgen in der gleichen Zone verarbeitet werden, unabhängig vom Erstellungszeitpunkt"

Investieren Sie Zeit ins PRD. Es zahlt sich exponentiell aus.

2. Tests sind Ihre Spezifikation

Als die KI ihre eigenen Tests schrieb, testeten sie manchmal nicht wirklich, was sie behaupteten zu testen. Die Tests liefen durch, aber das Feature war falsch.

Für kritische Funktionalität schreiben Sie die Tests selbst. Oder prüfen Sie zumindest die Tests, die die KI generiert, bevor Sie annehmen, dass sie korrekt validieren.

3. Externe Integrationen brauchen Dokumentation

Die KI konnte nicht erraten, wie die ERP-API funktioniert. Sie brauchte Dokumentation. Wenn Ihr Projekt externe Systeme involviert, schliessen Sie deren API-Docs in den Kontext ein.

4. Frischer Kontext hat Grenzen

Die Stärke des Ralph Loops—frischer Kontext bei jeder Iteration—ist auch eine Schwäche. Die KI erinnert sich nicht, was sie vorher versucht hat. Manchmal macht sie den gleichen Fehler wiederholt.

Lösung: Fehler loggen und in den Kontext der nächsten Iteration einschliessen, oder Hinweise zum PRD hinzufügen, wenn Sie wiederholte Fehler sehen.

5. Menschliches Urteilsvermögen ist noch erforderlich

87% autonomer Abschluss ist beeindruckend, aber die verbleibenden 13% erforderten menschliche Expertise:

• Unausgesprochene Anforderungen verstehen
• Design-Entscheidungen treffen
• Wirklich neue Situationen handhaben
• Validieren, dass "korrekt" tatsächlich korrekt ist

Die KI verstärkt menschliche Fähigkeiten. Sie ersetzt menschliches Urteilsvermögen nicht.

Würde ich es wieder tun?

Absolut. Aber mit Anpassungen:

1. Mehr PRD-Arbeit im Voraus - Die Zeit, die für detaillierte Anforderungen aufgewendet wird, ist minimal verglichen mit der eingesparten Zeit
2. Frühere menschliche Checkpoints - Ich würde den Fortschritt alle 6-8 Stunden prüfen, anstatt es unbeaufsichtigt laufen zu lassen
3. Vorgeschriebene kritische Tests - Für komplexe Geschäftslogik die Tests vor dem Start des Loops schreiben
4. Externe Dokumentation eingeschlossen - Jedes System, mit dem der Code interagieren muss, sollte im Voraus dokumentiert sein

Das grössere Bild

Dieses Experiment überzeugte mich, dass KI-gestützte Entwicklung nicht darum geht, Entwickler zu ersetzen. Es geht darum zu ändern, was Entwickler tun.

In diesem Projekt verschob sich meine Rolle von "Person, die Code schreibt" zu "Person, die Anforderungen definiert und Ergebnisse validiert." Die KI übernahm die Implementierung. Ich übernahm Spezifikation und Urteil.

Das ist eine andere Art von Arbeit—in mancher Hinsicht wohl schwieriger—aber dramatisch effizienter.

Für Schweizer KMU, die individuelle Tools bauen wollen, bedeutet das:

• Schnellere Markteinführung
• Niedrigere Entwicklungskosten
• Vorhersehbarere Ergebnisse (wenn Anforderungen klar sind)
• Menschliche Expertise fokussiert dort, wo sie am meisten zählt

Probieren Sie es selbst

Wenn Sie mit Ralph Loops experimentieren wollen:

1. Starten Sie mit einem kleineren Projekt (10-15 Aufgaben)
2. Schreiben Sie detaillierte Anforderungen für jede Aufgabe
3. Schliessen Sie Test-Spezifikationen ein
4. Richten Sie Logging ein, damit Sie überprüfen können, was passiert ist
5. Prüfen Sie den Fortschritt anfangs alle paar Stunden

Die Technik skaliert, aber fangen Sie klein an, um die Muster zu lernen.

---

Interessiert zu sehen, wie KI-gestützte Entwicklung für Ihr Projekt funktionieren könnte? Buchen Sie ein kostenloses Gespräch und lassen Sie uns erkunden, was möglich ist.