Google Conductor: KI-gestütztes Coding mit Struktur

Wer mit KI-Coding-Tools arbeitet, kennt das Problem: Nach einer Stunde ist der Kontext weg, der KI-Agent hat längst vergessen, welche Architekturentscheidungen du getroffen hast, und du erklärst zum dritten Mal dein Testing-Setup. Google hat mit Conductor eine Erweiterung für Gemini CLI veröffentlicht, die genau dieses Problem löst.

Conductor speichert dein Projektwissen nicht im flüchtigen Chat, sondern direkt als Markdown-Dateien in deinem Repository. Das Ergebnis: Der KI-Agent arbeitet mit persistentem Kontext, erstellt Pläne vor der Implementierung und hält sich an deine Vorgaben. Für Entwickler und Teams bedeutet das weniger Wiederholung, mehr Kontrolle und reproduzierbare Ergebnisse.

Dieser Artikel zeigt dir, wie Conductor funktioniert, wie du es einrichtest und warum der "Plan-first"-Ansatz deinen Entwicklungsworkflow verbessern kann.

Was Google Conductor von klassischen KI-Coding-Tools unterscheidet

Die meisten KI-Assistenten für Entwickler arbeiten sitzungsbasiert. Du gibst einen Prompt ein, erhältst Code zurück, und beim nächsten Gespräch startest du wieder bei null. Das funktioniert für kleine Aufgaben, scheitert aber bei größeren Projekten.

Conductor verfolgt einen anderen Ansatz, den Google als "Context-Driven Development" bezeichnet. Statt den Kontext in temporären Chat-Logs zu speichern, erstellt Conductor eine persistente Wissensbasis direkt im Code-Repository. Diese besteht aus strukturierten Markdown-Dateien, die der KI-Agent bei jedem Aufruf liest.

Der Entwicklungszyklus folgt dabei einem festen Schema: Kontext definieren, Spezifikation und Plan erstellen, dann erst implementieren. Das klingt nach klassischem Software Engineering, das KI-Tools bisher oft übersprungen haben.

Konkret bedeutet das: Bevor Conductor eine Zeile Code schreibt, existiert eine dokumentierte Spezifikation. Du weißt genau, was implementiert wird, und kannst den Plan vor der Umsetzung prüfen und anpassen.

Installation und erste Einrichtung

Conductor ist eine Erweiterung für Gemini CLI und wird mit einem einzigen Befehl installiert:

gemini extensions install https://github.com/gemini-cli-extensions/conductor --auto-update

Das --auto-update Flag sorgt dafür, dass Conductor automatisch aktualisiert wird, wenn neue Versionen erscheinen. Nach der Installation stehen die Conductor-Befehle in jedem Projektverzeichnis zur Verfügung.

Der erste Schritt in einem neuen Projekt ist das Setup. Mit /conductor:setup startest du eine interaktive Session, in der Conductor dein Projekt analysiert und dir strukturierte Fragen stellt. Dabei geht es um das Produkt, die Zielgruppe, technische Entscheidungen und Arbeitsweisen im Team.

Aus deinen Antworten generiert Conductor ein conductor/-Verzeichnis mit mehreren Dateien: product.md beschreibt, was du baust. tech-stack.md dokumentiert deine technischen Entscheidungen. workflow.md enthält deine Arbeitspräferenzen, etwa ob du Test-Driven Development bevorzugst. Zusätzlich können Style-Guides für verschiedene Sprachen hinterlegt werden.

Diese Dateien sind normaler Code, der mit Git versioniert wird. Änderungen am Projektkontext durchlaufen denselben Review-Prozess wie alle anderen Code-Änderungen.

Das Track-System: Arbeit in strukturierten Einheiten

Conductor organisiert Arbeit in sogenannten "Tracks". Ein Track repräsentiert eine abgeschlossene Arbeitseinheit wie ein neues Feature oder eine Bugfix-Reihe. Für jeden Track erstellt Conductor zwei zentrale Dokumente.

Die Spezifikation (spec.md) beschreibt detailliert, was implementiert werden soll und warum. Der Plan (plan.md) enthält eine konkrete Schritt-für-Schritt-Anleitung mit Phasen, Aufgaben und Teilaufgaben.

Um einen neuen Track zu starten, verwendest du den Befehl:

/conductor:newTrack "Dark Mode für die Einstellungsseite implementieren"

Conductor analysiert dann deinen bestehenden Projektkontext und erstellt einen Entwurf für Spezifikation und Plan. Du kannst diese Dokumente prüfen, anpassen und erst dann mit der Implementierung beginnen.

