Schneller Code, langsameres Team: die vier Folgekosten von KI-Entwicklung (die auf keiner Lizenzrechnung stehen)

Ich fange mit einer Selbstauskunft an, damit wir uns nicht falsch verstehen: Ich entwickle seit 2009 Software, und seit Anfang 2025 entsteht der größte Teil meines Codes im Dialog mit KI-Werkzeugen, allen voran Claude Code. Ich würde keinen einzigen Tag zurücktauschen. Dieser Artikel ist also keine Warnung vor dem Werkzeug. Er ist die Rechnung, die im Prospekt fehlt.

Kennst du diese Situation auch:

• Dein Dev-Team arbeitet seit Monaten mit KI-Tools, die Demo war beeindruckend, die Entwickler sind zufrieden, und trotzdem wurde das Release gerade wieder verschoben?
• Die Bugliste wird nicht kürzer, obwohl doch angeblich alles so viel schneller geht?
• Und dein erfahrenster Entwickler wirkt gestresster als vor der Einführung, dabei sollte ihn das Werkzeug doch entlasten?

Falls du irgendwo genickt hast: Es liegt wahrscheinlich weder am Tool noch am Team. Es liegt an vier Folgekosten, die KI-gestützte Entwicklung strukturell mitbringt: schleichend, in keinem Dashboard sichtbar, auf keiner Rechnung ausgewiesen. Bezahlt werden sie trotzdem. Die Frage ist nur: geplant oder ungeplant.

Die Rechnung, die dir kein Tool-Anbieter zeigt

Eine Abgrenzung vorweg: Was die Einführung von KI-Tools in Euro kostet (Lizenzen, Setup, Schulung), ist ein eigenes Thema für einen eigenen Beitrag. Heute geht es um das, was danach anfällt: die strukturellen Folgekosten im Entwicklungsalltag. Die stehen auf keiner Rechnung, und genau deshalb übersieht man sie so leicht.

Das Kernbild dahinter ist einfach: Code schreiben war nie der Engpass der Softwareentwicklung. Der teure Teil war immer das Drumherum: verstehen, was gebaut werden soll, prüfen, ob es stimmt, und warten, was schon da ist. KI verbilligt nun ausgerechnet den billigsten Teil der Arbeit, das Tippen. Die teuren Teile bleiben teuer. Und weil plötzlich viel mehr Code entsteht, werden sie sogar mehr.

Dass das kein Bauchgefühl von mir ist, zeigt der DORA-Report 2025 mit weltweit rund 5.000 Befragten: KI-Adoption korreliert dort positiv mit dem Durchsatz der Teams, aber negativ mit der Stabilität der Auslieferung. Mehr kommt raus, und es geht öfter schief. Der Kernsatz des Reports: KI wirkt als Verstärker dessen, was organisatorisch schon da ist. Sie repariert nichts.

Schauen wir uns die vier Posten einzeln an. Weil dieser Artikel für dich als Geschäftsführer geschrieben ist und nicht für deinen Tech-Lead, endet jeder mit dem Beschluss, den nur du fassen kannst.

Posten 1: Review-Last. Der Engpass verschwindet nicht, er wandert

Was passiert, wenn ein Team mit KI plötzlich doppelt so viel Code produziert? Ungefähr das, was passiert, wenn du auf einer einspurigen Straße doppelt so viele Autos losschickst. Die Telemetrie-Daten von Faros AI (ein kommerzieller Analytics-Anbieter, keine begutachtete Studie, aber mit Daten aus über tausend Entwicklungsteams) zeigen es deutlich: Teams mit intensiver KI-Nutzung mergen 98 Prozent mehr Pull Requests, also fertig entwickelte Änderungspakete, die auf Prüfung und Freigabe warten. Die Zeit pro Review steigt gleichzeitig um 91 Prozent. Der Ausstoß verdoppelt sich, der Prüfaufwand fast auch. Nur die Prüfkapazität bleibt gleich.

