Autonome Entwicklungs-Workflows mit Claude Code

Die meisten Entwickelnden nutzen KI-Tools heute als schnelleres Autocomplete. In den letzten Monaten habe ich in einem Kundenprojekt einen anderen Weg eingeschlagen: Multi-Agent-Setups mit Claude Code, in denen spezialisierte Agenten parallel arbeiten, sich gegenseitig reviewen und eigenständig koordinieren. In diesem Artikel beschreibe ich die Reise dorthin — von der anfänglichen Frustration mit fehlender Kontextübergabe über das schrittweise Aufbauen reproduzierbarer Blueprints bis zu Workflows, die Code produzieren, den ich nicht mehr Zeile für Zeile selbst schreibe. Ein Erfahrungsbericht mit konkreten Learnings für alle, die den nächsten Schritt in Richtung autonomer Entwicklung gehen wollen.

Inhalt

• Fünf Level, ein Spiegel
• Die Verlockung von Level 2
• Der Wendepunkt
• Das Umdenken
• Das Handwerk: Wie ein Setup aussieht
• Learnings
• Fazit
• Einstieg & Ausblick

---

Fünf Level, ein Spiegel

Dan Shapiro hat Anfang 2026 einen Artikel veröffentlicht, der in der Branche schnell die Runde gemacht hat: The Five Levels from Spicy Autocomplete to the Software Factory. Die Idee dahinter ist nicht besonders originell — im Wesentlichen wurden die bekannten Autonomiestufen selbstfahrender Autos auf die Softwareentwicklung mit KI übertragen. Da die Industrie bis dato aber kein eigenes Vokabular für das hatte, was viele von uns gerade durchleben, wurde das Framework aufgesaugt wie ein Schwamm.

Hier der Überblick in aller Kürze:

Level	Was die KI tut	Was der Mensch tut
0 – Manuell	nichts	schreibt jede Zeile selbst
1 – Assistiert	abgegrenzte Einzelaufgaben (Tests, Doku)	kontrolliert den gesamten Prozess
2 – Gemeinsames Entwickeln	übernimmt Routineaufgaben im Flow	führt — trägt Struktur, Kontext & Verantwortung
3 – Menschliche Aufsicht	wird zur primären Entwicklerin	reviewt Diffs, statt Code zu schreiben
4 – Autonome Ausführung	setzt Spezifikationen über längere Zeiträume um	schreibt Specs, prüft Ergebnisse im Nachhinein
5 – Dark Factory	wandelt Specs direkt in Software um	kaum noch beteiligt

Der Knackpunkt liegt bei Level 2: Hier arbeiten heute die meisten "KI-nativen" Entwickelnden — und genau das ist das Problem. Level 2 fühlt sich vollständig an. Es ist es nicht.

Shapiro schätzt, dass die meisten Teams bei Level 3 stagnieren. Level 5 haben bislang nur wenige kleine Teams erreicht.

Ich würde mich selbst zwischen Level 3 und 4 einordnen — mit klarer Tendenz zu 4. Was mich dorthin gebracht hat, ist weniger ein bestimmtes Tool als eine veränderte Denkweise darüber, wie ich mit KI arbeite.

---

Die Verlockung von Level 2

Level 2 ist komfortabel — man schreibt Code, die KI hilft dabei, schneller und mit weniger Tipparbeit, manchmal mit überraschend guten Ideen. Der Flow stimmt, und man hat das Gefühl, produktiv zu sein.

Diese Wahrnehmung spiegelt sich auch in den Zahlen wider: Laut einer Studie des Weizenbaum-Instituts (Krzywdzinski & Wotschack, 2026) bleiben die zentralen Ziele beim KI-Einsatz die Automatisierung von Arbeitsschritten und die Stärkung der Effizienz. 57 Prozent der befragten Betriebe setzen KI-Assistenten zur Unterstützung von Beschäftigten ein. Die freigewordene Zeit fließt in Qualitätsverbesserungen — nicht in eine Veränderung der Arbeitsweise selbst. Schneller das Gleiche tun, nicht anders arbeiten.

Aber Level 2 hat eine subtile Grenze: Die KI reagiert, der Mensch führt — und die Verantwortung für Struktur, Kontext und Entscheidungen liegt vollständig bei einem selbst.

Das bedeutet: Wächst die Komplexität, wächst auch der eigene Aufwand. KI-Unterstützung skaliert bei Level 2 nicht automatisch mit dem Problem.

