Du hast das Programmieren beschleunigt. Rate mal, wo der Engpass als Nächstes auftrat.

Irgendwann im letzten Jahr ist die Produktivität beim Programmieren deines Teams gestiegen. Pull-Requests werden schneller eröffnet. Der Rückstau an kleinen Korrekturen und Routineänderungen hat sich schneller abgebaut als früher.

Wenn sich die Bereitstellung immer noch ungefähr genauso langsam anfühlt wie zuvor, dann ist das genau das, was passiert, wenn man einen Teil eines Prozesses beschleunigt, ohne etwas weiter hinten im Prozess anzutasten.

Wo der Engpass tatsächlich liegt

Wichtigste Erkenntnis: Das Programmieren ist schneller geworden. Die Qualität von Review, Freigabe und Spezifikationen jedoch nicht. Die Einschränkung ist nicht verschwunden; sie hat sich lediglich auf den Teil des Prozesses verlagert, der nie berührt wurde.

Das Programmieren war schon immer der eigentliche Engpass für ein Team, das Software in beliebigem Umfang ausliefert – weshalb in der Vergangenheit so viel Zeit in die Planung und die Spezifikationen floss, bevor mit der Umsetzung begonnen wurde. KI hat diesen Engpass beseitigt. Was sie jedoch unberührt ließ, war die umgebende Arbeit: sicherzustellen, dass die Änderung ordnungsgemäß geprüft wurde, dass die richtige Person sie absegnet und dass das, was entwickelt wird, klar genug spezifiziert ist, damit die Entwicklung tatsächlich der richtige nächste Schritt ist

Das zeigt sich an drei Stellen, meist in dieser Reihenfolge.

1. Die Überprüfungsqueue. Je mehr Code durchläuft, desto mehr Pull-Requests landen bei denselben Reviewern, die ohnehin schon ausgelastet sind. Die Überprüfungslast eines erfahrenen Entwicklers kann sich leicht verdoppeln oder verdreifachen – wobei ein Großteil davon von einem Modell geschrieben wurde und nicht von einem Kollegen, zu dem man einfach rübergehen und eine Frage stellen kann.
2. Genehmigungen. Sobald sich die queue staut, suchen Teams nach Wegen, die Dinge schneller durchzubringen. Ein Teil dieses Drucks ist gesund und optimiert einen wirklich langsamen Prozess. Ein anderer Teil untergräbt still und leise die Genehmigung selbst – ein bloßer Stempel auf etwas, das eigentlich niemand genau gelesen hat.
3. Spezifikationen. Ein Agent kann nur mit den Informationen arbeiten, die ihm gegeben werden. Ein vages Ticket, das ein menschlicher Entwickler in einem kurzen Gespräch auf dem Flur geklärt hätte, wird oft wörtlich umgesetzt – mit allen Unklarheiten. Produkt- und Entwicklungsteams stellen fest, dass sie sich nun in einem Maße auf die Qualität der Spezifikationen verlassen müssen, wie sie es zuvor nie mussten, weil es keine Person mehr gibt, die still und leise die Lücken füllt.

Was man einführen sollte, bevor es noch schlimmer wird

Die wichtigste Erkenntnis: Die Lösung besteht nicht darin, überall noch mehr Prozesse einzuführen. Es geht darum, zu definieren, wo tatsächlich eine menschliche Entscheidung erforderlich ist, und sicherzustellen, dass die Technik nicht die einzige Funktion ist, die mit am Tisch sitzt. 

Nichts davon ist unvermeidbar. Es ist ein Zeichen dafür, dass ein paar bestimmte Strukturelemente fehlen, und es lohnt sich, diese bewusst einzuführen, anstatt darauf zu warten, dass der Rückstand das Thema erzwingt.

