KI-Coding-Hype: Was tatsächlich messbar ist

Es ist ein vertrautes Muster. Ein Entwickler prüft frisch KI-generierten Code: Syntaxcheck, kein offensichtlicher Fehler, Commit. Drei Wochen später meldet das Monitoring einen Produktionsausfall. Die Ursache ist eine API-Property, die das Modell mit vollständiger Überzeugung erfunden hatte – korrekte Benennung, plausible Struktur, nirgendwo dokumentiert. Der Property-Name existiert in keiner Versionshistorie des SDK. Er hat nie existiert. Der Output hatte ausgesehen wie Arbeit. Er war keiner.

Seit Monaten kursiert in Tech-Kreisen eine These mit dem Charme einer einfachen Wahrheit: Code wird bald nichts mehr kosten. Der eigentliche Engpass verlagert sich zur Spezifikation. Wer nicht weiß, was er bauen will, zahlt künftig den höchsten Preis.

Das klingt präzise. Es fühlt sich nach Erkenntnis an. Und es ist, in wesentlichen Teilen, nicht belegt.

Der Replit-Vorfall: Was er zeigt und was nicht

Im Juli 2025 löschte ein KI-Agent der Plattform Replit die gesamte Produktionsdatenbank von SaaStr – während eines ausdrücklich verhängten Code-Freeze. Der Agent ersetzte die gelöschten Daten durch rund 1.200 erfundene Executive-Profile und ebenso viele Firmenprofile, behauptete, ein Rollback sei unmöglich, und lag damit ebenfalls falsch. Das Rollback funktionierte. Replit-CEO Amjad Masad entschuldigte sich öffentlich auf X und kündigte Korrekturen an.

Der Vorfall wurde breit rezipiert – und dabei häufig mit falschen Angaben weiterverbreitet: falscher Produktname, falscher Personenname, falsches Jahr. Das ist weniger ein Vorwurf an einzelne Autoren als ein Symptom: In einer Debatte, die Präzision als zentrale Kompetenz des KI-Zeitalters ausruft, fehlt diese Präzision oft schon bei den Grundfakten.

Der Vorfall selbst ist ein Governance-Problem, kein KI-Alignment-Problem. Ein autonomer Agent mit Schreibrechten auf Produktionsdaten ohne ausreichende Leitplanken – das ist keine neue Kategorie von Versagen. Die Architekturklasse, die diese Fehler erst möglich macht, ist hier im Detail beschrieben. Was neu ist: die Geschwindigkeit, mit der solche Fehler in Produktion gelangen, wenn der Prozess nicht mithält. Wie sich dasselbe Muster in Security Operations Centers manifestiert, wenn autonome Agenten auf degradierter Telemetrie operieren, ist an anderer Stelle dokumentiert – der Mechanismus ist strukturell identisch.

Zahlen, die nicht aus der genannten Quelle stammen

Zwei Datenpunkte sind in der Debatte besonders hartnäckig im Umlauf. Erstens: KI-generierter Code erzeuge 1,7-mal mehr Logikprobleme als von Menschen geschriebener Code – belegt durch eine Analyse von 470 GitHub-Pull-Requests. Zweitens: Der DORA-Report von Google zeige einen Anstieg der Bug-Raten um 9 Prozent, korreliert mit 90 Prozent mehr KI-Nutzung, bei gleichzeitig 91 Prozent längerer Review-Zeit.

Der erste Datenpunkt ist real, aber mit Vorsicht zu lesen. Die Studie stammt von CodeRabbit – einem Unternehmen, das KI-gestützte Code-Review-Tools verkauft. CodeRabbit hat ein kommerzielles Interesse daran, zu belegen, dass KI-Code fehleranfällig ist und deshalb durch ihr Produkt geprüft werden muss. Die Methodik ist transparent, die Befunde sind plausibel – aber die Quelle ist nicht neutral, und in keinem der Texte, die diese Zahl verwenden, wird das erwähnt.

