KI hat deinen Ingenieuren geholfen, mehr Code zu veröffentlichen. Sie hat deinem Team jedoch nicht dabei geholfen, mehr Produkte auf den Markt zu bringen.

Irgendwann in diesem Jahr hast du wahrscheinlich einen Antrag genehmigt, den Zugriff auf KI-Codierungstools im gesamten Team auszuweiten. Das Argument war einfach: Entwickler programmieren schneller, das Team liefert mehr aus, die Investition macht sich bezahlt.

Die erste Hälfte hat sich bewahrheitet. Entwickler programmieren schneller. Wenn du nun gefragt wirst, ob sich die Investition gelohnt hat, und du feststellst, dass die ehrliche Antwort komplizierter ist als ein einfaches „Ja“, bist du nicht allein – und dir wurde kein fehlerhaftes Produkt verkauft. Du bist auf ein Muster gestoßen, das fast überall auftritt, wo so etwas ausprobiert wird.

Wohin der Gewinn tatsächlich fließt

Wichtigste Erkenntnis: Das Programmieren war selten der eigentliche Engpass. KI hat diesen Vorgang beschleunigt, während Überprüfung, Freigabe und Release-Bereitschaft genau so blieben, wie sie waren – daher wird der individuelle Gewinn von der queue aufgefressen, anstatt dem Team zugutezukommen.

Das Programmieren war selten der eigentliche Engpass dafür, wie schnell ein Team etwas ausliefern konnte – zumindest nicht bei einem Team von nennenswerter Größe. Der Engpass lag in den damit verbundenen Arbeitsschritten: Überprüfung, Freigabe und die Sicherstellung, dass eine Änderung sicher veröffentlicht werden kann. KI-Tools haben den ersten Teil beschleunigt und den zweiten Teil genau so belassen, wie er war.

Das hat eine ganz konkrete, vorhersehbare Auswirkung. Es gelangt mehr Code in höherem Tempo in die Überprüfung, und die Anzahl der Reviewer, die diese Überprüfung durchführen, sowie das Tempo, in dem sie das tun können, haben sich nicht geändert. Die queue schluckt den Unterschied auf. Ein erfahrener Entwickler, der früher jeden Tag einen überschaubaren Stapel Pull-Requests abarbeiten konnte, sieht sich nun mit deutlich mehr davon konfrontiert – ein Großteil davon wurde von einem Modell geschrieben und nicht von einem Kollegen, zu dem er einfach rübergehen und eine Frage stellen kann.

Der individuelle Gewinn ist real. Er schlägt sich nur nicht auf Teamebene nieder, weil er vollständig dafür aufgewendet wird, eine größere queue abzuarbeiten, anstatt etwas Neues auf den Markt zu bringen.

Warum das kein Problem der Tools ist

Kernaussage: Der Review-Prozess wurde für das Schreiben im menschlichen Tempo entwickelt. KI-generierter Code bricht mit dieser Annahme, und kein Tool kann einen Prozess reparieren, der nie entsprechend neu gestaltet wurde.

Der Instinkt ist verständlicherweise, nach einem besseren Tool zu suchen, nach strengeren Regeln dafür, was Entwickler generieren dürfen, oder nach mehr reviewers. Nichts davon geht auf den eigentlichen Mechanismus ein.

Das eigentliche Problem ist, dass der Überprüfungs- und Freigabeprozess, den dein Team bereits hat, für eine Welt konzipiert wurde, in der ein Mensch jede Zeile in menschlichem Tempo programmiert hat. Dieser Prozess ging von einer bestimmten Beziehung zwischen der Person, die das Programmiert hat, und der dahinterliegenden Logik aus. KI-generierter Code macht diese Annahme zunichte, ohne dass jemand beschließt, den Prozess entsprechend anzupassen.

Das ist eine Frage der Organisationsgestaltung, keine Frage der Tools. Wer was überprüft, wie viel Prüfung eine bestimmte Änderung tatsächlich erfordert und wo eine Entscheidung wirklich einen Menschen braucht – und wo nicht –, all das wurde nicht neu überdacht, als sich das Volumen änderte. Es läuft immer noch nach den Annahmen, die vor dem Aufkommen der KI-Tools galten.

Was das tatsächlich von dir als Führungskraft verlangt

Kernaussage: Vier bewusste Veränderungen, eine echte Ausgangsbasis, eine risikobasierte Zuweisung von Überprüfungen, die Einbeziehung von Nicht-Ingenieuren und der Widerstand gegen den Instinkt, einfach nur mehr Überprüfungen hinzuzufügen – und keine davon ist umsonst. Die Kosten sind es wert, benannt zu werden, statt sie zu verbergen.

Ein paar Dinge, die es wert sind, bewusst umgesetzt zu werden, anstatt darauf zu warten, dass der Rückstand das Thema erzwingt. Nichts davon ist kostenlos. Jedes einzelne kostet echte Zeit und echte Aufmerksamkeit, und es lohnt sich, dies von vornherein ehrlich zuzugeben, anstatt so zu tun, als wäre die Lösung ein kurzes Richtlinienmemo.

