KI-generierten Code prüfen: 7 Checks für Nicht-Programmierer

Die KI hat an einem Abend eine Website oder einen Bot für dich zusammengestellt. Alles lässt sich öffnen, die Schaltflächen funktionieren, und es scheint zu laufen. Du zeigst das Projekt anderen – und einen Tag später erfährst du, dass das Zahlungsformular Geld abbucht, aber keine Bestellungen eingehen. Oder dass die Datenbank mit den Telefonnummern deiner Kunden im gesamten Internet offen zugänglich ist.

Früher habe ich meine ersten Projekte auch so ausgeliefert: Dinge, die scheinbar funktionierten, sorgten bei echten Nutzern für Überraschungen. Heute prüfe ich jedes Projekt anhand derselben Checkliste, bevor ich es anderen zeige. Dabei lese ich keine einzige Codezeile – dafür bin ich nicht hier, und du wahrscheinlich auch nicht.

Und das ist keine Paranoia. Anthropic hat 400.000 Claude-Code-Sitzungen analysiert: Über sieben Monate sank der Anteil der Arbeit, der für die Reparatur fehlerhaften Codes aufgewendet wurde, von 33 % auf 19 %. Er sank, verschwand aber nicht. Jede fünfte Sitzung dreht sich noch immer darum, „zu reparieren, was die KI kaputt gemacht hat“.

Das Schreiben von Code selbst ist nicht mehr der Engpass. Entscheidend ist jetzt, wie gut du die Aufgabe verstehst und wie gut du das Ergebnis prüfen kannst.

Weitere Materialien zur Einrichtung von Tools findest du in der Ailoot-Dokumentation.

Warum sollte man KI-generierten Code prüfen, wenn er bereits funktioniert?#

Die KI schreibt Code, der auf den ersten Blick besteht. Er läuft, der Bildschirm wird angezeigt, und die Demo wirkt überzeugend. Doch der Start sagt dir nichts darüber, ob Geld korrekt berechnet wird, ob deine Datenbank von außen zugänglich ist oder ob alles abstürzt, sobald der hundertste Nutzer kommt.

Die Zahlen bestätigen das. Der Benchmark FrontierCode hat im Juni 2026 geprüft, wie einsatzbereit KI-generierter Code ohne Änderungen für echte Arbeit war. Selbst bei den besten Modellen und den schwierigsten Aufgaben lag der Anteil bei etwa 13 %. Anders gesagt: Bei anspruchsvollen Aufgaben muss der meiste KI-generierte Code von Hand überarbeitet werden, bevor du dich darauf verlassen kannst.

Die gute Nachricht: Jeder kann diese Prüfung vornehmen. Das hat Anthropic aus denselben 400.000 Sitzungen geschlossen:

Dein Vorteil gegenüber jedem Programmierer, den du hinzuziehst, ist, dass du deine Aufgabe verstehst. Auch beim Prüfen geht es ums Verstehen; du musst keinen Code lesen können. Die folgenden Prüfungen kannst du selbst erledigen, ganz unkompliziert.

Was kann bei KI-generiertem Code tatsächlich schiefgehen?#

Bevor du mit der Prüfung beginnst, hilft es zu wissen, wonach du suchst. KI-generierter Code hat fünf typische Probleme. Du kannst alle fünf erkennen, ohne Code zu lesen – indem du beobachtest, wie sich das Projekt verhält.

Es folgen sieben Prüfungen in der richtigen Reihenfolge. Die ersten decken „funktioniert nicht“ und „funktioniert falsch“ ab; die mittleren behandeln Sicherheit und Erfindungen; die letzten dienen als Schutzmaßnahmen vor der Veröffentlichung. Am besten gehst du sie der Reihe nach durch: Jede baut darauf auf, dass die vorherige Prüfung abgeschlossen ist.

Prüfung 1: Bitte die KI, ihren Code in einfachen Worten zu erklären#