Der zweite Datenpunkt ist falsch zugeordnet. Die Zahlen 9 Prozent und 91 Prozent stammen nicht aus dem Google DORA-Report. Sie stammen aus einer Analyse von Faros AI, ebenfalls einem kommerziellen Anbieter von DevOps-Analytics-Tools. Was der tatsächliche Google DORA 2024 zeigt, ist nüchterner und weniger griffig: steigende KI-Adoption korreliert mit 7,2 Prozent Rückgang bei Delivery Stability und 1,5 Prozent Rückgang bei Delivery Throughput. Reale Befunde – aber andere Zahlen, aus einer anderen Erhebung, mit anderen Implikationen.

Das Muster ist auffällig: Beide Quellenangaben sind entweder kommerziell befangen oder schlicht falsch zugeordnet. Das ist keine Kleinigkeit in einer Debatte, die vorgibt, auf Evidenz zu bestehen. Und es liegt nicht allein an mangelnder Sorgfalt – es liegt daran, dass das Feld zu jung ist für Langzeitstudien mit belastbaren Kontrollgruppen. Was 2025 als Evidenz gilt, ist methodisch gesehen Frühphase. Wer unter diesen Bedingungen mit Zahlen operiert, als wären sie gesettled science, macht denselben Fehler wie die Studien, die er zitiert.

Was eigene Messung zeigt

Wer KI-Coding-Tools nicht nur gelegentlich nutzt, sondern über einen längeren Zeitraum systematisch protokolliert, kommt zu anderen Zahlen als die Studien der Tool-Anbieter.

Aus eigener Praxis, über ein Jahr dokumentiert: Von 22 erfassten Fehlern in einem produktiven Entwicklungsprojekt waren 20 – 91 Prozent – auf KI-generierten Code zurückzuführen. Erfasst wurden alle Fehler, die im Review oder nach Deployment identifiziert wurden und auf eine konkrete Codezeile zurückgeführt werden konnten; Fehler ohne eindeutige Verursacherzuordnung wurden nicht gewertet. Die betroffenen 669 Codezeilen erforderten 231 Minuten Korrekturaufwand. Die KI hatte den entsprechenden Code in etwa 30 Minuten generiert. Die Nacharbeit dauerte achtmal so lange wie die Generierung.

Der dominierende Fehlertyp war nicht Syntax, nicht Formatierung – sondern API-Halluzinierung. Das Modell erfand Properties und Methodennamen ohne Prüfung, gab Index-Basen an ohne Beweis. Derselbe Fehlertyp trat in einem Fall viermal auf, dokumentiert als Wiederholung, mit steigendem Aufwand pro Iteration – ein Muster, das sich teilweise durch Kontextdegradation erklären lässt: KI-Coding-Tools werden über lange Konversationen schlechter, sie widersprechen sich, vergessen was sie gebaut haben, fangen an zu driften. Die Lektion aus jedem dieser Fälle war dieselbe: Quelldatei lesen, bevor API benutzt wird. Nie API-Verhalten behaupten ohne Beweis. Das Projekt arbeitete mit einer JavaScript/TypeScript-Codebasis und mehreren externen SDKs – einem Umfeld, in dem LLMs tendenziell gut trainiert sind und Halluzinierungsraten vergleichsweise niedrig liegen. Das Fehlerprotokoll beschreibt also nicht das schlechteste denkbare Szenario. Es beschreibt ein günstiges.

Dieselbe Praxisbeobachtung zeigt jedoch auch, unter welchen Bedingungen das Bild anders aussieht. Ein direkter Vergleich zwischen Neuentwicklung und einem Mapper-Projekt mit strukturierten, maschinenlesbaren Eingabedaten:

Metrik	Neuentwicklung	Mapper (maschinenlesbare Daten)
LOC	713	849
Fehler	19	8
Fehlerrate	1:38	1:106
Faktor	Baseline	2,8-fach besser

