Ihre Systeme haben bereits blinde Flecken. KI macht sie nur noch schlimmer.

Im Jahr 2022, bevor generative Codierungswerkzeuge Teil unserer täglichen Ingenieurarbeit waren, schrieb ich über meine Philosophie zur Werkzeugauswahl. Es hat sich besser gehalten, als ich erwartet hatte. Damals argumentierte ich, dass man mit den Problemen beginnen sollte, die man tatsächlich löst, seine Schwächen kennen und priorisieren sollte, wie man die Werkzeuge einsetzt, anstatt einfach jedes Werkzeug zu ergreifen, das am besten klingt, und zu hoffen, dass es funktioniert. Kenne dich selbst und deine Ziele, damit du realistische Erwartungen an deine Werkzeuge stellen kannst.

Damals dachte ich an SaaS‑Ausdehnung, nicht an KI‑generierten Code. Aber heute ist meine Philosophie noch dringlicher und noch wichtiger, ihr treu zu bleiben.

Viele von uns haben den 2025 DORA report, die feststellte, dass im Gegensatz zum Vorjahr die KI‑Einführung nun positiv mit der Liefergeschwindigkeit korreliert. Die zugrunde liegende Erkenntnis war, dass die Lieferinstabilität weiter anstieg, und sie prüften, ob die Geschwindigkeitsgewinne dies ausgleichen. Das tun sie nicht. Das entspricht unserer Erfahrung. Unser Team führte agentische Softwareentwicklung ein und verzeichnete einen Anstieg der Durchsatzrate um 48 % über zwei Quartale, gefolgt von einem Anstieg der Stabilitätsprobleme um 16 %. Zehn Personen sind eine kleine Stichprobe, aber es ist auch eine Stichprobe, aus der ich das Gesamtbild erkennen kann, und das Muster hielt an.

Die KI‑Einführung ist eigentlich keine Frage mehr. Man befindet sich entweder gerade am Anfang oder ist bereits tief darin. Was jetzt anders ist, ist, dass von technischen Führungskräften erwartet wird, KI zu übernehmen und gleichzeitig nachzuweisen, dass sie sich auszahlt. CEO, Vorstand und Finanzabteilung wollen wissen, wie sie ihre KI‑Investition optimieren können. Sie fragen, ob die von Ihnen gewählten Werkzeuge reale Probleme effizient lösen.

Die Lücke war immer da. KI hat sie nur verbreitert.

Als CTO verbringe ich einen beträchtlichen Teil meiner Zeit damit, mit anderen technischen Führungskräften zu sprechen, darunter Kunden, Interessenten und Kollegen, um Erfolge und Beschwerden über das, was wir mit KI erleben, zu vergleichen. Nach genügend vielen dieser Gespräche habe ich begonnen, Muster in der KI‑Einführung und deren Ergebnissen zu erkennen.

Die Hauptbeobachtung ist nicht meine. DORA führt das seit zwei Jahren an: KI verstärkt alles, was bereits in der Organisation geschieht, sowohl Stärken als auch Schwächen. Ein Team mit sauberer Architektur und gesunden Review‑Gewohnheiten wird schneller. Ein Team, das einen unordentlichen Haufen technischer Schulden gerade genug bändigte, um Code auszuliefern, stellt nun fest, dass die technischen Schulden zu einem großen Hemmnis werden. Was diese Darstellung jedoch verpasst, ist, warum das so viele Teams unvorbereitet trifft. KI hat diese Schwächen nicht verborgen; die Systeme, auf die wir uns verlassen haben, haben sie nie ans Licht gebracht.

Der Ticket‑ und Reporting‑Stack, den die meisten Ingenieurorganisationen verwenden, wurde entwickelt, um Fragen zu beantworten, die Menschen haben, mit menschlicher Geschwindigkeit, von Personen, die ungefähr verstanden haben, was „fertig“ für ein bestimmtes Arbeitspaket bedeutet. Es war nie ein perfektes Protokoll. Es war stets eine Annäherung, ergänzt von jemandem, der etwas Unordentlicheres darunter zusammenfasste. Jetzt fügt KI Volumen hinzu und bringt neue Eingaben, die neue Aktivitäten erzeugen. Keines der Systeme (oder Werkzeuge), die für traditionelle, nicht‑KI‑Entwicklungsmethoden verwendet wurden, wurde jemals dafür gebaut.