---

Der Wendepunkt

Mein Weg zu autonomen Workflows war nicht geradlinig.

Der erste Schritt waren Online-Tools wie ChatGPT oder Gemini. Hilfreich — aber mit einem grundlegenden Problem: der Projektkontext fehlt. Man kann nicht sicher wissen, was das Modell braucht, um eine Frage wirklich zu verstehen. Und selbst wenn man es wüsste, wäre es schlicht nicht machbar, alles Relevante manuell in den Chat zu kopieren. Das Ergebnis: generische Antworten auf komplexe Fragen.

GitHub Copilot war ein anderer Versuch. Direkt im Editor, immer verfügbar — aber auch nur mit der aktuellen Datei als Kontext. Was nicht sichtbar war, existierte für Copilot nicht. Mir persönlich war das Werkzeug öfter im Weg als hilfreich.

Der eigentliche Durchbruch kam mit Agent-Tools wie Claude Code: Agenten, die selbständig Projektkontext lesen — Dateien, Strukturen und Abhängigkeiten. Plötzlich konnte ich eine Frage stellen, ohne selbst entscheiden zu müssen, was das Modell dafür wissen muss — das erledigt der Agent. Der Kontext ist damit deutlich größer als bei jedem Online-Tool — aber wirklich rund wird er erst, wenn man dem Agenten gezielt zusätzliche Informationen gibt: Rules (feste Regeln, die der Agent automatisch befolgt), Projektbeschreibungen, gute Problembeschreibungen.

Der konkrete Auslöser

Vor einigen Monaten startete ein neues Kundenprojekt. Das Team wurde gebeten, die Einsetzbarkeit von Claude Code zu evaluieren. Mein Part dabei ist in erster Linie das Rust-Backend — eine Reihe von Lambdas und Libraries, die größte davon eine API auf Basis von Axum — und die Cloud-Infrastruktur.

Am Anfang war es frustrierend. Es war schwer, dem Agenten den nötigen Kontext zu geben — was eine große Lernerfahrung auf unserer Seite war. Und es war schwer, ihn dazu zu bringen, ein Problem aus verschiedenen Blickwinkeln zu betrachten: Security, Testing, Wartbarkeit. Alles musste man selbst anstoßen.

Das änderte sich mit dem Release von Opus 4.6 und dem experimentellen Feature "Agent Teams". Ab diesem Moment konnten wir spezialisierte Agenten nicht nur einsetzen, sondern direkt mit ihnen interagieren — vorher liefen sie zwar schon, ließen sich aber nicht direkt ansprechen, was das Debugging erschwerte. Wir hatten inzwischen die wesentlichen Zusammenhänge verstanden, und ich begann, mit Agent Teams eigene Multi-Agent-Setups zu bauen — Konfigurationen, in denen verschiedene Agenten mit eigenem Wissen und eigener Perspektive zusammenarbeiten.

Vorher arbeitete ich mit Claude im Dialog — Frage, Antwort, Korrektur, nächste Frage — nützlich, aber im Kern nicht viel anders als Pair-Programming.

Mit Agent Teams wurde aus dem Dialog ein Prozess. Ein Lead koordiniert, Teammates arbeiten parallel, eine geteilte Task-Liste hält den Überblick. Der entscheidende Unterschied zu Subagents — Hilfsagenten, die nur an den Lead zurückmelden: Teammates kommunizieren direkt miteinander. Sie tauschen Zwischenergebnisse aus, hinterfragen sich gegenseitig und koordinieren ohne mein Zutun. Das ist kein Assistent mehr, sondern ein autonomes Entwicklungsteam.

---

Das Umdenken

Der Schritt zu Level 3/4 ist nicht nur technisch — er ist vor allem mental.

Lange habe ich gedacht: "Ich entwickle Software." Mit Agent Teams verschiebt sich das: "Ich konfiguriere Agent Teams." Ich schreibe weniger Code — aber ich entscheide, wie das Team aufgestellt ist, welche Regeln gelten, welche Qualitätskriterien greifen. Die Arbeit wird abstrakter, die Wirkung größer.

Dieses Loslassen fällt vielen schwer — und das ist nachvollziehbar. Entwickeln macht Spaß: Probleme lösen, Systeme entwerfen, eleganten Code schreiben — das sind keine Tätigkeiten, die man gerne abgibt. Ich habe dafür volles Verständnis.