Der Unterschied ist nicht marginal. Bei strukturierten Eingaben sinkt die Fehlerrate um den Faktor 2,8. Das ist kein Zufall – es ist der Mechanismus: KI arbeitet aus Trainingsdaten, nicht aus der tatsächlichen Umgebung. Wo die Eingaben strukturiert und maschinenlesbar sind, trifft Trainingswissen auf reale Bedingungen. Wo sie es nicht sind – ältere Plattformen, proprietäre Bibliotheken, nichtstandardisierte APIs – rät das Modell. Und es sagt nicht, dass es rät. Der Output wirkt fertig. Er ist es nicht. Das ist dieselbe Fehlerklasse, die in Confident Wrong als strukturelles Architekturproblem beschrieben ist – nicht als Ausreißer, sondern als vorhersehbares Verhalten unter spezifischen Bedingungen.

Das ist keine Aussage gegen den Einsatz von KI-Tools. Es ist eine Aussage über die Bedingungen, unter denen ihr Output ohne intensive Prüfung übernommen werden kann – und unter welchen nicht.

AWS Kiro: richtige Idee, falsch eingeordnet

AWS hat Kiro veröffentlicht – eine Entwicklerumgebung, deren Kerninnovation darin besteht, strukturierte Spezifikationen vor der Code-Generierung zu erzwingen. Kiro arbeitet mit drei Pflichtdokumenten: requirements.md mit User Stories in EARS-Notation, design.md mit technischer Architektur, tasks.md mit Implementierungsplan. Code entsteht erst, wenn diese Dokumente vorliegen.

Die übliche Interpretation lautet: Schau, sogar Amazon erkennt, dass Spezifikation der neue Engpass ist. Das ist eine selektive Lesart. Die vollständige Interpretation lautet: Teams, die KI-Coding-Tools einsetzen, überspringen systematisch Planungsschritte, die vorher selbstverständlich waren – weil die Geschwindigkeit der Generierung den Prozess überrollt. Kiro ist nicht der Beweis, dass Spezifikation der neue Engpass ist. Kiro ist die Reaktion darauf, dass ein alter, bekannter Engpass durch neue Tools aktiv verschlimmert wird. Und dieser Engpass beginnt nicht beim Code – er beginnt weit davor.

Was Kiro als Innovation verkauft, ist in disziplinierten Entwicklungsumgebungen seit Jahrzehnten gelebte Praxis: Anforderung vor Implementierung, Testkriterium vor Code. Dass dieser Ansatz jetzt als Reaktion auf KI-Coding-Chaos in Tools auftaucht, ist weniger überraschend als symptomatisch – die Industrie entdeckt unter Druck, was sie unter anderem Druck nie verlernt hatte. Was das für israelische Hardware- und Softwarehersteller konkret bedeutet, die 2027 mit dem Cyber Resilience Act CE-konform sein müssen, ist hier ausgeführt.

Das Problem, das vor der KI schon da war

Kiro erzwingt den Prozess, weil er nicht mehr selbstverständlich ist. Das ist das sichtbare Symptom. Das eigentliche Problem liegt tiefer.

Es gibt einen Mechanismus, der in der KI-Coding-Debatte fast vollständig fehlt – obwohl er in vielen Organisationen bereits akut ist: Unternehmen wissen nicht, was sie wissen.

Prozesse, die seit Jahren funktionieren, sind selten vollständig dokumentiert. Ein erheblicher Teil des operativen Wissens steckt in den Köpfen der Personen, die diese Prozesse aufgebaut oder über Jahrzehnte betrieben haben. Nicht aus Fahrlässigkeit – sondern weil implizites Wissen schwer zu formalisieren ist und der Druck, es zu dokumentieren, solange fehlt, wie die betreffenden Personen noch da sind.

Dieser Zustand ist nicht neu. Neu ist die Gleichzeitigkeit von drei Entwicklungen: demografischer Wandel, Kostendruck durch KI-Einführung, und der Versuch, Prozesse zu automatisieren, die nie sauber beschrieben wurden.

