Welche typischen Fehler macht KI-generierter Code?

Fünf Klassen kehren wieder: halluzinierte APIs und Pakete (Aufrufe von Dingen, die nicht existieren), stille Randfall-Fehler (Happy Path funktioniert, Grenzen versagen), Scope Creep (Änderungen über den Auftrag hinaus), selbstbestätigende Tests (das Modell testet die eigenen Annahmen) und plausibel-aber-falsche Logik, die sich korrekt liest. Jede Klasse hat einen charakteristischen Grund, warum Review sie übersieht – und einen spezifischen Check, der sie fängt.

Was sind halluzinierte APIs und Pakete?

Aufrufe von Funktionen, Parametern oder ganzen Paketen, die es nicht gibt – das Modell vervollständigt ein plausibles Muster, statt die Realität zu konsultieren. Forschung maß bei Open-Source-Modellen rund 21,7 % halluzinierte Paketnamen, bei kommerziellen etwa 5,2 %; Angreifer nutzen das per Slopsquatting aus, indem sie häufig halluzinierte Namen vorregistrieren. Nicht existente APIs scheitern laut beim Build – nicht existente Pakete können still etwas Bösartiges installieren.

Warum wirkt KI-Code so überzeugend, obwohl er falsch ist?

Weil das Modell auf Plausibilität optimiert, nicht auf Wahrheit: idiomatischer Stil, konsistente Benennung, aufgeräumte Struktur sind genau das, was es gelernt hat zu produzieren. 61 % der Entwickler kennen KI-Code, der korrekt aussieht, aber nicht zuverlässig ist – die Politur, die Reviewer-Vertrauen aufbaut, trägt keinerlei Information über Korrektheit. Menschliche Schlampigkeit war früher ein Signal; ihr Fehlen führt jetzt in die Irre.

Liegt es am Tool oder am Workflow?

An beidem, in Schichten. Das Modell steuert charakteristische Fehlerklassen bei; der Workflow entscheidet, ob sie die Produktion erreichen. Derselbe Modell-Output ist harmlos in einer Pipeline mit vorab geschriebenen Tests, Grenzprüfung und Soll-Abgleich – und gefährlich in einer Merge-bei-grünem-Häkchen-Pipeline. Deshalb ist der Fix prozessual, nicht nur ein besseres Modell.

Beheben neuere Modelle diese Fehlermodi?

Die Raten verbessern sich, die Klassen bleiben. Kommerzielle Modelle halluzinieren deutlich seltener Pakete als offene, und jede Generation reduziert manche Fehlertypen – aber die strukturellen Ursachen (Mustervervollständigung ohne Bodenhaftung, Selbst-Testen, ungenannte Anforderungen mit erfundener Policy gefüllt) sind Eigenschaften des Setups, nicht der Modellversion. Für die Klassen planen, über die Raten freuen.

Welche einzelne Praxis fängt die meisten dieser Fehler?

Ein schriftlicher Auftrag mit Grenzen und Akzeptanzkriterien, nach dem Run geprüft. Er macht Scope Creep von unsichtbar zu einer Grenzverletzung, ungenannte Randfälle von modell-erfundener Policy zu expliziten Kriterien und „sieht richtig aus“ zu Kriterium-für-Kriterium Ja/Nein. Validierung, die das Modell nicht verfasst hat, schließt die Selbstbestätigungs-Schleife.

Konzept

Warum KI-Code Fehler macht

Zuletzt aktualisiert: 2026-07-02Lesezeit ca. 3 Min.

KI-generierter Code scheitert in charakteristischen Klassen statt in zufälligen Bugs: halluzinierte APIs und Pakete, stille Randfall-Fehler, Scope Creep, selbstbestätigende Tests und plausibel-aber-falsche Logik. Die gemeinsame Wurzel: Ein Modell vervollständigt plausible Muster ohne Bodenhaftung – und seine Politur entwaffnet genau das Review, das es fangen sollte.

Inhalt

Die fünf Fehlerklassen

