KI-gestützte Produktentwicklung: Claude Code nahtlos im Software-Lebenszyklus einsetzen

Die meisten KI-gestützten Entwicklungstools konzentrieren sich auf isolierte Code-Sessions – sie schlagen Vervollständigungen vor, refaktorieren einzelne Dateien oder beheben Fehler in einem begrenzten Kontext. Doch echte Produktentwicklung findet selten in einem einzigen Editor-Fenster statt. Sie erstreckt sich über Anforderungsanalyse, Ticket-Verwaltung, Code-Reviews, Merge-Requests und die langfristige Dokumentation von Entscheidungen.

Ein Entwickler hat nun ein System vorgestellt, das den KI-Code-Assistenten Claude Code über den gesamten Software-Lebenszyklus orchestriert. Seit Monaten im Einsatz, kombiniert es Automatisierung mit menschlicher Kontrolle und hat bereits wertvolle Erkenntnisse über typische Stolperfallen geliefert. Der zentrale Gedanke dahinter lässt sich in einem Satz zusammenfassen: Nicht der Workflow, sondern die Entscheidungsphase ist die richtige Einheit für den KI-Einsatz.

Warum herkömmliche KI-Code-Tools an Grenzen stoßen

Viele bestehende Lösungen behandeln KI als universellen Problemlöser, der jede Aufgabe übernimmt – von der Code-Generierung bis zur Ausführung von Git-Befehlen. Doch diese Herangehensweise ist ineffizient und riskant:

• Token-Kosten explodieren, wenn die KI mechanische Operationen wie Dateizugriffe oder Testläufe durchführt.
• Die Latenz steigt, da jede API-Aufnahme Zeit kostet und die KI mit Kontext überflutet wird.
• Fehleranfälligkeit wächst, wenn die KI irreversible Aktionen wie Code-Merges oder Ticket-Schließungen ausführt.

Das neue System setzt genau hier an, indem es die KI nur dann einsetzt, wenn echte Entscheidungen gefragt sind – etwa bei der Bewertung von Architekturoptionen, der Beurteilung von Review-Feedback oder der Implementierung komplexer Logik.

Die Architektur: Klare Trennung zwischen Automatisierung und KI-Entscheidung

Das Orchestrierungssystem folgt drei grundlegenden Prinzipien, die für Stabilität und Skalierbarkeit sorgen:

1. Python steuert, die KI entscheidet Jeder Workflow ist in Phasen unterteilt. Mechanische Aufgaben wie API-Aufrufe, Dateioperationen oder Testausführungen werden von deterministischen Python-Skripten übernommen. Die KI wird erst aktiv, wenn Urteilsvermögen gefragt ist. Diese Trennung reduziert nicht nur die Kosten, sondern beschleunigt auch den Prozess: Mechanische Phasen laufen in unter zwei Sekunden ab.

2. Vorschläge statt Ausführung Das System führt nie autonome Aktionen aus, die nicht umkehrbar sind – etwa das Mergen von Code, das Schließen von Tickets oder das Versenden von Benachrichtigungen. Stattdessen generiert es strukturierte Vorschläge, die in einem Dashboard zur menschlichen Prüfung bereitstehen. So kann das System auch unbeaufsichtigt laufen, ohne Risiken einzugehen.

3. Wissen akkumulieren statt neu zu erfinden Jede Entwicklungs-Session beginnt mit einem kontextuellen Gedächtnis: Architekturentscheidungen, Teamverantwortlichkeiten, historische Ticket-Daten und frühere Lösungsansätze werden in einer persistenten Wissensdatenbank gespeichert. Die KI muss nicht jedes Mal von vorne beginnen, sondern baut auf bereits gesammelten Erkenntnissen auf.

Die sechs Schichten des Systems

Das System ist modular aufgebaut und besteht aus sechs klar definierten Ebenen, die zusammen eine robuste Infrastruktur für KI-gestützte Entwicklung bieten:

┌─────────────────────────────────────────────────────────┐
│ 1. Benutzer-Interface (CLI + Dashboard)                  │
├─────────────────────────────────────────────────────────┤
│ 2. Skill-Kommando → Orchestrator-Routing                 │
├─────────────────────────────────────────────────────────┤
│ 3. Orchestrator (Python) – Phasenbasierte JSON-Eingabe   │
├─────────────────────────────────────────────────────────┤
│ 4. Agent (Claude Code + spezialisierte Subagenten)      │
├─────────────────────────────────────────────────────────┤
│ 5. Datenhaltung (SQLite + Markdown-Wiki + ChromaDB)     │
├─────────────────────────────────────────────────────────┤
│ 6. Externe Systeme (Jira, GitLab, Confluence, Kubernetes)│
└─────────────────────────────────────────────────────────┘

