GitLab-Playbook zu KI-nativer Entwicklung nimmt Engpässe jenseits des Codens ins Visier

Warum schnelleres Coden noch keine schnellere Auslieferung bedeutet

GitLab argumentiert, dass KI-Agenten mehr Code in Review-Warteschlangen schieben, die für das Tempo von Menschen ausgelegt sind. Ein Coding-Assistent könne das Schreiben beschleunigen, so das Unternehmen, zeige aber nicht, ob Review, Sicherheitsprüfungen und Release-Freigaben mithalten können. Das Playbook definiert KI-native Entwicklung als Praxis, den Engineering-Prozess so zu gestalten, dass Menschen und Agenten jeweils das tun, wofür sie am besten geeignet sind.

GitLab verweist auf seinen AI Accountability Report, der auf einer Umfrage unter 1.528 DevSecOps-Fachleuten vom April 2026 beruht. Laut dem Bericht stimmten 79 % der Befragten zu, dass die Produktivität einzelner Entwickler durch KI gestiegen ist, der gesamte Auslieferungsprozess sich aber nicht im selben Tempo beschleunigt hat. Die Befragten gaben an, nur 16 % ihrer Zeit mit dem Schreiben neuen Codes zu verbringen, und 85 % stimmten zu, dass KI den Engpass vom Schreiben des Codes auf dessen Prüfung und Validierung verlagert hat.

Das Unternehmen nennt auch ein Beispiel. Bei einem Auslieferungszyklus von 281 Tagen mit rund 32 Tagen Coding spart eine um 50 % schnellere Programmierung etwa 16 Tage, also eine Verbesserung um 6 %. Selbst wenn das Coden auf null sänke, blieben rund 88 % der Durchlaufzeit bestehen. GitLab merkt an, dass große Unternehmen typischerweise Durchlaufzeiten von deutlich über 200 Tagen haben, wobei die aktive Entwicklung nur 10 bis 20 % davon ausmacht.

Als ersten Schritt empfiehlt GitLab die Diagnose: eine kleine, reale Änderung von der Anforderung bis in die Produktion verfolgen und dabei jede Wartezeit und jede Übergabe markieren. Die längsten Wartezeiten zeigten, wo als Nächstes anzusetzen ist, so GitLab. Wenn ein Agent bei einer kleinen Aufgabe stocke, deute das oft auf einen nicht dokumentierten Standard, eine schwer zu startende Umgebung oder Kontext hin, der nur in einem Kopf steckt.

Eine vierstufige Leiter für die Autonomie von Agenten

Zur Frage, wie viel Freiheit Agenten bekommen sollten, heißt es im Playbook, die Autonomie solle davon abhängen, wie gut sich das Ergebnis überprüfen lässt. Beschrieben wird eine Leiter mit vier Stufen:

• Stufe 1: Menschen sind bei jedem Schritt beteiligt.
• Stufe 2: Menschen sind weiterhin beteiligt, der Agent arbeitet aber innerhalb festgelegter Grenzen.
• Stufe 3: Menschen sind im Normalbetrieb nicht beteiligt und kümmern sich nur um Ausnahmen.
• Stufe 4: ein Zero-Touch-Workflow, in dem der Agent sich von Anfang bis Ende selbst steuert und nur dann einen Menschen hinzuzieht, wenn vordefinierte Schwellenwerte erreicht sind.

Sprossen dürfen nicht übersprungen werden, und jeder Aufstieg braucht Belege aus der darunterliegenden Stufe. Für jeden KI-gestützten Workflow sollte ein namentlich benannter Mensch verantwortlich bleiben, und die Grenze zwischen Prüfen und Überwachen sollte ausdrücklich definiert sein. GitLab warnt, dass ein Mensch, der nominell beteiligt bleibt, aber alles freigibt, den Anschein von Kontrolle erzeugt, ohne ihren Nutzen zu bieten. Ein Kontrollpunkt, den niemand tatsächlich nutzt, sei schlimmer als gar keiner. Teams sollten vor jeder Ausweitung einen klaren Schwellenwert für Genauigkeit oder Erfolg festlegen; ein Agent, der häufiger anhält und um Hilfe bittet, gilt als gutes Zeichen.

Code-Review bei Agenten-Volumen

GitLab zufolge wurde das Review zum Zeitpunkt des Merge für das Tempo von Menschen entwickelt, und die manuelle Prüfung jedes Change-Sets sei nicht mehr tragbar. In der Untersuchung stimmten 78 % der Befragten zu, dass bestehende Code-Review-Prozesse nicht für das Ausmaß an Code ausgelegt sind, das KI-Tools ermöglichen, und 80 % stimmten zu, dass ihr Unternehmen KI-Coding-Tools schneller eingeführt hat, als es Richtlinien dafür entwickeln konnte.

Das Playbook schlägt ein mehrschichtiges Verifikationssystem vor. Zu den Empfehlungen gehören:

• Objektive Prüfungen wie Formatierung, Typen und Abhängigkeitsrichtlinien so nah wie möglich an die Entstehung des Codes verlagern.
• Änderungen klein halten, damit spätere Schichten schneller arbeiten.
• Das erwartete Verhalten vorab definieren, damit es etwas Konkretes zu prüfen gibt.
• Einen unabhängigen Reviewer einsetzen.
• Die Review-Tiefe am Risiko der Änderung ausrichten.
• Jede agentische Review-Entscheidung so dokumentieren, dass sie später nachvollzogen werden kann.

Menschen sollten nur dann aus dem Prozess genommen werden, wenn Risiko und Belege das rechtfertigen, niemals standardmäßig. GitLab zufolge haben die erfolgreichsten Organisationen bereits stark in automatisierte Tests, statische Analyse und kleine Change-Sets investiert.

Was das für Engineering-Teams bedeutet

Das Playbook stützt sich auf Erkenntnisse von Engineering-Verantwortlichen bei GitLab, seinen Kunden und Mitgliedern der Community des Software Engineering Leadership Forum (SELF). GitLab hat zudem mit IT Revolution zusammengearbeitet, um Erfahrungen von Praktikern zu Themen von Code-Review bis Agentenautonomie einzubeziehen.

Es gliedert sich in drei Teile: die Arbeit so umgestalten, dass Agenten in den Auslieferungsfluss passen; mit Agenten arbeiten und dabei entscheiden, wo menschliches Urteilsvermögen und Verantwortung bleiben; sowie steuern und skalieren, von einem Workflow auf viele. Teams können mit dem Teil beginnen, der zu ihrer größten Reibung passt. Für Engineering-Verantwortliche lautet die Botschaft von GitLab: Der Nutzen von Coding-Agenten hängt davon ab, den Prozess rund um den Code zu verbessern, und Autonomie sollte durch Belege verdient werden.