Klasse	Wie sie aussieht	Warum Review sie übersieht	Was sie fängt
Halluzinierte APIs & Pakete	Aufrufe nicht existenter Funktionen oder Pakete (~21,7 % Paket-Halluzination bei offenen, ~5,2 % bei kommerziellen Modellen)	Die Namen sehen exakt aus wie echte	Build-/Typ-Checks; Dependency-Allowlists
Stille Randfall-Fehler	Happy Path funktioniert; leere Eingaben, Duplikate, Timeouts nicht	Reviewer gehen auch den Happy Path	Unglückspfade als explizite Akzeptanzkriterien
Scope Creep	Änderungen über den Auftrag hinaus – „Verbesserungen“, die niemand wollte	Off-Scope-Änderungen wirken wie Fleiß	Deklarierte Grenzen, nach dem Run geprüft
Selbstbestätigende Tests	Modell-geschriebene Tests behaupten die Modell-Annahmen	Grüne Suite liest sich wie Verifikation	Tests vor dem Run; Validierung, die das Modell nicht verfasst hat
Plausibel-aber-falsche Logik	Liest sich idiomatisch, löst ein subtil anderes Problem	Politur erzeugt unverdientes Vertrauen (61 % kennen den Fall)	Soll-Ist-Abgleich gegen den schriftlichen Auftrag

Die fünf charakteristischen Fehlerklassen KI-generierten Codes: wie jede aussieht, warum Review sie übersieht und welcher Check sie fängt.

Die gemeinsame Wurzel: Plausibilität ohne Bodenhaftung

Keine dieser Klassen ist ein Zufallsdefekt – alle sind derselbe Mechanismus aus verschiedenen Blickwinkeln. Ein Sprachmodell vervollständigt die plausibelste Fortsetzung eines Musters. Meistens ist die plausible Fortsetzung auch richtig; die Fehlerklassen sind die Stellen, an denen Plausibilität und Wahrheit systematisch auseinanderlaufen: eine API, die es per Analogie geben müsste, eine Policy für leere Eingaben, die nie gefordert war, ein Test, der die eigene Annahme der Implementierung festschreibt.

Die Politur gehört zum Problem. 61 % der Entwickler kennen KI-Code, der korrekt aussieht und es nicht ist – und die Security-Daten beziffern die Lücke: 45 % der KI-PRs bringen mindestens ein OWASP-Top-10-Problem mit (Veracode). Beim menschlichen Autor korrelierte schlampiger Stil mit schlampiger Logik, und Reviewer waren auf dieses Signal kalibriert. KI-Output hat das Signal entfernt, ohne die Fehler zu entfernen.

Der Sonderfall: selbstbestätigende Tests

Die tückischste Klasse verdient ihren eigenen Absatz, weil sie das Standard-Gegenmittel aushebelt. „Lass die KI Tests schreiben“ klingt nach Verifikation – aber Tests des generierenden Modells verifizieren die Annahmen des Modells, nicht eure Anforderungen. Hat die Implementierung die Absicht missverstanden, schreiben die Tests das Missverständnis fest, und die Suite wird grün auf einem falschen Programm. Das ist das Zirkularitätsproblem, das eine externe Referenz – eine schriftliche Vorgabe – strukturell notwendig macht statt nur wünschenswert.

Was das für eure Pipeline heißt

Pro Klasse ein Gate. Build- und Typ-Checks gegen Halluzinationen, explizite Unglückspfad-Kriterien gegen stille Fehler, deklarierte Grenzen gegen Scope Creep, vorab geschriebene Tests gegen Selbstbestätigung und ein Soll-Ist-Abgleich gegen plausibel-aber-falsche Logik.
Volumen multipliziert die Klassen. Jede Fehlerrate reitet auf dem Review-Engpass: mehr Code, subtilere Fehler, konstante Lesekapazität.
Raten ändern sich, Klassen bleiben. Die Pipeline für die Klassen bauen; über jede Modellgeneration freuen, die die Raten senkt.

Wo Reality Graph ansetzt

Reality Graph ist ein Pro-Run-Gate gegen genau diese Klassen: Grenzen fangen Scope Creep, Akzeptanzkriterien zwingen die Unglückspfade ans Licht, Validierung, die das Modell nicht verfasst hat, bricht die Selbstbestätigung – und der Prüfbericht hält fest, welche Checks wirklich liefen.

Die Klassen zu kennen liefert

Gezielte Gates statt generischem „härter reviewen“
Ein Reviewer-Briefing: wo KI-Code charakteristisch lügt
Eine Erklärung für Produktionsvorfälle trotz grüner Suite
Belegte Raten für das Risikogespräch

Sie bedeuten nicht

