Dominic Böttger
← Zurück zum Blog

Veröffentlicht am 18. Januar 2026 von Dominic Böttger (vor 2 Monaten) · 28 Min. Lesezeit

KI-Codierassistenten haben grundlegend verändert, wie wir Software entwickeln. Tools wie Claude Code können ganze Funktionen schreiben, komplexe Fehler debuggen und Codebasen mit bemerkenswerter Genauigkeit refaktorisieren. Aber es gibt einen Haken, den jeder kennt, der diese Tools intensiv genutzt hat: Kontexterschöpfung.

Hinweis: KI-gestützte Entwicklung entwickelt sich rasant weiter. Dieser Artikel stellt meine persönliche Sicht und eine Momentaufnahme meiner aktuellen Experimente mit diesen Workflows dar. Die Landschaft könnte in einigen Monaten ganz anders aussehen. Ich baue auf der Arbeit anderer auf – insbesondere der Ralph-Wiggum-Methodik von Geoffrey Huntley, Spec Kit von GitHub und paddos hervorragendem Beitrag über Ralph Wiggum Autonomous Loops. In meinem eigenen Workflow beginne ich typischerweise damit, ein Architekturdokument zusammen mit einem “Pin” zu schreiben, in dem ich alle relevanten Informationen und Entscheidungen vorab sammle – das dient dann als Grundlage für Spec Kit.

Dieser Artikel ist ein tiefer Einblick in das Problem, zwei Methodiken, die verschiedene Aspekte davon adressieren, und wie ihre Kombination etwas erzeugt, das größer ist als die Summe seiner Teile. Wenn du Features mit mehr als 50 Aufgaben baust oder KI-gestützte Entwicklung über Nacht laufen lässt, könnte dieser Ansatz deine Arbeitsweise verändern.

Teil 1: Das Problem verstehen

Was ist Kontexterschöpfung?

Jedes KI-Modell hat ein Kontextfenster – die Menge an Text, die es gleichzeitig „sehen” kann. Bei Claude sind das derzeit rund 200.000 Token (etwa 150.000 Wörter). Das klingt nach viel, und für die meisten Gespräche ist es das auch. Aber bei der Softwareentwicklung füllt sich der Kontext schnell:

  • Dein Prompt und deine Anweisungen: 2.000–5.000 Token
  • Jede gelesene Datei: 500–5.000 Token pro Datei
  • Tool-Ausgaben (grep-Ergebnisse, Testausgaben usw.): 1.000–10.000 Token pro Stück
  • Die Antworten der KI selbst: 500–3.000 Token pro Antwort
  • Fehlermeldungen und Debugging: 500–2.000 Token pro Problem

In einer typischen Entwicklungssitzung liest du vielleicht 20 Dateien, führst 10 Befehle aus und hast 30 Hin-und-Her-Austausche. Das sind leicht 100.000+ verbrauchte Token – die Hälfte deines Kontextfensters ist weg, bevor du viel Code geschrieben hast.

Warum Kontexterschöpfung KI-Entwicklung kaputtmacht

Wenn sich das Kontextfenster füllt, hört die KI nicht einfach auf zu arbeiten – sie degradiert auf subtile, frustrierende Weise:

1. Vergessene Entscheidungen Früh in einer Sitzung legst du vielleicht fest, dass „alle API-Endpunkte JSON mit einem data-Wrapper zurückgeben sollen.” Bei Aufgabe 30 hat die KI das „vergessen”, weil diese frühen Nachrichten herausgeschoben oder komprimiert wurden. Du bekommst inkonsistente API-Antworten.

2. Wiederholte Fehler Du behebst einen Bug in Aufgabe 12. Derselbe Bug taucht in Aufgabe 25 wieder auf, weil der Kontext der Behebung weg ist. Die KI erinnert sich nicht daran, diese Lektion gelernt zu haben.

3. Architektonische Drift Die ersten 10 Aufgaben folgen deinen etablierten Mustern perfekt. Bei Aufgabe 40 erfindet die KI neue Muster, weil sie die Beispiele nicht mehr sehen kann, denen sie zuvor gefolgt ist. Deine Codebasis wird inkonsistent.

4. Halluzinierter Zustand Die KI fängt an, sich an Dinge zu „erinnern”, die nicht passiert sind. Sie referenziert Dateien, die nicht existieren, oder nimmt an, dass Code geschrieben wurde, der es nicht wurde. Das ist besonders gefährlich, weil die KI dabei selbstbewusst klingt.

5. Qualitätsverschlechterung Fehlerbehandlung wird schlampiger. Randfälle werden ignoriert. Tests werden oberflächlich. Die KI ist kognitiv überlastet, jongliert mit zu viel implizitem Zustand.

Die naiven Lösungen funktionieren nicht

„Starte einfach eine neue Sitzung”: Du verlierst den gesamten aufgebauten Kontext. Die KI weiß nicht, was implementiert wurde, welche Entscheidungen getroffen wurden oder welchen Mustern sie folgen soll. Du verbringst 30 Minuten damit, alles neu zu erklären.

„Warte auf größere Kontextfenster”: Selbst ein Kontextfenster mit 1 Million Token füllt sich irgendwann. Und größere Kontexte bringen ihre eigenen Probleme mit: langsamere Antworten, höhere Kosten und die KI kämpft damit, relevante Informationen in einer Flut von Text zu finden.

„Sei einfach präziser”: Es gibt eine Grenze, wie stark man komprimieren kann. Dateiinhalte sind, was sie sind. Fehlermeldungen enthalten notwendige Details. Man kann die grundlegende Größe des Problems nicht wegwünschen.

„Nutze RAG (Retrieval Augmented Generation)”: RAG hilft der KI, relevante Informationen zu finden, aber es löst nicht das Akkumulationsproblem. Jedes abgerufene Dokument verbraucht weiterhin Kontext. Und RAG führt eigene Fehlermodi ein – falsche Dokumente abrufen, kritischen Kontext übersehen.

Die echte Lösung erfordert ein Umdenken des Entwicklungsmodells selbst.

Teil 2: Die Ralph-Wiggum-Methodik

Ursprünge und Philosophie

Die „Ralph Wiggum”-Methodik (humorvoll benannt nach der Simpsons-Figur, die berühmt sagt „Me fail English? That’s unpossible!”) entstand aus der KI-Entwickler-Community als Antwort auf Kontexterschöpfung. Die zentrale Erkenntnis ist kontraintuitiv:

Akzeptiere die Amnesie. Mache das Vergessen zu einem Feature, nicht zu einem Bug.

