KI-Halluzination im Code: Woran Sie sie erkennen und wie Prüfung sie abfängt

Was eine KI-Halluzination im Code ist

Der Begriff kommt aus der Sprachverarbeitung und meint eine Ausgabe, die richtig klingt und trotzdem nicht stimmt. Im Fließtext fällt das auf, weil eine erfundene Jahreszahl sich beim Nachschlagen erledigt. Im Code ist es schwieriger: Ein erfundener Funktionsaufruf sieht aus wie ein echter, hat dieselbe Form und dieselbe Selbstverständlichkeit. Sichtbar wird der Unterschied erst, wenn jemand nachsieht, ob es die aufgerufene Sache gibt und ob sie tut, was der umgebende Code von ihr erwartet.

Dass genau diese Klasse von Fehlern den Alltag prägt, sagt die Berufsgruppe selbst. Im Stack Overflow Developer Survey 2025 nannten 66 % der Entwickler als größte Frustration KI-Lösungen, die „fast richtig, aber nicht ganz“ sind; 45 % gaben an, das Debuggen von KI-Code sei zeitaufwendiger als das Debuggen selbst geschriebenen Codes. „Fast richtig“ ist die genaue Beschreibung dessen, worum es hier geht.

Dazu kommt eine Verzerrung in der Selbsteinschätzung. In der Untersuchung von Perry und Kollegen (ACM CCS 2023) schrieben Entwickler mit KI-Assistent messbar unsichereren Code und hielten ihn zugleich häufiger für gelungen als die Vergleichsgruppe ohne Assistent. Wer eine plausibel aussehende Ausgabe vor sich hat, prüft weniger. Das ist der Mechanismus, über den eine Halluzination in den Betrieb gelangt.

Die typischen Formen einer KI-Halluzination im Code

Es gibt nicht die eine Halluzination, sondern eine Handvoll wiederkehrender Muster. Sie sauber auseinanderzuhalten lohnt sich, weil jede Form an einer anderen Stelle auffällt und von einem anderen Prüfschritt gefangen wird.

Der erfundene Paketname verdient besondere Aufmerksamkeit: Ein Name, den es heute nicht gibt, kann morgen von jemand anderem belegt sein. Deshalb ist die Frage, ob eine Abhängigkeit wirklich die ist, für die man sie hält, ein eigener Prüfschritt und keine Formsache.

Die vierte Form ist die unangenehmste, weil sie keine Fehlermeldung erzeugt. Ein Beispiel aus dem Alltag: Eine Auswertung summiert Bestellwerte und rechnet dabei mit einem Feld, das Rabatte bereits enthält. Für die meisten Vorgänge stimmt das Ergebnis. Für die Vorgänge mit nachträglicher Gutschrift stimmt es nicht, und auffallen wird das nicht in der Abnahme, sondern im Monatsabschluss.

Warum Halluzinationen im Test selten auffallen

Wer eine neue Anwendung ausprobiert, geht den Weg, für den sie gebaut wurde, und genau dieser Weg funktioniert bei halluziniertem Code meistens. Was ausbleibt, ist der Blick auf die Ränder: der Datensatz ohne Adresse, der Vorgang mit zwei Rechnungen, die Gegenstelle, die schweigt, das Konto mit weniger Rechten.

Bei sicherheitsrelevanten Stellen kommt hinzu, dass die Wirkung unsichtbar ist. Veracode testete 2025 über 100 KI-Sprachmodelle und fand in 45 % der erzeugten Code-Beispiele Schwachstellen aus den OWASP Top 10, bei Java in 72 %. Bemerkenswert ist der Nebenbefund: Neuere und größere Modelle schrieben funktionaleren, aber keinen sichereren Code. Ein besseres Modell verschiebt die Grenze also, es beseitigt sie nicht.

Für die Planung folgt daraus eine schlichte Rechnung: Die Zeit, die beim Schreiben gespart wird, fällt beim Prüfen wieder an. Wer nur den ersten Teil einkauft, kauft eine halbe Leistung.

Wie vier Prüfrollen eine KI-Halluzination abfangen

Der wirksame Hebel ist nicht mehr Kontrolle vom Gleichen, sondern eine andere Frage an dieselbe Stelle. Ein Modell, das gerade eine Abfrage geschrieben hat, prüft sie darauf, ob sie das Gewünschte liefert. Es prüft sie nicht darauf, was passiert, wenn jemand in der Adresszeile eine Nummer verändert. Deshalb prüfen bei MCP Baldux vier unabhängige Rollen jeden Plan, und keine gibt ihre eigene Arbeit frei.

Auf die Formen von oben übersetzt: Die erfundene Bibliothek fällt der Architekturrolle auf, weil sie nach Herkunft und Pflegezustand jeder Abhängigkeit fragt. Die falsche Annahme über Ihre Daten fällt der Vollständigkeitsrolle auf, weil sie den Plan gegen das hält, was vereinbart war. Die zu weit geöffnete Berechtigung fällt der Sicherheitsrolle auf, die als einzige ein Veto hat. Und das Verhalten bei einer schweigenden Gegenstelle ist die Frage der Integrationsrolle.

Dabei entsteht die Belegkette: Sie hält fest, was geändert wurde, welche Rolle es geprüft hat und was nach einer Beanstandung nachgebessert wurde. Ohne diesen Nachweis bleibt eine Aussage über Prüfung eine Behauptung.

Checkliste: Halluzinationen früh sichtbar machen

Die folgenden Punkte decken die fünf Formen ab, ohne dass Sie eine Zeile Code lesen müssen.

1. Fremdbausteine benennen lassen. Welche Bibliotheken kommen vor, woher stammen sie, wer pflegt sie? Eine Liste, die niemand liefern kann, ist ein Befund.
2. Sonderfälle vorher aufschreiben. Der Vorgang mit der Ausnahme, über die im Betrieb geredet wird, gehört in den Plan und nicht in die Nachbesserung.
3. Rechte gegenprüfen. Melden Sie sich mit einem Konto an, das wenig darf, und versuchen Sie an etwas heranzukommen, das Sie nichts angeht.
4. Ausfall vorführen lassen. Was passiert, wenn das angebundene System schweigt? Eine hängende Maske ist eine Antwort, eine verständliche Meldung eine andere.
5. Zahlen einmal von Hand nachrechnen. Ein Monatswert, den Sie selbst kennen, bringt stille Rechenfehler ans Licht.
6. Getrennte Prüfung verlangen. Die prüfende Instanz darf nicht die bauende sein, und mindestens eine Rolle muss blockieren können.
7. Prüfprotokoll ansehen. Verlangen Sie ein anonymisiertes Beispiel: Was wurde geändert, wer hat geprüft, was kam dabei heraus?
8. Den geprüften Stand wiedererkennen. Es muss ein Merkmal geben, an dem eine spätere Abweichung auffällt.

Vollständig ausschließen lässt sich diese Fehlerklasse nicht; das kann niemand zusichern, der mit Sprachmodellen arbeitet. Zusichern lässt sich der Umgang damit: getrennte Prüfung, dokumentierte Sonderfälle und ein Nachweis, den Sie nachlesen können.