Dazu passt, was Entwickler selbst berichten: In der Stack-Overflow-Umfrage 2025 nennen 66 Prozent als größte Frustration „KI-Lösungen, die fast richtig sind, aber eben nicht ganz", und 45 Prozent sagen, dass das Debugging von KI-Code mehr Zeit kostet. Fast richtig ist bei Code die teuerste Sorte von falsch, denn fast richtig muss erst einmal jemand finden.

Ich kenne den Effekt aus erster Hand, wenn auch im Ein-Personen-Maßstab: Ich führe kein Team von Seniors durch einen Review-Stau, meine Firma bin im Kern ich. Aber mein eigener Arbeitstag hat sich seit der Umstellung spürbar verschoben: vom Schreiben zum Prüfen. Die KI liefert in Minuten, was ich früher in Stunden gebaut habe, und einen guten Teil der gewonnenen Zeit verbringe ich damit, das Ergebnis zu lesen, zu hinterfragen und nachzubessern. Dass erfahrene Entwickler mit KI anfangs sogar messbar langsamer werden können, laut METR-Studie um 19 Prozent, habe ich im Beitrag zur J-Kurve ausführlich auseinandergenommen; das vertiefe ich hier nicht noch einmal.

Dein Beschluss als Geschäftsführer: Review-Kapazität ist ab sofort dein Time-to-Market-Engpass. Senior-Zeit fürs Prüfen muss budgetiert werden: als echte, eingeplante Arbeitszeit, nicht als „macht der Kollege nebenbei". Und die Feature-Erwartung gehört entsprechend kalibriert: Wer mehr Output bestellt, ohne Prüfkapazität mitzubestellen, bestellt einen Stau.

Woran du den Review-Stau erkennst (ohne Entwickler zu sein)

Du musst dafür keinen Code lesen können, drei Signale reichen. Wenn Pull Requests regelmäßig tagelang offen bleiben, staut es sich. Wenn „ist fertig entwickelt" und „ist live beim Kunden" in den Statusmeetings immer weiter auseinanderdriften, staut es sich. Und wenn dein erfahrenster Entwickler zum Nadelöhr geworden ist, durch das jede Änderung hindurchmuss, dann steht der Stau längst. Er heißt nur noch nicht so.

Posten 2: Technische Schuld. Code entsteht schneller, als er verstanden wird

Der zweite Posten ist leiser, dafür langlebiger. GitClear hat 623 Millionen Codeänderungen aus den Jahren 2023 bis 2026 ausgewertet, und die Trends sind eindeutig: Code-Duplikation ist um 81 Prozent gestiegen. Der Anteil kopierter Zeilen an allen Änderungen wuchs von 9,4 Prozent im Jahr 2022 auf 15,7 Prozent im Jahr 2026. Und das Refactoring, das Aufräumen und Umbauen von bestehendem Code, kollabierte im selben Zeitraum von 21 auf 3,8 Prozent. Es wird also deutlich mehr kopiert und deutlich weniger aufgeräumt als vor der KI-Ära.

Warum dich das interessieren sollte, obwohl es nach Entwickler-Hygiene klingt: Duplizierter Code bedeutet, dass derselbe Fehler an mehreren Stellen wohnt. Er muss mehrfach gefunden und mehrfach behoben werden, und jede künftige Änderung muss an mehr Stellen nachziehen. Technische Schuld ist ein Kredit mit Zinseszins, nur dass die Raten nicht auf dem Kontoauszug stehen, sondern in Sätzen wie „das dauert länger als gedacht, da hängt noch was dran".

In Codebasen, die wir von anderen übernehmen, meine ich diese Muster inzwischen wiederzuerkennen: Strukturen, die entstanden sind, weil das Annehmen des Vorschlags schneller war als das Aufräumen. Das ist eine Beobachtung aus Projekten, keine Statistik, und ich will sie nicht überdehnen. Die GitClear-Zahlen brauchen meine Anekdote zum Glück auch nicht.

