Claude Fable 5 Kleinstprojekt:Von der Anforderung bis zum Release – was die KI übernommen hat

Kurz gesagt: Mit Claude Fable 5 haben wir von null ein CLI namens pulsecheck gebaut — es prüft eine Liste von URLs und APIs parallel auf Erreichbarkeit, schreibt einen JSON-Report und liefert Exit-Codes für Cron oder Alerting. Der Artikel hat zwei Teile: Zuerst erklären wir, welches Problem das Tool löst und wie das fertige Ergebnis aussieht (inklusive Screenshot). Danach gehen wir in sieben Schritten durch, welchen Code Claude Code geschrieben hat und wo Sie als Engineer eingreifen müssen. Wer nur den Nutzen sehen will, liest bis zum Screenshot; wer selbst bauen will, startet bei Schritt 1.

Anwendungsfälle: drei reale Szenarien

Vergessen Sie kurz Go, YAML und JSON — das Tool beantwortet eine einfache Frage: Leben meine Dienste noch? Drei Situationen, in denen wir es gebaut haben:

• Geplante Inspektion — Sie haben 5 bis 20 Health-Check-URLs (Payment-Callbacks, öffentliche APIs, interne Gateways). Früher: Shell-Schleife mit for url in ...; do curl ..., schwer wartbar, kein einheitlicher Report. pulsecheck liest eine Config, liefert strukturiertes JSON, Cron dranhängen.
• Vor Deploy oder Rufbereitschaft — Ein Befehl vor dem Release: ./pulsecheck -config prod.yaml -o /tmp/pre-deploy.json. Exit-Code 0: weiter deployen. Exit-Code 1: erst fixen.
• Leichtgewicht-Probe fürs Alerting — Ohne Prometheus-Gesamtpaket reicht oft der Exit-Code: Bei 1 Webhook oder Mail-Skript anstoßen. Das JSON bleibt für die Post-Mortem-Analyse.

Was es nicht tut: Historische Trends, SMS-Paging, Multi-Tenant-UI — das gehört zu Datadog oder Cloud-Monitoring. pulsecheck kümmert sich nur um diesen Moment: Sind diese URLs erreichbar?

Screenshot des fertigen Tools

So sieht pulsecheck nach Abschluss aller Schritte im Mac-Terminal aus: Config einlesen, URLs prüfen, JSON schreiben — ein Endpoint liefert 503, daher Exit-Code 1.

Lokal reproduzieren Sie das mit drei Befehlen:

./pulsecheck -config config.example.yaml -o report.json
echo $?          # 1 = mindestens ein Ziel ungesund
cat report.json   # Report ansehen

Input / Output / Technik

Nach dem Nutzenbild folgt die technische Einordnung: Stellen Sie sich Batch-curl plus zusammengefasster Report vor — als kompilierbares CLI für Cron und Skripte.

Sie pflegen nur die YAML mit den Ziel-URLs; Prüfung und Aggregation übernimmt pulsecheck. Beispiel:

targets:
  - https://api.example.com/health
  - https://status.example.com/ping

Das fertige Repo umfasst etwa 400 Zeilen Go in folgender Struktur:

pulsecheck/
├── cmd/pulsecheck/main.go      # Einstieg: -config -o
├── internal/checker/checker.go # HTTP, Latenz messen
├── internal/config/config.go   # YAML parsen
├── config.example.yaml
├── Makefile · README.md
└── .github/workflows/ci.yml

Zweiter Teil: Was die KI in sieben Schritten schrieb

Bis hier sollte klar sein, was pulsecheck ist und wofür es taugt. Ab jetzt der Build-Report: Mit Claude Fable 5 und Claude Code vom leeren Ordner bis zum v0.1.0-Tag — welche Dateien die KI erzeugt hat und wo menschliche Entscheidungen nicht wegfallen.

Die Rollenverteilung in einem Satz: Die KI schreibt Code und Tests; Sie legen Scope fest, reviewen und geben das Release frei. Alle sieben Schritte lassen sich mit den Prompts unten nachbauen; als Modell reicht Fable 5 in Claude Code (Opus ist für dieses Kleinstprojekt Overkill — siehe Tier-Vergleich).

Voraussetzungen

• Go 1.22+ — mit go version prüfen
• Claude Code CLI — Modell Claude Fable 5 (für tägliche Agent-Schleifen ausreichend, siehe Modellvergleich)
• Leeres Verzeichnis — mkdir pulsecheck && cd pulsecheck && git init
• (Optional) GitHub-Remote — für Schritt 6 mit CI; lokaler Durchlauf ohne Remote möglich

Schritt 1: Repo anlegen, Anforderung schreiben

Ihre Aufgabe: Den Pain Point in drei Sätzen festhalten und als SPEC.md dokumentieren. Die KI darf ausformulieren — Nicht-Ziele müssen Sie selbst kürzen, sonst landen Web-UI und Datenbank im Scope.

Lies die Anforderung und erstelle einen SPEC.md-Entwurf. Keine Features außerhalb der Liste:

- Tool-Name pulsecheck, Go-1.22-CLI
- YAML mit URL-Liste einlesen, parallele HTTP-GETs
- JSON-Report nach -o Pfad schreiben
- Felder: url, status_code, latency_ms, ok
- Default-Timeout 5s, überschreibbar via PULSECHECK_TIMEOUT
- Exit-Codes: 0 alles ok, 1 Fehler, 2 Config-Fehler
- Nicht-Ziele: kein GUI, keine DB, kein Docker, kein Alert-Versand

KI liefert: SPEC.md. Sie prüfen: Keine Scope-Erweiterung; Abnahmebefehl go test ./... in der Spec erwähnt.

Abnahme: cat SPEC.md — Abschnitte „Muss“, „Nicht-Ziele“ und „Exit-Codes“ vollständig.

Schritt 2: Projektgerüst aufsetzen

Ihre Aufgabe: Die KI soll nur das Gerüst bauen, keine Fachlogik. Fable 5 übernimmt diesen Schritt fast vollständig.

Lies SPEC.md und initialisiere das Go-Modul github.com/you/pulsecheck.
Nur Gerüst, Business-Logik als Stub:
- cmd/pulsecheck/main.go mit -config und -o
- internal/config für YAML
- internal/checker als leere Implementierung
- Makefile: test, lint, build
- .github/workflows/ci.yml als Platzhalter
go build ./... muss durchlaufen, keine echte HTTP-Logik.

KI liefert: Die acht Dateien aus dem Verzeichnisbaum oben. Dauer im Test: etwa 6 Minuten.

Abnahme:

go build ./...
./pulsecheck -h   # Hilfe anzeigen

Schritt 3: Probe-Logik und Tests schreiben

Ihre Aufgabe: Tests zuerst, dann Implementierung verlangen. Das ist der schwierigste Schritt — die KI führt go test selbst aus, fixiert Fehler und iteriert bis grün.

In internal/checker:
1. Zuerst checker_test.go mit httptest für 200, 500, Timeout
2. Dann checker.go: HTTP GET, status_code und latency_ms erfassen
3. go test ./... wiederholen bis alles grün
4. main.go: config → checker → JSON nach -o schreiben

KI liefert: Die Kern-Probe-Logik. Vereinfachter Auszug:

func CheckURL(ctx context.Context, client *http.Client, url string) Result {
    start := time.Now()
    req, _ := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    resp, err := client.Do(req)
    if err != nil {
        return Result{URL: url, OK: false, LatencyMs: time.Since(start).Milliseconds()}
    }
    defer resp.Body.Close()
    ok := resp.StatusCode >= 200 && resp.StatusCode < 300
    return Result{
        URL: url, StatusCode: resp.StatusCode,
        LatencyMs: time.Since(start).Milliseconds(), OK: ok,
    }
}

Im Testlauf brauchte Fable 5 drei Runden go test: In Runde 2 wurde der Bug „Timeout nicht an HTTP-Client übergeben“ ohne menschlichen Eingriff behoben.

Abnahme:

go test ./... -v   # 12 Tabellentests grün

Schritt 4: Review und Nachbesserung

Ihre Aufgabe: Als Reviewer eine Liste zurückgeben, die die KI abarbeitet — nicht selbst patchen, wenn Sie testen wollen, ob Feedback-Schleifen funktionieren.

Setze diese Review-Punkte um; go test ./... muss danach grün bleiben:
1. JSON-Feld latency → latency_ms laut SPEC
2. Mehrere URLs per Worker-Pool, max. 10 parallel
3. stdout nur Pfad-Hinweis auf JSON; Warn-Logs nach stderr

KI liefert: Worker-Pool, Feldumbenennung, Log-Trennung. Sie entscheiden: Ob diese drei Punkte wirklich nötig sind — das ersetzt kein Modell.

Abnahme: go test ./... grün; manuell ein, zwei URLs prüfen und JSON-Feldnamen verifizieren.

Schritt 5: Config und README

Ihre Aufgabe: Dokumentation und Beispiel-Config, die Ops direkt kopieren kann.

Erstelle config.example.yaml und README.md:
- Installation: go install oder go build
- Nutzungsbeispiele, Exit-Code-Tabelle (0/1/2)
- Cron-Beispiel alle 5 Minuten mit Log-Append
- Keine erfundenen Subcommands

KI liefert:

targets:
  - https://api.example.com/health
  - https://status.example.com/ping

Abnahme: URLs in der Example-Config durch erreichbare Endpunkte ersetzen und die Befehle aus „Screenshot des fertigen Tools“ durchlaufen — report.json mit allen Feldern.

Schritt 6: GitHub Actions anbinden

Ihre Aufgabe: Auf GitHub pushen, CI vervollständigen lassen und bei Rot die KI die Logs lesen lassen.

Vervollständige .github/workflows/ci.yml:
- go test -race ./...
- golangci-lint run
- Go 1.22
Bei Lint-Fehler: Log lesen, fixen, erneut committen.