Trotzdem glaube ich: Wer diesen Schritt nicht geht, wird langfristig nicht Schritt halten können. Aktuell muss man noch verstehen, wie Software unter der Haube funktioniert — das bleibt wichtig, um Agenten sinnvoll zu steuern und ihre Ergebnisse zu beurteilen. Aber je besser die Modelle werden, desto weniger wird man mit Details konfrontiert.

Der eigentliche Wert verschiebt sich: von der Fähigkeit, Code zu schreiben, zur Fähigkeit, gute Systeme zu entwerfen — und Agent Teams so aufzusetzen, dass sie zuverlässig guten Code produzieren. Ein starker IT-Background bleibt aus meiner Sicht trotzdem nötiger denn je. Denn je schnelllebiger Software und Systeme werden, desto wichtiger wird es, dass Menschen ihnen ihre Aufmerksamkeit widmen und sie instand halten — wenn auch auf einer anderen Ebene.

---

Das Handwerk: Wie ein Setup aussieht

Der Sprung zu Level 3/4 passiert nicht durch mehr Prompting — er passiert durch Struktur.

Bevor ich die einzelnen Bausteine beschreibe, ein kurzer Blick darauf, wie sich ein typischer Arbeitszyklus anfühlt.

Ich beschreibe, was ich umsetzen will. Der Lead stellt Rückfragen — je nach Komplexität wenige oder viele. Bei Aufgaben in Bereichen, die mir vertraut sind, ist das in Minuten geklärt. Bei Themen, in denen ich selbst kein Detailwissen habe — wie dem Language Server Protocol für rlsp, ein eigenes Projekt von mir — stelle ich auch dem Agenten Rückfragen, um überhaupt Entscheidungen treffen zu können. Dann entsteht ein Plan, der intern geprüft wird, bevor ich ihn sehe. Ich schaue ihn mir an, überprüfe ihn und kläre eventuelle Rückfragen, falls mir etwas unklar ist. Wenn ich dem Plan zustimme, fängt das Agent-Team mit der Umsetzung an.

Was ich während der Ausführung tue, hängt von der Aufgabe ab. Bei unbekanntem Terrain schaue ich zu — manchmal lasse ich den Lead zwischen den Tasks stoppen, um mich zu vergewissern, dass alles nach Plan läuft. Bei Routineaufgaben schaue ich mir danach die Commits an, manchmal auch das nicht. Falls etwas grundlegend schiefläuft, passe ich das Blueprint (die kopierbare Setup-Vorlage) an und lasse den Plan von vorne laufen — was gleichzeitig zeigt, ob die Änderung am Setup greift.

Am Anfang habe ich deutlich öfter eingegriffen. Mittlerweile laufen auch komplexere Aufgaben zuverlässig durch. Die Arbeit verschiebt sich: weniger Eingreifen, mehr Entscheiden im Vorfeld.

Der Lead — Orchestrator, nicht Entwickler

Im Fall von Claude Code ist der Lead die zentrale Koordinationsinstanz — die initiale Session, die man über die CLI startet. Er kommuniziert mit dem Nutzenden, klärt Aufgaben, schlägt Workflows vor und koordiniert das Team. Was er explizit nicht tut: selbst entwickeln.

Das klingt einfacher als es ist. Der Lead wird über <projektverzeichnis>/.claude/CLAUDE.md konfiguriert — und anders als die spezialisierten Agenten, deren Rechte sich per Frontmatter einschränken lassen, läuft er immer mit vollen Berechtigungen. Das macht ihn besonders anfällig dafür, vorgegebene Pfade zu verlassen und Dinge selbst zu erledigen, statt zu delegieren. Meine Erfahrung: Den Lead am besten konsequent als Orchestrator und Kommunikations-Hub einsetzen. Klare Anweisungen in der CLAUDE.md helfen dabei — inklusive expliziter Verbote.

Blueprints — reproduzierbare Setups

Ein Blueprint ist eine Kopiervorlage: ein .claude/-Verzeichnis mit allem, was ein Projekt für autonome Agenten-Workflows braucht. Man kopiert es ins Projekt, passt es an, und das Setup ist einsatzbereit.

Die Bausteine, die Claude Code von Haus aus mitbringt und die ein Blueprint nutzt:

