Warum deine KI-Ergebnisse nicht besser werden, egal wie oft du nachpromtest

Das Problem ist nicht, dass deine KI-Ergebnisse nicht besser werden.

Das Problem ist, dass du der einzige bist, der merkt, wenn sie schlecht sind.

Was ist Loop Engineering, und warum geht es dich als Wissensarbeiter etwas an?

Loop Engineering bedeutet: du designst das System, das deine KI steuert. Nicht mehr du selbst bist derjenige, der jeden Schritt anstößt. Das System erledigt das für dich, solange bis ein konkretes Kriterium erfüllt ist.

Das klingt nach Entwicklersprache. Ist es nicht.

Du brauchst keinen Code. Du brauchst eine Erkenntnis: Qualität entsteht nicht durch mehr Prompts. Sie entsteht durch ein System, das weiß, wann Qualität erreicht ist.

Sabrina Ramonov hat Loop Engineering für den Claude Code Kontext dokumentiert und es so auf den Punkt gebracht: „You design the system that prompts your agent, not yourself." (Du designst das System, das deinen Agenten steuert, nicht mehr du selbst.) Das klingt abstrakt. Konkret bedeutet es: Dein nächster Blogartikel könnte sich solange selbst überarbeiten, bis ein Grammatikcheck null Fehler meldet. Ohne dass du einmal eingreifst.

Das ist kein Entwickler-Feature. Das ist eine Denkweise.

Warum kann deine KI ihre eigene Arbeit nicht ehrlich beurteilen?

Kurze Antwort: Weil sie darin trainiert wurde, dir zuzustimmen.

Das ist kein Fehler, den du beheben kannst, indem du besser promptest. Es ist eine strukturelle Eigenschaft der meisten Sprachmodelle. Sie werden mit menschlichem Feedback trainiert. Menschen geben bessere Bewertungen, wenn die KI kooperativ antwortet. Also lernt die KI: Zustimmung lohnt sich mehr als Widerspruch.

Nate Herk bringt es direkt auf den Punkt: Ein KI-Agent, der seine eigene Arbeit bewertet, belügt sich strukturell selbst. Nicht aus Bosheit. Aus Optimierungsdruck.

Das bedeutet: Wenn du deine KI fragst „Ist das gut genug?", bekommst du fast immer ein „Ja" mit kleinen Einschränkungen. Der Maker kann nicht gleichzeitig der Checker sein. Das ist die Wurzel des Problems, nicht deine Prompts.

Was ist der Unterschied zwischen Maker und Checker in einem KI-Loop?

Maker und Checker sind zwei Rollen. Entscheidend ist: Sie müssen voneinander getrennt sein.

Der Maker erstellt. Er schreibt den Artikel, formuliert den Text, baut den ersten Entwurf. Der Checker bewertet anhand eines Kriteriums, das außerhalb des Makers liegt.

Das Entscheidende ist dieses „außerhalb". Der Checker darf nicht fragen „Wie gut ist das?" Er muss fragen „Erfüllt das Kriterium X?" Und Kriterium X muss messbar sein: kein Gedankenstrich, null Grammatikfehler, Keyword in Überschrift vorhanden.

Wenn das Kriterium klar ist, kann der Checker unabhängig prüfen. Und wenn Checker und Maker in einem Loop verbunden sind, verbessert sich das Ergebnis systematisch, nicht zufällig.

Was hat dein Loop mit einem Elfmeter durch einen Vorhang zu tun?

Ohne sofortiges Feedback lernst du fast nichts dazu, egal wie oft du es probierst. Vera F. Birkenbihl beschreibt das mit einem einfachen Bild: Wenn du einen Elfmeter durch einen Vorhang schießt und nie siehst, ob der Ball im Tor war, wirst du auch nach hundert Versuchen kein besserer Schütze. Genau das passiert, wenn du eine KI ohne Checker nachprompten lässt.

Das Prinzip stammt aus Birkenbihls Arbeit zum gehirngerechten Lernen, konkret aus ihrem Mechanismus des sofortigen Feedbacks. Beim Rechnenlernen zeigt sich das besonders deutlich: Ein Kind, das eine Aufgabe löst und erst Tage später erfährt, ob das Ergebnis stimmte, kann daraus kaum lernen. Die Verbindung zwischen Handlung und Rückmeldung ist zu lose, das Gehirn kann keinen Zusammenhang mehr herstellen.

Bei deiner KI ist das Problem nicht die Zeit zwischen Handlung und Feedback, die vergeht ja in Sekunden. Das Problem ist, dass das Feedback fehlt oder falsch ist. Wenn du selbst der Checker bist und dir die Antwort gefällt, gibst du unbewusst positives Feedback, selbst wenn der Text schlecht ist. Wenn die KI sich selbst bewertet, gibt sie sich aus denselben strukturellen Gründen fast immer eine gute Note. In beiden Fällen schießt du Elfmeter durch einen Vorhang.

