So prüfst du KI-generierten Code

Um KI-generierten Code zu prüfen, beginnst du damit, was sich geändert hat, welche Dateien und warum. Dann testest du das Verhalten selbst, bevor du eine einzige Codezeile liest. Danach prüfst du die Bereiche, in denen KI-Code am häufigsten schiefgeht: fehlende serverseitige Berechtigungsprüfungen, Geheimnisse, die dem Browser ausgeliefert werden, nicht validierte Eingaben, Pakete oder Funktionen, die es nicht gibt, und Änderungen an Dingen, die du nie angefordert hast.

KI schreibt Code, der meist läuft und oft ordentlich aussieht. Das macht es leicht, ihn abzunicken, ohne wirklich hinzuschauen. Dieser Leitfaden ist eine Prüfroutine, die funktioniert, egal ob du Code flüssig liest oder gar nicht.

Den Aufwand am Risiko ausrichten

Nicht jede Änderung braucht dieselbe Aufmerksamkeit.

Schritt 1: Sieh, was sich geändert hat

Bevor du den Code beurteilst, hol dir die Liste der Änderungen:

• Liegt das Projekt in Git, schau dir den Diff an: die Dateien und Zeilen, die seit dem letzten Commit geändert wurden. Siehe wie du Git mit einer mit KI gebauten App nutzt.
• Oder frag die KI direkt:

Liste jede Datei auf, die du bei der letzten Änderung angefasst hast, und erkläre für jede in einem Satz, was sich geändert hat und warum.

Rote Flaggen in diesem Schritt: Dateien, die nichts mit der Anfrage zu tun haben, gelöschte Dateien, Änderungen an Konfiguration oder Abhängigkeiten, die du nicht verlangt hast.

Schritt 2: Zuerst das Verhalten testen

Code zu lesen verrät dir, was er tun soll. Testen verrät dir, was er tatsächlich tut. Bevor du liest:

• Probiere die Änderung als normaler Nutzer aus, am Desktop und in einer Bildschirmgröße wie am Telefon.
• Probiere sie mit falschen Eingaben aus: leere Felder, sehr langer Text, negative Zahlen, ein Datum in der Vergangenheit.
• Probiere sie ausgeloggt und als anderer Nutzer.
• Wiederhole die wichtigsten Abläufe: Anmelden, einloggen, die Hauptaktion, Zahlung.

Schlägt der Test fehl, hast du dir Lesezeit gespart. Melde es klar und lass die KI den Fehler beheben. Siehe wie du einen guten Fehlerbericht schreibst.

Schritt 3: Berechtigungen auf dem Server prüfen

Das ist der wichtigste Punkt. KI-Werkzeuge verstecken oft einen Button in der Seite, lassen den Server aber bereit, die Aktion für jeden auszuführen, der danach fragt.

Frage bei jeder Route oder Funktion, die Daten liest oder ändert:

• Prüft sie, ob der Nutzer eingeloggt ist?
• Prüft sie, ob dieser Nutzer auf genau diesen Datensatz zugreifen darf?
• Findet die Prüfung auf dem Server statt, nicht nur in der Seite?

Nenne für jede API-Route, die du hinzugefügt oder geändert hast, welche Berechtigungsprüfung sie auf dem Server macht, und zitiere die Zeile. Markiere jede Route ohne Prüfung.

Teste es dann: Melde dich als Nutzer A an, notiere die ID eines Datensatzes, melde dich als Nutzer B an und fordere ihn an. Die Sicherheitscheckliste für mit KI gebaute Apps enthält den vollständigen Test.

Schritt 4: Nach offengelegten Geheimnissen suchen

• Durchsuche die geänderten Dateien nach allem, was wie ein Schlüssel oder Passwort aussieht.
• Prüfe, dass geheime Schlüssel aus Umgebungsvariablen gelesen und nur im Servercode verwendet werden.
• Achte auf öffentliche Präfixe wie VITE_ oder NEXT_PUBLIC_ bei geheimen Variablen. Diese werden in den Browsercode eingebaut.

Siehe wie du API-Schlüssel sicher aufbewahrst.

Schritt 5: Eingaben und Fehler prüfen

• Validierung auf dem Server. Prüfungen im Browser lassen sich umgehen. Pflichtfelder, Längen, Formate und erlaubte Werte müssen auch der Server prüfen.
• Datenbankabfragen verwenden Parameter, nicht Text, der Nutzereingaben in eine Abfrage hineinklebt.
• Fehler werden nicht verschluckt. Ein try/catch, das nichts tut, verbirgt Fehler. Fehler sollten protokolliert werden, und Nutzer sollten eine verständliche Meldung sehen.
• Keine internen Details für Nutzer sichtbar: Stack-Traces und Datenbankfehler gehören in die Logs.