Anstatt gegen das begrenzte Gedächtnis der KI anzukämpfen, designst du ein System, das frische Starts erwartet und nutzt. Jede Aufgabe bekommt einen sauberen Start – kein angesammelter Ballast, kein vergessener Kontext, keine kognitive Überlastung.

Die drei Prinzipien des Ralph Mode

1. Kontext-Knappheits-Mindset

Traditionelle Entwicklung geht von persistentem Gedächtnis aus. Du lernst etwas, erinnerst dich daran und wendest es später an. Ralph Mode geht vom Gegenteil aus: Jedes Stück Kontext ist teuer und temporär. Das verändert, wie du Arbeit strukturierst:

  • Schreibe Dinge explizit auf (in Dateien, nicht im Gespräch)
  • Verlasse dich nicht darauf, dass „die KI sich schon erinnern wird”
  • Lade kritische Informationen am Anfang jedes Prompts
  • Minimiere, was erinnert werden muss

2. Plan-Wegwerfbarkeit

In der traditionellen Entwicklung sind Pläne lebende Dokumente, die sich weiterentwickeln. Im Ralph Mode werden Pläne konsumiert. Du erstellst eine detaillierte Aufgabenliste, und jede Iteration liest und führt genau eine Aufgabe aus. Der Plan muss nicht perfekt sein – er muss nur gut genug für die nächste Aufgabe sein.

Das ist befreiend. Du musst nicht jeden Randfall im Voraus antizipieren. Du brauchst keine perfekten Architekturdiagramme. Du brauchst eine Liste konkreter, umsetzbarer Aufgaben, die unabhängig voneinander ausgeführt werden können.

3. Gegendruck statt Anleitung

Anstatt zu versuchen, die KI durch komplexe mehrstufige Prozesse zu führen (was das Aufrechterhalten von Kontext erfordert), wendest du Gegendruck an: Bedingungen, die erfüllt sein müssen, bevor fortgefahren wird.

Der wichtigste Gegendruck sind Quality Gates:

  • Tests müssen bestehen
  • Linter muss sauber sein
  • Type Checker muss erfolgreich sein

Wenn die KI Code produziert, der diese Gates nicht besteht, muss sie den Code reparieren, bevor es weitergeht. Du musst nicht erklären, wie es repariert werden soll – nur dass es repariert werden muss. Die KI findet die Lösung mit ihrem frischen Kontext.

Wie Ralph Mode tatsächlich funktioniert

Eine Ralph-Mode-Sitzung sieht so aus:

┌─────────────────────────────────────────────────────────────┐
│  Orchestration Layer (bash script, persistent)              │
│                                                             │
│  while tasks_remain:                                        │
│      ├─ spawn new AI process                                │
│      ├─ pass: prompt + task list file path                  │
│      ├─ AI reads task list, executes ONE task               │
│      ├─ AI runs quality gates                               │
│      ├─ AI marks task complete in file                      │
│      ├─ AI commits changes                                  │
│      ├─ AI exits                                            │
│      └─ loop continues with next task                       │
└─────────────────────────────────────────────────────────────┘

Das entscheidende Detail: Jeder KI-Aufruf ist ein separater Prozess. Wenn du claude -p (Claude im Pipe-Modus) ausführst, startest du eine frische Instanz ohne jegliche Vorgeschichte. Die einzigen Informationen, die sie hat, sind:

  1. Der Prompt, den du hineinleitest
  2. Dateien, die sie von der Festplatte liest
  3. Befehle, die sie ausführt

Es gibt kein gemeinsames Gedächtnis zwischen den Iterationen. Die Aufgabenlisten-Datei (tasks.md) ist der einzige Kommunikationskanal, und es ist nur eine Textdatei mit Checkboxen.

Warum frischer Kontext pro Aufgabe funktioniert

Keine Akkumulation: Jede Aufgabe startet mit 0 Token Vorgeschichte. Die KI liest nur, was sie für die aktuelle Aufgabe braucht.

Keine Verschmutzung: Eine chaotische Debugging-Sitzung in Aufgabe 5 beeinflusst Aufgabe 6 nicht. Die Fehlermeldungen, gescheiterten Versuche und falschen Fährten sind weg.

Konstante Qualität: Aufgabe 50 bekommt die gleichen kognitiven Ressourcen wie Aufgabe 1. Die KI ist nicht müde oder verwirrt.

Natürliches Checkpointing: Jede abgeschlossene Aufgabe wird in Git committet. Wenn etwas schiefgeht, hast du eine saubere Commit-Historie zum Bisecten.

Parallelisierungspotenzial: Da Aufgaben unabhängig sind, könntest du theoretisch mehrere KI-Instanzen auf nicht-konfliktierende Aufgaben ansetzen.

Teil 3: Die Spec-Kit-Methodik

Was ist Spec Kit?

Spec Kit ist ein strukturierter Ansatz für KI-gestützte Entwicklung, der explizite Artefakte gegenüber implizitem Verständnis betont. Anstatt Anforderungen im Gespräch zu erklären, erstellst du formale Dokumente, die über Sitzungen hinweg bestehen bleiben.

Die zentralen Artefakte sind:

1. spec.md – Die Feature-Spezifikation Eine detaillierte Beschreibung dessen, was du baust. User Stories, Akzeptanzkriterien, Randfälle, Einschränkungen. Das ist das „Was”-Dokument.

# Feature: User Authentication

## User Stories

### US-1: User Registration
As a new user, I want to create an account with email and password
so that I can access the application.

**Acceptance Criteria:**
- Email must be valid format
- Password must be 12+ characters with mixed case and numbers
- Duplicate emails are rejected with clear error message
- Successful registration sends verification email

### US-2: User Login
...

2. plan.md – Der Implementierungsplan Technische Entscheidungen, Architekturwahlen, Technologie-Stack. Das ist das „Wie”-Dokument. Es beantwortet Fragen, die die KI sonst stellen oder erraten müsste.

# Implementation Plan

## Technology Stack
- Backend: Rust with Axum framework
- Database: PostgreSQL with sqlx
- Auth: JWT tokens with refresh rotation
- Session Storage: Redis

## Architecture Decisions

### AD-1: Password Hashing
Use Argon2id with these parameters:
- Memory: 64MB
- Iterations: 3
- Parallelism: 4

Rationale: OWASP recommendation for 2024+

### AD-2: Token Structure
...

3. tasks.md – Die Aufgabenaufteilung Granulare, umsetzbare Einträge, die unabhängig voneinander erledigt werden können. Jede Aufgabe sollte in einer KI-Sitzung abschließbar sein, ohne auf andere Aufgaben verweisen zu müssen.

