VM0-Entwicklungsworkflow: KI-Agenten wie ein Team managen

Im VM0-Entwicklungsteam arbeitet jeder Entwickler gleichzeitig mit mehreren Claude-Code-Instanzen. Normalerweise mehr als acht.

Wir behandeln Claude Code genauso wie einen echten Entwickler. (Ja, unser Unternehmen heißt halb im Scherz AI Colleagues Co!)

Deshalb spiegelt die Designphilosophie hinter dem VM0-Entwicklungsworkflow klassische Teampraktiken im Software Engineering wider.

Wir nutzen GitHub Issues zur Arbeitsverfolgung, Pull Requests für Code Reviews und Merging sowie GitHub Actions für die Automatisierung. Über zwei Monate hinweg half uns dieses Setup, 404 Releases zu veröffentlichen und mehr als 230.000 Codezeilen zu schreiben.

Dieser Beitrag erklärt, wie wir das umsetzbar gemacht haben und warum das Hauptproblem nie die KI-Fähigkeit war, sondern die menschliche Koordination.

KI-gestützter Entwicklungsworkflow in der Praxis

Wenn Sie viele KI-Agenten parallel koordinieren, ist der Engpass nicht, ob das Modell Code schreiben kann. Der echte Engpass ist die kognitive Belastung des Menschen.

Dieser Workflow besteht aus 14 Slash-Befehlen, die in drei Ebenen organisiert sind: Deep Dive, Issue Management und PR Management.

Schauen wir uns zunächst an, wie mein Workflow aussieht und wie ein Feature normalerweise entwickelt wird.

Anforderungsabstimmung

Ein Mensch öffnet eine Claude-Session und beginnt mit /deep-research. Claude sammelt Fakten aus der Codebasis, Dokumentation und relevantem Kontext. Wir diskutieren die Ergebnisse und stimmen uns ab, welches Problem wir tatsächlich lösen.
Lösungserkundung

Mit /deep-innovate schlägt Claude mehrere mögliche Richtungen mit Trade-offs vor. Wir diskutieren, grenzen ein und wählen eine Richtung.
Issue-Erstellung

Wir erstellen ein GitHub Issue mit /issue-create. Der Mensch überprüft das Issue, um sicherzustellen, dass die Anforderungen klar erfasst sind.
Planung und Genehmigung

Mit /issue-todo lassen wir Claude die Arbeit fortsetzen. Claude führt automatisch den vollständigen Deep-Dive-Workflow aus und postet die Ergebnisse zum Issue, einschließlich:
1. Erkenntnisse aus /deep-research
2. Vergleiche aus /deep-innovate
3. einen konkreten Implementierungsplan aus /deep-plan
Implementierung

Nach Genehmigung lässt /issue-continue Claude den Plan implementieren, Tests schreiben, einen PR öffnen und sicherstellen, dass CI durchläuft.
Review und Merge

Wir nutzen /pr-review-and-comment für ein strukturiertes Review und führen dann ein finales menschliches Review vor dem Merging durch.

Der Mensch greift an drei Checkpoints ein: Anforderungen, Richtung und Abnahme. Alles andere läuft autonom.

Perspektivwechsel: Sie leiten ein Team von KI-Entwicklern

Der Moment, in dem mir klar wurde, dass wir einen strukturierten Workflow brauchen, war, als das Hinzufügen weiterer Claude-Sessions die Dinge tatsächlich verschlimmerte. Je mehr Instanzen ich parallel laufen ließ, desto schwieriger wurde es nachzuverfolgen, was jede einzelne tat, in welchem Zustand die Arbeit war und was bereits entschieden worden war.

Ohne externe Tools konnte ich einfach nicht so viele Claude-Instanzen gleichzeitig verwalten. Da klickte es: Dies war kein KI-Problem, es war ein Management-Problem.

GitHub ist bereits das natürliche Tool für Zusammenarbeit in der Softwareentwicklung, also erfand ich nicht etwas Neues, sondern begann Claude genauso zu behandeln wie einen menschlichen Teamkollegen. Sobald ich das tat, skalierte meine Management-Bandbreite plötzlich.

Zehn Jahre Projekt- und Teammanagement-Erfahrung ergaben plötzlich Sinn in diesem neuen Kontext. Indem ich Claude als Teammitglied und GitHub als unseren gemeinsamen Kommunikations- und Managementraum behandelte, wurde das ganze System wieder handhabbar.

Ein guter Teamleiter weiß, wann er eingreifen und wann er einen Schritt zurücktreten muss:

Checkpoint	Was ich mache	Was die KI macht
Anforderungen	Problem abstimmen, Umfang klären	Codebasis recherchieren, Kontext sammeln
Richtung	Erkenntnisse überprüfen, Ansatz genehmigen	2-3 Ansätze vorschlagen, Trade-offs bewerten
Abnahme	PR überprüfen, Qualität verifizieren	Implementieren, testen, CI fixen

Dies spiegelt wider, wie effektive Software-Teams arbeiten. Ich mikromanage Entwickler nicht, sondern setze klare Anforderungen, überprüfe Schlüsselentscheidungen und verifiziere die finale Ausgabe. Das gleiche Prinzip gilt beim Management von KI-Agenten.

Der Deep-Dive-Flow erzwingt strukturiertes, langsames Denken

Der Deep-Dive-Workflow erzwingt bewusstes Denken vor der Implementierung. Manchmal läuft Claude in eine Sackgasse. Wenn das passiert, zwingen wir Claude zum Stoppen und Nachdenken und sprechen es dann gemeinsam durch. Er hat drei Phasen:

Phase	Befehl	Zweck	Output
Research	/deep-research	Fakten sammeln, Kontext verstehen	research.md
Innovate	/deep-innovation	Mehrere Ansätze erkunden	innovate.md
Plan	/deep-plan	Konkrete Schritte definieren	plan.md

Jede Phase hat strikte Grenzen.

Research: keine Vorschläge
Innovate: keine Details
Plan: keine Implementierung

Diese Einschränkungen zwingen Claude zu langsamer, bewusster Überlegung, anstatt direkt zum Code zu springen. Ohne sie werden Randfälle und architektonische Belange oft übersehen!

Verwendungsbeispiel

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude researches, analyzes 12 related files, finds 3 similar patterns]

/deep-innovate what are our options for fixing this?

[Claude presents 3 approaches with trade-offs, you pick one]

/issue-create let's track this fix

Für einfache Aufgaben können Sie den Deep Dive überspringen und direkt zu /issue-create gehen.

Für komplexe Aufgaben mit technischer Unsicherheit helfen die Deep-Dive-Phasen sicherzustellen, dass Sie und Claude abgestimmt sind, bevor die Implementierung beginnt.

GitHub als gemeinsamen Speicher nutzen

Die meisten KI-Tools behandeln Kontext als temporär. Wenn die Session endet, verschwindet der Speicher.

VM0 nutzt GitHub als persistenten Speicher:

GitHub-Feature	Was es speichert
Issue-Body	Anforderungen und Entscheidungen
Issue-Kommentare	Research, Optionen, Pläne
PR-Kommentare	Reviews und Zusammenfassungen
Labels	Workflow-Status

Dies löst auch ein menschliches Problem: Kontextwiederherstellung.

Wenn ich 8+ Claude-Instanzen manage, erhalte ich Benachrichtigungen, dass Arbeit abgeschlossen ist. Aber ich kann aus Claudes Konversation nicht rekonstruieren, was es tat, welche Entscheidungen getroffen wurden oder was der aktuelle Status ist.

GitHub Issues lösen das. Jedes Issue zeigt:

Die ursprünglichen Anforderungen
Research-Erkenntnisse (was entdeckt wurde)
Innovationsphase (welche Optionen erwogen wurden)
Den genehmigten Plan (was implementiert wird)

Dieses strukturierte Format macht das Review effizient. Ich kann schnell die Phasen überfliegen, den Ansatz verstehen und genehmigen oder Änderungen anfordern, alles ohne mich an die ursprüngliche Konversation erinnern zu müssen.

Wenn Arbeit abgeschlossen ist, muss ich mich nicht erinnern, was in einem Chatfenster passiert ist. Ich kann das Issue öffnen und die ganze Story sehen, strukturiert und aufgeschrieben.

Übergabe zwischen Agenten

Weil der gesamte Kontext in GitHub lebt, kann Arbeit nahtlos zwischen Agenten wechseln:

Ein Agent erstellt ein Issue oder PR
Ein anderer macht später weiter mit /deep-research issue 123 oder /issue-todo 123 oder /deep-research PR 124

Für lange Diskussionen konsolidiert /issue-compact alles in einen sauberen Issue-Body. Das macht Übergaben sowohl für Menschen als auch für KI einfach.

Zusammenfassung der Workflow-Muster

Nach all dem fasse ich ein paar praktische Tipps zusammen.

Einfache Aufgaben

/issue-create → /issue-todo → /issue-continue → /pr-check-and-merge

Verwenden Sie dies, wenn die Anforderungen klar und die Arbeit unkompliziert ist.

Komplexe Aufgaben

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-todo → /issue-continue →
/pr-review-and-comment → /pr-check-and-merge

Dies verhindert verschwendete Mühe für den falschen Ansatz.

