KI-Halluzinationen im Code erkennen

1. Was eine Code-Halluzination ist

Eine Code-Halluzination ist eine Ausgabe eines Sprachmodells, die syntaktisch korrekt und stilistisch passend aussieht, sich aber auf eine Methode, Klasse, Konfiguration oder ein Verhalten bezieht, das im referenzierten System schlicht nicht existiert. Das Modell erfindet nichts böswillig, sondern setzt bei der Token-für-Token-Vorhersage auf das statistisch Wahrscheinlichste. Wenn ein Muster wie $product->getStockQty() in unzähligen Trainingsbeispielen ähnlicher Getter-Methoden auftaucht, ist die Wahrscheinlichkeit hoch, dass Claude eine plausible, aber nicht real existierende Variante davon vorschlägt, selbst wenn die tatsächliche Magento-Methode anders heißt.

Wichtig ist die Abgrenzung zu einem gewöhnlichen Bug: Ein Bug ist meist ein Logikfehler in korrektem, ausführbarem Code. Eine Halluzination bezieht sich dagegen auf etwas, das schlicht nicht existiert, sei es eine API-Methode, ein Composer-Paket, eine Konfigurationsoption oder eine Behauptung über das Verhalten einer Bibliothek. Diese Unterscheidung ist entscheidend, weil die Erkennungsstrategien unterschiedlich sind: Bugs findet man durch Testen der Logik, Halluzinationen findet man durch Verifikation der Existenz.

2. Typische Erscheinungsformen im Code

Die häufigste Form ist die erfundene Methode auf einer bekannten Klasse: ein plausibel klingender Methodenname, der zur restlichen API passen würde, aber im tatsächlichen Interface nicht existiert. In Magento-Projekten tauchen zusätzlich Mischformen aus Magento-1- und Magento-2-Konventionen auf, weil beide Versionen im Trainingsmaterial vertreten sind. Ein Modell schlägt dann etwa eine Methode mit Magento-1-Namenskonvention auf einem Magento-2-Repository vor, was auf den ersten Blick stimmig wirkt, aber nicht kompiliert.

Eine zweite Form betrifft erfundene Pakete und Klassenpfade, etwa ein Composer-Paket mit einem Namen, der zur Namenskonvention eines bekannten Vendors passt, aber nie veröffentlicht wurde. Eine dritte Form sind falsche Parameterreihenfolgen oder Rückgabetypen, bei denen eine real existierende Methode mit vertauschten Argumenten oder einem falsch angenommenen Rückgabewert verwendet wird. Eine vierte, subtilere Form sind überzeugend falsche Konfigurationswerte, etwa ein XML-Attribut oder ein Event-Name, der wie ein echter Magento-Konventionswert aussieht, aber im System nirgends registriert ist und stillschweigend ignoriert wird.

// Hallucinated array method used inside an Alpine.js component
// groupToMap() does not exist on Array.prototype in any JS engine
document.addEventListener('alpine:init', () => {
  Alpine.data('productFilter', () => ({
    products: [],
    grouped: new Map(),
    init() {
      // This line looks plausible but throws:
      // TypeError: this.products.groupToMap is not a function
      this.grouped = this.products.groupToMap(p => p.category);
    }
  }));
});

// Correct: plain reduce, no such builtin exists in JavaScript
function groupByCategory(products) {
  return products.reduce((acc, product) => {
    const key = product.category;
    if (!acc.has(key)) acc.set(key, []);
    acc.get(key).push(product);
    return acc;
  }, new Map());
}

3. Warum Halluzinationen im Code gefährlicher sind als in Prosa

Eine Halluzination in einem Fließtext, etwa eine falsche Jahreszahl oder ein erfundenes Zitat, lässt sich meist durch Gegenlesen und gesunden Menschenverstand erkennen. Der Leser hat ein natürliches Sprachgefühl dafür, ob eine Aussage plausibel klingt, und kann sie leicht mit einer zweiten Quelle abgleichen. Bei Code fehlt dieses intuitive Korrektiv häufig: Ein Entwickler, der eine unbekannte Magento-API nutzt, hat oft kein eingebautes Gespür dafür, ob eine vorgeschlagene Methode wirklich existiert, weil moderne Frameworks hunderte Klassen mit ähnlich klingenden Namen enthalten.