• Erstelle eine echte Basislinie, bevor du Aussagen zum ROI machst. Die meisten
  Teams, die KI-Codierungstools eingeführt haben, haben vor dem Start nie die Zykluszeit, die Durchlaufzeit bei Reviews oder den Durchsatz gemessen. Ohne diese Zahlen ist jede Behauptung darüber, wie viel schneller die Dinge jetzt laufen, nur eine als Kennzahl getarnte Vermutung – und die wird einer ernsthaften Budgetdiskussion nicht standhalten. Diese Basislinie zu ermitteln, erfordert jetzt bewusste Anstrengungen und ist nicht nur eine nachträgliche Schätzung.
• Entscheide, worauf sich der Überprüfungsaufwand tatsächlich konzentrieren muss.
  Nicht jede Änderung birgt das gleiche Risiko. Ein Workflow, der Änderungen mit geringem Risiko einer weniger strengen Überprüfung unterzieht und eine gründliche Prüfung für alles reserviert, was die Produktion, Daten oder kundenbezogene Abläufe betrifft, bringt den Backlog voran, ohne die Messlatte dort zu senken, wo es darauf ankommt. Diese Unterscheidung zu treffen – was für dein Team konkret als geringes Risiko und was als hohes Risiko gilt – ist an sich schon echte Arbeit, kein Schalter, den man einfach umlegt.
• Beziehe die Leute mit ein, die keine Entwickler sind.
  Produkt, Sicherheit und Design werden in der Regel erst nachträglich in diesen Prozess eingebunden – wenn überhaupt. Eine Änderung, die eigentlich eine Sicherheitsfreigabe oder eine Produktentscheidung hätte erfordern sollen, erhält diese oft nicht – nicht, weil jemand absichtlich einen Schritt übersprungen hat, sondern weil die Überprüfungsstruktur darauf ausgelegt war, dass reviewer andere reviewer überprüfen.
• Widerstehe dem Drang, einfach mehr Überprüfungen als Standardlösung hinzuzufügen. Mehr
  Reviewer und mehr erforderliche Genehmigungen verschlimmern den Backlog meist noch, weil sie überall Reibungsverluste verursachen, anstatt jede Entscheidung an denjenigen weiterzuleiten, der sie eigentlich treffen sollte.

Die ehrliche Version dieses Ratschlags lautet: Die Prozessoptimierung kostet jetzt etwas – im Gegenzug dafür, dass man später keine größeren, weniger vorhersehbaren Kosten zahlen muss, sobald der Rückstand und die Vertrauenslücke so weit gewachsen sind, dass eine gezielte Korrektur nicht mehr einfach ist.

Dieses Muster – dass die Geschwindigkeit des Einzelnen die Leistung auf Teamebene übertrifft – ist der Ausgangspunkt für ein umfassenderes Rahmenkonzept, das es zu verstehen gilt.

Lies dir die 8 Stufen der Reife im AI-Engineering durch, um zu sehen, wo dein Team tatsächlich steht und was in jeder der folgenden Phasen typischerweise passiert.

Häufig gestellte Fragen (FAQ)

Warum haben KI-Coding-Tools unser Team insgesamt nicht schneller gemacht, obwohl die individuelle Leistung deutlich gestiegen ist?
Weil Programmieren selten der eigentliche Engpass für ein Team war, das in großem Maßstab liefert. Der Engpass lag bei der Überprüfung, der Freigabe und der Release-Bereitschaft – und keiner dieser Schritte wurde schneller, nur weil das Programmieren schneller fertig war. Der individuelle Gewinn wird von der queue aufgesogen, anstatt die Auslieferung auf Teamebene zu erreichen.

Ist das Hinzuziehen weiterer reviewer die richtige Antwort auf einen wachsenden Backlog?
Normalerweise nicht allein. Die Erweiterung der Prüfkapazitäten, ohne die Art und Weise zu ändern, wie Entscheidungen weitergeleitet werden, verschiebt den Backlog eher, anstatt ihn abzubauen. Die nachhaltigere Lösung besteht darin, zu entscheiden, welche Änderungen einer echten Prüfung bedürfen und welche nicht, und jede Änderung an die Person weiterzuleiten, die diese Entscheidung tatsächlich treffen sollte.

Woher wissen wir, ob das gerade in unserem Team passiert?
Das deutlichste Anzeichen ist eine wachsende Kluft zwischen der Geschwindigkeit, mit der Entwickler angeben, zu arbeiten, und der Geschwindigkeit, mit der Features tatsächlich in der Produktivumgebung gelangen. Wenn diese Kluft besteht und niemand sie mit Zahlen erklären kann, lohnt es sich, dem nachzugehen, bevor man davon ausgeht, dass die KI-Investition nicht funktioniert.

Wo passt eine Plattform wie Upsun Dispatch™ hier hinein?
Upsun Dispatch™ basiert auf der Idee, dass der Arbeitsablauf – und nicht irgendein einzelnes Tool – das ist, was es wert ist, bewusst gestaltet zu werden: Wo eine menschliche Entscheidung erforderlich ist, wer sie trifft und was dabei protokolliert wird. Es ist eine Möglichkeit, die oben genannten organisatorischen Entscheidungen konkret umzusetzen, anstatt sie nur als Wunschvorstellung zu belassen.