Dein Beschluss als Geschäftsführer: Wartbarkeit aktiv bepreisen. Konkret heißt das: Refactoring-Zeit als festen Anteil der Entwicklungszeit freigeben und eine Definition of Done durchsetzen (also verbindliche Kriterien, wann etwas wirklich fertig ist), die Aufräumen einschließt. Wenn du das nicht tust, entscheidet faktisch das Tool über die Wartbarkeit deines Produkts. Und falls dein Unternehmen Software an Kunden liefert: Denk das Gewährleistungsrisiko gleich mit.

Posten 3: Wissenserosion. Wenn niemand mehr weiß, warum der Code so aussieht

Der dritte Posten ist der am schwersten messbare, und das sage ich gleich ehrlich dazu: Für Wissenserosion gibt es bislang keine saubere Messgröße. Hier spricht Erfahrung, keine Statistik. Aber die Mechanik ist so einleuchtend wie unangenehm: Wer Code annimmt, den er nicht selbst durchdrungen hat, kann ihn später weder erklären noch sicher ändern. Multipliziere das über Monate und ein ganzes Team, und dein Unternehmen besitzt irgendwann ein Produkt, das niemand mehr wirklich versteht.

Ein paar Indizien gibt es dennoch. Dieselbe GitClear-Auswertung zeigt, dass die Pflege von Bestandscode um 74 Prozent zurückgegangen ist und die Refactoring-Aktivität um 70 Prozent: Es wird angebaut statt verstanden. Und der DORA-Report liefert ein bemerkenswertes Paradox: 90 Prozent der Befragten nutzen KI bei der Arbeit, aber 30 Prozent vertrauen KI-generiertem Code wenig oder gar nicht. Wenn beides gleichzeitig stimmt, liegt ein Schluss nahe, und das ist jetzt meine Interpretation, nicht der Wortlaut des Reports: Eine Menge Code geht in Produktion, dem sein eigener Autor nur begrenzt traut.

Mein eigenes Gegenmittel ist eine simple, unbequeme Regel: Nichts geht ins Repository, was ich nicht erklären könnte. Wenn ich einen KI-Vorschlag nicht in eigenen Worten begründen kann, ist er nicht fertig – dann ist er nur vorhanden. Das kostet Zeit, ja. Aber es ist der Unterschied zwischen einem System, das mir gehört, und einem, das ich nur noch bewohne.

Dein Beschluss als Geschäftsführer: Begrenze das Klumpenrisiko. Das System muss dem Unternehmen gehören, nicht dem Tool und nicht einem einzelnen Kopf. Konkret freizugeben: Zeit für die Dokumentation der Architektur-Entscheidungen und die Regel, dass Verstehen zur Abnahme gehört. Die Testfrage stellst du am besten dir selbst: Wenn dein bester Entwickler morgen kündigt und dein KI-Tool übermorgen den Anbieter wechselt, wer erklärt dir dann dein eigenes Produkt?

Posten 4: Sicherheitslücken. „Sieht plausibel aus" ist kein Sicherheitskonzept

Der vierte Posten ist der mit dem größten Schadenpotenzial. Veracode testet seit 2025 laufend über 100 Sprachmodelle mit denselben 80 Programmieraufgaben. Das Ergebnis: Rund 45 Prozent des generierten Codes enthält bekannte Sicherheitslücken. Die naheliegende Hoffnung, dass sich das mit besseren Modellen auswächst, hat das Frühjahrs-Update 2026 beerdigt: über 150 Modelle getestet, inklusive der neuesten Generationen. Die Syntax stimmt in etwa 95 Prozent der Fälle, die Sicherheits-Pass-Rate stagniert bei etwa 55 Prozent. Die Modelle sind exzellent darin geworden, Code zu schreiben, der läuft. Beim Code, der sicher ist, treten sie auf der Stelle.