Du hast die Aufgabe in Worten beschrieben. Die KI hat sie in Code übertragen. Zwischen diesen beiden Schritten kann Bedeutung verloren gehen: Die KI hat dich vielleicht anders verstanden, in deinem Namen etwas ergänzt oder Abkürzungen genommen. Du kannst die Abweichung erkennen, ohne Code zu lesen – bitte sie einfach, in einfacher Sprache zu beschreiben, was sie getan hat.

Erkläre in einfacher Sprache und ohne Code genau, was du gerade getan hast:

welche Aufgabe dieser Code löst

was passiert, wenn ein Nutzer auf die Schaltfläche klickt oder das Formular absendet

wo die Daten gespeichert werden und wer Zugriff darauf hat

was in welcher Situation schiefgehen könnte

Schreibe so, als würdest du es jemandem erklären, der noch nie programmiert hat. Wenn du dir bei etwas nicht sicher bist, ob es stimmt, sage es offen.

Lies die Antwort und vergleiche sie mit dem, was du im Sinn hattest. Wenn sie passt, mach weiter. Wenn die KI „herumdruckst“, sich in ihrer eigenen Erklärung verwirrt oder etwas anderes beschreibt, als du verlangt hast, bedeutet das, dass sie nicht vollständig versteht, was sie gebaut hat. Bitte sie mit einer Klarstellung um eine Überarbeitung, statt ihr einfach zu glauben.

Übrigens: Wenn die KI regelmäßig etwas anderes tut, als du verlangt hast, liegt das Problem oft daran, wie die Aufgabe formuliert wurde, und nicht am Modell selbst. Ich habe eine separate Erklärung dazu, warum Claude nicht tut, worum du es gebeten hast.

Die Prüfung der KI-Ausgabe gehört zum Context Engineering: Du steuerst sowohl, was du der KI als Eingabe gibst, als auch, wie du das Ergebnis als Ausgabe bewertest. Zum Werkzeugkasten gehören ein KI-Klon, ein Second Brain und Context Engineering. Danach ist Claude kein „halluzinierender Assistent“ mehr, sondern ein Werkzeug, dem du ein Projekt tatsächlich anvertrauen kannst.

Prüfung 2: Gehe die Szenarien so durch wie ein echter Nutzer#

Eine KI-Demo folgt immer dem Idealfall: korrekte Daten, ein Klick, alles klappt. Echte Nutzer verhalten sich nicht so. Sie machen Fehler, klicken auf das Falsche oder geben ein Emoji in das Telefonnummernfeld ein. Deine Aufgabe ist, das Projekt so zu durchlaufen wie sie.

1. Führe das Hauptszenario von Anfang bis Ende durch

   Tu, wofür das Projekt gedacht ist: Registriere dich, gib eine Bestellung auf oder sende eine Anfrage. Gehe bis zum Ende, nicht nur bis zur Hälfte.

2. Prüfe die Zahlung separat und wirklich

   Wenn das Projekt Geld annimmt, leiste selbst eine Zahlung über den Mindestbetrag im Testmodus. Vergewissere dich, dass die Bestellung erstellt wird, sich der Status ändert und eine E-Mail an dich und den Kunden geht. Eine Zahlung, die „durchgeht“, aber keine Bestellung erstellt, ist ein klassischer unbemerkter Fehler.

3. Bringe absichtlich Dinge durcheinander

   Lasse Felder leer. Gib Buchstaben ein, wo Zahlen erwartet werden. Klicke zweimal hintereinander auf „Absenden“. Lade eine Datei im falschen Format hoch. Ein gutes Projekt sagt höflich: „Das geht nicht“; ein schlechtes stürzt ab oder verschluckt die Daten unbemerkt.

4. Öffne es auf einem Smartphone

   Die Hälfte deiner Nutzer kommt über ein Smartphone. Prüfe, ob das Layout noch intakt ist und die gleichen Schaltflächen dort funktionieren.