Der zweite Grund ist struktureller Natur: Code wird ausgeführt, Prosa wird gelesen. Eine falsche Behauptung in einem Text bleibt eine falsche Behauptung, verändert aber keinen Systemzustand. Fehlerhafter Code hingegen kann Datenbanken verändern, Zahlungen auslösen, Preise falsch berechnen oder Bestände falsch reduzieren, bevor überhaupt jemand den Fehler bemerkt. In einem produktiven Magento-Shop bedeutet eine halluzinierte, aber zufällig lauffähige Preisberechnung nicht nur einen Bug, sondern einen direkten finanziellen Schaden, der sich erst im nächsten Reporting zeigt.

4. Zwei Fehlerklassen: laut scheitern vs. still falsch verhalten

Halluzinationen im Code lassen sich in zwei Kategorien einteilen, die sich in ihrer Gefährlichkeit stark unterscheiden. Die erste Kategorie ist der laute Fehler: Eine aufgerufene Methode existiert nicht, PHP wirft einen Error: Call to undefined method, der Build schlägt fehl, der Test läuft rot. Das ist ärgerlich, aber ungefährlich, weil der Fehler sofort sichtbar ist und niemand versehentlich fehlerhaften Code deployt, ohne es zu bemerken.

Die zweite Kategorie ist deutlich gefährlicher: das stille Fehlverhalten. Hier ruft der Code eine real existierende Methode korrekt auf, verwendet aber eine falsche Annahme über deren Verhalten, etwa einen falschen Standardwert, eine falsche Rundungsregel oder eine falsche Sortierreihenfolge. Der Code läuft fehlerfrei durch, produziert aber ein leicht falsches Ergebnis, das weder ein Test noch ein Reviewer bemerkt, wenn er nur oberflächlich prüft. Diese Fälle sind besonders tückisch, weil sie sich über Wochen unbemerkt in Datenbeständen anreichern können, etwa durch eine subtil falsche Steuerberechnung, die erst bei einer Betriebsprüfung auffällt.

#!/usr/bin/env bash
# Quick verification before trusting an AI-suggested method call
set -euo pipefail

CLASS_FILE="vendor/magento/module-catalog/Model/Product.php"
METHOD_NAME="getStockQty"

# Check if the suggested method actually exists in the vendor source
if grep -q "function ${METHOD_NAME}" "$CLASS_FILE"; then
  echo "[OK] Method exists in $CLASS_FILE"
else
  echo "[WARN] Method ${METHOD_NAME} not found, likely hallucinated"
  echo "Available getters on this class:"
  grep -o "function get[A-Za-z]*" "$CLASS_FILE" | sort -u
fi

5. Halluzinierte Pakete und das Slopsquatting-Risiko

Sprachmodelle erfinden gelegentlich Composer- oder NPM-Paketnamen, die zu einer erkennbaren Namenskonvention passen, aber nie veröffentlicht wurden. Das wird dann gefährlich, wenn ein Entwickler den vorgeschlagenen Paketnamen ungeprüft in die composer.json übernimmt und composer require ausführt. Sicherheitsforscher bezeichnen die daraus entstehende Angriffsfläche als Slopsquatting: Angreifer beobachten, welche erfundenen Paketnamen KI-Modelle wiederholt vorschlagen, und registrieren genau diese Namen vorab mit bösartigem Code, in der Erwartung, dass irgendwann ein Entwickler das Paket blind installiert.

Das Risiko betrifft nicht nur exotische Nischenpakete, sondern auch scheinbar seriöse Namen im Stil bekannter Vendoren, etwa ein angeblich offizielles Hilfspaket eines bekannten Magento-Anbieters. Die einzig zuverlässige Gegenmaßnahme ist, jedes neu vorgeschlagene Paket vor der Installation aktiv auf Packagist oder GitHub zu verifizieren: Existiert der Vendor-Namespace wirklich, hat das Paket eine nachvollziehbare Versionshistorie, und stimmt die Downloadzahl mit der angeblichen Bekanntheit überein.