# Tasks

## Phase 1: Database Setup
- [ ] T001: Create users table migration with email, password_hash, created_at
- [ ] T002: Create sessions table migration with user_id, token, expires_at
- [ ] T003: Add indexes for email lookups and session token lookups

## Phase 2: Core Authentication
- [ ] T004: Implement password hashing service with Argon2id
- [ ] T005: Implement JWT token generation and validation
- [ ] T006: Create registration endpoint POST /api/auth/register
...

4. constitution.md – Projektprinzipien Unverhandelbare Regeln, die für alle Features gelten. Codierstandards, Sicherheitsanforderungen, architektonische Einschränkungen.

# Project Constitution

## Security Principles
- All user input must be validated at API boundary
- SQL queries must use parameterized statements (no string interpolation)
- Passwords are never logged, even in debug mode

## Code Style
- Rust: Follow clippy lints with -D warnings
- Error handling: Use thiserror for library errors, anyhow for application errors
- All public functions must have doc comments

Warum explizite Artefakte wichtig sind

1. Persistenz über Sitzungen hinweg Wenn du eine neue KI-Sitzung startest, erklärst du nicht alles von Grund auf. Du sagst „lies spec.md und plan.md” und die KI hat in Sekunden den vollständigen Kontext.

2. Konsistenz über Aufgaben hinweg Aufgabe 47 kann dieselbe plan.md referenzieren wie Aufgabe 1. Architekturentscheidungen driften nicht, weil sie aufgeschrieben sind, nicht erinnert.

3. Punkte für menschliche Überprüfung Bevor die Implementierung beginnt, kannst du spec.md mit Stakeholdern und plan.md mit deinem Team reviewen. Fehler, die hier gefunden werden, sind günstig zu beheben.

4. Dokumentation als Nebeneffekt Wenn das Feature fertig ist, hast du Dokumentation. Die Spec erklärt, was gebaut wurde, der Plan erklärt, warum Entscheidungen getroffen wurden, und die Aufgabenliste zeigt die Implementierungsreihenfolge.

5. Reproduzierbarkeit Ein Jahr später kannst du das Feature verstehen, indem du diese Dateien liest. Du musst keine Entscheidungen aus Commit-Nachrichten oder Stammwissen rekonstruieren.

Der Spec-Kit-Workflow

1. /speckit.specify
   └─ Interaktives Gespräch zum Erstellen der spec.md

2. /speckit.plan
   └─ KI analysiert Spec + Codebasis, erstellt plan.md

3. /speckit.tasks
   └─ KI zerlegt Plan in granulare tasks.md

4. /speckit.implement
   └─ KI führt Aufgaben in einer einzelnen Sitzung aus

Dieser Workflow ist hervorragend für kleine bis mittlere Features (unter 20 Aufgaben). Die strukturierten Artefakte bedeuten, dass jeder Schritt auf dem vorherigen mit explizitem Kontext aufbaut.

Aber bei großen Features trifft Schritt 4 auf das Kontexterschöpfungsproblem. Ein 50-Aufgaben-Feature wird den Kontext vor der Fertigstellung erschöpfen.

Teil 4: Warum Spec Kit + Ralph Mode so leistungsfähig ist

Die Synergie

Spec Kit löst das Planungsproblem: Wie gibt man einer KI genug Kontext für gute Entscheidungen, ohne langwierige Gespräche?

Ralph Mode löst das Ausführungsproblem: Wie implementiert man ein großes Feature ohne Kontexterschöpfung?

Zusammen bilden sie ein vollständiges System:

┌─────────────────────────────────────────────────────────────┐
│                    SPEC KIT                                 │
│  ┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐     │
│  │ Specify │ → │  Plan   │ → │  Tasks  │ → │   ???   │     │
│  └─────────┘   └─────────┘   └─────────┘   └─────────┘     │
│       ↓             ↓             ↓                         │
│   spec.md      plan.md      tasks.md                        │
└─────────────────────────────────────────────────────────────┘
                                   │
                                   ▼
┌─────────────────────────────────────────────────────────────┐
│                    RALPH LOOP                               │
│                                                             │
│   ┌─────────┐   ┌─────────┐   ┌─────────┐                  │
│   │ Task 1  │ → │ Task 2  │ → │ Task 3  │ → ...            │
│   │ (fresh) │   │ (fresh) │   │ (fresh) │                  │
│   └─────────┘   └─────────┘   └─────────┘                  │
│        ↓             ↓             ↓                        │
│    commit 1      commit 2      commit 3                     │
└─────────────────────────────────────────────────────────────┘

Die Spec-Kit-Artefakte werden zur Koordinationsschicht für Ralph Mode:

  • spec.md sagt jeder frischen KI-Instanz, was gebaut wird
  • plan.md sagt jeder frischen KI-Instanz, wie es gebaut werden soll
  • tasks.md sagt jeder frischen KI-Instanz, was als Nächstes zu tun ist
  • constitution.md sagt jeder frischen KI-Instanz, welche Regeln gelten

Jede Iteration kann genau den Kontext laden, den sie braucht – nicht mehr und nicht weniger.

Was diese Kombination besonders macht

1. Skalierbarkeit 20 Aufgaben oder 200 Aufgaben – der Ansatz funktioniert gleich. Kontext akkumuliert nie, weil jede Aufgabe unabhängig ist.

2. Zuverlässigkeit Kein kognitives Driften. Aufgabe 150 folgt denselben Mustern wie Aufgabe 1, weil beide aus derselben plan.md lesen.

3. Wiederherstellbarkeit Bei Aufgabe 47 unterbrochen? Einfach neu starten. Die Schleife liest tasks.md, findet die erste unvollständige Aufgabe und fährt fort.

4. Beobachtbarkeit Jede Aufgabe produziert einen Commit. Du kannst genau sehen, was sich wann und in welcher Reihenfolge geändert hat.

5. Steuerbarkeit Gefällt dir nicht, wie Aufgabe 23 implementiert wurde? Reverte den Commit, passe die Aufgabenbeschreibung an und starte neu. Die folgenden Aufgaben müssen nicht geändert werden.

6. Kosteneffizienz Frischer Kontext bedeutet kleinere Prompts. Du zahlst keine Token für angesammelten Ballast. Jede Iteration nutzt nur die Token, die sie braucht.

Der philosophische Wandel

Traditionelle KI-Entwicklung behandelt die KI als Mitarbeiter – du führst ein Gespräch, baust gemeinsames Verständnis auf und arbeitest über die Zeit zusammen.

