Ich habe Buzz gerade bei mir installiert und darin einen Kanal mit Codex und Devin eingerichtet. Mein Test war bewusst klein: Die beiden Agenten sollten gemeinsam eine Anwendung entwickeln. Das Ergebnis hat mich nicht nur technisch überzeugt. Es hat mir vor allem gezeigt, wie anders sich Softwareentwicklung anfühlt, wenn KI-Agenten im selben Arbeitsraum zusammenkommen.
Codex und Devin sind für sich genommen bereits leistungsfähige Coding-Agenten. Neu war für mich die Zusammenarbeit in einem gemeinsamen Kanal. Ich musste nicht zwei getrennte Sitzungen führen, Kontext kopieren und Zwischenergebnisse manuell zwischen den Systemen transportieren. Das Projekt, die Diskussion und die Arbeit der Agenten waren an einem Ort sichtbar.
Mein Aha-Moment: Nicht der einzelne Agent bildete das Team. Erst der gemeinsame Kontext machte aus mehreren spezialisierten Systemen eine zusammenhängende Arbeitsumgebung.
Buzz denkt nicht vom einzelnen Chat aus
Buzz beschreibt sich selbst als nativen Workspace für Teams aus Menschen und Agenten. Menschen, Kontext, Entscheidungen und nächste Schritte sollen in einem gemeinsamen Raum bleiben. Spezialisierte Agenten können in die Unterhaltung eingeladen werden, ihre Ergebnisse vergleichen, Arbeit aufteilen und auf demselben Projektkontext aufbauen. Aus der Diskussion sollen anschließend Planung, Code, Reviews und Pull Requests entstehen können.
Genau dieser Perspektivwechsel ist wichtig. Viele KI-Werkzeuge beginnen mit einer leeren Eingabezeile: Ich formuliere eine Aufgabe, ein Agent arbeitet, und am Ende erhalte ich eine Antwort oder einen Diff. Das funktioniert gut, bleibt aber häufig eine Beziehung zwischen einem Menschen und einem Werkzeug. Sobald mehrere Agenten beteiligt sind, wird der Mensch schnell zum manuellen Router für Informationen.
Ein gemeinsamer Workspace verschiebt diese Aufgabe. Kontext muss nicht ständig zwischen voneinander getrennten Oberflächen bewegt werden. Entscheidungen werden Teil des Arbeitsraums, nicht nur Teil meines Gedächtnisses. Dadurch entsteht zumindest die Grundlage für echte Arbeitsteilung.
Mein erster Test: klein genug zum Beobachten
Für meinen ersten Versuch habe ich absichtlich keine große oder geschäftskritische Anwendung gewählt. Ich wollte nicht testen, ob zwei Agenten möglichst viel Code erzeugen können. Mich interessierte, ob die Zusammenarbeit verständlich bleibt und ob aus einer gemeinsamen Aufgabenstellung ein brauchbares Ergebnis entsteht.
Ich erstellte einen Kanal, holte Codex und Devin hinzu und ließ sie gemeinsam an einer kleinen Testanwendung arbeiten. Das funktionierte erstaunlich gut. Besonders überzeugend war für mich, dass die Systeme nicht wie zwei vollständig getrennte Werkzeuge wirkten. Ihre Beiträge waren Teil desselben Projektverlaufs.
Ein einzelner erfolgreicher Test ist noch kein belastbarer Benchmark. Ich habe damit weder Qualität, Kosten noch Geschwindigkeit systematisch gegen eine Entwicklung ohne Buzz verglichen. Trotzdem war der Versuch aussagekräftig: Die Zusammenarbeit war praktisch nutzbar und nicht nur eine interessante Produktdemo.
Die Frage lautet nicht mehr nur: Welcher Agent ist der beste?
Codex ist laut OpenAI für End-to-End-Engineering-Aufgaben ausgelegt: von Features und Refactorings bis zu Migrationen und Code Reviews. OpenAI positioniert Codex ausdrücklich auch für parallele Multi-Agent-Workflows. Devin wiederum wird als KI-Softwareentwickler für komplexe Engineering-Aufgaben, Pull Requests, Migrationen, Tests und länger laufende Arbeit beschrieben.
Claude Code ergänzt dieses Spektrum als agentisches Coding-Werkzeug im Terminal. Für mich sind Codex, Claude Code und Devin deshalb nicht zwingend drei austauschbare Produkte, von denen am Ende nur eines übrig bleiben darf. Sie können unterschiedliche Arbeitsstile, Integrationen und Stärken abdecken.
Die interessantere Frage lautet: Wie setze ich welches System für welche Rolle ein? Ein Agent kann eine Architektur oder einen bestehenden Codebestand analysieren, ein anderer ein klar umrissenes Arbeitspaket umsetzen, ein dritter Tests, Review oder Dokumentation übernehmen. Der Mensch muss dann nicht jedes Detail selbst ausführen, aber weiterhin Ziel, Grenzen und Qualitätsmaßstab bestimmen.
Gemeinsamer Kontext ist mehr als Bequemlichkeit
Bei der Arbeit mit mehreren KI-Systemen ist Kontext schnell der Engpass. Jeder Agent sieht zunächst nur den Ausschnitt, den er erhält. Fehlen Anforderungen, frühere Entscheidungen oder die Begründung für eine technische Grenze, kann ein lokal plausibles Ergebnis dem eigentlichen Projektziel widersprechen.
Ein gemeinsamer Kanal löst nicht automatisch jedes Context-Engineering-Problem. Repositories, Spezifikationen, Tests, Berechtigungen und Definition of Done müssen weiterhin sauber gepflegt werden. Aber der Arbeitsraum reduziert Reibung: Agenten und Menschen können sich auf dieselbe Diskussion beziehen, statt eine wachsende Kette aus kopierten Prompts und Zusammenfassungen zu erzeugen.
Für mich liegt hier der größere Wert von Buzz. Die Oberfläche ist nicht nur ein weiterer Zugang zu einem Modell. Sie kann zur Koordinationsschicht werden, in der mehrere Menschen und Agenten ihre Arbeit auf einen gemeinsamen Stand beziehen.
Der Mensch verschwindet nicht – seine Rolle verändert sich
Meine Begeisterung über den Test bedeutet nicht, dass ich die Verantwortung an die Agenten abgebe. Gerade wenn mehrere Systeme gemeinsam arbeiten, braucht es klare Leitplanken. Wer darf Dateien verändern? Wer darf einen Pull Request eröffnen oder mergen? Welche Tests müssen erfolgreich sein? Wie erkenne ich, welcher Agent eine Entscheidung getroffen hat?
Der Mensch wird in dieser Arbeitsweise stärker zum Auftraggeber, Architekten und Reviewer. Er muss nicht jeden Arbeitsschritt selbst erledigen, aber er verantwortet weiterhin das Ergebnis. Das ist anspruchsvoller als einfaches Prompting: Gute Aufgaben müssen zerlegbar sein, Abnahmekriterien brauchen Klarheit und widersprüchliche Agentenergebnisse müssen bewertet werden.
Auch Kosten und Laufzeiten gehören dazu. Zwei Agenten sind nicht automatisch wirtschaftlicher als einer. Wenn beide dieselbe Arbeit wiederholen oder sich gegenseitig umfangreichen Kontext zuspielen, kann die Zusammenarbeit teurer werden. Der Mehrwert entsteht erst durch sinnvolle Rollen, gute Übergaben und überprüfbare Ergebnisse.
Was ich als Nächstes ausprobieren möchte
Der erste Test hat bei mir mehr Fragen geöffnet als geschlossen – im positiven Sinne. Mich interessiert nun, wie stabil die Zusammenarbeit bei größeren Repositories und über mehrere Tage hinweg bleibt. Ebenso spannend ist, ob sich Rollen gezielt definieren lassen: beispielsweise ein Agent für Implementierung, einer für Review und einer für Dokumentation oder Architekturfragen.
Ich möchte außerdem beobachten, wie gut Entscheidungen nachvollziehbar bleiben, wenn mehr Agenten und Menschen beteiligt sind. Für den produktiven Einsatz werden Berechtigungen, Auditierbarkeit, Kostenkontrolle und ein sauberer Umgang mit parallelen Änderungen entscheidend sein.
Mein Fazit: Der nächste Schritt im KI-Coding ist für mich nicht einfach ein noch leistungsfähigeres Einzelwerkzeug. Es sind Arbeitsräume, in denen Menschen und spezialisierte Agenten gemeinsam planen, entwickeln und prüfen können. Mein erster Versuch mit Buzz, Codex und Devin war klein – aber er hat dieses Zukunftsbild überraschend konkret gemacht.