• CLAUDE.md (Lead-Instruktionen): Rolle, Startup-Verhalten, Clarification-Prozess — die zentrale Konfigurationsdatei, die der Lead beim Start lädt
• agents/ (spezialisierte Agenten): z.B. Architect, Developer, Test Engineer, Security Engineer, Reviewer — jeder mit klar definierter Rolle und Einschränkungen
• rules/ (modulare Rules): topic-spezifische Instruktionen, die für alle Agenten automatisch geladen werden — unbedingt (immer aktiv) oder bedingt (pfadabhängig, z.B. nur bei .rs-Dateien)
• skills/ (wiederverwendbare Skills): projektspezifische Kommandos wie /project-init, das ein Projekt scannt und aus Sprachen, Frameworks und Testtools eine erste Projekt-CLAUDE.md generiert
• settings.json (Konfiguration): Aktiviert Agent Teams, definiert Verzeichnisse für Pläne, steuert Berechtigungen

/project-init füllt dabei nur, was sich automatisch erkennen lässt; Intent-Felder wie Architektur und Anti-Patterns bleiben bewusst als TODOs stehen — die Grenze, an der menschliches Urteil übernimmt.

Darüber hinaus kann man eigene Strukturen ergänzen. In meinem Workflow-Blueprint definieren wir z.B. Workflow-Dateien, die verschiedene Autonomiegrade beschreiben — von "Develop-Review mit manueller Freigabe pro Commit" bis "vollautonome Umsetzung nach Plan-Approval". Der Lead liest diese Dateien und bietet sie den Nutzenden als Auswahl an. Das ist kein Claude-Code-Feature, sondern eine Konvention, die über die CLAUDE.md gesteuert wird.

Blueprints reifen — nicht auf einmal

Mein erstes Blueprint war ein Experiment: fünf Agenten mit festen Rollen, einem starren Ablauf und umfangreichen Hooks — automatisch ausgeführten Skripten — für die Pre-Commit-Validierung. Damit habe ich rlsp immer wieder von Grund auf neu erstellt — anfangs reine Wegwerf-Versuche, um zu verstehen, wie die Agenten unter verschiedenen Bedingungen arbeiten.

Daraus entstand das Workflow-Blueprint. Statt starrer Abläufe wählen Nutzende zwischen verschiedenen Workflows je nach Aufgabe — Develop-Review mit manueller Freigabe, vollautonome Variante, etc. Die Hooks fielen weg — stattdessen übernehmen bedingte Rules das Qualitäts-Enforcement. Dieses Blueprint setzen wir heute als Team im Kundenprojekt ein.

Nachdem es sich in der Praxis bewährt hatte, entstand das Autonomous-Blueprint — speziell für Hands-off-Programmierung. Der Lead übernimmt Planung und Aufgabenzerlegung selbst und steuert, wann beratende Agenten einbezogen werden. Optimiert auf Durchsatz bei minimaler menschlicher Interaktion.

Nach mehreren Anläufen wurde daraus etwas Ernsthaftes: rlsp (Rust Language Server Project) — schlanke Language-Server in Rust, aktuell einer für YAML. Die Mehrheit des Codes darin entstand mit dem Autonomous-Blueprint; inzwischen ist rlsp eigenständig, mit Extensions für VS Code und Zed. Ich habe die Architektur und die Regeln entworfen — den Code haben die Agenten geschrieben. Nicht perfekt, aber die Code-Qualität steht den handgeschriebenen Teilen in nichts nach.

Aber wie werden Blueprints eigentlich besser?

Am Anfang war das noch Handarbeit: einen Fehler im Testprojekt beobachten, die Ursache mit Claude durchgehen, die Verbesserung umsetzen lassen und das .claude/-Verzeichnis zurück ins Projekt kopieren. Das funktionierte, solange die Setups überschaubar waren.

Mit wachsender Komplexität reichte das nicht mehr. Einzelne Fehlerbeschreibungen per Prompt griffen zu kurz — man musste den gesamten Ablauf verstehen: Welche Agenten waren beteiligt? In welcher Reihenfolge? Welche Rule hat gegriffen, welche nicht? Die Verbesserung eines Blueprints wurde damit selbst zu einer strukturierten Aufgabe.

Parallel entstand eine neue Arbeitsweise für die Fehleranalyse: Wenn ein Agent-Team einen Fehler produziert, lasse ich das Team selbst eine Retrospektive durchführen. Die Agenten analysieren ihren eigenen Ablauf — welche Entscheidungen wurden getroffen, wo hat der Prozess versagt, was war die Ursache. Das Ergebnis landet als Report im Projekt. Aus diesem Report leite ich dann die konkreten Verbesserungen am Blueprint ab.