Gib der KI alles, was du gefunden hast, in einer Liste: „Das ist bei diesen Schritten schiefgegangen; behebe es und erkläre, warum es passiert ist.“ Bearbeite die Probleme nicht einzeln – gib ihr die gesamte Liste, damit sie das Gesamtbild sieht und beim Beheben nicht so leicht etwas anderes kaputt macht.

Prüfung 3: Bitte die KI um eine Sicherheitsprüfung – hier ist ein Prompt#

Eine kaputte Schaltfläche ist sofort offensichtlich. Eine Sicherheitslücke ist es nicht: Das Projekt läuft weiter, als wäre nichts, bis jemand sie ausnutzt. Zu den häufigsten Problemen bei Vibe-Coding-Projekten gehören geheime Schlüssel, die direkt im Code stehen, eine im Internet offengelegte Datenbank und Formulare, über die jemand bösartige Eingaben senden kann. Die KI kann all das finden, wenn du sie direkt darum bittest.

Prüfe dieses Projekt auf Sicherheitslücken und erkläre jeden Fund in einfacher Sprache, ohne Fachjargon. Gehe diese Liste durch:

Prüfe, ob geheime Schlüssel, Passwörter oder Tokens direkt im Code stehen. Private Geheimnisse dürfen nur serverseitig verwendet werden. Lokale Geheimniskonfiguration wie .env muss aus Git ausgeschlossen sein. .env und .gitignore verhindern nicht, dass Frontend-/Public-Variablen im Browserbuild landen. Prüfe tatsächlich ausgeliefertes JavaScript, Source Maps, HTML und Netzwerkantworten auf fehlende private Schlüssel.

Prüfe, ob die Datenbank im Internet erreichbar ist und wer Zugriff darauf hat.

Prüfe, ob Eingaben die Formulare beschädigen können: Einschleusungen in Datenbankabfragen oder zusätzlicher Code in Textfeldern.

Was passiert, wenn ein Nutzer bösartige Daten übermittelt?

Prüfe, ob interne Seiten oder das Admin-Panel ohne Passwort zugänglich sind.

Gib für jeden Punkt an, ob ein Problem vorliegt, nenne ein klares Beispiel für das Risiko und erkläre, wie es behoben werden kann. Beginne mit dem gefährlichsten Problem.

Prüfe außerdem, ob dein Projekt blind alles tut, was es von außen erhält. Das nennt man indirekte Prompt-Injection: Ein Befehl ist in einer E-Mail, einem Kommentar oder einer Datei von jemand anderem versteckt, und dein KI-Agent folgt ihm, weil er ihn für eine Aufgabe hält. Wenn das Projekt externe Daten liest und daraufhin handelt, frage die KI, was passieren würde, wenn diese Daten eine versteckte Anweisung enthielten.

Das ist ein umfangreiches Thema, und ein Prompt kann es nicht vollständig abdecken. Wenn das Projekt Geld oder personenbezogene Kundendaten verarbeitet, lies den separaten Leitfaden zu Vibe-Coding-Sicherheit.

Prüfung 4: Hat die KI Bibliotheken oder Daten erfunden?#

Die KI schreibt selbstbewusst Dinge, die es gar nicht gibt. Vielleicht fügt sie eine Bibliothek mit einem plausiblen Namen hinzu, die aber nicht existiert. Vielleicht lässt sie Testplatzhalter im Projekt stehen: ein Produkt namens „Example“, die E-Mail-Adresse example@example.com oder Fülltext anstelle echter Inhalte. In einer Demo übersieht man das leicht, aber für einen echten Nutzer wirkt es peinlich oder das Projekt funktioniert nicht.

Du kannst das in zwei Schritten erkennen. Frage zuerst direkt:

Gehe das Projekt durch und prüfe ehrlich:

Existieren alle hinzugefügten externen Tools und Bibliotheken wirklich und lassen sie sich korrekt installieren? Hast du etwas erfunden?

Sind noch Test-Platzhalter, Beispiele oder Fülltexte vorhanden, statt echter Daten?

