Wann man KI-Code-Vorschlägen nicht vertrauen sollte

1. Warum KI-Code-Vorschläge grundsätzlich Skepsis verdienen

Claude und vergleichbare Assistenten erzeugen Code, indem sie statistisch plausible Fortsetzungen aus riesigen Mengen an Trainingsdaten generieren, nicht indem sie Korrektheit formal beweisen. Das Ergebnis liest sich oft wie Code von einem erfahrenen Entwickler: sauber formatiert, mit passenden Variablennamen, mit Kommentaren, die logisch klingen. Genau diese Überzeugungskraft ist das Problem. Review-Gewohnheiten, die auf menschlich geschriebenen Code kalibriert sind, suchen nach Tippfehlern, inkonsistentem Stil und offensichtlichen Auslassungen. KI-generierter Code zeigt diese Signale seltener, kann aber trotzdem an entscheidender Stelle falsch sein, etwa bei einer vertauschten Bedingung oder einer fehlenden Randbedingung.

Ein brauchbarer Rahmen zur Einschätzung ist die Kombination aus Tragweite, Umkehrbarkeit und Erkennbarkeit eines Fehlers. Eine falsche CSS-Klasse ist billig zu entdecken und zu korrigieren. Ein falsches SQL-Statement, das auf Produktivdaten läuft, kann nicht rückgängig zu machende Schäden verursachen, bevor überhaupt jemand den Fehler bemerkt. Dieser Artikel ist kein Plädoyer gegen den Einsatz von KI-Assistenten, sondern für eine Prüftiefe, die sich am tatsächlichen Risiko orientiert statt an der Bequemlichkeit, generierten Code einfach zu übernehmen.

2. Sicherheitskritischer Code: Authentifizierung, Verschlüsselung, Zugriffskontrolle

Bei Authentifizierung, Verschlüsselung und Zugriffskontrolle wiegen selbst kleine Logikfehler schwer, weil sie oft erst durch gezielten Missbrauch sichtbar werden, nicht durch normale Nutzung. KI-Assistenten schlagen gelegentlich veraltete kryptografische Verfahren vor, etwa ungesalzene Hashes für Passwörter, oder implementieren Berechtigungsprüfungen mit einer vertauschten Bedingung, die im Testfall zufällig funktioniert, aber eine Rolle zu viel durchlässt. Solche Fehler bestehen Unit-Tests häufig trotzdem, weil die Tests denselben blinden Fleck haben wie der generierte Code.

Deshalb gilt für Auth- und Crypto-Code eine härtere Regel als für den Rest der Codebasis: Ein bestandener Test beweist nicht Sicherheit, sondern nur, dass der getestete Pfad funktioniert. Statische Sicherheitsanalyse mit Werkzeugen wie Semgrep, ergänzt um PHPStan-Regeln auf hohem Level, deckt viele bekannte Muster automatisiert auf. Wichtiger ist ein zweiter Blick durch jemanden mit Sicherheitserfahrung, unabhängig davon, ob der Code von einem Menschen oder von Claude stammt. Diese Prüfung sollte fester Bestandteil des Merge-Prozesses sein, nicht optionale Kür.

#!/usr/bin/env bash
# Run before merging any AI-suggested auth/crypto code, never skip this step
set -euo pipefail

# Static security analysis with Semgrep security rulesets
semgrep --config p/security-audit --config p/php src/app/code/Mironsoft/Auth

# Scan for accidentally hardcoded secrets or weak hashing calls
gitleaks detect --source . --no-git -v
grep -rn "md5(\|sha1(\|ECB" src/app/code/ --include="*.php" || true

# "It passed the tests" is not sufficient evidence for auth-critical code
bin/analyse app/code/Mironsoft/Auth --level=8

3. Zahlungsverkehr und Payment-Integrationen: null Toleranz für Vermutungen

Payment-Code hat zwei Eigenschaften, die ihn besonders unversöhnlich gegenüber Fehlern machen: Er bewegt echtes Geld, und viele Fehlerpfade sind ohne Domänenwissen unsichtbar. Ein KI-Assistent generiert für einen Stripe- oder PayPal-Webhook-Handler häufig einen technisch funktionierenden Happy Path, der die eingehenden Daten aber ungeprüft übernimmt. Fehlt die Signaturprüfung des Webhooks, kann jeder mit der URL beliebige Zahlungsereignisse fälschen. Fehlt ein Idempotenz-Schlüssel, führt ein wiederholter Webhook-Aufruf zu doppelter Gutschrift oder doppeltem Versand.

