Gemini Conductor: Googles neues Tool soll KI-Programmierung reparieren

Der Sprecher stellt Googles neuen Context-Engineering-Workflow 'Gemini Conductor' vor und gibt direkt zu, dass dieser nicht besser als andere verfügbare Workflows ist. Es werden verschiedene Probleme angedeutet, die selbst innerhalb des Gemini-Ökosystems die Qualität beeinträchtigen. Nach dieser kritischen Einschätzung folgt eine Werbeunterbrechung für Automata, ein Unternehmen, das KI-basierte Entwicklungs-Workflows implementiert. Automata positioniert sich als technischer Co-Pilot, der Ideen in funktionierende Apps und Websites verwandelt, ohne dass ein eigenes Entwicklerteam benötigt wird.

Der Sprecher erklärt, wie Conductor als Erweiterung in Gemini CLI installiert wird und welche grundlegenden Konzepte verwendet werden. Erweiterungen sind Befehlssätze, MCPs und Regeln, die gebündelt und als Paket geteilt werden können - ähnlich wie Claude's Plugins. Nach der Installation mit einem Befehl stehen fünf Slash-Befehle zur Verfügung, die den Workflow steuern. Der Setup-Befehl ist der erste Schritt, der prüft, ob bereits Conductor-Dateien existieren und ob ein Projekt initialisiert wurde. Anstelle von 'Stories' verwendet Conductor 'Tracks', die nacheinander vervollständigt werden, und initialisiert ein neues GitHub-Repository.

Für den Test wurde ein einfaches Projekt erstellt, wobei der Sprecher bewusst angab, dass es produktionsreif und für viele Benutzer skalierbar sein sollte, um die Qualität der Architekturempfehlungen zu prüfen. Conductor erstellte eine product.md-Datei mit dem Konzept und stellte Fragen zur Verfeinerung, die jedoch simpel waren und nirgendwohin führten. Daraufhin wurden Produktrichtlinien für Styling und Designprinzipien erstellt. Bei der Definition des Technologie-Stacks zeigte sich ein Hauptproblem: Obwohl Conductor das gesamte Projekt kannte, empfahl es keinen angemessenen Tech-Stack. Nach manueller Korrektur wurden auch Code-Style-Guides für die verwendeten Programmiersprachen hinzugefügt.

Der Standard-Workflow von Conductor beinhaltet einige positive Aspekte: 80% Code-Test-Abdeckung ist standardmäßig aktiviert, und beim Schreiben von Basiskomponenten werden auch Tests erstellt. Nach Abschluss jeder Aufgabe werden Änderungen committet und Git-Notes verwendet, um nachzuvollziehen, wo Fehler auftraten. Nach dem initialen Setup werden übergeordnete Produktanforderungen erstellt, die in Tracks umgesetzt werden. Der erste Track war jedoch zu breit gefasst und musste in kleinere Einheiten aufgeteilt werden. Jeder Track besteht aus zwei Dateien: plan.md mit den konkreten Aufgaben und spec.md mit Zielen und technischen Details aus dem Tech-Stack.

Mit dem Implement-Befehl beginnt die eigentliche Arbeit, wobei Conductor die Tracks nacheinander aus dem Tracks-Ordner implementiert. Der Status jedes Tracks wird verfolgt: leer bedeutet nicht gestartet, eine Markierung zeigt 'in Bearbeitung' an, und eine andere Markierung signalisiert Abschluss. Der Status-Befehl gibt einen Überblick über laufende und abgeschlossene Tracks. Der New-Track-Befehl ermöglicht das Hinzufügen neuer Aufgaben. Bei Tests in einem bereits vorhandenen Repository lief der Prozess ähnlich ab, allerdings mit Blick auf bestehende Dateien und nur klärenden Fragen - neue Tracks mussten jedoch manuell als Features implementiert werden. Der Revert-Befehl nutzt Git-Bewusstsein, um Fehler des Agents rückgängig zu machen.

Das Dateimanagement und die Struktur von Conductor sind durchaus solide - die Implementierung von Features in Tracks und deren Nachverfolgung funktioniert gut. Jedoch weisen die Anweisungen und Befehlsdateien erhebliche Mängel auf, besonders bei der Verwaltung der Kontextschleife für Überprüfungen und Änderungen. Während des initialen Prozesses traten zahlreiche Fehler auf: Die Idee wurde bei der Dokumenterstellung nicht richtig zerlegt, was viel manuelle Führung erforderte. Beim Technologie-Stack wurden viele wichtige Komponenten für eine skalierbare App mit vielen Benutzern übersehen und mussten explizit nachgefordert werden. Das generierte Datenbankschema im ersten Track war völlig unvollständig und verfehlte entscheidende Elemente für die App-Einrichtung.

Obwohl Gemini ein gutes Modell ist, lassen die implementierten Befehle - besonders in der workflow.md - den Agent problematisch agieren. Ein katastrophaler Fehler trat auf, als der Sprecher nachträglich von NPM zu PNPM wechseln wollte: Conductor versuchte ein Backup zu erstellen und sollte nur NPM-Dateien entfernen, löschte aber stattdessen den gesamten Conductor-Ordner mit allen Planungsdateien. Danach suchte es kontinuierlich nach dem Ordner, und als es ihn nicht fand, versuchte es, alles aus dem Kontext und Speicher neu zu schreiben. Dies widerspricht dem Prinzip eines normalen Kontext-Workflows, bei dem Änderungen nur die Hauptkontextdateien und spezifisch betroffene Dateien betreffen sollten - wie es Be Mad effizient praktiziert.

Bei der Initialisierung des Projekts und der ersten Aufgabe traten weitere Probleme auf: Beim Konfigurieren der Umgebungsvariablen für die Supabase-Verbindung markierte Conductor die Aufgabe automatisch als abgeschlossen, obwohl nur ein Dummy-Schlüssel eingefügt wurde. Es forderte weder zur Einrichtung des Supabase-Projekts auf noch zur Bereitstellung eines echten Schlüssels, versuchte aber trotzdem, das Datenbankschema zu pushen, was natürlich fehlschlug. Die Aufgaben wurden nicht ordnungsgemäß aktualisiert oder korrekt befolgt. Der Sprecher kommt zum Fazit, dass er Conductor derzeit nicht für End-to-End-Spec-Entwicklung empfehlen würde - Be Mad sei die deutlich bessere Option, und für kleine Projekte erstellt er weiterhin eigene Kontextdateien. Das Video schließt mit einem Dank an die Zuschauer und dem Hinweis auf den Super-Thanks-Button zur Unterstützung des Kanals.