Der Engpass ist gewandert: Wie Tech-Teams schnell bleiben, wenn Agenten den Code schreiben

Coding ist nicht mehr der langsame Schritt. Über vier aktuelle Talks hinweg zeigt sich dasselbe Muster: Agenten können Änderungen schnell entwerfen, und Teams bleiben dann an Qualität, Review, Vertrauen und Verifikation hängen.

Das ist nicht dasselbe Argument wie die Automatisierung einer ganzen Firma oder wie eine einzelne Verifikationsschleife innerhalb eines Coding-Produkts. Es geht darum, wie ein Team schnell bleibt, sobald Agenten bereits die meisten Diffs schreiben.

Wohin die Zeit tatsächlich geht

Unbeaufsichtigte Agenten verschlechtern die Codebase über die Zeit. Dexter Horthy geht auf Beyond Coding und erneut bei der Agentic AI Foundation durch SlopCodeBench: Modelle bekommen eine Greenfield-App, dann eine Sequenz von Features, ohne das ganze Problem vorab. Fehlschlagende Tests steigen. Die besten Modelle landen immer noch im mittleren Teenagerbereich. Seine Warnung ist praktisch: Verpfände die Codebase nicht auf die Hoffnung, dass das Modell des nächsten Jahres sie aufräumt. Ziele auf 2-4x, nicht 100x. Tu weniger Dinge parallel und behalte einen Menschen in der Research-Design-Plan-Schleife für alles, was Architektur ändert.

Der Review-Prozess ist oft langsamer als das Modell. Dario Hamidi von Amp sagt ebenfalls auf Beyond Coding, das Team shippt etwa 50 Mal am Tag in Produktion, und die Änderung, die das möglich macht, ist nicht der Agent. Es ist das Weglassen von Pull Requests und Feature-Branches. Er argumentiert, dass selbst ein Team, das keine KI nutzt, durch Merging auf Trunk zweistellige Produktivität aufheben kann, weil Leute dann ihre eigene Arbeit prüfen, statt in einer Queue zu warten, die für Fremde gebaut wurde. Die passende Constraint ist Vertrauen: Baue Umgebungen, in denen Agenten nicht „mit Messern jonglieren“ können, mit kurzlebigen Credentials und Permissions, die du tatsächlich freigeben würdest.

Verifikation skaliert nicht mit Generation. IBMs Prompt to Production fasst den neuen Engpass in einem Satz: menschliche Verifikation im KI-Maßstab. Planung, Impact und Evidenz zählen mehr als die erste Codezeile, weil eine echte Änderung auch Tests, Config, Pipelines und Monitoring berührt. Ein verwandter IBM-Beitrag zu IDE vs CLI macht denselben Punkt von der Toolchain-Seite: Die Reibung ist die Koordination der Arbeit um den Code herum, nicht das Tippen.

Specs und Evals sind die Team-Schnittstelle. Guillermo Rauch beschreibt in David Ondrejs Interview einen agentischen Workflow, der auf dem Ausprobieren vieler Modelle, persönlichen und Firmen-Evals und Agenten basiert, die eine App reviewen oder eine Funktion aus einer kurzen Anweisung shippen können. Der nützliche Teil für ein Team ist nicht das Celebrity-Setup. Es ist ein geteilter Eval, damit „welches Modell diese Woche“ kein privates Argument wird.

Was man am Montag ändern sollte

1. Teile die Arbeit. Kleine, reversible Änderungen können an einen Hintergrund-Agenten gehen. Alles, was eine Abstraktion ändert, bleibt in einem Research-Design-Plan-Durchgang mit einem Menschen.
2. Hör auf, Geschwindigkeit an Tokens oder parallelen Agenten zu messen. Miss Deploys, die keine Incidents ausgelöst haben, und halte eine Priorität in der Luft.
3. Verschiebe Review nach links. Auto-Checks und eine vertrauenswürdige Umgebung schlagen eine lange PR-Queue. Wenn du Pull Requests weglässt, sage, was sie ersetzt: Trunk, Tests und jemand, der den Diff noch liest.
4. Schreibe Anti-Slop-Regeln, die der Agent sehen kann: Patterns, die du nicht mergen wirst, und einen Ort, an dem User-Feedback wieder in die Fabrik eingeht.
5. Behandle Verifikation als knappe Ressource. Plane die Evidenz (Tests, Flags, einen kurzen manuellen Check), bevor du den Agenten um Implementierung bittest.

Die Teams, die schneller werden, sind nicht die mit den meisten Agenten, die über Nacht laufen. Es sind die, die bemerkt haben, dass der Engpass gewandert ist, und diesen Schritt besetzt haben.