Der neue Engpass
Warum schnellerer Code eure Probleme nicht löst
Wir haben Code-Generierung so effizient gemacht, dass wir jetzt ein neues Problem haben: Menschen, die schneller Output abnehmen müssen, als sie denken können.
Die AI-Diskussion in der Softwareentwicklung dreht sich fast ausschließlich um eine Frage: Wie generieren wir Code schneller? Das ist verständlich – aber es lenkt von dem ab, was gerade wirklich passiert.
Das Bottleneck hat sich verschoben
Vor einem Jahr war “Code schreiben” noch ein limitierender Faktor. Heute kann ein einzelner Entwickler mit den richtigen Agents an einem Tag produzieren, wofür früher eine Woche nötig war.
Klingt nach Fortschritt. Ist es auch – bis man fragt: Wer reviewt das alles? Wer versteht es? Wer verantwortet es?
Die Velocity-Metriken sehen fantastisch aus. Aber die Engpässe sind nicht verschwunden. Sie haben sich verschoben – zum Menschen.
Fünf Fragen, auf die niemand gute Antworten hat
1. Wie bewertest du Arbeit, die du nicht mehr selbst machst?
Engineering Leads haben jahrelang Code-Reviews gemacht. Sie wussten, worauf sie achten mussten, weil sie selbst im Code steckten. Wenn Agents den Großteil des Codes produzieren und Engineers zu “Orchestratoren” werden – nach welchen Kriterien bewerten wir dann? Wie unterscheidest du guten von schlechtem Output, wenn du selbst nicht mehr Zeile für Zeile durchgehst?
2. Wer übernimmt die Verantwortung?
Agent generiert Code. Engineer gibt ihn frei. QA testet. Alles grün. Drei Monate später: Security-Problem, das niemand gesehen hat.
Wer ist verantwortlich? Der Engineer, der den Code freigegeben hat, ohne ihn wirklich zu verstehen? Das Team, das die Guardrails definiert hat? Die Organisation, die keine besseren Review-Prozesse etabliert hat?
In klassischen Strukturen war Verantwortung an Wissen gekoppelt: Wer den Code geschrieben hat, verstand ihn und verantwortete ihn. Diese Kopplung löst sich gerade auf.
3. Wie befähigst du Menschen, Verantwortung zu übernehmen, die sie nicht tragen können?
“Human in the Loop” klingt beruhigend. Aber was bedeutet das konkret?
Ein Mensch, der zehnmal so viel Output überprüfen muss wie vorher, prüft nicht gründlicher – er prüft oberflächlicher. Oder er wird zum Bottleneck, der die gesamte AI-Velocity wieder zunichtemacht.
Wir verlangen von Menschen, dass sie Arbeit verantworten, für die wir sie weder ausgebildet noch ausgestattet haben.
4. Was genau wird verifiziert – und was nicht?
Tests laufen durch. Linting ist sauber. Der Code funktioniert.
Aber: Ist die Architektur-Entscheidung richtig? Passt die Lösung ins Gesamtsystem? Entsteht gerade technische Schuld, die erst in zwei Jahren sichtbar wird?
Agents optimieren lokal. Sie lösen die Aufgabe, die vor ihnen liegt. Die systemischen Auswirkungen sieht niemand – bis es zu spät ist.
5. Was passiert mit den Bereichen, die nicht Engineering heißen?
Code-Generierung ist nur ein Teil des Delivery-Systems. Was ist mit Produktentscheidungen, die jetzt schneller technisch umsetzbar sind – aber nicht schneller durchdacht? Was ist mit Dokumentation, die niemand mehr schreibt, weil der Code sich zu schnell ändert? Mit Onboarding neuer Teammitglieder in eine Codebase, die niemand im Team mehr wirklich versteht?
Wenn Engineering plötzlich zehnmal schneller liefern kann, verschiebt sich der Druck auf Product, Design, QA. Die Friction wandert – sie verschwindet nicht.
Das eigentliche Problem
Wir haben das Code-Schreiben beschleunigt. Aber die Arbeit, die sich nicht beschleunigen lässt – verstehen, bewerten, entscheiden, verantworten – ist immer noch da. Und unsere Organisationen sind nicht dafür gebaut.
Die meisten Unternehmen behandeln AI wie ein Upgrade ihrer Werkzeuge. Schnellere IDE, besserer Copilot, mehr Output pro Kopf.
Aber das Werkzeug hat sich fundamental verändert. Es trifft jetzt eigene Entscheidungen. Und wir haben keine Strukturen, Prozesse oder Rollenbilder, die damit umgehen können.
Kleine AI-native Teams bauen gerade ihre Strukturen um diese Realität herum. Große Organisationen diskutieren noch, welchen Copilot sie lizenzieren. Die Frage ist nicht, ob sich das rächt – sondern wann.