Das Ergebnis ist absehbar. Wer Prozesse automatisieren will, die nur als implizites Erfahrungswissen existieren, bekommt von KI-Tools exakt das, was er spezifiziert – nicht das, was gemeint war. Und wenn die Personen, die den Unterschied kennen, nicht mehr erreichbar sind, gibt es keine Korrekturfunktion mehr.

Dieses Muster ist keine Theorie. Es ist in Unternehmen beobachtbar, die in den vergangenen Jahren Erfahrungsträger aus Kostengründen frühzeitig verabschiedet haben – und zwei Jahre später feststellten, dass kritisches Prozesswissen schlicht weg ist. Nicht digitalisiert, nicht übergeben, nicht rekonstruierbar. Wie das in der Praxis aussieht, wenn implizites Konfigurationswissen auf einen agentenbasierten KI-Einsatz trifft, ist hier dokumentiert – der Ausfall beginnt mit 147 GPOs und endet im Mailarchiv von 2018.

Wer dann KI als Lösung einführt, automatisiert im besten Fall eine Lücke. Im schlechteren Fall bemerkt er es nicht.

KI kann diesen Prozess unterstützen – Interviews transkribieren, Prozessbeschreibungen strukturieren, Wissenslücken sichtbar machen. Aber sie kann implizites Wissen nicht rekonstruieren, das nie externalisiert wurde. Das ist eine harte Grenze, die kein besseres Modell überwindet. Und sie ist, wie Sicherheit am Kipppunkt für regulierte Umgebungen zeigt, keine neue Grenze – sie war schon vor der KI da.

Wer das ignoriert und trotzdem automatisiert, bekommt schnelle Ergebnisse – und langsam wachsende Probleme, die er nicht mehr auf die KI schieben kann.

Was tatsächlich passiert, wenn Baukosten fallen

Die Unterversorgungsthese – billiger Code erzeugt explodierende Nachfrage, also mehr Jobs, nicht weniger – ist historisch als Analogie beliebt. Desktop-Publishing, Smartphone-Kameras, Mobile. Mehr Werkzeuge, mehr Arbeit.

Die Analogien haben ein strukturelles Problem: Sie beschreiben Domänen, in denen sinkende Produktionskosten tatsächlich neue Nutzergruppen erschlossen haben, weil die Technologie robust genug für Laien war. Desktop-Publishing funktioniert, wenn jemand Schriften auswählt und Layouts verschiebt. KI-Coding funktioniert nicht, wenn jemand ohne Entwicklungserfahrung eine Geschäftsanwendung für ein Krankenhaus bauen will. Die Bedingungen für gute KI-Code-Ergebnisse – strukturierte Eingaben, enger Scope, kompetente Aufsicht, verbreitete Zieltechnologie im Trainingsdatensatz – sind dieselben Bedingungen, die gute Softwareentwicklung immer vorausgesetzt hat. Die Einstiegshürde ist nicht verschwunden. Sie ist verschoben.

Was tatsächlich passiert, wenn Baukosten schnell sinken und die Governance nicht mithält: Fehler werden nicht mehr durch lange Entwicklungszyklen gebremst. Sie landen schneller in Produktion. Nicht trotz der Geschwindigkeit, sondern wegen ihr. Hinzu kommt ein Fehlermodus, der in der Vibe-Coding-Debatte systematisch unterbelichtet bleibt: der Prototyp, der mit einem produktionstauglichen System verwechselt wird. KI senkt die Kosten, Software zu erstellen – nicht die Kosten, Software zu besitzen. Wer ein in Stunden vibecodiertes Tool deployed, das echte Nutzer hat, trägt die Haftung für das, was um 2 Uhr nachts kaputtgeht. Authentication, Fehlerbehandlung, Edge Cases – KI deckt zuverlässig den Happy Path ab. Genau dort wohnen die Probleme, wenn reale Nutzer kommen.

Das eigentliche Risiko ist nicht der Fehler

Es gibt einen Einwand gegen die bisherige Kritik an KI-Coding-Tools, der oberflächlich plausibel klingt: LLMs haben Fehler, aber sie werden besser. In vier Jahren haben sie mehr erreicht als erwartet. In weiteren vier Jahren werden viele der heutigen Fehlerprotokolle überholt sein.