Sind alle Links, Adressen und Kontaktdaten im Projekt echt und keine Platzhalter?

Liste auf, was du gefunden hast, und schlage vor, womit es ersetzt werden sollte.

Führe anschließend einfach das Projekt aus und sieh es dir an. Eine erfundene Bibliothek verursacht beim Start fast immer einen Fehler. Und Platzhalter sind leicht zu erkennen: Wenn auf der Seite „Produkt 1“ steht, hast du sie nicht ersetzt.

Erfundene Bibliotheken bergen eine besondere Gefahr, weil Angreifer absichtlich Tools mit Namen registrieren, die die KI gern erfindet. Installierst du eines davon, gelangt der Code einer anderen Person in dein Projekt. Deshalb solltest du die Frage „Gibt es diese Bibliothek überhaupt?“ ernst nehmen – sie betrifft unmittelbar die Sicherheit deines Projekts.

Prüfung 5: Lass ein zweites Modell das erste prüfen#

KI hat eine unangenehme Eigenschaft: Sie stimmt zu. Fragst du: „Ist hier alles in Ordnung?“, wird sie bestätigen, dass alles in Ordnung ist, weil sie sich an die erwartete Antwort anpasst. Das nennt man KI-Sykophanz, und ich habe separat darüber geschrieben. Ein Gesprächspartner, der sich so verhält, wird die eigene Arbeit nachsichtig beurteilen.

Die Lösung ist einfach: Hol dir eine zweite Meinung. Öffne eine neue Sitzung oder verwende ein anderes Modell und bitte es, das Projekt mit demselben Prompt aus Prüfung 3 zu prüfen. Ergänze dabei: „Eine andere KI hat diesen Code geschrieben; finde seine Schwachstellen.“ Ein frisches Modell ist nicht an das vorherige Gespräch gebunden und weist eher auf Probleme hin.

1. Öffne eine leere Sitzung oder verwende ein anderes Modell

   Verwende ein zweites Modell oder dasselbe Modell in einem neuen Fenster ohne Aufgabenverlauf.

2. Gib ihm das Projekt und den richtigen Rahmen

   Sage deutlich: „Eine andere KI hat diesen Code geschrieben; deine Aufgabe ist es, Fehler und Risiken zu finden, nicht ihn zu loben.“ Das wirkt der Sykophanz entgegen.

3. Vergleiche die beiden Einschätzungen

   Wenn beide übereinstimmen, haben sie wahrscheinlich recht. Wenn sie unterschiedlicher Meinung sind, untersuche diesen Punkt – dort wird es interessant.

Genau das passiert gerade in der Branche: KI schreibt, KI prüft, und die endgültige Entscheidung bleibt beim Menschen. Du kannst sie dem Modell nicht überlassen – das ist deine Aufgabe.

Prüfung 6: Wie kannst du Änderungen rückgängig machen, wenn etwas kaputtgeht?#

Die Prüfungen auf dieser Liste führen oft zu Änderungen, und Änderungen machen manchmal kaputt, was vorher funktioniert hat. Damit daraus kein Desaster wird, speichere die funktionierende Version in Git, bevor du eine Runde von Korrekturen startest. Das ist wie beim Speichern eines Spiels: Wenn du etwas kaputt machst, lädst du den letzten Speicherpunkt.

Du musst dafür keinen Code lesen. Bitte die KI einfach: „Speichere die aktuelle funktionierende Version in Git mit einer klaren Bezeichnung, bevor du etwas änderst.“ Und wenn nach den Änderungen alles schiefgeht: „Stelle das Projekt auf die zuvor gespeicherte Version zurück.“

Falls Git noch Neuland für dich ist, habe ich zwei Anleitungen: Änderungen in Claude Code rückgängig machen und Was tun, wenn die KI deine Datenbank gelöscht hat. Die zweite ist für den Fall, dass es schon zu spät ist, um Änderungen rückgängig zu machen, die Daten aber noch wiederhergestellt werden können.