Solche Lücken fallen in oberflächlichen Tests nicht auf, weil der Testfall selten einen manipulierten oder wiederholten Request simuliert. Zusätzlich verschärfen Rundungsfehler bei Währungsumrechnung und Race Conditions zwischen Lagerbestandsreservierung und Zahlungsbestätigung das Risiko. Jeder KI-generierte Payment-Code gehört gegen die offizielle Sandbox-Umgebung und die aktuelle API-Dokumentation des Zahlungsanbieters getestet, nicht nur gegen selbst geschriebene Mock-Daten, denn Trainingsdaten veralten und API-Details ändern sich schneller, als ein Modell sie nachlernt.

// WRONG: AI-suggested webhook handler trusts the payload without verification
app.post('/webhook/stripe', express.json(), (req, res) => {
  const event = req.body;
  if (event.type === 'payment_intent.succeeded') {
    markOrderAsPaid(event.data.object.metadata.orderId);
  }
  res.sendStatus(200);
});

// RIGHT: verify the signature before trusting any payload data
app.post('/webhook/stripe', express.raw({ type: 'application/json' }), (req, res) => {
  let event;
  try {
    event = stripe.webhooks.constructEvent(
      req.body,
      req.headers['stripe-signature'],
      process.env.STRIPE_WEBHOOK_SECRET
    );
  } catch (err) {
    // Reject anything that cannot be proven to come from Stripe
    return res.status(400).send(`Webhook signature verification failed: ${err.message}`);
  }

  if (event.type === 'payment_intent.succeeded') {
    // Idempotency check prevents double-fulfillment on retried webhooks
    markOrderAsPaidIdempotent(event.id, event.data.object.metadata.orderId);
  }
  res.sendStatus(200);
});

4. Datenmigrationen und Schema-Änderungen: der Punkt ohne Rückweg

Datenmigrationen unterscheiden sich von den meisten anderen Codeänderungen dadurch, dass ein Fehler nicht einfach durch ein neues Deployment korrigiert werden kann. Ist eine UPDATE-Anweisung ohne ausreichende WHERE-Bedingung einmal auf der Produktivdatenbank gelaufen, sind die ursprünglichen Werte verloren, sofern kein aktuelles Backup existiert. KI-generierte Migrationsskripte sehen syntaktisch oft vollständig aus, lassen aber typischerweise Transaktionsgrenzen, Batch-Verarbeitung für große Tabellen und einen Dry-Run-Modus weg, weil diese Aspekte im Trainingsmaterial seltener demonstriert werden als die reine Update-Logik.

Bei einer großen InnoDB-Tabelle mit Millionen Zeilen kann ein einzelnes, nicht gebatchtes UPDATE zusätzlich die Tabelle für die Dauer der Ausführung sperren und den laufenden Shop-Betrieb beeinträchtigen. Jede KI-vorgeschlagene Migration sollte deshalb zunächst gegen eine vollständige, produktionsnahe Kopie der Datenbank getestet werden, nicht gegen eine Handvoll Fixture-Zeilen. Ein Dry-Run, der nur zählt und protokolliert, was passieren würde, gehört vor jeden schreibenden Lauf.

# WRONG: AI-suggested one-shot update, no batching, no dry-run, no transaction
def migrate_customer_addresses(connection):
    cursor = connection.cursor()
    cursor.execute("UPDATE customer_address SET country_id = 'DE' WHERE country_id = ''")
    connection.commit()

# RIGHT: batched, reversible, verifiable before it touches production
def migrate_customer_addresses(connection, dry_run=True, batch_size=500):
    cursor = connection.cursor()
    cursor.execute(
        "SELECT entity_id FROM customer_address WHERE country_id = '' LIMIT %s",
        (batch_size,)
    )
    rows = cursor.fetchall()
    print(f"Would update {len(rows)} rows in this batch (dry_run={dry_run})")

    if dry_run:
        return len(rows)

    connection.autocommit = False
    try:
        ids = [row[0] for row in rows]
        cursor.executemany(
            "UPDATE customer_address SET country_id = 'DE' WHERE entity_id = %s",
            [(i,) for i in ids]
        )
        connection.commit()
    except Exception:
        connection.rollback()
        raise
    return len(rows)

5. Code mit Zugriff auf Produktivdaten: warum Staging nicht reicht

