Es läuft. Aber keiner weiß, warum.
Stell dir vor, dein Unternehmen rolled eine neue Software aus. Die Tests sind grün, der Code sieht sauber aus, das Deployment läuft durch. Drei Monate später, an einem Sonntag um 2 Uhr nachts, geht die Produktion in die Knie. Das Team springt in den War-Room – und dann die Stille. Niemand kann erklären, was da eigentlich kaputtgegangen ist. Der Code wurde größtenteils von einer KI geschrieben. Er funktionierte. Bis er es nicht mehr tat.
Das ist kein Gedankenspiel. Es passiert gerade, in Unternehmen jeder Größe. Und es hat einen Namen: Comprehension Debt – die wachsende Lücke zwischen dem, was an Code in einem System existiert, und dem, was irgendein Mensch darin tatsächlich versteht.
Das Tückische daran: Anders als klassische technische Schulden, die man sehen, benennen und priorisieren kann, wächst Comprehension Debt unsichtbar. Der Code kompiliert. Die Tests laufen. Alles sieht gut aus. Bis es das nicht mehr tut.
Die Zahlen, die jede Führungskraft kennen sollte
Ein aktuelles Video eines erfahrenen CTOs hat die verstreuten Daten zu diesem Phänomen zusammengetragen – und sie zeichnen ein Bild, das über reine Tech-Kreise hinaus relevant ist:
- 45 % aller KI-generierten Codezeilen enthalten Sicherheitslücken. Das hat Veracode ermittelt, die über 100 verschiedene KI-Modelle analysiert haben. Dass die Gefahr real ist, zeigt der Fall der PocketOS-Datenbanklöschung durch einen KI-Agenten in 9 Sekunden. Bei Login-Systemen liegt die Fehlerquote bei 88 %, bei Web-Sicherheit bei 86 %. Hartcodierte Passwörter tauchen unter KI-Einsatz doppelt so häufig auf.
- Code-Churn – also Zeilen, die kurz nach dem Schreiben wieder gelöscht oder umgeschrieben werden – stieg von 5,5 % auf 7,9 %. Das ist keine Produktivität. Das ist Verschwendung im Kreis.
- Duplizierte Codeblöcke haben sich 2024 verachtfacht. Nicht weil Entwickler nachlässiger geworden sind. Sondern weil es schneller ist, etwas Neues von der KI generieren zu lassen, als bestehenden Code zu verstehen und wiederzuverwenden.
Der Grund für die Sicherheitsprobleme ist ebenso simpel wie beunruhigend: Die KI-Modelle wurden mit Milliarden Zeilen öffentlich verfügbaren Codes trainiert. Und öffentlicher Code enthält jahrzehntelang unsichere Praktiken. Das Modell kann nicht zwischen „das kommt häufig vor“ und „das ist sicher“ unterscheiden. Es reproduziert, was es gesehen hat.
⚠️ Das Haftungsproblem
Wenn dein System mit Finanzdaten, Patientendaten oder kritischer Infrastruktur arbeitet, ist „Die KI hat’s geschrieben“ vor Gericht keine Verteidigung. Es ist ein Geständnis.
Das stille Karrieredrama: Was mit den Menschen passiert
Hinter den technischen Metriken verbirgt sich ein menschliches Problem, über das kaum jemand spricht.
Die Jüngeren verlieren den Anschluss, ohne es zu merken. Studien zeigen: Entwickler, die ihre Arbeit an KI-Tools delegieren, schneiden in Verständnistests 17 % schlechter ab als diejenigen, die selbst programmieren. Sie bauen keine mentalen Modelle mehr auf. Sie leihen sie sich nur. Und geliehene Modelle helfen nicht, wenn um drei Uhr nachts das System brennt.
Die Junioren von heute sollen eigentlich die Senioren von morgen werden – diejenigen, die komplexe Architekturen entwerfen, kritische Entscheidungen treffen und den Laden am Laufen halten. Aber wenn sie nie durch Probleme kämpfen, nie Fehler machen und selbst beheben, nie die Intuition dafür entwickeln, warum etwas funktioniert – dann werden sie keine Senioren. Sie werden zu Menschen, die Prompts schreiben können, aber nicht wissen, was dahinter passiert.
Die Erfahrenen werden zu Aufräumkräften. Eine Analyse von über 2.700 Projekten zeigt: Wenn Junioren mit KI schneller Code produzieren, sinkt die Produktivität der Senioren, die diesen Code prüfen müssen, um 19 %. Sie designen keine Systeme mehr. Sie räumen hinter der KI her – und hinter den Kollegen, die ihr blind vertraut haben. Es ist, als würde man die Produktionshalle verdoppeln, während die Qualitätskontrolle gleich bleibt. Mehr Volumen, mehr Ausschuss, mehr Nacharbeit.
Wie es der CTO im Quellvideo formuliert: „Lass deine jungen Leute KI nicht als Ersatz fürs Denken nutzen. Nutze sie wie ein Kontrollwerkzeug, nachdem sie selbst gedacht haben. Das ist ein fundamentaler Unterschied.“
Warum SQLite und die NASA KI-Code verbieten – und was das für dein Unternehmen bedeutet
Es gibt Organisationen, die aus dieser Erkenntnis bereits klare Konsequenzen gezogen haben:
SQLite, die Datenbank-Engine, die in Milliarden von Geräten steckt – in jedem Smartphone, in jedem Browser, in Flugzeugen und Autos – hat KI-generierten Code explizit verboten. Ihre Begründung: Wenn etwas schiefgeht, muss ein Mensch vollständig dafür geradestehen können. Präzision schlägt Wahrscheinlichkeit. Immer.
Die NASA verlangt für sicherheitskritische Software nachweisbare Testabdeckung nach strengen Standards – Standards, an denen KI-generierter Code routinemäßig scheitert. Er produziert zu viel unnötigen Ballast, zu viele Abstraktionen, zu viele Stellen, an denen etwas schiefgehen kann, ohne dass es jemand gemerkt hat.
Dass der KI-Hype und echte Produktivitätsgewinne zudem weit auseinanderklaffen, belegt die Goldman-Sachs-Analyse zu KI-Produktivitätsgewinnen – messbare Effekte gibt es demnach nur in zwei Bereichen.
Natürlich baut nicht jedes Unternehmen Raketensoftware. Aber die Logik dahinter ist übertragbar: Je mehr von dem, was dein Unternehmen am Laufen hält, aus einer Blackbox kommt, desto größer wird das Risiko – und desto teurer wird der Moment, in dem es sich materialisiert.
Nicht weniger KI, sondern bessere Prozesse
Die Antwort ist nicht, KI-Tools zu verbannen. Die Antwort ist, die Reihenfolge zu ändern, in der sie eingesetzt werden.
In den meisten Teams läuft es aktuell so: Jemand tippt einen Prompt. Die KI generiert Code. Ein Mensch schaut kurz drüber. Es geht live. Das Problem daran: Das primäre Arbeitsergebnis ist der Code – und die KI hat ihn geschrieben. Der Mensch ist nur noch Qualitätskontrolle im Nachhinein.
Die Alternative heißt Spec-Driven Development: Das primäre Arbeitsergebnis ist die menschengeschriebene Beschreibung dessen, was gebaut werden soll – und warum. Die KI übersetzt diese Beschreibung in Code. Der Mensch prüft den Code gegen seine eigene Beschreibung, nicht nur gegen „es kompiliert“.
In der Praxis bedeutet das vier Schritte:
- Erklären, was gebaut werden soll – und warum. Das macht der Mensch. Vor jeder Zeile Code.
- Die Architektur durchdenken. Wie hängt das Neue mit dem Bestehenden zusammen? Der Mensch entscheidet.
- Die Arbeit in verdaubare Häppchen zerlegen, die die KI Schritt für Schritt abarbeiten kann.
- Das Ergebnis gegen die eigene Beschreibung prüfen. Nicht nur: Läuft es? Sondern: Tut es genau das, was ich beschrieben habe?
GitHub selbst nennt diesen Ansatz eine „Project Constitution“ – eine Art Grundgesetz für dein Projekt: Qualitätsstandards, Sicherheitsanforderungen und Testregeln, die feststehen, bevor die erste Zeile KI-Code entsteht.
KI ist kein Werkzeug, das dich schneller macht. Sie ist ein Verstärker.
Der vielleicht wichtigste Perspektivwechsel aus dem CTO-Video ist dieser: Denk nicht über KI wie über ein Tool, das dich schneller macht. Denk über sie wie über einen Verstärker.
Bringst du klare Vorstellungen, durchdachte Strukturen und sorgfältige Prüfroutinen mit – dann verstärkt KI genau das. Bringst du vage Wünsche, schwache Standards und blindes Vertrauen mit – dann verstärkt KI auch das. Nur eben schneller und in größerem Maßstab.
Die Menschen, die in dieser neuen Welt überflüssig werden, sind deshalb nicht die, deren Arbeit eine KI erledigen kann. Es sind die, die nie gelernt haben zu erkennen, wann die KI falsch liegt. Die abhängig wurden, bevor sie kompetent wurden.
Wer diese Disziplin beherrscht, kann KI-Coding produktiv einsetzen – wie mein Projektbericht zum Bau eines MCP-Servers mit Vibecoding zeigt.
Der Wechsel vom „Ich schreibe Code“ zum „Ich steuere, was Code tun soll“ ist keine Herabstufung. Es ist die natürliche Weiterentwicklung des Berufs. Aber dafür musst du die Absicht tatsächlich besitzen. Du musst beschreiben können, was du willst. Du musst Standards setzen, an denen du misst. Und du musst genug verstehen, um den Fehler zu erkennen, bevor er in der echten Welt Schaden anrichtet.
Um es mit den Worten des CTOs zu sagen: „Wenn du nicht erklären kannst, was deine KI geschrieben hat, wenn das System ausfällt – dann bist du kein Entwickler mehr. Du bist ein Risiko mit einem Firmen-Login.“
FAQ – Häufige Fragen zu KI-generiertem Code
Was ist Comprehension Debt – und warum ist es gefährlicher als normale technische Schulden?
Comprehension Debt beschreibt die Lücke zwischen dem, was an Code in deinem Unternehmen existiert, und dem, was jemand darin tatsächlich versteht. Anders als klassische technische Schulden („diesen Teil müssen wir irgendwann aufräumen“) ist sie unsichtbar: Der Code läuft, die Tests sind grün, alles wirkt in Ordnung. Das Problem zeigt sich erst, wenn etwas schiefgeht – und dann steht das Team da und kann den Fehler nicht erklären.
Wie viele Sicherheitslücken enthält KI-generierter Code wirklich?
Laut Veracode, die über 100 große KI-Modelle getestet haben, enthalten 45 % aller KI-generierten Codezeilen Sicherheitslücken. Bei Web-Sicherheit scheitert KI in 86 % der relevanten Fälle, bei Login-Systemen in 88 %. Besonders alarmierend: Hartcodierte Passwörter tauchen unter KI-Einsatz doppelt so häufig auf wie bei manueller Programmierung.
Macht KI-unterstütztes Arbeiten Teams wirklich schneller?
Es ist komplizierter als die Werbeversprechen. Junge Entwickler werden zwar schneller im Code-Schreiben. Aber die erfahrenen Kollegen, die diesen Code prüfen müssen, werden um 19 % langsamer. Der Netto-Effekt über das gesamte Team ist deutlich geringer als die oft zitierten 50 % Produktivitätssteigerung. Die Arbeit verschiebt sich vom Schreiben zum Korrigieren – und zwar auf die teuersten Schultern.
Warum verbieten SQLite und die NASA KI-geschriebenen Code?
SQLite steckt in Milliarden Geräten weltweit und verfolgt einen Null-Toleranz-Ansatz bei Fehlern: Wenn ein Problem auftritt, muss ein Mensch die volle Verantwortung übernehmen können – das ist mit KI-Code nicht gegeben. Die NASA muss für sicherheitskritische Systeme lückenlos nachweisen können, dass jede Code-Zeile unter allen Bedingungen korrekt funktioniert. KI-Code erfüllt diese Standards nicht und produziert zudem unnötige Komplexität. Beide setzen auf nachweisbare Korrektheit statt auf Wahrscheinlichkeit.
Was bedeutet Spec-Driven Development konkret für mein Team?
Statt die KI einfach Code produzieren zu lassen, schreibt das Team zuerst eine klare Beschreibung: Was soll entstehen, warum, und wie hängt es mit dem Rest des Systems zusammen? Diese Beschreibung – nicht der Code – ist das Hauptergebnis der Arbeit. Die KI übersetzt sie in Code, und der Mensch prüft: Tut der Code genau das, was beschrieben wurde? So bleibt die Kontrolle beim Menschen, und das Verständnis ist dokumentiert.
Was kann ich morgen anders machen?
Drei konkrete Dinge: (1) Beschreiben, bevor generiert wird – schreib auf, was du willst und warum, bevor die KI loslegt. (2) Die Prüfprozesse ausbauen, bevor du die Code-Produktion hochskalierst. (3) KI-generierten Code an kritischen Stellen wie Zahlungen oder Login-Systemen grundsätzlich wie ungeprüfte Fremdeingabe behandeln – also immer von einem Menschen gegenprüfen lassen. Wenn du den Code im Ernstfall nicht erklären kannst, hätte er nicht live gehen dürfen.
Quellen: CTO-Video: „Comprehension Debt“, GitClear Code Churn Analysis (211M Codezeilen), Veracode LLM Security Analysis (100+ KI-Modelle), SQLite AI Code Policy, NASA Safety-Critical Software Standards, GitHub Spec Kit.