Ein Beispiel: Der Reviewer-Agent prüfte Code-Qualität — Korrektheit, Tests, Linting. Was er nicht prüfte: ob der Code den Plan vollständig umsetzt. In einem Fall wurde eine komplette Feature-Infrastruktur gebaut, getestet und durch das Review gewunken — aber nie in den Server integriert. Toter Code, sauber geschrieben. Die Retrospektive identifizierte die Lücke: Der Reviewer kannte die Aufgabe, aber nicht den Plan. Daraus entstand der Plan-Reviewer — ein Agent, der vor der Freigabe prüft, ob die Umsetzung den Plan tatsächlich erfüllt.

Dieser Zyklus — Fehler, Retrospektive, strukturelle Verbesserung — ist der eigentliche Entwicklungsprozess. Man baut nicht sofort das perfekte Setup — man baut ein System, das aus seinen eigenen Fehlern lernt.

Bedingte Rules — Qualität ohne Hooks

Claude Code bietet Hooks als Mechanismus, um Shell-Befehle bei bestimmten Ereignissen auszuführen — z.B. Tests vor einem Commit oder Validierung beim Abschluss einer Aufgabe. In meinen frühen Setups habe ich davon intensiv Gebrauch gemacht.

In der Praxis hat sich ein anderer Ansatz als wirkungsvoller erwiesen: bedingte Rules. Das sind modulare Instruktionsdateien, die sich automatisch aktivieren, sobald ein Agent Dateien eines bestimmten Typs anfasst. Öffnet ein Agent eine .rs-Datei, laden die Rust-spezifischen Rules. Berührt er TypeScript, gelten die TypeScript-Konventionen. Ohne manuelles Eingreifen, ohne Konfigurationsaufwand.

Der Vorteil gegenüber Hooks: Rules wirken präventiv — der Agent kennt die Regeln, bevor er Code schreibt. Hooks wirken erst reaktiv, wenn der Code bereits geschrieben ist.

Begründungen schreiben — auch für Agenten

Eine der wirkungsvollsten Erkenntnisse aus der Arbeit mit Blueprints: Instruktionen ohne Begründung produzieren brüchigen Gehorsam. Der Agent befolgt die Regel — aber missversteht ihren Geist.

Ein Beispiel aus der Praxis:

Schwach: "Jeder Test muss isoliert laufen."

Gut: "Jeder Test muss isoliert laufen — geteilter Zustand zwischen Tests erzeugt reihenfolgeabhängige Fehler, die nur in CI auftreten und teuer zu debuggen sind."

Der zweite Satz gibt dem Agenten eine Grundlage für Abwägungen: Wenn vollständige Isolation in einem konkreten Fall teuer ist, kann er beurteilen, ob der Trade-off akzeptabel ist. Ohne Begründung fehlt dieses Urteilsvermögen.

Das gilt für alles: CLAUDE.md, Agenten-Definitionen, Rules, Workflow-Beschreibungen. Wer Gründe nennt, erhält zuverlässigere Ergebnisse.

Statische Analyse als Leitplanke

Ein Muster zieht sich durch alle meine Projekte: Je strikter die Werkzeuge, desto besser der Code, den Agenten produzieren. Statische Codeanalyse — Compiler, Typprüfung, Linter — sollte man deshalb so breit und so streng wie möglich einsetzen. Jede Regel, die ein Tool automatisch durchsetzt, ist eine Leitplanke: Sie wirkt unabhängig vom Agenten und fängt Fehler ab, bevor sie überhaupt ins Review gelangen.

Verstärken lässt sich dieser Effekt in jeder Sprache. Strenge Linter-Konfigurationen, Compiler-Warnungen als Fehler behandeln, zusätzliche statische Checks — und im Blueprint sprachspezifische Rules (z.B. für Rust, Python, TypeScript, Go), die projektspezifische Konventionen ergänzen. So kennt der Agent nicht nur die Sprache, sondern die Regeln, die in genau diesem Projekt gelten.

Sandboxed Execution — devcontainer als Sicherheitsnetz

Wer autonome Agenten laufen lässt, will nicht, dass sie versehentlich in die eigene Entwicklungsumgebung schreiben. Ein devcontainer-Template löst das: Agenten laufen in einem isolierten Container mit eigenem Claude-Konfigurationsverzeichnis. Das Host-System bleibt unberührt. Die eigenen Einstellungen werden read-only als Vorlage eingebunden.