Nicht nur Migrationen sind riskant, sondern jedes Skript, jeder Cronjob und jeder einmalige Cleanup-Befehl, der mit Schreibrechten auf der Produktivdatenbank oder auf Kundendateien läuft. Die entscheidende Frage vor jeder Ausführung lautet nicht, ob der Code korrekt aussieht, sondern was im schlimmsten Fall passiert, wenn er es nicht ist. Ein KI-generiertes Aufräumskript, das verwaiste Datensätze löschen soll, kann bei einer falsch verstandenen Beziehung zwischen Tabellen auch aktive Kundendaten erfassen. Staging-Umgebungen bilden dieses Risiko selten realistisch ab, weil sie meist kleinere Datenmengen, andere Randfälle und seltener echte historische Altlasten enthalten als die Produktion.

Praktikabel ist ein dreistufiges Vorgehen: Zunächst ein reiner Lesezugriff, der genau protokolliert, welche Datensätze betroffen wären. Danach eine explizite Bestätigung durch einen Menschen, die die tatsächliche Trefferzahl gegen die Erwartung abgleicht. Erst danach der schreibende Lauf, idealerweise mit einem Datenbank-Account, der nur die minimal notwendigen Rechte besitzt. Dieses Prinzip der geringsten Berechtigung begrenzt den Schaden, falls die vorherigen Prüfungen trotzdem etwas übersehen haben.

6. Selbstbewusst klingende Erklärungen als Warnsignal

Ein wenig intuitives, aber wichtiges Muster: Die sprachliche Sicherheit einer KI-Erklärung sagt nichts über die tatsächliche Korrektheit des Codes aus. Ein Sprachmodell formuliert Sätze wie „diese Implementierung ist jetzt vollständig thread-sicher und behandelt alle Randfälle“ mit derselben flüssigen Selbstverständlichkeit, egal ob die Aussage stimmt oder nicht. Menschliche Experten drücken Unsicherheit typischerweise sprachlich aus, etwa mit „das müssten wir noch testen“ oder „ich bin mir bei diesem Teil nicht ganz sicher“. Bei einem Sprachmodell fehlt dieses kalibrierte Zögern häufig, weil der Trainingsprozess flüssige, abgeschlossen wirkende Antworten begünstigt, nicht notwendigerweise korrekte.

Die praktische Konsequenz: Eine Formulierung, die absolute Vollständigkeit oder Fehlerfreiheit behauptet, sollte eher zu genauerem Hinsehen führen als zu Entspannung. Es hilft, den Assistenten gezielt nach den Annahmen zu fragen, die er getroffen hat, und nach den Randfällen, die er bewusst nicht behandelt hat. Diese Rückfrage deckt oft Lücken auf, die in der ursprünglichen, glatt klingenden Erklärung verborgen blieben, weil das Modell nicht von sich aus auf Unvollständigkeit hinweist, wenn nicht explizit danach gefragt wird.

7. Halluzinierte APIs, Pakete und Versionen erkennen

Sprachmodelle erfinden gelegentlich Methodennamen, Klassen oder ganze Pakete, die plausibel klingen, aber nicht existieren, ein Phänomen, das mittlerweile als Package-Halluzination oder Slopsquatting bekannt ist. Im Magento-Kontext äußert sich das etwa als Aufruf einer Interface-Methode, die es in der tatsächlich installierten Version nicht gibt, oder als Vorschlag, ein Composer-Paket zu installieren, dessen Name zwar sinnvoll klingt, aber auf Packagist nicht registriert ist. Genau diese Lücke nutzen Angreifer aus, indem sie häufig halluzinierte Paketnamen vorab selbst registrieren und mit Schadcode füllen.

Ein weiteres, subtileres Problem ist der Versionsdrift: Trainingsdaten haben einen Stichtag, und zwischen diesem Stichtag und dem tatsächlichen Einsatz können API-Methoden entfernt, umbenannt oder in ihrem Verhalten geändert worden sein. Jede von der KI referenzierte Klasse oder Methode gehört deshalb gegen den tatsächlich installierten Code im vendor-Verzeichnis oder gegen die aktuelle offizielle Dokumentation geprüft, bevor sie verwendet wird, insbesondere bei sich schnell weiterentwickelnden Frameworks.

{
  "require": {
    "php": "^8.4",
    "magento/framework": "^103.0",
    "mironsoft/core": "^2.0",
    "magento/module-secure-payment-validator": "^1.0"
  },
  "_note_unverified_dependency": "magento/module-secure-payment-validator was suggested by an AI assistant and does not exist on Packagist as of this writing. Verify every unfamiliar package name against the official registry before running composer require."
}

8. Wann man komplett auf manuelle Implementierung zurückfallen sollte