Parallele Arbeit

Mehrere Agenten können gleichzeitig arbeiten, während der Mensch abgeschlossene Checkpoints überprüft. Hier skaliert der Workflow am besten.

Agent 1: /issue-todo #123
Agent 2: /issue-todo #124
Agent 3: /pr-review-and-comment #100
Agent 4: /deep-research new feature requirements

Befehlsreferenz

Deep-Dive-Befehle

Befehl	Zweck
`/deep-research`	Informationen sammeln, Codebasis verstehen. Keine Vorschläge erlaubt.
`/deep-innovate`	2-3 Ansätze erkunden, Trade-offs bewerten. Kein Code erlaubt.
`/deep-plan`	Konkrete Implementierungsschritte erstellen. Keine Implementierung erlaubt.

Issue-Befehle

Befehl	Zweck
`/issue-create`	Issue aus Gesprächskontext erstellen
`/issue-bug`	Bug-Report mit Reproduktionsschritten erstellen
`/issue-feature`	Feature-Request fokussiert auf Anforderungen erstellen
`/issue-todo`	Vollständigen Deep-Dive-Workflow ausführen, Ergebnisse zum Issue posten
`/issue-continue`	Implementierung nach menschlicher Genehmigung fortsetzen
`/issue-compact`	Issue-Body + Kommentare für Übergabe konsolidieren

PR-Befehle

Befehl	Zweck
`/pr-check`	CI-Pipeline überwachen, automatisch fixen, bis zu 3x wiederholen
`/pr-check-and-merge`	CI überwachen und mergen, wenn alle Checks bestehen
`/pr-review`	PR Commit-für-Commit gegen Projektstandards reviewen
`/pr-review-and-comment`	Reviewen und Ergebnisse als PR-Kommentar posten
`/pr-comment`	Konversationsdiskussion als PR-Kommentar zusammenfassen

Erste Schritte

Einfach starten: Verwenden Sie /issue-create → /issue-todo → /issue-continue für Ihre erste Aufgabe
Deep Dive für komplexe Aufgaben hinzufügen: Wenn Anforderungen unklar oder technisch komplex sind, beginnen Sie mit /deep-research
Graduell skalieren: Fügen Sie mehr Claude-Instanzen hinzu, wenn Sie sich mit dem Review-Rhythmus wohlfühlen
Dem Prozess vertrauen: Lassen Sie Claude zwischen Checkpoints autonom arbeiten

Der Workflow ist für inkrementelle Einführung konzipiert. Sie müssen nicht alle 14 Befehle vom ersten Tag an verwenden. Beginnen Sie mit dem grundlegenden Issue-Flow und fügen Sie dann Deep-Dive-Phasen und parallele Arbeit hinzu, wenn Sie Vertrauen gewinnen.

Skalierungsüberlegungen: Was tun, wenn Sie mehr Agenten haben

Der Workflow wurde mit 10+ gleichzeitigen Claude-Instanzen getestet. Unsere Empfehlung:

Bis zu 10 Agenten: Komfortabel für tiefe Zusammenarbeit mit jedem
Über 10 hinaus: Nicht empfohlen

Der limitierende Faktor ist nicht der Workflow, sondern menschliche Aufmerksamkeit und Entscheidungsqualität. Wenn Sie mehr als 10 Agenten verwalten, riskieren Sie, ein Engpass bei Review-Checkpoints zu werden, und die Entscheidungsqualität beginnt zu sinken.

Das klassische "Zwei-Pizza-Team"-Prinzip gilt hier. Die gleichen Beschränkungen, die menschliche Teamgröße limitieren, limitieren auch, wie viele KI-Agenten eine Person effektiv managen kann.

Ich erkunde derzeit eine 8×8-Zwei-Ebenen-Teamstruktur für Skalierung über 10 Agenten hinaus, habe aber noch keine effektiven Praktiken entwickelt. Ich werde mehr teilen, wenn es konkrete Ergebnisse gibt…

Der VM0-Entwicklungsworkflow verändert, wie wir über Softwareentwicklung denken, wenn KI Teil des Teams wird.

Wenn Sie KI-Agenten als Teammitglieder statt als Tools behandeln, fügt sich alles zusammen. GitHub wird zum gemeinsamen Speicher Ihres Teams. Issues werden zu Arbeitsaufgaben. PRs werden zu Deliverables. Und Sie werden zum Teamleiter, der sich auf Architektur, Richtung und Qualität konzentriert, während Ihr KI-Team die Implementierung übernimmt.

So haben wir 404 Releases in 2 Monaten ausgeliefert. Und so können Sie Ihre eigene Entwicklung mit KI skalieren.