{
  "require": {
    "php": "^8.4",
    "magento/framework": "^103.0",
    "mironsoft/magento2-webp-converter": "^2.1"
  }
}

Im Beispiel oben wurde mironsoft/magento2-webp-converter von einem KI-Assistenten als Lösung für eine Bildkonvertierung vorgeschlagen. Der Paketname folgt einer plausiblen Namenskonvention, existiert zum Zeitpunkt der Recherche für diesen Artikel aber nicht auf Packagist. Ein blindes composer require würde entweder sofort fehlschlagen, weil das Paket nicht gefunden wird, oder, falls ein Angreifer den Namen inzwischen registriert hat, Schadcode in das Projekt einschleusen.

6. Halluzinierte Erklärungen: wenn die Begründung falsch ist

Neben erfundenem Code gibt es eine subtilere Form der Halluzination: die falsche Erklärung zu korrektem oder scheinbar korrektem Code. Claude kann einen tatsächlich funktionierenden Codeausschnitt liefern und dabei eine überzeugend klingende, aber sachlich falsche Begründung dafür geben, warum er funktioniert. Ein Beispiel: eine falsche Aussage über die Reihenfolge, in der Magento-Observer bei einem bestimmten Event ausgeführt werden, oder eine falsche Behauptung über das Cache-Verhalten einer bestimmten Blockklasse.

Diese Form ist deshalb besonders riskant, weil sie sich nicht im Code selbst zeigt, sondern im mentalen Modell, das ein Entwickler daraus übernimmt. Wer eine falsche Erklärung glaubt, baut künftige Entscheidungen auf einer falschen Prämisse auf, auch wenn der ursprüngliche Code zufällig funktioniert hat. Besonders anfällig sind Fragen zu Rand- und Ausnahmefällen, etwa Nebenwirkungen von PHP-Typumwandlungen, Reihenfolgegarantien bei asynchronen Prozessen oder das genaue Verhalten von Magentos Indexer bei bestimmten Statuswechseln. Bei solchen Themen lohnt es sich immer, die Erklärung gegen die offizielle Dokumentation oder den tatsächlichen Quellcode gegenzuprüfen, statt sie als gegeben hinzunehmen.

7. Praktische Verifikationsgewohnheiten

Die wirksamste Gegenmaßnahme gegen Halluzinationen ist keine einzelne Technik, sondern eine feste Gewohnheit: Jeder unbekannte Methoden-, Klassen- oder Paketname wird vor dem Ausführen kurz verifiziert, bevor er in den Code übernommen wird. In der Praxis bedeutet das, die IDE-Autovervollständigung als schnellen Realitätscheck zu nutzen. Schlägt die IDE die vorgeschlagene Methode nicht vor, ist das ein starkes Warnsignal, das man nicht ignorieren sollte, nur weil der generierte Code plausibel aussieht.

Eine weitere Gewohnheit betrifft den Umgang mit unbekannten Bibliotheken: Bevor eine von Claude vorgeschlagene Methode einer Drittanbieter-Bibliothek verwendet wird, lohnt sich ein kurzer Blick in die tatsächliche Vendor-Quelle unter vendor/ oder in die offizielle Dokumentation. Das dauert selten länger als eine Minute, verhindert aber zuverlässig, dass eine erfundene Methode unbemerkt in einen Commit gelangt. Grundsätzlich gilt: Je unbekannter das Framework oder je seltener die verwendete API, desto höher die Wahrscheinlichkeit einer Halluzination, weil das Trainingsmaterial für Nischen-APIs dünner ist als für weit verbreitete Standardbibliotheken.

8. Werkzeuge und Automatisierung als Sicherheitsnetz

Manuelle Wachsamkeit allein reicht in größeren Projekten nicht aus, deshalb sollte automatisierte Verifikation Teil des Standardworkflows sein. Statische Analyse mit PHPStan auf Level 5 oder höher findet einen erheblichen Teil der lauten Halluzinationen automatisch, weil aufgerufene Methoden gegen die tatsächlichen Klassendefinitionen geprüft werden, ohne dass der Code je ausgeführt werden muss. Für Paket-Halluzinationen empfiehlt sich ein kleines Verifikationsskript, das jeden neuen Paketnamen gegen die Packagist-API prüft, bevor er tatsächlich installiert wird.