Wie sich das anfühlt, habe ich Ende letzten Jahres in meinem Beitrag über den Alltag mit KI-Agenten beschrieben: Ein Agent lieferte mir Code für ein neues Feature. Saubere Struktur, gute Lesbarkeit, Tests grün. Erst beim zweiten Hinsehen fiel mir auf, dass er eine zentrale Sicherheitsprüfung „vereinfacht" hatte. Also: entfernt. In Produktion wäre das übel ausgegangen. Genau das ist der teuerste Fehlertyp: Code, der funktioniert und plausibel aussieht, aber subtil verwundbar ist. Der fällt nicht im Test auf. Der fällt im Vorfall auf.

Und damit ist es kein reines Technikthema mehr. Wenn dein Unternehmen unter NIS2 fällt oder Software an Kunden liefert, ist ungeprüfter KI-Code ein Risikomanagement-Thema mit deinem Namen darunter. Warum ich Sicherheit und KI ohnehin für untrennbar halte, habe ich an anderer Stelle aufgeschrieben. Und wie sich das in konkrete Compliance-Maßnahmen übersetzt, ist ein eigenes Kapitel.

Dein Beschluss als Geschäftsführer: Preise das Haftungsrisiko ein. Sicherheitsprüfung, automatisierte Scanner plus menschliches Review, wird nicht verhandelbarer Teil der Definition of Done. Mit einer klaren Regel: KI-generierter Code durchläuft dieselbe oder eine strengere Prüfung wie von Menschen geschriebener. Niemals eine laxere, nur weil er so überzeugend aussieht.

Vier Posten, vier Beschlüsse: die Übersicht

Falls du nur eines aus diesem Artikel mitnimmst, dann bitte diese Tabelle:

Die gute Nachricht: Das ist ein Regel-Problem, kein Werkzeug-Problem

Vielleicht klingt das alles, als wollte ich dir die KI-Entwicklung ausreden. Das Gegenteil ist der Fall: Ich will dir die zweite Hälfte der Rechnung zeigen, bevor du sie ungeplant bezahlst. Denn alle vier Posten haben dieselbe Eigenschaft: Sie sind beherrschbar. Nicht durch ein besseres Tool, sondern durch Regeln. Und der DORA-Befund vom Anfang ist dabei ausnahmsweise eine gute Nachricht: Wenn KI verstärkt, was da ist, dann verstärkt sie eben auch gute Review-Praxis, gepflegte Codebasen und klare Verantwortlichkeiten. Dasselbe Muster sehe ich bei KI-Agenten: Nicht das Werkzeug entscheidet über den Erfolg, sondern die Regeln und die Wartung drumherum.

Die ehrliche Grenze gehört aber auch hierher: Diese Regeln kosten real etwas. Wer KI-Entwicklung einführt und 100 Prozent der versprochenen Geschwindigkeit einplant, hat schon verloren: Ein Teil des Tempogewinns wird in Prüfen, Aufräumen und Sicherheit reinvestiert. Wie sich die Produktivität dabei über die Zeit entwickelt (erst runter, dann rauf), steht im Beitrag zur J-Kurve. Der Rest ist dann echter, dauerhafter Gewinn. Und das ist mehr, als die meisten Digitalisierungsversprechen am Ende halten.

Wenn du KI-Entwicklung in deinem Team einführen willst, ohne die vier Folgekosten ungebremst einzusammeln, oder wenn du den Verdacht hast, dass sie sich bei dir schon stapeln, weil Releases stocken, die Bugliste wächst und dein Senior zum Dauerengpass geworden ist: Lass uns reden. Im Erstgespräch schauen wir gemeinsam, wo dein Engpass wirklich sitzt: ob ein Workshop zu KI-Entwicklungsregeln für dein Team der richtige Schritt ist oder erst einmal eine ehrliche Zweitmeinung zur Codebasis. Keine Panik-Folien, keine 45-Prozent-Schlagzeilen als Verkaufsargument. Versprochen.