Spec Kit + Ralph Mode behandelt die KI als Auftragnehmer – du lieferst detaillierte Spezifikationen, klare Aufgabendefinitionen und Qualitätskriterien. Die KI führt aus. Dann kommt ein neuer Auftragnehmer für die nächste Aufgabe mit denselben Spezifikationen.

Dieser Wandel hat tiefgreifende Auswirkungen:

  • Investition in Specs zahlt sich aus: Jede Minute, die in die Klärung der spec.md investiert wird, spart Stunden an Debugging wegen Kontextverwirrung
  • Aufgaben müssen eigenständig sein: Wenn eine Aufgabe das Verständnis der Implementierung von Aufgabe N-1 erfordert, ist sie zu stark gekoppelt
  • Quality Gates sind unverhandelbar: Der Auftragnehmer kann nicht erklären, „warum das eigentlich in Ordnung ist” – die Tests bestehen oder nicht

Teil 5: Meine Implementierung

Nachdem ich verstanden hatte, warum diese Kombination sinnvoll ist, habe ich eine konkrete Implementierung für meine Projekte gebaut. So funktioniert sie.

Das Prompt-Template

Das Herzstück des Systems ist ein minimales Prompt-Template (.specify/.ralph-prompt.template.md), das jede Iteration erhält:

# Ralph Build Mode - Spec Kit Integration

Execute **one task** from tasks.md per iteration. Each iteration runs with FRESH CONTEXT.

> **Note:** Batching happens at planning time via composite tasks in tasks.md, not at runtime.

## Phase 0: Orient

0a. **Read tasks.md** - Find the first incomplete task (`- [ ]`)

0b. **Determine task complexity:**

| Task Type | Context Loading |
|-----------|-----------------|
| Config/scaffolding | Skip architecture deep-dive, just implement |
| Feature work | Read relevant spec.md section + related source files |
| Complex logic | Full architecture review (spec.md, plan.md, constitution.md) |

0c. **Verify not already done** - Search codebase for existing implementation

## Phase 1: Implement

1. Implement the task completely
2. Keep changes minimal and focused
3. Use existing utilities rather than creating new abstractions

## Phase 2: Validate (Backpressure)

Run quality gates - **MUST pass before proceeding:**

{QUALITY_GATES}

If validation fails:
- Fix immediately
- Re-run validation
- Do NOT mark complete until gates pass

## Phase 3: Update & Commit

1. Mark task `- [x]` in tasks.md
2. Commit and push:
   ```bash
   git add -A && git commit -m "feat: [task summary]"
   git push origin $(git branch --show-current)
   ```
3. Exit - you will restart with fresh context

## Phase 4: Completion Check

When NO incomplete tasks remain (no `- [ ]` in tasks.md):

<promise>ALL_TASKS_COMPLETE</promise>

## Guardrails

| # | Rule |
|---|------|
| 999 | **One task per iteration** - Exit after completing one task |
| 998 | **Tests MUST pass** - Never proceed with failing code |
| 997 | **Verify not implemented** - Search codebase before implementing |
| 996 | **Follow existing patterns** - Match codebase conventions |
| 995 | **Exit on complexity** - If unexpectedly hard, finish and exit |
| 994 | **Mark complete immediately** - Update tasks.md right after validation |
| 993 | **Subagent discipline** - Up to 500 Sonnet for reads, only 1 for build/tests |

## File Paths

- Tasks: `{FEATURE_DIR}/tasks.md`
- Spec: `{FEATURE_DIR}/spec.md`
- Plan: `{FEATURE_DIR}/plan.md`
- Constitution: `.specify/memory/constitution.md`

Das ist das vollständige Prompt-Template. Es ist bewusst minimal gehalten mit ca. 70 Zeilen. Zentrale Designentscheidungen:

Schlankes Context Loading: Die Komplexitätstabelle sagt der KI, dass sie nicht alles für einfache Aufgaben lesen muss. Das Hinzufügen einer .gitignore erfordert nicht das Lesen der Authentifizierungs-Spec.

Explizite Exit-Anweisung: Die KI muss nach einer Aufgabe beenden. Ohne das könnte sie versuchen weiterzumachen und Kontext zu akkumulieren.

Quality Gates als Platzhalter: {QUALITY_GATES} wird zur Laufzeit mit projektspezifischen Befehlen ersetzt.

Nummerierte Guardrails: Kritische Regeln bekommen Nummern (999, 998 usw.), damit sie leicht zu referenzieren und schwer zu übersehen sind.

Die Bash-Orchestrierungsschleife

Das Bash-Skript (ralph-loop.sh) verwaltet den Iterationszyklus:

#!/bin/bash
# Ralph Loop - True fresh context per iteration
# Usage: ./ralph-loop.sh <prompt-file> [max-iterations] [tasks-file]

set -uo pipefail

PROMPT_FILE="${1:-.specify/.ralph-prompt.md}"
MAX_ITERATIONS="${2:-50}"
TASKS_FILE="${3:-}"
ITERATION=0
LOG_DIR=".specify/logs"
LOG_FILE="$LOG_DIR/ralph-$(date '+%Y%m%d-%H%M%S').log"
LATEST_LOG="$LOG_DIR/ralph-latest.log"
STATE_FILE=".specify/.ralph-state"
CONSECUTIVE_FAILURES=0
MAX_CONSECUTIVE_FAILURES=3

# Colors
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
CYAN='\033[0;36m'
MAGENTA='\033[0;35m'
DIM='\033[2m'
BOLD='\033[1m'
NC='\033[0m'

# Ensure log directory exists
mkdir -p "$LOG_DIR"

# Logging functions
log() {
    local level="$1"
    local message="$2"
    local timestamp=$(date '+%Y-%m-%d %H:%M:%S')
    echo "[$timestamp] [$level] $message" >> "$LOG_FILE"
}

log_section() {
    echo "" >> "$LOG_FILE"
    echo "═══════════════════════════════════════════════════════════════" >> "$LOG_FILE"
    echo "$1" >> "$LOG_FILE"
    echo "═══════════════════════════════════════════════════════════════" >> "$LOG_FILE"
}

# Get current task from tasks.md
get_current_task() {
    if [[ -n "$TASKS_FILE" ]] && [[ -f "$TASKS_FILE" ]]; then
        grep -m1 '^\s*- \[ \]' "$TASKS_FILE" 2>/dev/null | sed 's/^\s*- \[ \] //' | head -c 60
    fi
}

# Get last git commit info
get_last_commit() {
    git log -1 --format='%h %s' 2>/dev/null | head -c 70
}