• Ebenen 1–3 sind rein deterministisch und steuern die Abläufe.
• Ebene 4 ist die Domäne der KI, die nur bei Bedarf aktiv wird.
• Ebenen 5–6 stellen den Zustand und die Integration externer Tools sicher.

Die Skill-Schicht mappt Benutzerbefehle mithilfe einer YAML-Manifest-Datei auf die entsprechenden Orchestrator-Skripte. So bleibt transparent, welche Fähigkeiten das System bietet. Spezialisierte Subagenten – etwa für Code-Reviews oder Wissenssynthese – arbeiten in isolierten Kontexten mit eingeschränkten Berechtigungen.

Orchestriert oder agentennativ? Wann lohnt sich der Mehraufwand?

Nicht jede Aufgabe erfordert das volle Orchestrierungssystem. Der entscheidende Faktor ist die Komplexität der Nebenwirkungen:

Orchestrierte Skills umfassen Workflows mit externen Effekten wie:

• Ticket-Implementierung mit Branch-Erstellung und CI-Läufen
• Merge-Request-Erstellung und Code-Review-Prozesse
• Analyse von Build-Fehlern und automatisierte Fehlerbehebung

Diese Aufgaben benötigen deterministische Steuerung (z. B. Testausführung, Git-Operationen) kombiniert mit KI-basierter Entscheidungsfindung. Ohne Orchestrierung wäre die KI überfordert oder würde fehleranfällige Automatisierungsschritte durchführen.

Agent-native Skills sind dagegen einfache Reasoning-Aufgaben ohne Seiteneffekte:

• Debugging eines Service-Problems
• Klassifizierung unbekannter Eingaben
• Generierung von Standup-Zusammenfassungen

Hier reicht ein direkter KI-Aufruf aus, da keine komplexen Automatisierungsschritte nötig sind. Der Mehraufwand für ein Orchestrierungssystem lohnt sich nur, wenn die mechanischen Schritte so komplex sind, dass die KI sie nicht zuverlässig ausführen könnte.

Von der Anforderung zum Merge-Request: Ein vollständiger Workflow

Um die Funktionsweise greifbar zu machen, lässt sich der Lebenszyklus eines Tickets in vier Phasen unterteilen:

Phase 1: Kontextzusammenstellung (Python-Orchestrator)

• Abrufen der Ticket-Details aus Jira
• Suche in der Wissensdatenbank nach relevanten Architekturentscheidungen
• Erstellung eines temporären Arbeitsbaums und eines Feature-Branches
• Extraktion einer präzisen Implementierungsanleitung als JSON-Paket

Phase 2: Implementierung (Claude Code)

• Die KI liest die Anleitung sowie Coding-Standards
• Generierung oder Anpassung des benötigten Codes
• Rückgabe des implementierten Codes an den Orchestrator

Phase 3: Validierung (Orchestrator + Review-Agent)

• Automatisierte Ausführung von Tests, Linters und Formatierern
• Bei Fehlern: Bis zu dreimalige Rückgabe an die KI zur Korrektur
• Durchführung eines Code-Reviews durch einen spezialisierten Subagenten
• Blockierende Issues werden erneut an die KI zur Lösung übergeben

Phase 4: Vorschlag und Bereitstellung (Orchestrator → Mensch → Orchestrator)

• Erstellung eines strukturierten Vorschlags mit allen relevanten Änderungen
• Präsentation im Dashboard zur menschlichen Entscheidung
• Bei Freigabe: Automatisiertes Pushen des Codes und Anlegen eines Merge-Requests
• Protokollierung aller Aktionen in einer Aktivitätshistorie

Fazit: KI-Orchestrierung als Zukunft der Produktentwicklung?

Das beschriebene System zeigt, wie KI-gestützte Entwicklung über die Grenzen einzelner Editor-Sessions hinauswachsen kann. Durch die klare Trennung zwischen Automatisierung und KI-Entscheidung wird nicht nur die Effizienz gesteigert, sondern auch die Zuverlässigkeit erhöht. Die größten Herausforderungen liegen weniger in der Technologie selbst als in der richtigen Modellierung der Workflows und der kontinuierlichen Pflege des systemischen Wissens.

Für Entwicklungsteams, die bereits KI-Code-Assistenten einsetzen, könnte diese Herangehensweise den nächsten logischen Schritt darstellen. Die Zukunft der Softwareentwicklung wird nicht darin bestehen, die KI immer mächtiger zu machen – sondern sie zielgerichtet und kontrolliert einzusetzen, wo sie den größten Mehrwert bietet: bei der komplexen Entscheidungsfindung.