Der Flaschenhals hat sich verschoben
In der klassischen Softwareentwicklung war das Schreiben von Code der teuerste Schritt. Ticketsysteme, Sprint-Planung und Issue-Tracking existieren, weil menschliche Arbeitszeit knapp und teuer ist. Genau diese Annahme trägt nicht mehr, wenn Coding-Agenten Änderungen in Minuten statt in Tagen erzeugen.
Was übrig bleibt, ist der Pull Request. Also jener Schritt, in dem eine Codeänderung geprüft und in den Hauptzweig übernommen wird. Er ist die letzte Stelle, an der ein Mensch systematisch draufschaut, und damit die Stelle, an der sich Arbeit anstaut. In der Entwickler-Community wird deshalb offen diskutiert, ob Issue-Tracking in seiner heutigen Form noch einen Zweck erfüllt oder nur noch Verwaltung von Dingen ist, die längst erledigt sind. Belastbare Zahlen zu dieser These liegen bislang nicht vor, sie ist eine Beobachtung aus der Praxis und keine Messung.
Merge Gates: vom Kompromiss zum Risiko
Konkreter fassbar ist ein zweiter Punkt. Merge Gates, also automatisierte Prüfschritte vor dem Zusammenführen von Code, waren immer ein Kompromiss zwischen Geschwindigkeit und Sicherheit. Nicht jeder Test lief vor dem Merge, manches wurde bewusst erst danach geprüft. Bei einer Handvoll Pull Requests pro Tag war das vertretbar.
Bei Coding-Agenten kippt diese Rechnung. Was als Kompromiss geplant war, wird zum Risiko, weil das Volumen an Änderungen steigt und die Prüftiefe gleich bleibt.
Dazu kommt ein zweites Problem. Coding-Agenten halten sich häufig nicht an die Contribution Guidelines von Projekten, also an die Regeln, wie Beiträge aussehen und getestet sein müssen. Im Open-Source-Umfeld hat das bereits zu erheblichem Aufwand geführt, als KI-Agenten Open-Source-Projekte auf GitHub mit Beiträgen überzogen. Wer Regeln ignoriert, produziert Arbeit für die Reviewer, nicht weniger.
Verifikation braucht eine echte Laufzeitumgebung
Ein technischer Konsens zeichnet sich ab: Agenten sollen ihren Code selbst ausführen. Anbieter wie Greptile, Cursor und Devin gehen in diese Richtung. Entscheidend ist dabei nicht, dass überhaupt etwas läuft, sondern wogegen es läuft. Bei cloud-nativen Anwendungen mit vielen Diensten, Datenbanken und Abhängigkeiten ist das ein Infrastrukturproblem und keine Frage des Modells.
Genau hier entstehen neue Kostenstellen. Wenn jeder Agent eine eigene, realistische Testumgebung braucht, wachsen Datenbanken und Umgebungen unkontrolliert mit. Für das Thema Werkzeugaufrufe von Agenten entwickelt Amazon mit Dogwood eine Prüfschicht gegen falsche Tool-Aufrufe. Details dazu sind bislang dünn, die Richtung ist aber klar: Verifikation wird zum eigenen Produktfeld.
Was das für Unternehmen bedeutet
Wer KI-Agenten in der Entwicklung einsetzt, sollte prüfen, wo das Geld künftig hingeht. Die Tabelle zeigt die Verschiebung im Groben.
| Schritt | Bisher | Mit Coding-Agenten |
|---|---|---|
| Planung und Tickets | hoher Anteil | verliert Gewicht |
| Code schreiben | teuerster Schritt | weitgehend automatisiert |
| Review und Merge | Nebenaufwand | der eigentliche Engpass |
| Testumgebungen | geteilt, statisch | viele, kurzlebig, teuer |
Zwei Konsequenzen liegen auf der Hand. Erstens lohnt es sich, das Budget für klassische Projektverwaltungs-Abos zu hinterfragen, wenn ein Großteil der dort verwalteten Arbeit ohnehin von Agenten erledigt wird. Zweitens sollte niemand darauf setzen, dass menschliche Freigaben das Sicherheitsnetz sind. Untersuchungen zeigen, dass Human-in-the-Loop-Freigaben einen erheblichen Teil der Gefahren übersehen, weil Reviewer bei hoher Änderungsfrequenz abstumpfen.
Praktisch heißt das: Prüfschritte müssen automatisiert und in der eigenen Infrastruktur verankert werden. Reproduzierbare Testumgebungen, klare Regeln für Agenten und harte automatische Gates sind wichtiger als ein weiteres Werkzeug-Abo. Offene Alternativen wie der Coding-Agent Goose ohne Abo zeigen, dass die Agentenschicht selbst zunehmend austauschbar ist. Der Wert liegt in der Prüfstrecke, und die gehört ins eigene Haus.