# Calculate progress bar
progress_bar() {
    local complete=$1
    local total=$2
    local width=30
    if [[ $total -eq 0 ]]; then
        printf "[%${width}s]" ""
        return
    fi
    local filled=$((complete * width / total))
    local empty=$((width - filled))
    printf "[%s%s]" "$(printf '█%.0s' $(seq 1 $filled 2>/dev/null) || echo "")" "$(printf '░%.0s' $(seq 1 $empty 2>/dev/null) || echo "")"
}

# Graceful exit on Ctrl+C
cleanup() {
    local end_time=$(date +%s)
    local duration=$((end_time - START_TIME))

    echo ""
    echo -e "${YELLOW}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"
    echo -e "${YELLOW}  Loop interrupted after $ITERATION iterations${NC}"
    echo -e "${YELLOW}  Duration: $((duration / 60))m $((duration % 60))s${NC}"
    echo -e "${YELLOW}  Work is safely committed - resume with /speckit.ralph.implement${NC}"
    echo -e "${YELLOW}  Log: $LOG_FILE${NC}"
    echo -e "${YELLOW}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"

    log "INFO" "Interrupted after $ITERATION iterations (duration: ${duration}s)"
    rm -f ".specify/.ralph-prev-output" "$STATE_FILE"
    exit 130
}
trap cleanup SIGINT SIGTERM

# Start time tracking
START_TIME=$(date +%s)

# Header
echo -e "${BLUE}╔════════════════════════════════════════════════════════════╗${NC}"
echo -e "${BLUE}║${NC}  ${BOLD}Ralph Loop${NC} - Fresh Context Per Iteration                  ${BLUE}║${NC}"
echo -e "${BLUE}╠════════════════════════════════════════════════════════════╣${NC}"
echo -e "${BLUE}║${NC}  Prompt: ${DIM}${PROMPT_FILE}${NC}"
echo -e "${BLUE}║${NC}  Max iterations: ${MAX_ITERATIONS}"
if [[ -n "$TASKS_FILE" ]]; then
    echo -e "${BLUE}║${NC}  Tasks: ${DIM}${TASKS_FILE}${NC}"
fi
echo -e "${BLUE}║${NC}  Log: ${DIM}${LOG_FILE}${NC}"
echo -e "${BLUE}╚════════════════════════════════════════════════════════════╝${NC}"

# Verify prompt file exists
if [[ ! -f "$PROMPT_FILE" ]]; then
    echo -e "${RED}Error: Prompt file not found: $PROMPT_FILE${NC}"
    log "ERROR" "Prompt file not found: $PROMPT_FILE"
    exit 1
fi

# Initialize log
log_section "RALPH LOOP STARTED"
log "INFO" "Prompt: $PROMPT_FILE"
log "INFO" "Max iterations: $MAX_ITERATIONS"
log "INFO" "Tasks file: ${TASKS_FILE:-none}"

# Create symlink to latest log
ln -sf "$(basename "$LOG_FILE")" "$LATEST_LOG"

# Initial task count
if [[ -n "$TASKS_FILE" ]] && [[ -f "$TASKS_FILE" ]]; then
    INITIAL_INCOMPLETE=$(grep -c '^\s*- \[ \]' "$TASKS_FILE" 2>/dev/null) || INITIAL_INCOMPLETE=0
    INITIAL_COMPLETE=$(grep -c '^\s*- \[[Xx]\]' "$TASKS_FILE" 2>/dev/null) || INITIAL_COMPLETE=0
    TOTAL_TASKS=$((INITIAL_INCOMPLETE + INITIAL_COMPLETE))
    log "INFO" "Initial state: $INITIAL_COMPLETE/$TOTAL_TASKS complete"
fi