Das ist wahrscheinlich richtig. Und es ist trotzdem kein Argument gegen sorgfältige Prüfung heute.

Der tiefere Einwand liegt woanders. Wenn KI-Tools Lesen, Schreiben, Rechnen und Urteilen zunehmend übernehmen, wird die menschliche Fähigkeit, ihren Output zu bewerten, nicht parallel mittrainiert – sie verkümmert. Wer nicht mehr selbst rechnet, verliert das Gefühl dafür, ob ein Ergebnis plausibel ist. Wer nicht mehr selbst schreibt, verliert das Gespür dafür, ob ein Text stimmt. Wer nicht mehr selbst prüft, verliert die Fähigkeit, Fehler zu erkennen. Dass dieser Mechanismus nicht auf Coding beschränkt ist, sondern in sicherheitsrelevanten Entscheidungssystemen dieselbe Struktur annimmt, zeigt Eskalation als Default am Beispiel von Frontier-Modellen unter maximalem Entscheidungsdruck.

Das ist keine romantische Kulturkritik. Es ist ein funktionales Problem: KI-Systeme brauchen menschliche Urteilsfähigkeit als Korrekturfunktion. Wenn diese Korrekturfunktion durch denselben Prozess geschwächt wird, der die Systeme nützlich macht, entsteht eine Abhängigkeit ohne Rückfallebene.

Wer jetzt nicht ernsthaft prüft, wann und wie KI-Output übernommen werden kann, trainiert sich selbst ab – und bemerkt es nicht, weil der Output so überzeugend wirkt.

Fazit

KI-Coding ist real. Die Werkzeuge werden besser. Einige Einsatzszenarien funktionieren gut. Aber die Voraussetzungen dafür sind organisational, nicht technisch – und in vielen Unternehmen schlicht nicht erfüllt.

Für KRITIS-Betreiber und NIS-2-pflichtige Organisationen in Deutschland ist das keine abstrakte Debatte. Der Einsatz von KI-Coding-Tools ohne angepasste Qualitäts- und Governance-Prozesse ist kein produktives Experiment – es ist eine dokumentierbare Lücke gegenüber BSI IT-Grundschutz CON.8 und Artikel 21 NIS-2. Was normkonforme KI-Governance in diesem Kontext konkret bedeutet, ist hier beschrieben. Nicht weil KI grundsätzlich unsicher ist, sondern weil Geschwindigkeit ohne Kontrollstruktur in regulierten Umgebungen keine Effizienzsteigerung ist. Es ist ein Haftungsrisiko.

Was sich seriös sagen lässt: KI-Coding-Tools erzeugen unter engen, gut strukturierten Bedingungen mit kompetenter Aufsicht und verbreiteter Zieltechnologie messbar brauchbare Ergebnisse. Außerhalb dieser Bedingungen produzieren sie Code, der formal korrekt wirkt, konzeptuell aber falsch liegt – und das ist schwerer zu erkennen als ein Syntaxfehler.

Die Debatte, wie sie derzeit geführt wird, arbeitet mit falsch zugeordneten Studien, verschwiegenen Interessenkonflikten und Analogien als Belegen. Das untergräbt nicht nur die Glaubwürdigkeit einzelner Texte. Es verzögert die ernsthafte Auseinandersetzung mit einer Technologie, die tatsächlich Konsequenzen hat – für Organisationen, die zu früh vertrauen, genauso wie für solche, die zu lange warten.

Qualitätskontrolle war schon immer der Engpass. KI macht ihn sichtbarer – und teurer, wenn er ignoriert wird.

Das Modell rät. Und es sagt nicht, dass es rät.

Wer in seiner Organisation gerade abwägt, wie weit KI-generierter Code ohne angepasste Governance-Strukturen tragfähig ist – und wer die regulatorischen Konsequenzen davon einordnen will: Sprechen Sie mich direkt an.

Anmelden zu unserem Newsletter:

Cyber Atlas Israel