Dieses Vorgehen hat einen entscheidenden Vorteil: Du siehst vorab, was der KI-Agent plant, und kannst korrigieren, bevor eine einzige Zeile Code geschrieben wird. Das spart Zeit, die sonst für das Rückgängigmachen fehlgeleiteter Implementierungen draufgeht.

Implementierung mit Checkpoints

Sobald du den Plan freigibst, startest du die Implementierung mit /conductor:implement. Der KI-Agent arbeitet nun systematisch durch den Plan und markiert abgeschlossene Aufgaben direkt in der plan.md.

Der Workflow folgt dabei deinen definierten Präferenzen. Wenn du Test-Driven Development konfiguriert hast, schreibt Conductor erst den Test, lässt ihn fehlschlagen, implementiert dann die Funktionalität und verifiziert, dass der Test besteht.

Zwischen den Phasen fügt Conductor Checkpoints ein. An diesen Punkten pausiert die automatische Ausführung, und du kannst den bisherigen Stand prüfen. Das verhindert, dass der Agent große Refactorings durchführt, die du nicht überblicken kannst.

Zusätzliche Befehle unterstützen den Workflow: /conductor:status zeigt den aktuellen Fortschritt. /conductor:review hilft bei der Prüfung abgeschlossener Arbeit. /conductor:revert macht Änderungen auf Track-, Phasen- oder Aufgabenebene rückgängig, ohne dass du Git-Commits manuell suchen musst.

Vorteile für Teams und Unternehmen

Für Einzelentwickler löst Conductor das Kontextproblem. Für Teams bringt die Erweiterung zusätzliche Vorteile, die über die individuelle Produktivität hinausgehen.

Da der Projektkontext als Code im Repository liegt, teilen alle Teammitglieder dieselbe Basis. Egal wer einen Conductor-Befehl ausführt, der KI-Agent arbeitet mit denselben Architekturentscheidungen, Style-Guides und Workflow-Präferenzen. Das reduziert Inkonsistenzen zwischen verschiedenen Features, die von unterschiedlichen Entwicklern gebaut wurden.

Neue Teammitglieder profitieren ebenfalls. Die conductor/-Dateien funktionieren als strukturierte Onboarding-Dokumentation, die gleichzeitig von Menschen und KI-Agenten gelesen wird. Das spart die doppelte Pflege von Wissen, das sonst in separaten Wikis und Agent-Konfigurationen existieren müsste.

Für Compliance-Anforderungen ist die Versionierung wertvoll. Jede Änderung am Projektkontext, an Spezifikationen und Plänen ist nachvollziehbar. Auditoren können prüfen, wie und warum bestimmte Entscheidungen getroffen wurden.

Unternehmen, die bereits Gemini CLI im Einsatz haben, können Conductor ohne zusätzliche Infrastruktur einführen. Die Erweiterung ist Open Source unter Apache-2.0-Lizenz und läuft komplett lokal im Repository.

Token-Verbrauch und Kostenüberlegungen

Ein Punkt verdient besondere Aufmerksamkeit: Conductor liest bei jedem Aufruf den gesamten Projektkontext. Bei umfangreichen Projekten mit vielen Style-Guides und komplexen Spezifikationen kann der Token-Verbrauch spürbar steigen.

Google dokumentiert diesen Trade-off offen im Repository. Der Befehl /stats model zeigt den Token-Verbrauch der aktuellen Session. Teams sollten den Kontext bewusst pflegen und nur die tatsächlich benötigten Informationen aufnehmen.

Für die meisten Projekte überwiegt der Nutzen die zusätzlichen Kosten. Die Zeit, die durch fehlenden Kontext verloren geht, kostet mehr als ein paar zusätzliche Tokens. Aber bei Projekten mit sehr knappem Token-Budget ist die Abwägung relevant.

Praktisches Beispiel: Authentifizierung implementieren

Ein konkretes Szenario verdeutlicht den Workflow. Angenommen, du möchtest Google- und GitHub-Authentifizierung zu einer bestehenden Anwendung hinzufügen.

Du startest mit /conductor:newTrack "OAuth-Authentifizierung mit Google und GitHub". Conductor analysiert dein bestehendes Projekt, identifiziert das verwendete Framework und schlägt eine Spezifikation vor. Diese enthält die Anforderungen, die zu unterstützenden Provider und Nicht-Ziele wie etwa, dass Social Sharing nicht Teil dieses Tracks ist.