• Lege fest, wo tatsächlich eine menschliche Entscheidung erforderlich ist. Nicht jede Änderung erfordert das gleiche Maß an Prüfung. Ein Workflow, der Änderungen mit geringem Risiko einer weniger strengen Prüfung unterzieht und besonders genaues Augenmerk auf alles richtet, was die Produktion, Daten oder das kundenorientierte Verhalten betrifft, bringt den Backlog voran, ohne die Messlatte dort zu senken, wo es darauf ankommt.
• Verleihe der Genehmigung eine konkrete Bedeutung. Eine Genehmigung, die nicht an eine definierte Prüfung geknüpft ist – passt das zur Spezifikation, besteht es die entscheidenden Tests? – ist nur ein Name in einem Datensatz, keine Entscheidung. Es lohnt sich, klar zu formulieren, was ein reviewer tatsächlich bestätigt, wenn er etwas genehmigt.
• Stell die Qualität der Spezifikationen auf die gleiche Ebene wie die Qualität beim Programmieren. Wenn ein Agent direkt aus einem Ticket heraus programmieren soll, muss das Ticket die Klarheit aufweisen, die früher ein menschlicher Entwickler informell geliefert hat. Es ersetzt ein Gespräch, das früher unsichtbar stattfand, durch eines, das nun schriftlich erfolgen muss.
• Beziehe die Leute mit ein, die nicht programmieren. Genau hier scheitern die meisten Teams. Die oben beschriebene Review- und Genehmigungsstruktur wird meist von Ingenieuren für Ingenieure aufgebaut, und die Bereiche Produkt, Design und Sicherheit werden – wenn überhaupt – erst im Nachhinein angehängt. Ein Workflow, der Entscheidungen ausschließlich an die technische Abteilung weiterleitet, übersieht genau die Kontrollpunkte, die eine Spezifikation abgefangen hätten, die niemals hätte veröffentlicht werden dürfen, oder eine Änderung, die eine Sicherheitsfreigabe benötigt hätte, die sie nie erhalten hat.

Was leicht übersehen wird

Das Wichtigste zum Mitnehmen: Mehr Überprüfungen zu machen, verschlimmert den Backlog, statt ihn zu verbessern. Die Teams, die das gut hinbekommen, leiten Entscheidungen an die richtige Person weiter – statt einfach nur mehr zu prüfen.

Der erste Reflex, sobald ein Team das bemerkt, ist, mehr Überprüfungen einzuführen. Mehr reviewers, mehr erforderliche Genehmigungen, mehr Prozess. Das verschlimmert den Backlog meist, weil es überall Reibungsverluste verursacht, anstatt Entscheidungen an die Leute weiterzuleiten, die sie eigentlich treffen sollten.

Die Teams, die das gut hinbekommen, führen nicht mehr Überprüfungen durch. Sie leiten Entscheidungen besser weiter: Die Technik kümmert sich um technische Entscheidungen, das Produktteam um Produktentscheidungen, die Sicherheitsabteilung um Sicherheitsentscheidungen – und keiner von ihnen wartet in derselben queue hinter den anderen. Das funktioniert nur, wenn der Workflow selbst den Unterschied versteht, anstatt jede Änderung standardmäßig als technische Freigabe zu behandeln.

Schau dir die Dispatch-Demo an, um zu sehen, wie die Plattform tatsächlich funktioniert – vom eingehenden Ticket bis zur veröffentlichten Änderung, einschließlich der Entscheidungspunkte auf dem Weg dorthin.

Häufig gestellte Fragen (FAQ)

Warum haben KI-Codierungs-Tools die Reviews verlangsamt statt zu beschleunigen? 
Sie haben die Reviews nicht verlangsamt. Sie haben das Code-Volumen erhöht, das zur Überprüfung gelangt, ohne die Kapazität des Teams zur Überprüfung zu steigern – was praktisch denselben Effekt hat.

Ist mehr Code-Review die richtige Lösung für diesen Engpass? 
Nicht für sich allein. Die Kapazität für Reviews zu erhöhen, ohne zu ändern, wie Entscheidungen weitergeleitet werden, verschiebt den Rückstand meist nur, anstatt ihn abzubauen. Die nachhaltigere Lösung besteht darin, jede Art von Entscheidung an die Person weiterzuleiten, die sie tatsächlich treffen sollte.

Warum sind Spezifikationen heute wichtiger als früher? 
Weil ein menschlicher Entwickler, der anhand eines unklaren Tickets arbeitet, die Lücken durch sein Urteilsvermögen und Gespräche füllt. Ein Agent, der anhand desselben Tickets arbeitet, erstellt fast genau das, was geschrieben steht – einschließlich aller Unklarheiten. Die Qualität der Spezifikationen, die früher informell korrigiert wurde, muss nun explizit sein.

Wer außer den Entwicklern sollte als reviewer an der Überprüfung von KI-generierten Änderungen beteiligt sein? 
Wer auch immer für die Entscheidung verantwortlich ist, die von der Änderung tatsächlich betroffen ist. Das Produktmanagement für benutzerseitiges Verhalten, die Sicherheitsabteilung für alles, was mit Zugriff oder Daten zu tun hat, und das Designteam für alles, was den Benutzer betrifft. Wenn jede Entscheidung standardmäßig über die Entwickler geleitet wird, werden die Kontrollpunkte übersehen, die für jeden dieser Bereiche am wichtigsten sind.