KI-Code ist in jeder Dimension schlechter als menschlicher
Jede Klasse tritt in jedem Run auf – es sind Raten
Bessere Modelle machen die Pipeline überflüssig
Menschlicher Code hätte keine eigenen Fehlerklassen

Wenn diese Grenzen zu eurem Team passen:

Early Access sichern So funktioniert es

FAQ

Welche typischen Fehler macht KI-generierter Code?: Fünf Klassen kehren wieder: halluzinierte APIs und Pakete (Aufrufe von Dingen, die nicht existieren), stille Randfall-Fehler (Happy Path funktioniert, Grenzen versagen), Scope Creep (Änderungen über den Auftrag hinaus), selbstbestätigende Tests (das Modell testet die eigenen Annahmen) und plausibel-aber-falsche Logik, die sich korrekt liest. Jede Klasse hat einen charakteristischen Grund, warum Review sie übersieht – und einen spezifischen Check, der sie fängt.
Was sind halluzinierte APIs und Pakete?: Aufrufe von Funktionen, Parametern oder ganzen Paketen, die es nicht gibt – das Modell vervollständigt ein plausibles Muster, statt die Realität zu konsultieren. Forschung maß bei Open-Source-Modellen rund 21,7 % halluzinierte Paketnamen, bei kommerziellen etwa 5,2 %; Angreifer nutzen das per Slopsquatting aus, indem sie häufig halluzinierte Namen vorregistrieren. Nicht existente APIs scheitern laut beim Build – nicht existente Pakete können still etwas Bösartiges installieren.
Warum wirkt KI-Code so überzeugend, obwohl er falsch ist?: Weil das Modell auf Plausibilität optimiert, nicht auf Wahrheit: idiomatischer Stil, konsistente Benennung, aufgeräumte Struktur sind genau das, was es gelernt hat zu produzieren. 61 % der Entwickler kennen KI-Code, der korrekt aussieht, aber nicht zuverlässig ist – die Politur, die Reviewer-Vertrauen aufbaut, trägt keinerlei Information über Korrektheit. Menschliche Schlampigkeit war früher ein Signal; ihr Fehlen führt jetzt in die Irre.
Liegt es am Tool oder am Workflow?: An beidem, in Schichten. Das Modell steuert charakteristische Fehlerklassen bei; der Workflow entscheidet, ob sie die Produktion erreichen. Derselbe Modell-Output ist harmlos in einer Pipeline mit vorab geschriebenen Tests, Grenzprüfung und Soll-Abgleich – und gefährlich in einer Merge-bei-grünem-Häkchen-Pipeline. Deshalb ist der Fix prozessual, nicht nur ein besseres Modell.
Beheben neuere Modelle diese Fehlermodi?: Die Raten verbessern sich, die Klassen bleiben. Kommerzielle Modelle halluzinieren deutlich seltener Pakete als offene, und jede Generation reduziert manche Fehlertypen – aber die strukturellen Ursachen (Mustervervollständigung ohne Bodenhaftung, Selbst-Testen, ungenannte Anforderungen mit erfundener Policy gefüllt) sind Eigenschaften des Setups, nicht der Modellversion. Für die Klassen planen, über die Raten freuen.
Welche einzelne Praxis fängt die meisten dieser Fehler?: Ein schriftlicher Auftrag mit Grenzen und Akzeptanzkriterien, nach dem Run geprüft. Er macht Scope Creep von unsichtbar zu einer Grenzverletzung, ungenannte Randfälle von modell-erfundener Policy zu expliziten Kriterien und „sieht richtig aus“ zu Kriterium-für-Kriterium Ja/Nein. Validierung, die das Modell nicht verfasst hat, schließt die Selbstbestätigungs-Schleife.

Weiterlesen

KonzeptVibe Coding und seine RechnungPrompten und ausliefern ohne Review tauscht Verifikation gegen Tempo – die aufgeschobene Rechnung in Churn, ~55 % Security-Pass-Raten, Fix-Zyklen und Aufräumkosten, samt der ehrlichen Gegenposition.VergleichCodeRabbit-Alternativen ohne CloudWas CodeRabbit gut macht, wo das Cloud-Modell zum Ausschlusskriterium wird und vier lokale Wege im Vergleich – self-hosted, Open Source, lokale Modelle, Verifikationsschicht. Preise Stand Juli 2026.Alle ArtikelDie ganze Sammlung – 30 belegte, datierte Guides zur Prüfung von KI-generiertem Code.