Ungeachtet dessen sind wir weiterhin für dieselben Ziele verantwortlich. Sie sind weiterhin für Geschwindigkeit, Qualität, Ausgaben und die tatsächliche Leistung Ihres Teams verantwortlich. Sie können die Dashboards vom letzten Jahr nicht mehr blind vertrauen.

Hier gibt es einen berechtigten Einwand. DORA’s 2026 ROI report beschreibt eine J‑Kurve: einen Produktivitätseinbruch unmittelbar nach der Einführung, verursacht durch die Lernkurve, die Kosten für die Verifizierung von KI‑generiertem Code und nachgelagerte Prozesse, die nicht Schritt gehalten haben. Sie nennen es die „Ausbildungskosten“ der Transformation und warnen Führungskräfte, sie nicht mit einem Scheitern zu verwechseln. Das ist nachvollziehbar. Aber Ausbildungskosten und ein echtes Problem sehen auf einem aus Tickets erstellten Dashboard identisch aus. Wenn Sie nicht erkennen können, in welchem Sie sich befinden, sind Sie nicht geduldig. Sie raten.

Wir müssen zu den Grundlagen zurückkehren. Kenne dich selbst. Kenne dein Team. Kenne die Probleme, die du löst.

Wie können Sie sich mit KI „selbst kennen“?

Aus meinen Gesprächen habe ich fünf Hauptbereiche identifiziert, in denen konventionelle Systeme, die für von Menschen erzeugte, von Menschen gemeldete Arbeit gebaut wurden, blind sind. Ignorieren Sie sie, und Sie riskieren, Ihre Schwächen zu verstärken, während Sie KI weiter einführen.

Blinder Fleck 1: Geschwindigkeitstheater

Mehr Commits und mehr PRs können wie Fortschritt wirken, und das ist oft auch so. KI erhöht beide Zahlen automatisch. Ein Stanford case study zeigte, dass die Einführung von KI die PR‑Anzahl um 14 % steigerte. Was jedoch fehlt, ist, wie viel von dieser Aktivität tatsächliche Feature‑Arbeit ist, die ausgeliefert wird, im Vergleich zu Wartung, Nacharbeit oder Fluktuation durch eine Refaktorisierung, die nicht Bestand hatte.

Um dem zu begegnen, beobachten Sie die Aufteilung zwischen Feature‑Arbeit und Wartung sowie die Bereitstellungshäufigkeit und Durchlaufzeit im Vergleich zu Ihrer eigenen historischen Basislinie, nicht einem Branchendurchschnitt. Ohne diese Aufteilung berichten Sie über Fortschritt, den Sie nicht tatsächlich belegen können.

Blinder Fleck 2: Review‑Schulden

Die Review‑Kapazität skaliert nicht automatisch mit dem Output. Die Verifikationssteuer ist keine Phase, die man einfach durchläuft; sie ist Teil der laufenden Kosten für agentische Entwicklung. Eine eine aktuelle Umfrage von Führungskräften im Ingenieurwesen ergab, dass 80 % der Teams mindestens 10 % ihrer Zeit für Reviews aufwenden, und etwa jedes zehnte mehr als 40 %. Unter dieser Belastung schwanken die Teams zwischen einem wachsenden Rückstand und dem geduldeten Absegnen, und beides ist keine wirkliche Lösung.

Die Beschränkung beim Ausliefern liegt nicht mehr darin, wie schnell Code geschrieben wird. It’s wie schnell ein Mensch tatsächlich sicher sein kann, dass eine Änderung korrekt ist, wie schnell und präzise Defekte erkannt und behoben werden können. Beobachten Sie, wie die Review‑Last tatsächlich über Ihr Team verteilt ist; andernfalls riskieren Sie, Ihre Senior‑Engineers zu überlasten, Ihre Releases zu verzögern oder gravierende Produktionsprobleme zu verursachen.

Blind Spot 3: Versteckte Arbeit

Refactors und Architekturverschiebungen neigen dazu, sich in anderen Tickets zu verstecken, falls sie überhaupt im Ticketsystem auftauchen. KI erzeugt mehr dieser Art von Arbeit, nicht weniger. Ein Agent zögert nicht, zwölf Dateien zu berühren, um einen Bug zu beheben, während ein Mensch vielleicht innehalten und nachdenken würde. Arbeit, die das Aufzeichnungssystem umgeht, umgeht auch die Planung, was bedeutet, dass Ihr Kapazitätsmodell falsch ist und jede darauf basierende Prognose ebenfalls falsch ist. 

