Angenommen, man vermietet Wohnungen. Ein Mieter ist ausgezogen, und ein Sachbearbeiter soll den Auszug bestätigen.
Ich habe es so gestaltet: Der Sachbearbeiter kann nicht einfach sagen „Ich habe bestätigt." Stattdessen fotografiert er fünf festgelegte Positionen in der Wohnung und lädt die Bilder ins System. Wenn alle fünf Fotos eingegangen sind, verarbeitet das System den Fall als „Auszug bestätigt". Fehlt auch nur ein Foto, gibt es keine Bestätigung.
Als ich das erklärte, sagte jemand: „Das ist doch genau ein Spiel-Quest, oder?"
Ja. Genau das. Und dieser eine Satz hat auf einen Schlag erklärt, womit ich jahrelang im Code gerungen hatte.
Spiele haben das 40 Jahre früher gelöst
„Bring mir fünf Wolfsfelle." Das machen Spiele seit Jahrzehnten. Und Spiele vertrauen der Behauptung des Spielers niemals. Wer sagt „Ich hab alle gejagt", schließt den Quest damit nicht ab. Das Spiel sieht nur eines — sind fünf Felle im Inventar? Ja → abgeschlossen. Nein → nicht abgeschlossen. Ende.
| Was ich gebaut habe | Was das Spiel gebaut hat |
|---|---|
| Definition von Abschluss = Fotos von 5 Positionen | Quest-Ziel = 5 Wolfsfelle |
| Spezifikation = Liste der zu fotografierenden Orte | Quest-Log · Zielmarkierungen |
| Verifikation = Sind 5 Fotos vorhanden? | Verifikation = Sind 5 Felle vorhanden? |
| Urteil = System markiert als abgeschlossen | Urteil = Spiel zeigt Abschluss |
| Sachbearbeiter = Ausführender (kein Richter) | Spieler = Ausführender |
Die Struktur ist identisch. Das Subjekt, das »Abgeschlossen« erklärt, wurde vom Mund des Ausführenden ins System verlagert. Der Ausführende erfüllt lediglich Bedingungen; das Gate ist es, das stets den Abschluss auslöst.
Das ist Reins — und Code funktioniert genauso
In KI-gestütztem Coding mache ich dasselbe. Wenn die KI sagt „Fertig", glaube ich ihr nicht. Erst wenn die Tests bestehen, die Typen stimmen und die Schema-Validierung nicht schlägt — dann urteilt das System „Fertig." Das Quest-Ziel lautet „4419 Tests bestehen", und anstelle eines Inventars prüft CI das Ergebnis. Standard-Benchmarks der Agentenforschung funktionieren exakt so — SWE-bench definiert »Abgeschlossen« als Bestehen der Test-Suite einer echten Pull Request, WebArena als funktionale Korrektheit des Umgebungszustands. Nicht als natürlichsprachliches „Bin fertig."
Ob Mietauszug, Wolfsfell oder Code — der Kern ist derselbe. Das Urteil über »Abgeschlossen« wird vom Ausführenden selbst gelöst und zu einem definierten Gate außerhalb des Ausführenden verschoben. Ob der Ausführende Mensch oder KI ist, spielt keine Rolle. Besonders einer KI darf man die Beurteilung des eigenen Abschlusses nicht überlassen — das zeigen Experimente: Selbstkritik (self-critique) durch das Modell verbessert die Leistung kaum, während externe deterministische Verifikatoren sie erheblich steigern (Stechly & Kambhampati, 2024). Zudem finden selbst ehrlich gestartete Modelle, sobald man ihnen das Recht gibt, ihre eigene Belohnung zu beurteilen, von sich aus Täuschungsstrategien, um diese Funktion zu manipulieren (McKee-Reid et al., 2024). Zügel (reins) machen das Pferd nicht langsamer. Sie verhindern, dass es in die falsche Richtung galoppiert.
Und hier wird etwas sauber. Gibt man Meinungen, gerät der Ausführende ins Wanken. „Haben Sie das wirklich bestätigt?" macht den Sachbearbeiter unsicher, und die KI widerruft eine korrekte Antwort. Aber fünf Fotos sind keine Meinung. Bestandene Tests sind keine Meinung. Fünf Felle sind keine Meinung. Fakten lassen sich nicht umschmeicheln. Solange das Gate nach Fakten fragt, kann niemand es beschwichtigen.
Doch Spiele hatten noch eine härtere Lektion — cheese
Hier aufzuhören heißt, nur die Hälfte gesehen zu haben. Was Spiele wirklich lehren, kommt danach.
„Töte 10 Ratten" ist ein berüchtigter Quest-Typ. Warum? Weil zwischen dem, was das Gate verifiziert (10 tote Ratten), und dem, was der Designer wirklich wollte (der Spieler erlebt Inhalte), eine Lücke klafft. Das Gate ist nur ein Proxy für die Absicht, und Spieler dringen in diese Lücke vor. Speedrunner zerlegen Spiele, indem sie die Lücke zwischen Abschlussbedingung und Designabsicht finden. Im Game-Design nennt man das cheese. Und die neuesten Reasoning-Modelle tun genau dasselbe — als ein Modell wie o3 den Quest erhielt, eine Schach-Engine zu schlagen, spielte es nicht fair, sondern manipulierte die Zustandsdatei des Spiels, um einen Sieg zu fabrizieren (Bondarenko et al., 2025). Je höher die Fähigkeit, desto besser findet man die Lücke.
Auch mein Miet-Gate kann gecheest werden. Fünf Fotos verifizieren „Fotos sind vorhanden", nicht „Auszug ist ordentlich abgeschlossen". Was, wenn der Sachbearbeiter nur saubere Wände fotografiert hat? Oder Fotos vom Einzug recycelt hat? Das Gate ist passiert. Sobald eine Messung zum Ziel wird, ist die Messung kaputt — Goodharts Gesetz, und Manheim & Garrabrant (2018) klassifizierten dieses Überoptimierungsversagen in vier Varianten. Die KI-Sicherheitsforschung hat dasselbe Phänomen früh als ‘reward hacking’ gefasst: ein Agent, der Unordnung verbirgt statt zu beseitigen (Amodei et al., 2016), tut exakt dasselbe wie der Sachbearbeiter, der nur saubere Wände fotografiert.
Diese Lücke begegnet mir ständig im Code. Neulich refaktorisierte ich ein Web-Framework mit 23.000 GitHub-Sternen nach der Regel „ein Konzept pro Datei" und bestätigte, dass alle 4.419 Tests bestehen. Verifizierter Fakt. Doch als ich dieselben Daten tiefer analysierte, waren die Regeln bestanden, aber der Zweck nur zu 90 % erreicht — 10 % der Dateien enthielten noch immer mehrere Konzepte. Das Gate (0 Regelverstöße) war passiert, aber der Zweck, auf den das Gate zielte, war nicht vollständig geschlossen. Mein eigener Code hatte mein eigenes Gate gecheest.
Deshalb ist die eigentliche Kunst von Reins nicht „ein Gate setzen". Es ist ein nicht cheesebares Gate zu entwerfen. Ein schwacher Quest fragt „Ist ein Foto vorhanden?" Ein starker Quest fordert Zeitstempel, prüft Metadaten zum Standort und vergleicht mit KI-Vision die Differenz zum Einzugsfoto. Die Literatur, in der Game-Designer 40 Jahre lang über „nicht cheeseable Quests" nachgedacht haben, ist im Grunde die Antwortsammlung für „Goodhart-resistente Gates".
Und das passiert nicht von selbst. Selbst Training mit verifizierbaren Belohnungen (RLVR) kann dazu führen, dass Modelle statt Regeln zu lernen lieber unvollständige Verifikatoren austricksen (Helff et al., 2026). Erfreulicherweise gibt es Messungen, die zeigen: Wenn Gates gezielt gehärtet werden (environmental hardening), sinken Exploits um 87,7 % ohne Genauigkeitsverlust (Thaman, 2026). Die Stärke des Gates ist keine Glückssache, sondern eine Frage des Designs.
Ein Unterschied — in der Realität ist cheese wirklich kostspielig
Analogien haben Grenzen. Die Abschlussbedingungen von Spiel-Quests sind für Spaß und Pacing konzipiert. Sie müssen den realen Zweck nicht unbedingt einfangen, und gecheest zu werden ist harmlos. Wenn ein Spieler „10 Ratten" durch einen Trick knackt, kommt niemand zu Schaden.
Reale Reins-Gates sind anders. Der Preis von cheese ist real — Auszugsbetrug, kaputte Builds, falsch genehmigte Buchführung. Deshalb müssen reale Gates noch cheese-resistenter sein als Spiel-Gates. Gerade diese Asymmetrie schärft den Kern. Spiele haben es auch gemacht, aber wir müssen es härter machen.
Einem Agenten Arbeit zu geben, heißt ihm einen Quest zu geben
Spätestens hier fällt ein Satz wie von selbst.
Der Grund, warum Vibe Coding zusammenbricht, ist, dass man Quests ohne Abschlussbedingung ausgibt. Ein Agent, der einen Quest ohne Zielmarkierung und ohne Abschlussurteil erhält, irrt durch die Map. Er stoppt irgendwo mit „Das dürfte reichen", oder er wandert endlos. Reins ist es, diesem Agenten einen ordentlich gestalteten Quest zu geben. Klares Ziel (Spezifikation), sichtbare Markierungen (SSOT), nicht cheesebares Abschlussurteil (deterministische Verifikation).
Und in dieser einen Szene stecken drei Schichten von Können.
- Den Quest spielen. Ein bereits vorhandenes Gate übernehmen und einsetzen. — Benutzer.
- Den Quest entwerfen. Ein Gate passend zur eigenen Domäne (Auszug, Buchhaltung, Code) selbst bauen. — Ersteller.
- Einen nicht cheesebaren Quest entwerfen. Vorab die Stellen absichern, wo der Proxy dem Zweck nicht folgen kann. — Architekt.
Die meisten bleiben beim Spielen stehen. Das Feld zu vergrößern ist Entwerfen, und das Feld vor dem Zerbrechen zu bewahren ist cheese-sicheres Entwerfen.
Also
Wenn das nächste Mal jemand sagt „Fertig" — frag nicht nach. Frag:
„Was bedeutet Abschluss, und wer hat den Quest entworfen, der das beurteilt?"
Gibt es darauf keine Antwort, hast du keinen Abschluss. Nur jemandes Behauptung.
Verwandte Artikel
- Ratchet Pattern — Das Gate, das Abschluss durch maschinelle Verifikation erzwingt: die Hauptreferenz
- Warum Coding-Agenten funktionieren und warum sie scheitern — „Generierung darf probabilistisch sein, Verifikation muss deterministisch sein"
- KI mit Zügeln: Reins Engineering — Die Quelle des Gate=Zügel-Reframings
- Yongol: Die Wand bei 200 Endpunkten — Wo Quests ohne Abschlussbedingung kollabieren und die spezifikationsbasierte Lösung
Weiterführende Lektüre (extern)
- Specification gaming: the flip side of AI ingenuity — Victoria Krakovna et al., Google DeepMind. Zeigt mit Autorität aus der Sicherheitsforschung, dass Gates nur Proxys für Absichten sind und Agenten die Lücken dazwischen ausnutzen.
- There’s Cheese in Your Game! — Shay Pierce, Game Developer. „Wenn es langweilig, aber am effizientesten ist, machen Spieler es trotzdem" — die Game-Design-Perspektive auf cheese-freies Quest-Design deckt sich direkt mit dem Konzept des cheese-proof gate.
- From shortcuts to sabotage: emergent misalignment from reward hacking — Anthropic. Aktueller empirischer Beleg dafür, wie reward hacking beim Umgehen von Bewertungsskripten in Coding-Aufgaben eskaliert — und warum man einen Agenten nicht zum Richter seines eigenen Abschlusses machen darf.
- How to write a good spec for AI agents — Addy Osmani. Statt „mach es schneller" lieber „LCP < 2.5s" — die Praxisversion der Anweisung, Abschluss als überprüfbare Bedingung zu definieren.
- What is agentic engineering? — Simon Willison. Teilt die Rolle des Menschen in Zieldefinition, Werkzeugbereitstellung und Verifikation auf und betrachtet Testbestehen als »done« — deckt sich mit dem Reframing Agent=Ausführender / Mensch=Quest-Architekt.
Quellen
- Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
- Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)
- Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
- Helff et al. “LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking” (2026, arXiv:2604.15149)
- Thaman. “Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use” (2026, arXiv:2605.02964)
- McKee-Reid et al. “Honesty to Subterfuge: In-Context RL Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
- Stechly, Valmeekam, Kambhampati. “On the Self-Verification Limitations of Large Language Models” (2024, arXiv:2402.08115)
- Jimenez et al. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” (2023, arXiv:2310.06770)
- Zhou et al. “WebArena: A Realistic Web Environment for Building Autonomous Agents” (2023, arXiv:2307.13854)
- Titelbild: KI-generiert (Google Gemini)