while [ $ITERATION -lt $MAX_ITERATIONS ]; do
    ITERATION=$((ITERATION + 1))
    ITER_START=$(date +%s)

    # Get current state
    CURRENT_TASK=$(get_current_task)
    if [[ -n "$TASKS_FILE" ]] && [[ -f "$TASKS_FILE" ]]; then
        INCOMPLETE=$(grep -c '^\s*- \[ \]' "$TASKS_FILE" 2>/dev/null) || INCOMPLETE=0
        COMPLETE=$(grep -c '^\s*- \[[Xx]\]' "$TASKS_FILE" 2>/dev/null) || COMPLETE=0
        TOTAL=$((INCOMPLETE + COMPLETE))
    fi

    echo ""
    echo -e "${CYAN}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"
    echo -e "${CYAN}  ITERATION ${BOLD}$ITERATION${NC}${CYAN} / $MAX_ITERATIONS  ${DIM}$(date '+%H:%M:%S')${NC}"
    echo -e "${CYAN}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"

    # Show progress
    if [[ -n "$TASKS_FILE" ]] && [[ -f "$TASKS_FILE" ]]; then
        PROGRESS_BAR=$(progress_bar "$COMPLETE" "$TOTAL")
        echo -e "  ${BLUE}Progress:${NC} $PROGRESS_BAR ${GREEN}$COMPLETE${NC}/${TOTAL} tasks"
    fi

    # Show current task
    if [[ -n "$CURRENT_TASK" ]]; then
        echo -e "  ${MAGENTA}Next task:${NC} ${CURRENT_TASK}..."
    fi

    echo ""

    # Log iteration start
    log_section "ITERATION $ITERATION"
    log "INFO" "Starting iteration $ITERATION"
    log "INFO" "Current task: ${CURRENT_TASK:-unknown}"
    log "INFO" "Progress: $COMPLETE/$TOTAL tasks complete"

    # Save state for resumption
    echo "ITERATION=$ITERATION" > "$STATE_FILE"
    echo "TASK=$CURRENT_TASK" >> "$STATE_FILE"

    # Run Claude with fresh context (new process each time)
    echo -e "  ${DIM}Running claude -p ...${NC}"

    ITER_OUTPUT=$(cat "$PROMPT_FILE" | claude -p \
        --dangerously-skip-permissions \
        --model sonnet \
        2>&1) || true

    ITER_END=$(date +%s)
    ITER_DURATION=$((ITER_END - ITER_START))

    # Log full output
    log "OUTPUT" "--- BEGIN CLAUDE OUTPUT ---"
    echo "$ITER_OUTPUT" >> "$LOG_FILE"
    log "OUTPUT" "--- END CLAUDE OUTPUT ---"

    # Display output
    echo "$ITER_OUTPUT"

    # Show iteration stats
    echo ""
    echo -e "  ${DIM}────────────────────────────────────────────────────────${NC}"
    echo -e "  ${DIM}Iteration completed in ${ITER_DURATION}s${NC}"

    # Check for git commit
    LAST_COMMIT=$(get_last_commit)
    if [[ -n "$LAST_COMMIT" ]]; then
        echo -e "  ${GREEN}Latest commit:${NC} ${DIM}$LAST_COMMIT${NC}"
        log "INFO" "Latest commit: $LAST_COMMIT"
    fi

    # Stuck detection: warn if output identical to previous
    STUCK=false
    if [[ -f ".specify/.ralph-prev-output" ]]; then
        if diff -q ".specify/.ralph-prev-output" <(echo "$ITER_OUTPUT") > /dev/null 2>&1; then
            STUCK=true
            CONSECUTIVE_FAILURES=$((CONSECUTIVE_FAILURES + 1))
            echo -e "  ${YELLOW}⚠️  Output identical to previous iteration (${CONSECUTIVE_FAILURES}/${MAX_CONSECUTIVE_FAILURES})${NC}"
            log "WARN" "Stuck detection: output identical to previous (consecutive: $CONSECUTIVE_FAILURES)"

            if [[ $CONSECUTIVE_FAILURES -ge $MAX_CONSECUTIVE_FAILURES ]]; then
                echo -e "  ${RED}❌ Stuck after $MAX_CONSECUTIVE_FAILURES identical outputs${NC}"
                echo -e "  ${YELLOW}   Suggestion: Ctrl+C and run /speckit.tasks to regenerate${NC}"
                log "ERROR" "Aborting: stuck after $MAX_CONSECUTIVE_FAILURES consecutive identical outputs"
                rm -f ".specify/.ralph-prev-output" "$STATE_FILE"
                exit 2
            fi
        else
            CONSECUTIVE_FAILURES=0
        fi
    fi
    echo "$ITER_OUTPUT" > ".specify/.ralph-prev-output"

    # Check for completion promise in output
    if echo "$ITER_OUTPUT" | grep -q "<promise>ALL_TASKS_COMPLETE</promise>"; then
        END_TIME=$(date +%s)
        TOTAL_DURATION=$((END_TIME - START_TIME))

        echo ""
        echo -e "${GREEN}╔════════════════════════════════════════════════════════════╗${NC}"
        echo -e "${GREEN}║  ✅ ALL TASKS COMPLETE                                     ║${NC}"
        echo -e "${GREEN}╠════════════════════════════════════════════════════════════╣${NC}"
        echo -e "${GREEN}║${NC}  Iterations: $ITERATION"
        echo -e "${GREEN}║${NC}  Duration: $((TOTAL_DURATION / 60))m $((TOTAL_DURATION % 60))s"
        echo -e "${GREEN}║${NC}  Log: ${DIM}$LOG_FILE${NC}"
        echo -e "${GREEN}╚════════════════════════════════════════════════════════════╝${NC}"

        log_section "COMPLETE"
        log "INFO" "All tasks complete after $ITERATION iterations"
        log "INFO" "Total duration: ${TOTAL_DURATION}s"

        rm -f ".specify/.ralph-prev-output" "$STATE_FILE"
        exit 0
    fi

    # Also check tasks.md directly if provided
    if [[ -n "$TASKS_FILE" ]] && [[ -f "$TASKS_FILE" ]]; then
        INCOMPLETE=$(grep -c '^\s*- \[ \]' "$TASKS_FILE" 2>/dev/null) || INCOMPLETE=0
        COMPLETE=$(grep -c '^\s*- \[[Xx]\]' "$TASKS_FILE" 2>/dev/null) || COMPLETE=0

        if [[ "$INCOMPLETE" -eq 0 ]] && [[ "$COMPLETE" -gt 0 ]]; then
            END_TIME=$(date +%s)
            TOTAL_DURATION=$((END_TIME - START_TIME))

            echo ""
            echo -e "${GREEN}╔════════════════════════════════════════════════════════════╗${NC}"
            echo -e "${GREEN}║  ✅ ALL TASKS COMPLETE (verified in tasks.md)             ║${NC}"
            echo -e "${GREEN}╠════════════════════════════════════════════════════════════╣${NC}"
            echo -e "${GREEN}║${NC}  Iterations: $ITERATION"
            echo -e "${GREEN}║${NC}  Duration: $((TOTAL_DURATION / 60))m $((TOTAL_DURATION % 60))s"
            echo -e "${GREEN}║${NC}  Log: ${DIM}$LOG_FILE${NC}"
            echo -e "${GREEN}╚════════════════════════════════════════════════════════════╝${NC}"

            log_section "COMPLETE"
            log "INFO" "All tasks complete (verified via tasks.md) after $ITERATION iterations"
            log "INFO" "Total duration: ${TOTAL_DURATION}s"

            rm -f ".specify/.ralph-prev-output" "$STATE_FILE"
            exit 0
        fi
    fi

    log "INFO" "Iteration $ITERATION completed in ${ITER_DURATION}s"
done

end_time=$(date +%s)
total_duration=$((end_time - START_TIME))

echo ""
echo -e "${YELLOW}╔════════════════════════════════════════════════════════════╗${NC}"
echo -e "${YELLOW}║  ⚠️  Max iterations ($MAX_ITERATIONS) reached              ║${NC}"
echo -e "${YELLOW}╠════════════════════════════════════════════════════════════╣${NC}"
echo -e "${YELLOW}║${NC}  Duration: $((total_duration / 60))m $((total_duration % 60))s"
echo -e "${YELLOW}║${NC}  Run /speckit.ralph.implement to continue"
echo -e "${YELLOW}║${NC}  Log: ${DIM}$LOG_FILE${NC}"
echo -e "${YELLOW}╚════════════════════════════════════════════════════════════╝${NC}"

log_section "MAX ITERATIONS REACHED"
log "WARN" "Max iterations ($MAX_ITERATIONS) reached"
log "INFO" "Total duration: ${total_duration}s"

rm -f ".specify/.ralph-prev-output" "$STATE_FILE"
exit 1

Zentrale Features:

Visueller Fortschritt: Ein Fortschrittsbalken und aktuelle Aufgabenanzeige, damit du den Stand überwachen kannst, ohne Logs zu lesen.

Zeitgestempelte Protokollierung: Jeder Lauf erstellt eine separate Log-Datei. Ein Symlink (ralph-latest.log) zeigt immer auf den aktuellen Lauf.

Stuck-Erkennung: Wenn drei aufeinanderfolgende Iterationen identische Ausgaben produzieren, stimmt etwas nicht. Die Schleife bricht mit einer hilfreichen Meldung ab.