Schritt 6: Prüfen, ob es real ist

KI-Modelle erzeugen manchmal Code, der richtig aussieht, aber auf Dinge verweist, die es nicht gibt.

• Pakete: Jede neue Abhängigkeit sollte ein echtes, gepflegtes Paket mit genau diesem Namen sein. Sei misstrauisch bei Namen, die nach Tippfehlern bekannter Pakete aussehen.
• Funktionen und API-Optionen: Ruft der Code eine Bibliotheksfunktion oder eine Option einer externen API auf, die du noch nie gesehen hast, prüfe die offizielle Dokumentation.
• Platzhalter-Code: Suche nach TODO, mock, fake, fest eingetragenen Beispieldaten oder Funktionen, die immer einen festen Wert zurückgeben.

Hast du neue Pakete hinzugefügt? Nenne für jedes den genauen Namen, wofür es ist, und ob wir darauf verzichten könnten.

Schritt 7: Prüfen, ob es passt

Code kann funktionieren und die App trotzdem später schwerer veränderbar machen:

• Doppelte Logik. Dieselbe Logik, an mehreren Stellen kopiert, driftet auseinander.
• Konsistenz. Sie sollte den Mustern folgen, die der Rest der App nutzt.
• Umfang. Eine Anfrage mit 20 Zeilen, die 600 Zeilen erzeugt hat, verdient eine Nachfrage.
• Toter Code. Alte Versionen, die neben den neuen liegen geblieben sind.

Gibt es im Projekt Code, der durch diese Änderung jetzt ungenutzt ist, oder Logik, die anderswo dupliziert ist? Ändere nichts, liste es nur auf.

Häufige Fehler

• Abnicken, weil es sauber aussieht. Ordentlicher Code kann trotzdem eine Berechtigungsprüfung auslassen.
• Lesen statt testen. Teste zuerst, lies danach.
• Nur den Idealfall testen. Probiere falsche Eingaben, den falschen Nutzer und den Zustand ausgeloggt.
• Unzusammenhängende Dateiänderungen ignorieren. Frage nach, warum sich jede Datei geändert hat.
• Einer Selbstprüfung der KI vollständig vertrauen. Nutze den Befund der KI als ersten Durchgang und bestätige ihn durch Tests.
• Eine Woche Änderungen auf einmal prüfen. Prüfe kleine Änderungen, während sie passieren.

Checkliste

• Ich weiß, welche Dateien sich geändert haben und warum, und nichts Unzusammenhängendes wurde geändert.
• Die Änderung funktioniert am Desktop und am Telefon, mit falschen Eingaben, ausgeloggt und als anderer Nutzer.
• Jede Datenroute prüft Login und Zugehörigkeit auf dem Server.
• Keine Geheimnisse im Code oder in Browser-Bundles.
• Eingaben werden auf dem Server validiert; Abfragen verwenden Parameter.
• Fehler werden protokolliert, nicht verschluckt, und Nutzern nicht im Detail gezeigt.
• Neue Pakete sind echt und nötig; keine erfundenen Funktionen oder Platzhalter bleiben übrig.
• Riskante Änderungen wurden sorgfältig gelesen und bei Bedarf von einer zweiten Person geprüft.

Code auf Mythex prüfen

• Frage-Modus beantwortet Fragen zum Code, ohne ihn zu ändern. Ideal für Anfragen wie „erkläre jede Änderung“ oder „welche Routen haben keine Berechtigungsprüfung“. Siehe Chat.
• Code-Ansicht zeigt den Dateibaum, den Editor und das Terminal in jedem Tarif (im Free-Tarif nur lesbar, im Pro-Tarif bearbeitbar), damit du selbst liest, was sich geändert hat. Siehe Code-Editor.
• /test lässt den Agenten die Vorschau als Nutzer durchklicken und kaputte Abläufe melden.
• Checkpoints erlauben dir, eine Änderung zurückzunehmen, die die Prüfung nicht besteht.

Prüft ein Entwickler für dich, erklärt wie du mit einem Entwickler an einer mit KI gebauten App zusammenarbeitest, die Übergabe. Findet die Prüfung einen Fehler, siehe wie du eine mit KI gebaute App debuggst.

Fragen