Es gibt einen Punkt, an dem die sinnvolle Reaktion nicht mehr „genauer prüfen“, sondern „selbst schreiben“ lautet. Das ist der Fall, wenn eine Operation irreversibel ist und kein getesteter Rollback existiert, wenn die Geschäftslogik tiefes Fach- oder Rechtswissen voraussetzt, etwa bei steuerlicher Berechnung oder einer DSGVO-konformen Datenlöschung, oder wenn Geld, personenbezogene Daten und Produktivzugriff gleichzeitig betroffen sind. In solchen Fällen kann die Zeit, die eine gründliche Verifikation des KI-Vorschlags kostet, die Zeit für eine manuelle Implementierung übersteigen, wodurch der vermeintliche Geschwindigkeitsvorteil verschwindet.

Ein einfacher Test hilft bei der Entscheidung: Kann man die Korrektheit des Codes einem Kollegen in eigenen Worten erklären, ohne auf die Erklärung der KI zurückzugreifen? Gelingt das nicht, fehlt das nötige Verständnis, um Verantwortung für den Code zu übernehmen, unabhängig davon, wer ihn geschrieben hat. Widerspricht sich der Assistent zudem innerhalb derselben Konversation selbst, etwa weil eine spätere Erklärung eine frühere Zusicherung stillschweigend revidiert, ist das ein zusätzliches Signal, die komplette Vorgehensweise noch einmal von Grund auf selbst durchzudenken.

#!/usr/bin/env bash
# Manual verification checklist before running any AI-suggested migration on production
set -euo pipefail

# 1. Take a verified, restorable backup first, always
bin/mysqldump --single-transaction magento > "backup-$(date +%Y%m%d-%H%M%S).sql"

# 2. Run the migration in dry-run mode against a full-size copy, not a fixture
bin/magento migration:run --dry-run --env=staging-full-copy

# 3. Check the actual row count and EXPLAIN plan, not just "no errors"
bin/mysql magento -e "EXPLAIN UPDATE customer_address SET country_id='DE' WHERE country_id='';"

# 4. Roll out in small batches with a kill switch, not one giant statement
bin/magento migration:run --batch-size=500 --max-batches=1 --env=production
echo "Verify results manually before running the next batch"

9. Risikokategorien im direkten Vergleich

Nicht jede Codeänderung verdient dieselbe Prüftiefe. Die folgende Übersicht ordnet typische Aufgabenbereiche danach ein, wie viel Vertrauen ein KI-Vorschlag dort verdient und welche Praxis das jeweilige Risiko tatsächlich absichert.

Die Tabelle zeigt, dass Vertrauen in KI-Code keine binäre Entscheidung ist, sondern sich nach Tragweite und Umkehrbarkeit der jeweiligen Aufgabe richtet. Ein Team, das diese Kategorien kennt und konsequent unterschiedlich behandelt, verliert nicht die Geschwindigkeitsvorteile von KI-Assistenten bei risikoarmen Aufgaben, vermeidet aber die teuren Fehler in den Bereichen, in denen ein einziger übersehener Randfall echten Schaden anrichtet.

10. Zusammenfassung

KI-Code-Vorschläge sind kein einheitliches Risiko, sondern verdienen unterschiedlich viel Vertrauen je nach Tragweite, Umkehrbarkeit und Erkennbarkeit möglicher Fehler. Bei Authentifizierung, Verschlüsselung und Zugriffskontrolle bestehen Logikfehler oft trotz grüner Tests, weshalb dedizierte Sicherheitsanalyse Pflicht bleibt. Zahlungsverkehr verlangt Prüfung gegen echte Sandbox-Umgebungen, weil fehlende Signaturprüfungen oder Idempotenz-Lücken im Alltagstest unsichtbar bleiben. Datenmigrationen und jeder Code mit Zugriff auf Produktivdaten brauchen Dry-Run, Backup und Batch-Verarbeitung, weil Fehler dort selten rückgängig zu machen sind.

Zwei Muster verdienen besondere Aufmerksamkeit: Eine selbstbewusst klingende KI-Erklärung ist kein Beweis für Korrektheit, sondern häufig nur ein Zeichen sprachlicher Flüssigkeit, unabhängig vom tatsächlichen Inhalt. Und halluzinierte Methoden, Klassen oder Pakete lassen sich nur durch Abgleich mit dem tatsächlich installierten Code und der aktuellen offiziellen Dokumentation zuverlässig erkennen. Wo die Verifikation eines Vorschlags länger dauert als eine eigene Implementierung, oder wo Geld, personenbezogene Daten und Produktivzugriff zusammentreffen, ist manuelle Umsetzung durch einen Menschen weiterhin die verlässlichere Wahl.

11. FAQ: Wann man KI-Code-Vorschlägen nicht vertrauen sollte