Selbstkritik-Schleifen: das Modell den eigenen Output prüfen lassen

Ein zweiter, unabhängiger Durchgang zur Prüfung findet mehr Fehler als die Bitte „sei gründlich" im selben Atemzug.

Das Prinzip

Bei einer Selbstkritik-Schleife (Critique-then-Revise) lässt du das Modell die eigene Lösung danach in einem separaten Schritt bewerten – und erst dann überarbeiten. Statt „löse die Aufgabe gründlich" in einem Prompt läuft das in bewussten Schritten: erst erzeugen, dann prüfen, dann verbessern.

Warum getrennte Durchgänge besser funktionieren

Bittest du im selben Atemzug um Lösung und Gründlichkeit, bewertet das Modell seinen Output oft im selben Gedankengang, in dem es ihn erzeugt hat – Fehler aus einer bestimmten Denkrichtung bleiben dort meist unentdeckt. Ein zweiter Durchgang mit frischem Blick auf den fertigen Output findet dagegen eher Fehler, die beim Erzeugen selbst unsichtbar waren.

Ein Praxis-Beispiel

Ein Reviewer-Pass mit frischem Kontext: Du gibst nur den fertigen Code (ohne die Denkgeschichte) in eine neue Anfrage und bittest gezielt um Fehlersuche. Ohne Erinnerung an die eigene vorherige „Begründung" prüft das Modell den Code neutraler.

Die Grenze: Selbstbestätigung

Selbstkritik-Schleifen garantieren keine Fehlerfreiheit. Bei einem grundlegenden Missverständnis der Aufgabe wiederholt das Modell dieses Missverständnis oft auch in der eigenen Prüfung. Für echte Unabhängigkeit hilft ein zweites Modell oder ein Mensch als Prüfinstanz.

BEISPIEL

Schritt 1 (neue Anfrage): „Schreibe eine Funktion, die ein Datum im Format TT.MM.JJJJ validiert." Schritt 2 (separate, frische Anfrage, nur mit dem fertigen Code als Input): „Hier ist eine Datumsvalidierung. Finde Bugs und Edge Cases, ohne zu wissen, wie oder warum sie geschrieben wurde." Schritt 3: „Überarbeite die Funktion basierend auf dieser Kritik."

🛠️ ÜBUNG — MACH DAS BEI DIR

Baue eine zweistufige Selbstkritik-Schleife für eine kleine Coding-Aufgabe.

Lass das Modell eine kleine Funktion schreiben (z. B. eine Datumsvalidierung).
Öffne eine neue, separate Anfrage und gib nur den fertigen Code ohne den bisherigen Verlauf ein, mit der Bitte 'Finde Bugs und Edge Cases in diesem Code.'
Lass das Modell auf Basis der Kritik eine überarbeitete Version schreiben.
Vergleiche die erste und die überarbeitete Version.

✅ SELBST-CHECK

☐ Hat der frische Prüf-Durchgang Probleme gefunden, die beim ursprünglichen Schreiben nicht auffielen?
☐ Wäre 'sei gründlich' im selben Durchgang zum gleichen Ergebnis gekommen?

KURZ-QUIZ

Warum findet ein separater Prüf-Durchgang oft mehr Fehler als die Bitte „sei gründlich" im selben Antwortdurchgang?