Duale Abschlussprüfung: Prüft sowohl das explizite Promise der KI als auch den tatsächlichen Zustand der tasks.md.

Zeiterfassung: Die Dauer jeder Iteration wird für die Leistungsanalyse protokolliert.

Die Befehlsschnittstelle

Der benutzerseitige Befehl /speckit.ralph.implement bindet alles zusammen. Dies ist als Skill-Datei definiert (.specify/skills/speckit.ralph.implement.md):

### Step 1: Load Feature Context
Run prerequisite script to identify:
- FEATURE_DIR: Path to active feature (e.g., specs/002-backend-auth)
- Available documentation files

### Step 2: Analyze Tasks
1. Count incomplete tasks (`- [ ]` lines)
2. Count completed tasks (`- [x]` lines)
3. Exit early if nothing to do

### Step 3: Extract Quality Gates
Parse plan.md for tech stack, generate appropriate commands:
- Rust: `cargo clippy -- -D warnings && cargo test`
- TypeScript: `pnpm lint && pnpm tsc --noEmit`
- Python: `ruff check . && pytest`
- Go: `go vet ./... && go test ./...`

### Step 4: Generate Prompt
1. Read `.specify/.ralph-prompt.template.md`
2. Substitute `{FEATURE_DIR}` and `{QUALITY_GATES}`
3. Write to `.specify/.ralph-prompt.md`

### Step 5: Execute Loop
Calculate max iterations: `incomplete_tasks + 10`
Run: `ralph-loop.sh .ralph-prompt.md {MAX} {FEATURE_DIR}/tasks.md`

Die Trennung von Template und generierter Datei ist wichtig: .ralph-prompt.template.md ist versionskontrolliert und enthält Platzhalter. .ralph-prompt.md wird zur Laufzeit mit tatsächlichen Werten generiert und ist gitignored.

Umgang mit der Batching-Frage

Eine frühe Version versuchte, 3–5 zusammengehörige Aufgaben pro Iteration zu bündeln. Das scheiterte, weil:

  1. Laufzeit-Batching erfordert Urteilsvermögen: „Sind diese Aufgaben verwandt?” erfordert das Verständnis der Codebasis, was Kontext verbrennt, bevor die eigentliche Arbeit beginnt.

  2. Teilweise Fehler sind mehrdeutig: Wenn die KI 2 von 4 gebündelten Aufgaben vor einem Fehler abschließt – welche zwei? Der Zustand wird unklar.

  3. Kontext akkumuliert trotzdem: Selbst 3 Aufgaben können erheblich Kontext füllen.

Die Lösung: Bündelung zur Planungszeit, nicht zur Laufzeit.

Anstatt fünf separate Aufgaben zu schreiben:

- [ ] Create .gitignore
- [ ] Create .editorconfig
- [ ] Create tsconfig.json
- [ ] Create eslint.config.js
- [ ] Create prettier.config.js

Schreibe eine zusammengesetzte Aufgabe:

- [ ] Set up project configuration (.gitignore, .editorconfig, tsconfig.json, eslint, prettier)

Die KI erledigt alle fünf Dateien, markiert eine Checkbox, committet, beendet. Deterministisches Batching, das während der Planung entschieden wird, statt probabilistisches Batching zur Laufzeit.

Diese Erkenntnis kam aus dem Feedback, dass die Batching-Heuristiken „gegen Claudes natürlichen Instinkt kämpfen, zusammengehörige Arbeit zu bündeln.” Anstatt die KI zur Laufzeit einzuschränken, schränken wir die Aufgabengranularität zur Planungszeit ein.

Um sicherzustellen, dass Spec Kit angemessen große zusammengesetzte Aufgaben generiert, füge diese Richtlinien zu deinem /speckit.tasks-Befehl oder deiner constitution.md hinzu:

## Task Granularity Guidelines

- Batch related config/setup into single composite tasks (e.g., "Set up linting and formatting (eslint, prettier, .editorconfig)" not 3 separate tasks)
- Target tasks that take 5-15 minutes to implement
- Group related CRUD/boilerplate operations together
- Keep distinct features as separate tasks

Dateien und Gitignore

Das System generiert mehrere Dateien, die nicht committet werden sollten:

# Spec Kit (generated at runtime)
.specify/.ralph-prompt.md      # Generated from template
.specify/.ralph-prev-output    # Stuck detection state
.specify/.ralph-state          # Resumption state
.specify/logs/                 # All log files

Das Template (.ralph-prompt.template.md) WIRD committet – es ist Teil der Entwicklungsinfrastruktur des Projekts.

Teil 6: Ergebnisse und gewonnene Erkenntnisse

Praxisleistung

Bei einem kürzlichen Feature mit über 100 Aufgaben (Authentifizierung mit Azure AD, Session-Management, RBAC und vollständige Testabdeckung):

MetrikEinzelsitzungRalph Loop
Aufgaben vor Degradation~15100+
KontextverschmutzungsproblemeHäufigKeine
Manuelle EingriffeAlle 10–15 AufgabenNur bei festgefahrenen Aufgaben
ImplementierungszeitN/A (abgebrochen)~4 Stunden
Commit-HistorieUnübersichtlichSauber, atomar

Der Unterschied ist nicht subtil. Einzelsitzungs-Entwicklung wird zu einem Kampf gegen Kontexterschöpfung. Ralph-Loop-Entwicklung ist fast langweilig – du schaust zu, wie Aufgaben eine nach der anderen abgeschlossen werden, jede so sauber wie die erste.

Was ich gelernt habe

1. Prompt-Größe ist wichtiger als du denkst

Frühe Versionen hatten Prompts mit über 200 Zeilen, die jeden Randfall abdecken sollten. Das Kürzen auf ca. 70 Zeilen verbesserte die Zuverlässigkeit. Jedes Token im Prompt ist ein Token, das nicht für die eigentliche Arbeit zur Verfügung steht.

2. Quality Gates sind unverhandelbar

Ohne Quality Gates kaskadieren Fehler. Aufgabe 5 führt einen Bug ein, Aufgabe 6 baut darauf auf, Aufgabe 7 baut darauf auf. Bei Aufgabe 10 hast du ein Chaos, das kein frischer Kontext mehr reparieren kann.

Mit Quality Gates werden Fehler eingedämmt. Der Bug von Aufgabe 5 muss in der Iteration von Aufgabe 5 behoben werden, bevor die Aufgabe als abgeschlossen markiert wird.

3. Aufgabengranularität ist eine Kunst

Zu granular: „Erstelle die Users-Tabelle” / „Füge die Email-Spalte hinzu” / „Füge die password_hash-Spalte hinzu” – drei Iterationen für eine logische Änderung.