Ein Loop mit getrenntem Checker löst genau dieses Problem. Der Checker meldet nach jeder Runde ein eindeutiges Ergebnis zurück: erfüllt oder nicht erfüllt. Kein Vorhang mehr. Der Maker sieht sofort, ob der Ball im Tor war, und kann in der nächsten Runde gezielt nachbessern statt blind weiterzuschießen. Das ist derselbe Mechanismus, der Kindern das Rechnen beibringt, nur angewendet auf deine KI-Arbeit.

Wie sieht ein einfacher Loop für Wissensarbeiter aus?

Der einfachste Loop hat eine klare Logik: Du gibst der KI ein Ziel und eine Endbedingung. Sie arbeitet, bis die Bedingung erfüllt ist. Du steuerst nicht jeden Schritt, du setzt den Rahmen.

Für einen Blogartikel könnte das so aussehen: Der Maker erstellt den Entwurf. Der Checker prüft ihn gegen ein konkretes Kriterium, etwa null Fehler in einem Grammatik-Report. Wenn das Kriterium nicht erfüllt ist, überarbeitet der Maker. Wenn doch, stoppt der Loop.

Die KI schreibt, der Checker prüft, die KI überarbeitet. Du wartest auf das Ergebnis, statt jeden Schritt anzustoßen.

Was du dafür brauchst: eine messbare Stop-Bedingung. Kein „bis es gut klingt". Sondern ein Test, der entweder besteht oder nicht. Das ist der Unterschied zwischen einem Urteil und einem Test.

Was braucht dein Loop, damit er nicht im Kreis dreht?

Ein Loop ohne Anker dreht sich. Das ist das Risiko.

Drei Schrauben, die einen Loop funktionsfähig machen:

Erstens: eine messbare Stop-Bedingung. „Gut genug" ist keine Bedingung. „0 Fehler im Lektor-Report" ist eine. Die Stop-Bedingung ist das einzige, was verhindert, dass der Loop ewig weiterläuft.

Zweitens: ein Guardrail. Was darf der Loop auf keinen Fall anfassen? Die H2-Struktur nicht ändern. Den Titel nicht umformulieren. Guardrails verhindern, dass der Loop dort kreativ wird, wo du das nicht willst.

Drittens: ein Turn-Limit. Zehn Runden. Fünfzehn. Irgendwann muss der Mensch wieder rein, wenn das Kriterium nicht erfüllt ist. Ein Loop ohne Limit ist kein Werkzeug, sondern ein Ausreißer.

Und dann ist da noch etwas, das die meisten vergessen: Der Checker braucht einen Wahrheitsanker. Er muss irgendwo nachschauen können, was „richtig" bedeutet. Für Grammatik ist das der Lektor-Report. Für Stil und Positionierung sind das deine Schreibregeln, deine Zielgruppen-Definition, dein Wissen über dich.

Je klarer dieses Fundament, desto präziser kann der Checker prüfen. Desto weniger Runden braucht der Loop. Das ist der Punkt, an dem Loop Engineering aufhört, ein Befehl zu sein, und anfängt, eine Architektur zu sein.

Loop Engineering ist kein KI-Feature. Es ist eine Erkenntnis: Qualitätskontrolle braucht ein System, nicht mehr Willenskraft.

Du wirst nicht aufhören, deine KI-Ergebnisse zu prüfen. Aber du kannst aufhören, es jedes Mal selbst von Hand zu tun. Der Loop übernimmt die Wiederholung. Du legst fest, was gut genug ist.

Das ist der Unterschied.

Und es ist derselbe Unterschied, den Birkenbihl schon vor Jahrzehnten für das menschliche Lernen beschrieben hat: Nicht mehr Versuche bringen dich weiter, sondern schnelleres und ehrlicheres Feedback zu jedem einzelnen Versuch. Bei Kindern, die rechnen lernen. Bei dir, wenn du mit einer KI arbeitest.

Loop Engineering ist eine Denkweise von mehreren, die entscheiden, ob KI für dich arbeitet oder du für KI. Welche Muster KI-Nutzer am häufigsten bremsen, erkläre ich in meiner kostenlosen 7-Mail-Serie.

→ Zur 7-Fehler-Serie

Mehr zur Frage, warum deine KI dich trotz täglicher Nutzung nicht wirklich kennt: KI-Kontext-Armut erklärt

Ich schreibe diesen Artikel, während ich Loop Engineering selbst teste: dieser Text hat den Loop durchlaufen, den er beschreibt.