Eine vollständige CI-Pipeline aus composer validate, statischer Analyse und automatisierten Tests fängt die meisten lauten Halluzinationen zuverlässig ab, bevor sie überhaupt einen Reviewer erreichen. Stille Fehlverhalten lassen sich dagegen nur durch gezielte Tests für neue Geschäftslogik aufdecken, insbesondere für Randfälle wie Rundungsdifferenzen, Zeitzonen oder Nullwerte. Wichtig ist, dieses Sicherheitsnetz nicht als Ersatz für Verständnis zu betrachten, sondern als zusätzliche Absicherung gegen Fehler, die auch einem aufmerksamen Reviewer entgehen können.

#!/usr/bin/env python3
# Verify a Composer package actually exists on Packagist
# before adding it to composer.json based on an AI suggestion
import sys
import urllib.request
import urllib.error

def package_exists(vendor_name: str) -> bool:
    url = f"https://packagist.org/packages/{vendor_name}.json"
    try:
        with urllib.request.urlopen(url, timeout=5) as response:
            return response.status == 200
    except urllib.error.HTTPError as error:
        if error.code == 404:
            return False
        raise

if __name__ == "__main__":
    package = sys.argv[1]
    if package_exists(package):
        print(f"[OK] {package} exists on Packagist")
    else:
        print(f"[FAIL] {package} not found, possible hallucination")
        sys.exit(1)

#!/usr/bin/env bash
# CI safety net that catches many hallucinated method calls and imports
set -euo pipefail

echo "Validating composer.json and lock file consistency"
bin/composer validate --strict

echo "Running static analysis to catch undefined methods and classes"
bin/analyse app/code/Mironsoft/SeoSuite --level=5

echo "Running unit and integration tests"
bin/magento dev:tests:run unit

echo "All automated checks passed, no obvious hallucinated references found"

9. Verifikationsstrategien im Vergleich

Nicht jede Situation erfordert denselben Verifikationsaufwand, aber ein paar wiederkehrende Muster verdienen besondere Aufmerksamkeit. Die folgende Übersicht zeigt, welches Verhalten riskant ist und welches empfohlene Vorgehen das jeweilige Risiko gezielt reduziert.

Auffällig ist, dass keines der empfohlenen Verhaltensweisen einen grundsätzlichen Vertrauensverlust in KI-Assistenten voraussetzt. Es geht nicht darum, jeden Vorschlag zu misstrauen, sondern darum, die Verifikation genau dort zu konzentrieren, wo die Kosten eines unentdeckten Fehlers am höchsten sind: bei neuen Abhängigkeiten, bei Geschäftslogik mit finanzieller Wirkung und bei Aussagen über Verhalten, das sich nicht sofort durch einen Fehler zeigt.

10. Zusammenfassung

KI-Halluzinationen im Code entstehen, weil Sprachmodelle das statistisch Wahrscheinlichste vorschlagen, nicht zwingend das tatsächlich Existierende. Das zeigt sich als erfundene Methode, erfundenes Composer-Paket oder als überzeugend falsche Erklärung zu tatsächlich funktionierendem Code. Anders als in Fließtext haben Halluzinationen im Code zwei sehr unterschiedliche Ausprägungen: laute Fehler, die sofort beim Ausführen auffallen, und stille Fehlverhalten, die unbemerkt falsche Ergebnisse produzieren und sich über Wochen in Datenbeständen anreichern können.

Die wirksamste Verteidigung ist eine Kombination aus Gewohnheit und Automatisierung: unbekannte APIs vor der Nutzung verifizieren, neue Pakete gegen Packagist prüfen, um Slopsquatting-Risiken zu vermeiden, Erklärungen zu Framework-Verhalten gegen die offizielle Dokumentation gegenchecken, und statische Analyse sowie Tests konsequent als automatisches Sicherheitsnetz einsetzen. Keine dieser Maßnahmen erfordert grundsätzliches Misstrauen gegenüber KI-Assistenten, sondern lediglich, die Verifikation dort zu konzentrieren, wo unentdeckte Fehler den größten Schaden anrichten können.

11. FAQ: KI-Halluzinationen im Code erkennen