Ein Entwicklungsprojekt aus der Westschweiz sorgt derzeit für Aufmerksamkeit: Ein Entwickler hat mit rund 15 KI-Agenten einen digitalen Zwilling der Stadt Genf gebaut – also ein digitales Abbild realer Strukturen, das sich am Rechner betrachten und auswerten lässt. Bemerkenswert ist weniger das Ergebnis als die Arbeitsweise. Der Mensch hat dabei im Wesentlichen Regie geführt und nicht mehr jede Zeile selbst geschrieben.

Für Projekte, die neben dem Tagesgeschäft entstehen, ist das ein relevanter Hinweis. Wer komplexe Software im Alleingang schreibt, stößt üblicherweise nach wenigen Wochen an eine zeitliche Grenze. Verteilt sich die Umsetzung auf mehrere parallel arbeitende Agenten, verschiebt sich diese Grenze – allerdings nicht beliebig und nicht ohne neue Anforderungen an die Steuerung.

Was Agenten-Orchestrierung praktisch heißt

Ein KI-Agent ist, vereinfacht gesagt, ein Sprachmodell, das nicht nur Text ausgibt, sondern eigenständig Arbeitsschritte ausführt: Dateien lesen und schreiben, Code erzeugen, Tests starten, Ergebnisse prüfen. Orchestrierung bezeichnet die Koordination mehrerer solcher Agenten, die an verschiedenen Teilaufgaben desselben Projekts arbeiten.

Die Rollenverteilung ähnelt dabei eher einem Team als einem Werkzeug. Ein Agent kümmert sich um die Datenaufbereitung, ein zweiter um die Darstellung, ein dritter um Tests, ein vierter um Dokumentation. Die menschliche Aufgabe verlagert sich von der Implementierung zur Spezifikation: Was genau soll entstehen, in welcher Reihenfolge, nach welchen Kriterien gilt ein Teilergebnis als fertig?

Genau hier liegt der eigentliche Aufwand. Agenten arbeiten schnell, aber sie arbeiten entlang dessen, was ihnen vorgegeben wurde. Unklare Vorgaben führen zu Code, der technisch funktioniert, fachlich aber am Ziel vorbeigeht – und das in hoher Geschwindigkeit und in mehreren Teilbereichen gleichzeitig.

Warum Geschwindigkeit nicht automatisch Qualität ist

Der naheliegende Schluss aus solchen Projekten lautet: Entwicklung wird billiger und schneller. Diese Rechnung greift zu kurz. Was sich beschleunigt, ist die Strecke von der Idee zum lauffähigen Prototyp. Was unverändert bleibt, ist der Bedarf an fachlicher Steuerung, Review und Qualitätssicherung.

In der Praxis bedeutet das vor allem: Prüfaufwand verlagert sich nach hinten. Wenn mehrere Agenten parallel Code produzieren, entsteht in kurzer Zeit eine erhebliche Menge an Änderungen, die niemand mehr zeilenweise liest. Teams brauchen deshalb automatisierte Sicherungsnetze – Tests, statische Codeanalyse, klare Schnittstellen zwischen Modulen –, damit Fehler früh auffallen und nicht erst im Betrieb.

Hinzu kommt die Frage der Wartbarkeit. Ein Prototyp, der nach wenigen Wochenenden funktioniert, ist nicht automatisch ein System, das sich über Jahre betreiben, erweitern und von wechselnden Personen pflegen lässt. Der Unterschied zwischen beidem entscheidet darüber, ob ein Projekt eine Demo bleibt oder produktiv geht.

Was sich für die Projektplanung ändert

Für Unternehmen, die Softwarevorhaben beauftragen oder intern verantworten, ergeben sich aus dieser Entwicklung mehrere konkrete Konsequenzen.

  • Prototypen werden günstiger als Entscheidungsgrundlage. Statt lange über Varianten zu diskutieren, lässt sich eine Idee schneller sichtbar machen und dann bewerten.
  • Die Anforderungsarbeit gewinnt an Gewicht. Je präziser Ziele, Datenquellen und Abnahmekriterien beschrieben sind, desto brauchbarer sind die Ergebnisse der Agenten.
  • Review-Kapazität wird zum Engpass. Nicht die Codeerzeugung limitiert das Tempo, sondern die Fähigkeit, Ergebnisse fachlich zu beurteilen.
  • Architekturentscheidungen bleiben menschlich. Fragen nach Datenhaltung, Schnittstellen, Betrieb und Sicherheit lassen sich nicht an einen Agenten delegieren, weil sie den Rahmen vorgeben, in dem Agenten überhaupt arbeiten.

Sinnvoll ist deshalb ein gestuftes Vorgehen: zuerst ein Prototyp, der eine Hypothese prüft, dann eine bewusste Entscheidung darüber, ob und in welcher Form dieser Prototyp zur Grundlage eines produktiven Systems wird. Diese Entscheidung sollte explizit getroffen werden – nicht dadurch entstehen, dass ein Demonstrator stillschweigend in den Regelbetrieb rutscht.

Grenzen und offene Fragen

Ein einzelnes Projekt belegt keine allgemeine Regel. Dass eine Person mit mehreren Agenten ein anspruchsvolles Vorhaben umsetzen konnte, sagt zunächst etwas über diesen Anwendungsfall aus. Wie gut der Ansatz in Umgebungen mit gewachsenem Altcode, strengen Compliance-Anforderungen oder vielen Beteiligten funktioniert, ist damit nicht beantwortet.

Ebenso offen bleiben Fragen nach Kosten und Nachvollziehbarkeit. Mehrere Agenten parallel laufen zu lassen, verursacht laufenden Aufwand, und die Entstehungsgeschichte einer Codebasis ist schwerer zu rekonstruieren, wenn große Teile automatisiert erzeugt wurden. Für Audits, Übergaben und Fehlersuche ist das relevant.

Vernünftig ist daher ein nüchterner Umgang: Agenten-Orchestrierung als Methode betrachten, die bestimmte Arbeitsschritte deutlich beschleunigt, andere aber nicht ersetzt. Wer sie einführt, sollte zuerst die eigenen Prüfprozesse ertüchtigen und erst dann die Produktionsgeschwindigkeit erhöhen.

Einordnung für Web- und Softwareprojekte

Für Web- und Softwarevorhaben verschiebt sich der Schwerpunkt der Projektarbeit: Die Umsetzung einzelner Funktionen wird weniger zum Flaschenhals, während klare Anforderungen, saubere Architektur und belastbare Abnahmen an Gewicht gewinnen. Kundinnen und Kunden profitieren vor allem davon, dass Ideen schneller in prüfbare Zwischenstände übersetzt werden können. Der Bedarf an erfahrener fachlicher Begleitung sinkt dadurch nicht – er verlagert sich von der Tastatur in die Steuerung und Qualitätssicherung.

Quellen