Beim ersten Lauf meldete lint einen unused import — Fable 5 las das CI-Log und entfernte ihn selbst. Auf einem 16-GB-Mac kann -race ins Swap laufen; dann race auf einen GitHub Runner oder Cloud-Mac-Knoten verlagern — dieselbe Denke wie bei der Claude-Code-Ausführungsumgebung.

Abnahme: CI auf GitHub komplett grün.

Schritt 7: Abnahme und Release-Tag

Ihre Aufgabe: Der letzte Schritt ist bewusst manuell — Smoke-Test und Tag. CHANGELOG-Entwurf darf die KI schreiben; die Freigabe liegt bei Ihnen.

go test ./...
make build
./pulsecheck -config config.example.yaml -o /tmp/report.json
cat /tmp/report.json | jq .
git add -A && git commit -m "feat: pulsecheck v0.1.0"
git tag -a v0.1.0 -m "first release: YAML-driven HTTP health probe"
git push && git push --tags

Ab hier gilt pulsecheck als von der Anforderung bis zum Release fertig: ein cron-taugliches CLI mit Monitoring-Hook — in etwa 52 Minuten End-to-End.

Schritt-für-Schritt: KI vs. Mensch

Rückblick auf die sieben Phasen — so verteilt sich die Arbeit:

Rund 78 % der codierbaren Artefakte kamen von der KI. Scope-Schere, Review-Urteil und Release-Freigabe bleiben menschlich — unabhängig vom Modell.

Entscheidungsmatrix

Empfohlene Kombinationen

• Solo-Entwickler — Fable 5 für Schritte 2–6; Cursor Tab für Feinschliff vor dem Tag; Opus nur für externe Services.
• Kleines Team — Repo-Template mit Sieben-Schritte-Checkliste; neue Tools kopieren den pulsecheck-Flow; Agent an Claude-Code-Produktions-Workflow hängen.
• Token sparen — Spec-Glättung und CHANGELOG mit Gemini Flash; Coding-Schleife weiter mit Fable 5; Routing siehe OpenRouter-Preisstruktur.

Mit MCP ergänzen: MCP holt Issue- und Monitoring-Kontext, Fable 5 ändert das Repo — Schritt 7 (Release-Freigabe) bleibt manuell.

Typische Fehler

• Fehler 1: Ohne klares Projektziel starten — Die KI liefert generische Architektur; erst ein Satz wie „pulsecheck für URL-Batch-Check“.
• Fehler 2: In Schritt 2 schon Fachlogik verlangen — Gerüst und Implementierung vermischen erschwert Tests.
• Fehler 3: Schritt 4 Review überspringen — JSON-Feldnamen und stdout-Verschmutzung rutschen ins Release.
• Fehler 4: Tag ohne Schritt 7 — Ohne Smoke-Test ist es kein Release.
• Fehler 5: race + Agent parallel auf 16 GB — Langsamkeit ist RAM, nicht Modell; CI auf Runner oder Cloud Mac.

FAQ

Welches Problem löst pulsecheck?

Die Frage „Sind diese URLs gerade erreichbar?“ — ohne handgeschriebene Shell-Schleifen und ohne schweres Monitoring. Passend für Side Projects, kleine Teams oder Pre-Deploy-Checks.

Unterschied zu UptimeRobot oder Prometheus?

pulsecheck ist ein leichtes CLI auf Ihrer Maschine, Config in Ihrer Hand, kein SaaS-Zwang. UptimeRobot und Prometheus sind vollwertige Monitoring-Stacks — mehr Features, höhere Kosten. Hier geht es um genug für den Job, Code unter Ihrer Kontrolle.

Kann ich einfach ein Repo klonen?

Dieser Text ist ein Praxisbericht mit reproduzierbaren Prompts. Mit den sieben Schritten bauen Sie eine äquivalente Implementierung — Zeile-für-Zeile-Gleichheit ist nicht das Ziel.

In welchem Schritt leistet die KI am meisten?

Schritt 3 (Tests + Implementierung) und Schritt 2 (Gerüst) fast vollständig durch Fable 5; Schritt 1 und Schritt 7 am meisten menschlich.

Was ist der Unterschied zu Cursor Tab?

Tab eignet sich für Einzeldatei-Edits; ein ganzes Projekt braucht Claude Code mit Multi-File und Testläufen. Siehe Copilot vs. Cursor im Praxistest.

Fazit

Ergebnis: pulsecheck — YAML mit URLs einlesen, Batch-Check, report.json schreiben (Screenshot oben). Prozess: Mit Claude Fable 5 in sieben Schritten vom leeren Ordner bis v0.1.0; die KI schrieb den Großteil von Go-Code und Tests, Menschen trugen Scope, Review und Release bei. Wer nur bewerten will, ob KI Kleinstprojekte stemmt, liest Screenshot und Input/Output-Tabelle; wer nachbauen will, kopiert den Prompt aus Schritt 1.