Nach deiner Freigabe erstellt Conductor einen Plan mit mehreren Phasen: Zuerst die Backend-Infrastruktur, dann die Provider-Integration, schließlich die Frontend-Anbindung. Jede Phase enthält konkrete Aufgaben mit Akzeptanzkriterien.

Mit /conductor:implement beginnt die Umsetzung. Der Agent arbeitet die Aufgaben ab, führt nach deiner Workflow-Konfiguration Tests aus und markiert abgeschlossene Punkte. An Phasengrenzen pausiert er und wartet auf deine Bestätigung.

Am Ende liegt ein vollständig implementiertes Feature vor, dokumentiert durch die Spezifikation und den Plan im Repository. Wenn drei Monate später jemand fragt, warum die Authentifizierung so aufgebaut ist, existiert die Antwort bereits.

Einschränkungen und aktuelle Grenzen

Conductor befindet sich noch in der Preview-Phase, und einige Bereiche entwickeln sich weiter. Die Unterstützung für Brownfield-Projekte, also bestehende Codebasen, funktioniert bereits, wird aber laut Google kontinuierlich verbessert.

Der strukturierte Workflow passt besonders gut zu komplexeren Aufgaben. Für schnelle Einzeiler oder explorative Experimente kann der Overhead zu hoch sein. In solchen Fällen ist die direkte Nutzung von Gemini CLI ohne Conductor sinnvoller.

Die Qualität der Ergebnisse hängt stark vom definierten Kontext ab. Je präziser die product.md, tech-stack.md und Style-Guides sind, desto besser die Pläne und die Implementierung. Das initiale Investment in guten Kontext zahlt sich aus, erfordert aber Zeit.

Vergleich mit alternativen Ansätzen

Der Markt für KI-gestützte Entwicklungswerkzeuge ist aktiv. Cursor, GitHub Copilot und Claude Code verfolgen ähnliche Ziele mit unterschiedlichen Ansätzen.

Conductor unterscheidet sich durch den expliziten Plan-first-Ansatz und die Repository-native Kontextspeicherung. Während andere Tools oft proprietäre Kontextsysteme nutzen, liegt bei Conductor alles als lesbare Markdown-Dateien im Git.

Das hat Vor- und Nachteile. Die Transparenz ist höher, du siehst und kontrollierst genau, was der Agent weiß. Gleichzeitig erfordert die Pflege mehr manuellen Aufwand als automatische Kontexterfassung.

Für Teams, die Wert auf Nachvollziehbarkeit und Kontrolle legen, ist Conductor eine starke Option. Wer schnelle Ergebnisse ohne viel Konfiguration sucht, findet bei anderen Tools möglicherweise einen niedrigeren Einstieg.

Erste Schritte und weiterführende Ressourcen

Der praktische Einstieg ist unkompliziert. Installiere Gemini CLI, füge die Conductor-Erweiterung hinzu und führe /conductor:setup in einem Projekt aus. Die interaktive Einrichtung führt durch die wichtigsten Entscheidungen.

Das GitHub-Repository unter github.com/gemini-cli-extensions/conductor enthält ausführliche Dokumentation, Beispiele und Best Practices. Der Google Developers Blog bietet zusätzliche Hintergründe zur Philosophie hinter Context-Driven Development.

Für Teams empfiehlt sich ein Pilotprojekt, um den Workflow kennenzulernen, bevor Conductor breit eingeführt wird. Die Lernkurve ist überschaubar, aber die beste Konfiguration entsteht durch praktische Erfahrung mit den eigenen Projekten.

Fazit: Struktur für KI-Coding

Google Conductor adressiert ein echtes Problem: Die Flüchtigkeit von Kontext in KI-gestützter Entwicklung. Durch die Verlagerung des Wissens ins Repository und den strukturierten Plan-first-Workflow wird KI-Coding reproduzierbarer und kontrollierbarer.

Die Erweiterung passt besonders gut zu Teams, die bereits Wert auf Dokumentation und strukturierte Prozesse legen. Für sie ist Conductor eine natürliche Erweiterung bestehender Praktiken. Für Einzelentwickler bietet es eine Möglichkeit, auch in längeren Projekten den Überblick zu behalten.

Der nächste logische Schritt: Conductor in einem kleinen Projekt ausprobieren und erleben, wie sich der Workflow anfühlt. Die Installation dauert Minuten, und die Erkenntnisse helfen bei der Entscheidung, ob der Ansatz zur eigenen Arbeitsweise passt.