Die Bestandsaufnahme, beziffert und belegt
Im Jahr 2026 haben mehrere unabhängige Arbeiten aufgehört, von Eindrücken zu sprechen, und begonnen zu messen. Der meistzitierte Befund passt in einen Satz: Nur rund 35 % des KI-generierten Backend-Codes sind laut empirischen Auswertungen zugleich sicher UND korrekt. Anders gesagt: In der Mehrzahl der Fälle ist der erzeugte Code entweder falsch oder verwundbar oder beides, selbst wenn er auf den ersten Blick „funktioniert“.
Der Anteil an Code mit mindestens einer Schwachstelle wird je nach Studie auf 62 % bis 92 % geschätzt. Das ist eine weite Spanne, und sie sollte auch so gelesen werden: Die Methoden unterscheiden sich (getestete Sprachen, Definition einer Schwachstelle, angesetzte Schweregrade, Prompt-Korpus). Keine einzelne Zahl aus dieser Spanne sollte isoliert zitiert werden, ohne die Studie und ihre Methode zu nennen; ehrlich ist die Spanne, nicht ein einzelner Punkt.
Das Risiko ist nicht theoretisch. Der „Vibe Security Radar“ von Georgia Tech verzeichnet für das erste Quartal 2026 eine starke Beschleunigung der CVEs, die mit KI-generiertem Code zusammenhängen: 6 im Januar, 15 im Februar, 35 im März, über diese drei Monate also mehr als im gesamten Jahr 2025 zusammen.
Bei der Wahrnehmung folgt das Misstrauen den Zahlen: 87 % der Entwickler sagen, dass sie an der Zuverlässigkeit von KI-generiertem Code zweifeln. Wer ihn am meisten nutzt, vertraut ihm oft als Erster nicht blind.
Ein methodischer Hinweis, der Fairness halber: Dieses Korpus besteht überwiegend aus industrieller Sicherheitsforschung, aus Berichten von Sicherheitsfirmen, Audits und Benchmarks, und nicht aus einer von Fachkollegen begutachteten wissenschaftlichen Literatur. Nur eine einzige wirklich akademische Arbeit ist darunter (ein arXiv-Papier); der Rest stammt aus der Industrie. Das macht die Zahlen nicht falsch, verlangt aber, sie als das zu lesen, was sie sind: konvergierende unabhängige Messungen, kein festgeschriebener wissenschaftlicher Konsens.
Eine dieser Arbeiten verdient es, benannt zu werden, weil sie die Debatte genau einrahmt: Der unabhängige Benchmark Vibe-Eval (2026) katalogisiert die Fehlermodi mehrerer verbreiteter Generatoren, Lovable, Bolt, Cursor, Replit, v0, anhand von Kriterien der Anwendungssicherheit. Genau auf diesem Feld kann sich eine Engine, die eine datierte Laufzeitvalidierung veröffentlicht, frontal messen lassen, statt auf Vertrauen zu verweisen.
- ~35 % des KI-generierten Backend-Codes sind zugleich sicher und korrekt (empirische Auswertungen).
- 62 % bis 92 % des generierten Codes enthalten Schwachstellen, weite Spanne, unterschiedliche Methoden.
- Zugehörige CVEs: 6 → 15 → 35 pro Monat (Jan. → März 2026, Vibe Security Radar, Georgia Tech).
- 87 % der Entwickler zweifeln an der Zuverlässigkeit von KI-generiertem Code.
Warum: Ein probabilistisches Modell erzeugt plausiblen Code, keinen garantierten
Die Ursache ist struktureller, nicht vorübergehender Natur. Ein großes Sprachmodell erzeugt das wahrscheinlichste Token im gegebenen Kontext. Auf Code angewandt ergibt das die wahrscheinlichste Fortsetzung, nicht zwingend die korrekte und nicht die sichere. Das Modell hat keinen inneren Begriff von „dieses Schema kompiliert“, „diese Abfrage ist parametrisiert“, „diese Zugriffskontrolle existiert“; es hat einen Begriff davon, „wie Code dieser Art aussieht“.
Genau das macht das Problem heimtückisch: Halluzinierter Code ist plausibel. Er liest sich gut, kompiliert manchmal, wird ausgeliefert und versagt im Einsatz, oder schlimmer, er funktioniert dem Anschein nach und lässt zugleich eine SQL-Injektion, ein im Klartext hinterlegtes Geheimnis oder eine fehlende Berechtigungsprüfung offen. Die von den Studien dokumentierten wiederkehrenden Schwachstellenkategorien (Injektion, schlechter Umgang mit Geheimnissen, fehlende Eingabevalidierung, defekte Zugriffskontrolle) sind genau jene, die ein Modell reproduziert, weil sie in seinen Trainingsdaten reichlich vorkommen.
Eine Anweisung im Prompt zu ergänzen („schreibe sicheren Code“) verschiebt die Wahrscheinlichkeiten, ändert aber nichts an der Natur der Sache: Nichts garantiert das Ergebnis, weil nichts es überprüft. Eine Anweisung ist kein Beweis.
Die Unterscheidung, die alles verändert: Die KI schreibt die Spezifikation, ein Builder kompiliert den Code
Blueprint Maker geht von dieser Feststellung aus und weigert sich, den Code vom Modell schreiben zu lassen. Die Pipeline trennt zwei Rollen, die nichts zu vermischen zwingt. Die KI tut, was sie am besten kann: eine Fachdomäne verstehen und eine strukturierte Spezifikation erzeugen, ein Schema aus Entitäten, Beziehungen und Regeln im JSON-Format. Sie entwirft, sie programmiert nicht.
Anschließend verwandeln deterministische Builder, einmal geschrieben, getestet, versioniert, diese Spezifikation in Code: Datenbankschema, Bildschirme, Routen, Dashboards. Der Code wird also nie vom LLM „halluziniert“: Er wird von einem Programm erzeugt, dessen Verhalten man kennt. Die Eigenschaften der Komponenten werden nicht erraten, sondern nach festen Regeln aus der Spezifikation abgeleitet. Dieselbe Spezifikation als Eingabe erzeugt stets denselben Code als Ausgabe.
Diese Trennung beseitigt nicht auf magische Weise jedes Risiko, aber sie verlagert das Problem dorthin, wo es beherrschbar ist: Statt zu hoffen, dass ein probabilistisches Modell in Tausenden einzigartiger Zeilen keine Schwachstelle eingebaut hat, garantieren wir durch Konstruktion, dass die Code-Muster (Abfragen, Formulare, Kontrollen) aus einem einzigen, prüfbaren Generator stammen, der ein für alle Mal korrigierbar ist.
- Die KI → versteht die Domäne → erzeugt eine Spezifikation (keinen Code).
- Deterministische Builder → kompilieren die Spezifikation → erzeugen den Code.
- Der Code wird nicht Zeile für Zeile vom Modell abgeleitet: Er wird von einem bekannten Programm erzeugt.
Die belastbare Verteidigung: eine veröffentlichte Laufzeitvalidierung (K-15 / Health Score)
Code mit einer sichereren Methode zu schreiben, bleibt ein Versprechen, solange man es nicht beweist. Der entscheidende Unterschied besteht nicht darin zu behaupten „unser Code ist zuverlässig“, sondern darin, es zu messen und die Messung zu veröffentlichen. Jede von Blueprint Maker erzeugte Anwendung durchläuft eine automatisierte Laufzeitvalidierung namens K-15: Der Code wird kompiliert, die Anwendung tatsächlich gestartet und dann von einem automatisierten Browser Bildschirm für Bildschirm durchlaufen. Das Kriterium ist binär: Sie läuft, oder sie läuft nicht.
Das aggregierte Ergebnis, der Anteil der Anwendungen, die all diese Prüfungen über ein gleitendes Sieben-Tage-Fenster bestehen, wird unter dem Namen Health Score veröffentlicht und datiert. Es ist eine belastbare Zuverlässigkeitskennzahl: überprüfbar, nicht deklarativ, von einem automatischen Richter erzeugt und nicht von einem Marketingargument.
Genau das veröffentlicht kein rein probabilistischer Generator, und zwar aus einem grundlegenden Grund: Eine solche Messung zu erzeugen setzt einen deterministischen, reproduzierbaren Weg voraus, jede Ausgabe unter realen Bedingungen zu testen. Eine Pipeline, die den Code vom Modell schreiben lässt und ihn unverändert ausliefert, hat kein systematisches Laufzeit-Gate zum Vorzeigen. Transparenz über Zuverlässigkeit ist nur möglich, wenn Zuverlässigkeit so gebaut ist, dass sie sich messen lässt.
Unsere Grenzen, ehrlich gesagt
Eine Laufzeitvalidierung beweist, dass eine Anwendung sich bauen, starten und korrekt durchlaufen lässt; sie verringert die Fehlerklasse „plausibler, aber kaputter Code“ deutlich. Sie ersetzt keinen vollständigen Sicherheitsaudit der Anwendung, keinen Penetrationstest und keine Konformitätsprüfung. Blueprint Maker beansprucht bis heute keine SOC-2- oder ISO-Zertifizierung: Wir veröffentlichen lieber eine reale, datierte Kennzahl als ein Siegel, das nichts über das ausgelieferte Produkt aussagt.
Die richtige Lesart lautet so: KI-generierter Code hat ein gemessenes Zuverlässigkeitsproblem; die einzige glaubwürdige Antwort ist kein Versprechen, sondern eine veröffentlichte Überprüfung; die Trennung von Entwurf (die KI) und Fertigung (deterministische Builder) macht diese Überprüfung möglich und reproduzierbar. Das ist ein Fundament, kein Freibrief, und es ist besser als eine Zahl, die man nicht zeigt.
Quellen
Cloud Security Alliance, Vibe Coding / AI Governance Gap: https://labs.cloudsecurityalliance.org/research/csa-research-note-vibe-coding-ai-governance-gap-20260602-csa/
The Security Crisis in AI-Generated Code (2026): https://blog.vibecoder.me/security-crisis-ai-generated-code-2026
IOActive, The Security Gap in AI-Generated Code: https://www.ioactive.com/wp-content/uploads/2026/05/IOA-The-Security-Gap-in-AI-Generated-Code.pdf
AppStuck, AI-Generated App Security Risks (2026): https://www.appstuck.com/blog/ai-generated-app-security-risks
Vibe-Eval, AI App Security Benchmark 2026: https://vibe-eval.com/data-studies/ai-app-security-benchmark-2026/
Sherlock Forensics, AI Code Security Report 2026: https://www.sherlockforensics.com/pages/ai-code-security-report-2026.html
OX Security, Vibe Coding Security: https://www.ox.security/blog/vibe-coding-security/
arXiv, Coding With AI: https://arxiv.org/pdf/2512.23982