---

Learnings

Was ich auf dem Weg gelernt habe — in aller Kürze:

Kontext ist alles. Das war unsere größte Lernerfahrung am Anfang des Projekts. Agenten arbeiten mit dem, was sie wissen — eine schwache CLAUDE.md oder fehlende Projektbeschreibung produziert generische Ergebnisse, unabhängig vom Modell.

Gründe nennen, nicht nur Regeln. Instruktionen mit Begründung werden zuverlässiger befolgt und besser auf neue Situationen übertragen.

Aufgaben richtig zuschneiden. Zu kleine Aufgaben: Der Koordinationsaufwand überwiegt den Nutzen. Zu große Aufgaben: Agenten arbeiten zu lange ohne Check-in, Fehler akkumulieren sich. Der Sweet Spot liegt bei Aufgaben mit einem klaren, abgrenzbaren Ergebnis — eine Funktion, eine Testdatei, ein Review.

Den Lead konsequent als Orchestrator einsetzen. Sobald der Lead selbst Code schreibt statt zu delegieren, verliert man die Qualitätsgates der spezialisierten Agenten.

Level 2 ist schwer loszulassen. Der Impuls, selbst einzugreifen und Dinge "schnell selbst zu machen", ist stark. Autonomie entsteht durch Loslassen — und durch Vertrauen in die Struktur, die man aufgebaut hat.

Agenten kürzen ab. Wenn ein Prozessschritt optional aussieht, wird ein Agent ihn überspringen — selbst wenn er es nicht sollte. Mehrstufige Abläufe brauchen explizite Markierungen: "immer", "ohne Ausnahme", "auch wenn der vorherige Schritt bereits erfolgreich war". Das klingt redundant — ist aber der Unterschied zwischen einem Prozess, der unter Druck hält, und einem, der still zerfällt.

Qualitätsgates von Anfang an. Bedingte Rules, Plan-Approval-Workflows und ein unabhängiger Reviewer sind kein Nice-to-have. Ohne sie entstehen Ergebnisse, die man aufwändig nachkorrigieren muss.

---

Fazit

Die meisten Entwickelnden bleiben bei Level 2 — KI als schnelleres Autocomplete. Mein Weg der letzten Monate führte woanders hin: erst im Kundenprojekt, dann in rlsp habe ich Multi-Agent-Setups mit Claude Code aufgebaut, gebündelt in reproduzierbaren Blueprints. Der entscheidende Hebel war nie mehr Prompting, sondern Struktur — klare Rollen, eingebaute Leitplanken und ein Prozess, der aus seinen eigenen Fehlern lernt. Das Ergebnis sind Workflows, die Code produzieren, den ich nicht mehr Zeile für Zeile selbst schreibe — und ein Rollenwechsel: vom Entwickeln hin zum Entwerfen von Systemen, die zuverlässig guten Code liefern.

---

Einstieg & Ausblick

Wer mit autonomen Workflows beginnen will, muss nicht sofort ein vollständiges Blueprint-Setup aufbauen. Der erste Schritt ist einfacher:

1. CLAUDE.md schreiben — für jedes Projekt. Auch wenn man noch alleine mit Claude arbeitet. Das zwingt dazu, Ziele, Einschränkungen und Qualitätskriterien explizit zu machen — inklusive Begründungen.
2. Rules anlegen — sprachspezifische oder projektspezifische Regeln in .claude/rules/ definieren. Sie laden automatisch und verbessern die Code-Qualität sofort.
3. Erste Delegation — eine klar abgegrenzte Aufgabe vollständig delegieren und nicht eingreifen, bis sie fertig ist.

Agent Teams kommen dann, wenn diese Grundlagen sitzen.

Meine langfristige Vision: ein vollständiger Zyklus, in dem Nutzende Issues und Feature-Requests schreiben — und nach einer Freigabe ein Workflow automatisch die Umsetzung übernimmt. Davon bin ich noch ein Stück entfernt. Aber die Bausteine dafür existieren bereits.

Das Repository mit meinen Blueprint-Setups ist auf GitHub verfügbar: chdalski/claude_orchestration. Es ist ein lebendiges Repository — die Blueprints entwickeln sich mit jeder neuen Erfahrung weiter. Wer den im Artikel beschriebenen Stand nachvollziehen möchte, findet ihn unter dem Tag blog-2026-06.