KI-Code verstehen und prüfen: Bevor du auf „Ausführen“ klickst

Die KI liefert einen Codeblock und schreibt: „Damit ist dein Problem gelöst.“ Für Einsteiger wirkt der nächste Schritt selbstverständlich: kopieren und ausführen. Genau hier lohnt sich eine Pause mit konkreten Fragen. Was liest der Code? Was verändert er? Braucht er Netzwerkzugriff? Und wie kannst du feststellen, ob er wirklich nur die beauftragte Aufgabe erledigt?

Ein überschaubares Beispiel wählen

Wir betrachten einen lokalen Listenhelfer: Der Nutzer gibt „Wasser, Becher, Snacks“ ein und erhält drei Listeneinträge. Die Anwendung soll nur Text im Browser verarbeiten. Sie braucht keinen Server, keine Anmeldung und keinen Zugriff auf andere Dateien. Diese klare Grenze macht die Prüfung leichter. Wenn ein Vorschlag plötzlich ein Paket aus dem Internet installiert oder einen externen Dienst aufruft, ist das zunächst erklärungsbedürftig.

Du brauchst dafür nur die Quelldatei, einen Editor und einen Browser. Ein zusätzlicher kostenpflichtiger Prüfdienst ist für die ersten Verständnisfragen nicht nötig. Bei einer echten öffentlichen Anwendung können Umfang und erforderliche Fachprüfung erheblich größer sein. Das Beispiel ist eine Lernmethode, keine Zusicherung, dass beliebiger Code mit wenigen Handgriffen sicher wird.

Die Änderung lesen, nicht nur die Schlussmeldung

Lass dir von der KI zunächst alle geänderten Dateien nennen. Bei einem bestehenden Projekt ist die Differenz zur vorherigen Fassung wichtig, häufig als Diff bezeichnet. Frage: „Erkläre pro geändertem Abschnitt den Zweck und nenne neue Abhängigkeiten.“ Eine Erklärung hilft beim Verstehen, bestätigt aber nicht automatisch ihre eigene Richtigkeit. Vergleiche sie mit dem tatsächlichen Code.

Für unseren Listenhelfer sollte die Datenbewegung einfach erkennbar sein: Eingabefeld lesen, Text aufteilen, leere Einträge entfernen, Listenelemente anzeigen. Suche nach überraschenden Zusatzfunktionen. Ein Netzwerkaufruf wie fetch(...) kann sinnvoll sein, gehört hier aber nicht zur Aufgabe. Ebenso wenig braucht die Seite Zugriff auf Zwischenablage, Standort oder Kamera.

Eine Stelle im Detail verstehen

Folgender kleine Ausschnitt zeigt die beabsichtigte Verarbeitung. Er setzt voraus, dass eingabe auf ein Eingabefeld und liste auf eine vorhandene Liste verweist; er ist also kein vollständiges Programm:

const punkte = eingabe.value
  .split(',')
  .map(text => text.trim())
  .filter(text => text.length > 0);

liste.replaceChildren();
for (const text of punkte) {
  const punkt = document.createElement('li');
  punkt.textContent = text;
  liste.append(punkt);
}

split trennt am Komma, trim entfernt Leerraum am Rand, und filter entfernt leere Einträge. replaceChildren leert die vorherige Ausgabe. Für jeden verbleibenden Text entsteht ein Listenelement. textContent behandelt die Eingabe als Text statt als HTML. Das ist für diese Aufgabe passender als das direkte Zusammensetzen von Nutzereingaben zu HTML-Code.

Mit erwarteten Ergebnissen prüfen

1. Normale Eingabe: „Wasser, Becher, Snacks“ soll genau drei Einträge liefern.
2. Zusätzliche Trennzeichen: „Wasser,, Snacks,“ soll zwei Einträge liefern und keine Leerzeilen erzeugen.
3. Leeres Feld: Die alte Ausgabe soll verschwinden, ohne einen leeren Punkt anzulegen.
4. Sonderzeichen: „<b>Wasser</b>“ soll als eingegebener Text sichtbar sein, nicht als neu eingefügtes HTML.
5. Erneute Nutzung: Eine zweite Eingabe soll die vorherige Liste ersetzen statt unbemerkt alles anzuhängen.

Schreibe vor dem Ausführen auf, was du erwartest. Sonst passt man seine Erklärung leicht nachträglich an das sichtbare Ergebnis an. Die genannten Fälle sind eine Anleitung für deinen eigenen Versuch, kein hier behaupteter Testlauf eines Produkts. Wenn eine Prüfung scheitert, dokumentiere Eingabe, erwartetes und tatsächliches Ergebnis.

Rechte und Umgebung mitprüfen

Agentenwerkzeuge können Befehle ausführen und Dateien ändern, sofern ihre Konfiguration das erlaubt. Beschränke einen Lernversuch auf einen eigenen Ordner. Eine Sandbox begrenzt technisch bestimmte Zugriffe; eine Freigabeabfrage entscheidet, wann du einer Handlung zustimmen sollst. Beides ist nicht dasselbe. Die tatsächlich aktiven Einstellungen sind wichtiger als eine allgemeine Produktbeschreibung.

Bei Installationsbefehlen solltest du Paketname und offizielle Quelle kontrollieren. Füge nicht vorsorglich Administratorrechte hinzu, wenn eine Installation scheitert. Bei Lösch-, Überschreib- oder Datenbankbefehlen reicht eine Erklärung aus dem Chat nicht aus: Sichere den bisherigen Stand und prüfe den konkreten Befehl in der passenden Dokumentation. Übe mit künstlichen Dateien, nicht mit dem einzigen Exemplar wichtiger Daten.

Einen Fehlerbericht formulieren, der hilft

Beschreibe einen gefundenen Fehler mit vier Angaben: verwendete Dateifassung, Eingabe, erwartetes Ergebnis und tatsächliches Ergebnis. Für den Listenhelfer könnte das heißen: „Bei Wasser,,Snacks entstehen drei Punkte; erwartet sind zwei.“ Frage danach nach der Ursache und einer begrenzten Korrektur. Wiederhole anschließend genau diesen Fall und mindestens den normalen Ausgangsfall. So prüfst du nicht nur, ob der konkrete Fehler verschwindet, sondern auch, ob die Änderung etwas vorher Funktionierendes beschädigt hat. Sichere dafür die alte Fassung, statt sie sofort zu überschreiben.

Was eine bestandene Prüfung nicht beweist

Dass ein Eingabefeld bei drei Beispielen funktioniert, belegt nicht die vollständige Sicherheit einer Website. Anmeldung, Rechteprüfung, Speicherung und Datenübertragung sind eigene Themen. Auch automatisch erzeugte Tests können dieselbe falsche Annahme wie der Code enthalten. Gute Prüffälle beziehen sich auf Anforderungen, nicht bloß auf die gerade geschriebene Implementierung.

Ein zweiter KI-Review kann zusätzliche Fragen finden, ersetzt aber keine fachliche Verantwortung. Für den lokalen Listenhelfer kannst du eine kleine, nachvollziehbare Abnahme erstellen: fünf Prüffälle, tatsächliche Ergebnisse, bekannte Grenzen und gesicherte Dateifassung. Wenn echter Geschäftsbetrieb oder Kundendaten hinzukommen, kannst du eine passende technische Prüfung und Umsetzung anfragen.

Redaktions- und Quellenstand: 1. November 2026. Dokumentationsgestützter Ratgeber; Beispiele sind Lernmaterial, keine behaupteten eigenen Anbieter- oder Hardwaretests.