Höre auf, Token zu verschwenden: die Claude Code + OpenClaw Entwicklungsschleife

Eine ernsthafte Entwicklungssitzung in OpenClaw — einen Backend-Service bauen, Integrationen debuggen, an einer API iterieren — kann 50 bis 100+ € an Sonnet-Tokens verbrennen, bevor du zur Hälfte fertig bist. Nicht weil irgendetwas kaputt ist. OpenClaw pflegt den Workspace-Zustand, lädt Context aggressiv, führt Reasoning-Schleifen aus und macht bei jedem Schritt Tool-Calls. Genau das macht Orchestrierung effektiv. Es macht das Schreiben von CRUD-Endpoints aber auch absurd teuer.

Die eigentliche Ursache: OpenClaw ist für System-Level-Reasoning gebaut. Es für Unit-Tests zu verwenden ist wie einen Drehmomentschlüssel zum Nägeleinschlagen zu benutzen.

Orchestrierung und Coding trennen

Teile die Arbeit auf zwei Tools auf:

Claude Code läuft auf einem Flat-Abo — ungefähr 17 €/Monat. Umfangreiche Coding-Arbeit bleibt innerhalb dieser Fixkosten. OpenClaw berührt das Projekt nur, wenn du System-Level-Reasoning brauchst: Architektur entwerfen, Integrationen validieren, Edge Cases über Komponenten hinweg identifizieren.

Ich habe Kosteneinsparungen von bis zu 80 % bei Projekten gesehen, die sonst reine Sonnet-Sitzungen gewesen wären.

Git als Schnittstelle zwischen Agents

Git wird zum Vertrag zwischen den beiden Umgebungen. OpenClaw committet Architekturentscheidungen. Claude Code committet Implementierungen. Keiner muss wissen, was der andere intern getan hat — sie lesen den aktuellen Zustand des Repositorys und arbeiten von dort aus.

Eine saubere Repo-Struktur ist wichtig:

repo/
 ├─ src/
 ├─ tests/
 ├─ docs/
 ├─ requirements.md
 ├─ architecture.md
 └─ README.md

Die requirements.md-Datei ist die Single Source of Truth — die Spezifikation, die Claude Code liest, um zu verstehen, was gebaut werden soll, und die OpenClaw aktualisiert, wenn sich der Scope ändert. Behandle sie wie einen Vertrag, nicht wie einen groben Entwurf.

Committe bei jeder Übergabe. Das gibt dir eine reproduzierbare History und einfache Rollbacks, falls ein Reasoning-Durchlauf schiefgeht.

OpenClaw entwirft das Framework

Starte in OpenClaw, aber verwende für diese Phase ein günstiges Reasoning-Modell wie DeepSeek Chat. Du brauchst kein Sonnet, um Architektur zu skizzieren.

Das Ziel ist, Artefakte zu erzeugen, keinen Code:

• requirements.md — was das System können muss
• architecture.md — wie es strukturiert ist, welche Komponenten existieren
• Initiales Datei-Layout — leere Dateien oder Stubs, die die geplante Struktur zeigen
• API-Contracts — Endpoint-Signaturen, Request/Response-Formate, Error Codes
• Aufgabenliste — geordnete Implementierungsarbeit

Halte das eigentliche Coding minimal. OpenClaw definiert das Grundgerüst, füllt es aber nicht aus. Ein paar Zeilen Boilerplate pro Datei sind okay. Vollständige Implementierungen nicht.

Sobald das Grundgerüst steht:

git init
git add .
git commit -m "Initial architecture and requirements"
git push

Dieser Push ist die Übergabe.

Claude Code implementiert das Projekt

Claude Code checkt das Repository aus, liest requirements.md und architecture.md und beginnt mit dem Bauen.

Hier verdient es die Abo-Kosten. Es ist wirklich hervorragend bei:

• Vollständige Features anhand einer Spezifikation implementieren
• Sauberen, idiomatischen Code schreiben
• Test-Suites mit sinnvoller Abdeckung erstellen
• Tests lokal ausführen und Fehler beheben
• Inline-Dokumentation und README-Abschnitte schreiben
• Erstes Refactoring, sobald Features funktionieren

Eine typische Sitzung für einen Backend-Service:

→ Authentifizierungsmodul gemäß architecture.md implementieren
→ Unit-Tests für Auth-Modul schreiben
→ User-CRUD-Endpoints implementieren
→ Integrationstests schreiben, die die Endpoints ansprechen
→ Drei fehlschlagende Tests beheben
→ README mit Setup-Anweisungen aktualisieren
→ black + isort ausführen

All das innerhalb des Abos. Keine Kosten pro Token. Wenn die Sitzung endet:

git add .
git commit -m "Implement auth module and user endpoints with tests"
git push

OpenClaw validiert die Integration

Ziehe das Repository zurück in OpenClaw. Jetzt nutze es für das, wofür es wirklich gut ist.

git pull

OpenClaws Aufgabe in dieser Phase:

• Stimmt der implementierte Code mit der Architektur-Spezifikation überein?
• Gibt es Interaktions-Bugs zwischen Komponenten, die Unit-Tests nicht finden würden?
• Fehlende Edge Cases in den API-Contracts?
• Hält das Error Handling über den gesamten Request-Lifecycle stand?

OpenClaw findet Dinge, die Claude Code übersehen hat — nicht weil Claude Code schlechter im Coding ist, sondern weil Reasoning auf Integrationsebene erfordert, das gesamte System gleichzeitig im Kontext zu halten. Genau dafür ist OpenClaws Context-Management gebaut.