Um zu verstehen, wie viel Arbeit tatsächlich geleistet wird, müssen Sie beobachten, wie viel sich tatsächlich im Code‑Base und in der Pull‑Request‑Historie ändert. Ohne das basiert Ihr Kapazitätsplan auf dem, was die Leute sich gemerkt haben zu protokollieren, nicht auf dem, was sie tatsächlich getan haben. 

Blind Spot 4: Qualitätsdrift

Die gleiche Umfrage ergab, dass fast die Hälfte der Ingenieur‑Führungskräfte Schwierigkeiten hat, Sicherheitsprobleme von Woche zu Woche zu erkennen. Komplexität, Duplikation und Abhängigkeiten, die nicht ganz passen, häufen sich über viele kleine, jeweils vernünftige Änderungen an. Keines von ihnen wirkt für sich genommen alarmierend. In derselben Stanford‑Fallstudie sank die Code‑Qualität um 9 % und ihre Varianz mehr als verdreifachte sich. Während sich der Durchschnitt nur wenig verschob, änderte sich die Streuung (der Teil, den Sie bemerken) stark. Bei AI‑Volumen akkumulieren sie schneller, als die meisten Review‑Prozesse sie erfassen können. Drift zeigt sich häufig als On‑Call‑Alarm, der auf eine Abhängigkeit zurückgeführt wird, an die sich niemand mehr erinnert, sie geprüft zu haben. Wenn das passiert, besteht eine beträchtliche Wahrscheinlichkeit, dass ein Kunde es zuerst bemerkt hat.

Beobachten Sie die Trendlinien bei Sicherheitsfindungen, Abhängigkeiten sowie Ausfällen und Wiederherstellungen – nicht den einzelnen Commit. Komplexität und Duplikation, die sich über mehrere Wochen einschleichen, sind wichtiger als jede einzelne Änderung, die im Review markiert wird. Ohne das entdecken Sie Drift auf die gleiche Weise wie die meisten Teams: erst, nachdem sie bereits einen Vorfall verursacht hat. 

Blind Spot 5: Unbewiesene Ausgaben

Sobald die KI‑Einführung keine Debatte mehr ist, werden KI‑Ausgaben und ROI zur zentralen Frage. Die Finanzabteilung möchte wissen, was kapitalisierbar und was operativ ist. Die Führungsebene will wissen, worin die Investition resultiert hat. Die meisten Teams treffen nach wie vor Entscheidungen zu Werkzeugen, Lizenzen und Personal auf Basis von Intuition, nicht anhand eines Nachweises der Verbindung zwischen Geld und erbrachter Arbeit.

Beobachten Sie, wohin der technische Aufwand tatsächlich im Code‑Base fließt, Quartal für Quartal – nicht dort, wo der Fahrplan sagt, dass er fließen soll. Ohne diese Verbindung verteidigen Sie das Budget für das nächste Jahr mit Anekdoten, und Anekdoten halten einer harten Diskussion mit dem CFO nicht stand.

Beginnen Sie mit dem, was Sie nicht sehen können

Die Frage der Finanzabteilung nach kapitalisierten Ausgaben und einer On‑Call‑Seite um 2 Uhr morgens wirkt zwar unzusammenhängend, ist es aber nicht. Beide können aus der Aktivität „geschätzt“ werden. Tatsächlich lassen sich beide jedoch anhand von Belegen aus dem Code selbst beantworten.

DORAs Antwort auf all das ist das Engineering‑System selbst: Plattform‑Qualität, Klarheit der Arbeitsabläufe, Team‑Ausrichtung. Das stimmt, und es ist zudem nicht der erste Schritt. Sie können ein System nicht reparieren, das Sie nicht sehen. Jeder dieser fünf Bereiche muss beobachtbar sein, bevor Sie für Investitionen dafür argumentieren können.

Der erste sinnvolle Schritt ist kein neues Tool oder Prozess. Es ist, sich selbst ehrlich zu kennen und zu bestimmen, welche dieser fünf Bereiche blinde Flecken sind, in denen Ihnen echte Belege fehlen. Die meisten Führungskräfte können sofort Probleme in einem dieser Bereiche erkennen (und achten darauf). Allerdings sind gerade die Bereiche, in denen Sie am wenigsten Informationen haben, am wahrscheinlichsten, dass sie auftauchen und Ihnen Probleme bereiten, wenn Sie KI weiter einführen.