Zu grob: „Implementiere das gesamte Authentifizierungssystem” – Kontexterschöpfung innerhalb der Aufgabe.

Der Sweet Spot: Aufgaben, die 5–15 Minuten für die KI zum Abschließen brauchen. Komplex genug, um bedeutsam zu sein, einfach genug, um in frischen Kontext zu passen.

4. Stuck-Erkennung spart Stunden

Ohne Stuck-Erkennung könnte die Schleife 50 Iterationen lang identische Ausgaben produzieren, während du nicht zuschaust. Die Drei-Treffer-Erkennung fängt das schnell ab.

5. Logs sind unverzichtbar fürs Debugging

Wenn etwas schiefgeht, sind die zeitgestempelten Log-Dateien von unschätzbarem Wert. Du kannst genau sehen, was die KI versucht hat, was fehlgeschlagen ist und warum.

6. TDD mit Unit- UND E2E-Tests durchsetzen

Unit-Tests allein reichen nicht aus. KI kann Code schreiben, der isolierte Unit-Tests besteht, aber die Integration bricht – sie versteht nicht richtig, wie Komponenten zusammenwirken, besonders mit frischem Kontext pro Aufgabe, wo sie nicht „sehen” kann, was vorherige Aufgaben implementiert haben.

Die Lösung: Erzwinge sowohl Unit- als auch E2E-Tests und schreibe TDD (Test-Driven Development) vor. Spezifiziere in deiner constitution.md:

## Testing Requirements

- Follow TDD: Write tests FIRST (RED), then implement (GREEN)
- Every feature task must include unit tests for isolated logic
- Every user-facing flow must have e2e test coverage
- Quality gates must run both: `npm test && npm run test:e2e`

Der RED/GREEN-Zyklus ist entscheidend. Wenn die KI den Test zuerst schreibt, erzwingt das Klarheit darüber, was „fertig” bedeutet, bevor die Implementierung beginnt. Der Test wird zu einem Vertrag, der erfüllt werden muss – nicht zu einem nachträglichen Gedanken, der an den geschriebenen Code angepasst wird.

E2E-Tests fangen die Integrationslücken auf, die frischer Kontext erzeugt. Aufgabe 12 könnte einen API-Endpunkt perfekt isoliert implementieren, aber der Frontend-Code von Aufgabe 15 ruft ihn möglicherweise falsch auf. Ohne E2E-Tests erfährst du das erst bei manuellen Tests.

Wann man das verwenden sollte

Gut geeignet:

  • Features mit mehr als 20 Aufgaben
  • Mehrstündige oder über Nacht laufende Implementierungen
  • Teams, die CI-ähnliche automatisierte Entwicklung wollen
  • Projekte mit guter Testabdeckung (Quality Gates brauchen Tests)

Übertrieben für:

  • Schnelle Bugfixes
  • Einzeldateiänderungen
  • Features unter 10 Aufgaben
  • Explorative oder experimentelle Arbeit

Für kleinere Arbeiten führt der Standard-/speckit.implement alles in einer Sitzung aus. Der Overhead von Ralph Loop ist nicht gerechtfertigt, wenn Kontexterschöpfung kein Problem ist.

Teil 7: Zukünftige Richtungen

Mehrere Verbesserungen stehen auf der Roadmap:

Pattern Caching: Entdeckte Codebasis-Muster in einer leichtgewichtigen Datei speichern. Nachfolgende Iterationen lesen dies statt die Codebasis erneut zu durchsuchen. ~20 Token statt ~2000 Token an grep-Ergebnissen.

Parallele Ausführung: Für wirklich unabhängige Aufgaben mehrere Claude-Instanzen gleichzeitig ausführen. Aufgabe 10 (Frontend-Komponente) und Aufgabe 11 (Backend-Endpunkt) kollidieren nicht.

Intelligentere Wiederaufnahme: Derzeit geht bei einer Unterbrechung der Zustand der laufenden Aufgabe verloren. Bessere Zustandsverfolgung könnte mitten in einer Aufgabe fortsetzen.

Kostenstufen: Haiku für einfache Aufgaben (Konfigurationsdateien), Sonnet für komplexe Aufgaben (Business-Logik) verwenden. Derzeit verwendet alles Sonnet.

Metriken-Dashboard: Log-Daten in Visualisierungen aggregieren: Aufgaben pro Stunde, durchschnittliche Iterationszeit, Stuck-Häufigkeit.

Fazit

Die Kombination von Spec Kit und Ralph Loop löst ein reales Problem: Kontexterschöpfung macht KI-gestützte Entwicklung für große Features unzuverlässig. Durch die Trennung von Planung (Spec Kit) und Ausführung (Ralph Loop) und durch das Annehmen frischen Kontexts statt dagegen anzukämpfen, bekommen wir ein System, das skaliert.

Die zentralen Erkenntnisse:

  1. Explizite Artefakte schlagen implizites Verständnis – Schreibe Dinge in spec.md und plan.md auf
  2. Frischer Kontext schlägt akkumulierten Kontext – Jede Aufgabe bekommt volle kognitive Ressourcen
  3. Quality Gates schlagen Vertrauen – Tests bestehen oder die Aufgabe ist nicht erledigt
  4. Planungszeit-Batching schlägt Laufzeit-Batching – Entscheide die Aufgabengranularität im Voraus
  5. Minimale Prompts schlagen umfassende Prompts – Jedes Token zählt

Wenn du Features mit über 50 Aufgaben baust oder jemals eine KI-Entwicklungssitzung abgebrochen hast, weil die KI „vergessen” hat, was ihr gerade macht, könnte dieser Ansatz deine Arbeitsweise verändern.

Der Code ist im Spec Kit Plugin für Claude Code verfügbar. Die Investition in die Einrichtung zahlt sich beim ersten großen Feature aus.

Kurzreferenz

# 1. Create feature specification
/speckit.specify

# 2. Generate implementation plan
/speckit.plan

# 3. Generate task breakdown
/speckit.tasks

# 4. Run Ralph Loop (for large features)
/speckit.ralph.implement

# Monitor progress
tail -f .specify/logs/ralph-latest.log

# View task status
grep -E '^\s*- \[' specs/*/tasks.md

Jede abgeschlossene Aufgabe ist ein Commit. Jeder Commit ist ein Checkpoint. Jeder Checkpoint ist wiederherstellbar. Das ist die Stärke davon, KI-Amnesie als Feature zu behandeln.

Geschrieben von Dominic Böttger

← Zurück zum Blog

Aktuelle Blogbeiträge

zum Blog