Das Ergebnis ist eine Liste von Problemen, keine Fixes:

## Gefundene Integrationsprobleme

1. Auth-Token-Ablauf wird nicht an Downstream-Services weitergegeben
2. User-Deletion-Endpoint kaskadiert nicht zu verknüpften Ressourcen
3. Rate Limiting wird vor dem Auth-Check angewendet — Reihenfolge umkehren
4. Fehlende Error Response für fehlerhaften JSON-Body

Committe das als aktualisierte Requirements-Datei, pushe und übergib zurück an Claude Code.

Der Iterationszyklus

Entwicklung wird zu einem straffen Zyklus:

OpenClaw → Architektur / Integrations-Feedback / Problem-Identifikation
    ↓
Claude Code → Implementierung / Tests / Fixes / Refactoring
    ↓
git commit → git push → git pull
    ↓
wiederholen

Jedes Tool arbeitet auf seiner natürlichen Ebene. Claude Code denkt nie über Systemarchitektur nach. OpenClaw schreibt nie eine For-Schleife. Git hält sie sauber getrennt.

Ein Backend-Service, der in reinen OpenClaw-Sitzungen einen ganzen Tag dauern könnte, durchläuft Architektur, Implementierung und Validierung in wenigen Stunden — zu einem Bruchteil der Kosten.

Der finale Refactoring-Durchlauf

Sobald das Projekt stabil ist — Tests bestehen, Integrationsprobleme gelöst, Spezifikation vollständig implementiert — übergib das Repo ein letztes Mal an Claude Code.

• Coding-Stil über Module hinweg vereinheitlichen, die in verschiedenen Sitzungen geschrieben wurden
• Architektur vereinfachen, die während der Iteration komplex geworden ist
• Docstrings und Dokumentation erweitern
• Toten Code und ungenutzte Imports entfernen
• Testabdeckung finalisieren und fehlende Edge Cases ergänzen

Dieser Durchlauf ist günstig. Reine Coding-Arbeit ohne architektonische Unklarheiten.

Wann das funktioniert und wann nicht

Am besten geeignet für Backend-Services, APIs, Automatisierungstools, CLI-Tools, Infrastruktur-Code — alles, was letztendlich in einen OpenClaw-Workflow integriert wird.

Weniger nützlich für sehr kleine Skripte (der Overhead lohnt sich nicht), exploratives Prototyping (du hast keine Spezifikation zum Übergeben) oder Einmalaufgaben, bei denen die gesamte Coding-Zeit unter einer Stunde liegt.

Praktische Tipps

Halte OpenClaw-Prompts kurz. Du bezahlst für Reasoning, nicht für Kontext. Füge keine ganzen Codebases ein, wenn du eine Architekturmeinung willst — beschreibe die Struktur und lass OpenClaw daraus schlussfolgern.

Committe bei jeder Übergabe. Übergib kein unsauberes Working Directory zwischen Tools. Jede Übergabe ist ein Commit.

Behandle requirements.md während der Implementierung als unveränderlich. Änderungen an den Requirements gehen über OpenClaw, werden committet, und dann übernimmt Claude Code sie. Lass Claude Code nicht die Spezifikation ändern.

Lass Claude Code die Tests besitzen. OpenClaw identifiziert, was auf Integrationsebene getestet werden muss. Claude Code schreibt den eigentlichen Testcode.

Vermeide es, Code in OpenClaw zu schreiben, es sei denn, es ist Glue Logic. Sobald du Business Logic in einer OpenClaw-Sitzung implementierst, verbrennst du teure Tokens für günstige Arbeit.

Das Prinzip

OpenClaw ist hervorragend in dem, wofür es entwickelt wurde. Der Fehler ist, es für alles zu verwenden.

Implementierung, Testing, Refactoring, Dokumentation — das gehört zu Claude Code mit Flat-Abo-Kosten. Architektur, Integrationsvalidierung, System-Level-Reasoning — das gehört in OpenClaw, wo das Context-Management den Token-Verbrauch rechtfertigt.

Git ist der Handshake. Jeder Commit ist eine saubere Übergabe. Jeder Pull ist ein frischer Context Load. Die Agents müssen nie voneinander wissen — nur den aktuellen Zustand des Repos.

Du kannst die URL dieses Beitrags in Claude Code oder deinen KI-Assistenten deiner Wahl einfügen, um Kontext beim Einrichten dieses Workflows zu haben.

Wo du das betreiben kannst

Du brauchst einen VPS, der OpenClaw zuverlässig betreiben kann. Hetzner gibt dir 10 € Guthaben bei der Anmeldung — ein CX22 für 4,85 €/Monat bewältigt OpenClaw und deine Git-Repos problemlos. Auf diesem Server läuft auch dieser Blog.

Wenn du das Self-Hosting komplett überspringen möchtest, bietet xCloud verwaltetes OpenClaw-Hosting an. Zeigen, klicken, deployen — du bekommst den gleichen Hybrid-Workflow, nur ohne den Server selbst zu warten.

Für Teams, die die Orchestrierungsschicht ohne den Infrastrukturaufwand wollen, ist ClawTrust eine KI-Automatisierungsplattform, die die OpenClaw-Seite dieses Zyklus als Managed Service übernimmt.

(Affiliate-Links — ich erhalte eine kleine Provision, wenn du dich anmeldest, ohne zusätzliche Kosten für dich.)