Der Flaschenhals bin ich

Wer anfängt, agentisch zu arbeiten, erlebt erstmal einen Produktivitätsschub. Ein Agent, ein Task, ein Terminal. Schneller als von Hand, aber noch überschaubar. Dann kommt der zweite Agent dazu, weil der erste gerade arbeitet und man sonst warten würde. Irgendwann der dritte. Und irgendwann merkt man: Man schreibt keinen Code mehr. Man designt Aufgaben, formuliert Anforderungen, prüft Ergebnisse. Die Arbeit hat sich verschoben, vom Handwerk zur Steuerung.

Über die letzten anderthalb Jahre habe ich diesen Übergang begleitet und selbst durchlaufen. Erst bei mir, dann in Kundenprojekten. Und ein Muster zieht sich durch: Der Output skaliert wunderbar. Was nicht mitskaliert, ist die menschliche Kontrolle.

Die Lernkurve ist real

Agentische Arbeit ist eine Fähigkeit die man aufbaut. Am Anfang ist ein einziger Agent genug Kontextwechsel. Das mentale Modell muss sich erst verschieben, weg von “welche Zeile Code schreibe ich als nächstes” hin zu “was ist das Ziel, was sind die Akzeptanzkriterien, welche Dateien sind betroffen”. Je präziser die Delegation, desto besser das Ergebnis, desto weniger Korrekturschleifen.

Wer das verinnerlicht hat, fängt an die Wartezeiten zu nutzen. Agent arbeitet, ich plane den nächsten Task. Oder reviewe den Output vom vorherigen. Man lernt den Rhythmus, man lernt wo Agents typischerweise daneben liegen, man baut Routinen auf.

Aber mit jeder Stufe steigt nicht nur der Output, sondern auch die Last. Drei Agents heißt drei verschiedene Kontexte im Kopf. Drei verschiedene Stände. Drei Entscheidungen die gleichzeitig auf dich warten. Das fühlt sich an wie Fluglotse, nur dass die Flugzeuge schneller werden je besser man wird.

Lest ihr noch den Code?

Diese Frage kam kürzlich in einer internen Diskussion auf. Nicht provokativ gemeint, sondern ehrlich: Wenn ein Agent in zehn Minuten 500 Zeilen Code produziert, wie gründlich schaut man da noch drüber?

Wenn ich ehrlich bin: Wenn Agent drei gerade fertig wird während ich den Output von Agent eins noch prüfe, dann wird das Review oberflächlich. Kompiliert? Tests grün? Sieht vernünftig aus? Weiter. Und das, obwohl ich meine Review-Routinen habe und weiß, wo ich genauer hinschauen muss.

“You build it, you own it” gilt auch für generierten Code. Vielleicht sogar besonders dafür, weil niemand sonst weiß was drinsteht. Nicht mal der, dessen Name im Git Log steht.

Die Frage die sich daraus ergibt, ist strategischer Natur: Welcher Code braucht ein menschliches Review Zeile für Zeile? Wo reicht Test Coverage und Typing? Wo braucht es ein architekturelles Review? In den meisten Projekten die ich sehe, wurde diese Entscheidung nie bewusst getroffen. Es wird generiert und gehofft, dass die Tests es richten.

Die Antwort liegt im Workflow

Die mentale Last lässt sich reduzieren. Aber nicht indem man weniger Agents nutzt, sondern indem man die menschliche Intervention gezielt nach hinten schiebt.

Konkret: Statt jeden Output selbst zu reviewen, baut man Review-Personas in den Workflow ein. Ein Agent der den Code eines anderen Agents auf Security-Patterns prüft. Einer der auf Architektur-Konsistenz schaut. Einer der die Test Coverage bewertet. Jede Persona hat klare Kriterien, und nur wenn alle zufrieden sind, landet das Ergebnis beim Menschen.

Das verändert die Rolle. Statt Fluglotse wird man zum Architekten des Kontrollsystems. Man definiert, was die Agents prüfen sollen, nach welchen Kriterien sie eskalieren, und wo man selbst eingreift. Human-in-the-Loop, aber gezielt und spät statt ständig und früh.

Ich bin damit noch nicht fertig. Aber die Richtung ist klar: Je mehr Qualitätssicherung die Agents untereinander leisten, desto seltener muss ich in die Ergebnisse eingreifen, und desto mehr kann ich mich auf die strategischen Fragen konzentrieren. Welche Features bauen wir? Warum? Passt die Architektur zum Gesamtbild?

Das Team-Problem bleibt

Was sich mit besseren Workflows nicht von allein löst, ist die Isolation.

Vor anderthalb Jahren war Pair Programming normal. Architekturentscheidungen wurden im Team diskutiert. Es gab Wissenstransfer. Jemand konnte sagen: “Halt, das wird so nicht funktionieren.”

In Projekten sehe ich zunehmend, dass jeder seinen eigenen Agent-Stack hat, seine eigene Arbeitsweise, seine eigenen Worktrees. Die Produktivität pro Kopf geht hoch. Die Schnittmenge zwischen den Köpfen geht runter. Der produktivste Einzelkämpfer mit Agent-Flotte schlägt kurzfristig das Team. Langfristig fehlt das Korrektiv.

Das ist kein Anfängerproblem. Gerade die Leute, die gelernt haben Agents effektiv zu steuern, driften am stärksten in dieses Muster. Die Versuchung ist groß: Warum auf ein Team-Review warten, wenn in der gleichen Zeit das nächste Feature fertig sein könnte?

Skalierung braucht Strategie

Agentische Software-Entwicklung skaliert den Output pro Kopf enorm. Wer die Lernkurve durchläuft und sich die richtigen Workflows baut, multipliziert seine Wirkung. Aber zwei Probleme muss man aktiv lösen, sie verschwinden nicht von allein:

Das Review-Problem lässt sich mit Agent-Review-Personas und klaren Eskalationspfaden in den Griff bekommen. Menschliche Kontrolle wird seltener, aber gezielter. Das ist lösbar, wenn man es als Workflow-Design-Aufgabe begreift statt als persönliche Disziplinfrage.

Das Team-Problem ist schwieriger. Wenn Einzelne 10x produktiver werden, verändert das die Teamdynamik. Neue Formate für Wissenstransfer und Architektur-Alignment müssen her, die zur neuen Geschwindigkeit passen. Wie genau das aussieht, weiß ich noch nicht. Aber dass die alten Formate nicht mehr reichen, das sehe ich jeden Tag.

Der Flaschenhals ist nicht das Modell und nicht die Hardware. Der Flaschenhals ist der Mensch. Und die Arbeit besteht darin, ihn gezielt zu entlasten, nicht ihn zu ersetzen.