Prüfung 7: Was solltest du vor der Veröffentlichung zuletzt prüfen?#

Bei den ersten sechs Prüfungen geht es darum, was der Code tut. Bei der siebten geht es darum, ob das Projekt bereit ist, echten Menschen zu begegnen. Hier machen die meisten einen Fehler: Das Projekt funktioniert, aber sie haben vergessen, die Zahlung vom Testschlüssel auf den Live-Schlüssel umzustellen, sodass die ersten Kunden „zum Schein“ bezahlen.

1. Zahlung: vom Test- zum Live-Modus

   Wenn du Zahlungen annimmst, vergewissere dich, dass der Live-Schlüssel des Zahlungssystems verbunden ist und nicht der Testschlüssel. Leiste eine echte Zahlung über den Mindestbetrag und erstatte sie dir selbst zurück.

2. Geheime Daten sind am richtigen Ort

   Frage die KI: „Werden private Schlüssel nur serverseitig verwendet, und ist .env aus Git ausgeschlossen? Enthält der tatsächliche Browserbuild oder eine Clientantwort private Schlüssel, auch über Frontend-/Public-Variablen oder Source Maps?“ Prüfe gebaute Dateien und Browser-Netzwerkantworten statt nur die .env-Quelldatei. Git-Ausschluss hält einen Wert nicht aus dem Frontend-Bundle heraus.

3. Sichere die Daten

   Vergewissere dich, dass die Datenbank automatisch irgendwo gesichert wird. Wenn dein Projekt auf deinem eigenen Server läuft, erkläre ich im Coolify-Leitfaden, was bei der Veröffentlichung zu tun ist.

4. Die Veröffentlichung funktioniert auch auf anderen Geräten

   Öffne das Projekt auf deinem Smartphone über einen externen Link und nicht nur auf deinem eigenen Computer. Was lokal funktioniert, funktioniert nach der Veröffentlichung nicht unbedingt auch.

Gehe alle vier Punkte durch; dann kannst du das Projekt beruhigt anderen zeigen. Wenn etwas nicht stimmt, investiere lieber jetzt eine halbe Stunde, als dich später mit unzufriedenen Kunden herumzuschlagen.

Was, wenn das Prüfen zu lange dauert – solltest du der KI einfach vertrauen?#

Ich verstehe die Versuchung. Prüfen fühlt sich langweilig an und „nicht nach dem Grund, weshalb ich mir eine KI geholt habe“. Doch du, nicht das Modell, bist für das Ergebnis verantwortlich. Die KI hat keinen Ruf zu verlieren und muss keine Folgen tragen: Sie hat den Code erstellt und ihn dann vergessen. Du wirst dem Kunden Rede und Antwort stehen müssen, dessen Zahlung nicht durchging.

Der Schöpfer von Claude Code sieht das noch umfassender:

Das Schreiben von Code ist nicht mehr der Engpass – die KI hat das übernommen. Der Wert liegt jetzt anderswo: darin, die Aufgabe zu verstehen und das Ergebnis zu prüfen. Das ist deine Stärke – du weißt besser als jeder externe Entwickler, welches Ergebnis dein Kunde bekommen sollte.

Warum ist Prüfen eine Fähigkeit und keine einmalige Aufgabe?#

Diese sieben Prüfungen sind das Minimum, das „Ich habe es veröffentlicht und hoffe“ von „Ich habe es veröffentlicht und weiß, dass es funktioniert“ unterscheidet. Gehst du sie einmal durch, erkennst du schon die meisten Überraschungen, bevor deine Kunden es tun.

Von da an wird es zur Gewohnheit. Gib der KI den richtigen Kontext als Eingabe und prüfe das Ergebnis als Ausgabe. Dann ist jedes neue Projekt schneller fertig, weil du nicht bei null anfängst.

KI-Klon, Second Brain und Context Engineering – weitere Materialien zur Arbeit mit Tools findest du in der Ailoot-Dokumentation.