# Hör auf, KI zum kritischen Selbstcheck zu bitten Canonical URL: https://huecki.com/blog/ki-selbstcheck-findet-immer-etwas/ Markdown URL: https://huecki.com/blog/ki-selbstcheck-findet-immer-etwas.md Language: German Published: 2026-05-21 Updated: 2026-05-21 Author: Dominic Hückmann Topic: KI-Agent Workflows - Agent topics: Agent Security, Context Engineering, Agent Evals - Tags: KI-Agenten, Prompt Engineering, Evals, KI-Sicherheit, Developer Workflow Content status: field-note ## Summary Offene Anweisungen wie „prüf das kritisch“ belohnen das Modell ungewollt dafür, Kritik zu produzieren. Die Lösung ist nicht weniger Review, sondern kalibriertes Review: klare Kriterien, PASS_NO_CHANGE, Evidenz pro Finding, Severity-Schwellen und ein kleines Änderungsbudget. ## Description Warum KI-Reviewer fast immer etwas finden — und der bessere Ersatz: Review nach Rubrik, bei dem PASS_NO_CHANGE erlaubt ist. ## Body ## Die Kurzfassung „Prüf das kritisch selbst“ klingt verantwortungsvoll. In der Praxis baut man damit oft einen kleinen Reward-Hack: Die KI wirkt wie ein nützlicher Reviewer, indem sie etwas findet. Das heißt nicht, dass Self-Review nutzlos ist. Self-Refine, Reflexion, CRITIC, Constitutional AI und Eval-Tools zeigen alle, dass Feedback-Loops Outputs verbessern können. Das Problem ist enger: **offene Kritik hat keinen Stop-Zustand.** Der bessere Prompt ist: ```txt Bewerte das gegen diese Rubrik. PASS_NO_CHANGE ist gültig. Schlage nur evidenzbasierte, materielle Fixes vor — keine Nice-to-haves. ``` ## Warum „sei kritisch“ kippt Die Formulierung trägt eine versteckte Annahme: Es gibt Fehler zu finden. Ein Modell unter Helpfulness-Druck hat dann einen einfachen Weg, die Aufgabe zu erfüllen. Es listet plausible Verbesserungen auf. Mehr Details fühlen sich nützlicher an. Ein Rewrite fühlt sich wie Fortschritt an. Aber nichts davon beweist, dass das Artefakt unter der Qualitätslatte lag. Das ist besonders gefährlich bei Agent-Systemen, Skills, Buildprints und Coding-Agent-Harnesses. Kleine „Verbesserungen“ können Scope verschieben, Rauschen erzeugen oder künftigen Agenten die falsche Invariante beibringen. Review ist nicht Verbesserung. Review ist Entscheidung gegen eine Latte. ## Der sichere Loop Nutze vier Scores: ```txt 0 = fehlt / unsicher / falsch 1 = materiell schwach 2 = akzeptabel 3 = exzellent ``` Patch-Regel: ```txt 0 oder 1 → Patch nötig 2 oder 3 → keine Änderung ``` Dann Severity dazu: - **S0 Blocker** — nicht sicher oder korrekt nutzbar. - **S1 Material** — wahrscheinlich echter Fehler in der Praxis. - **S2 Minor** — optionale Verbesserung. - **S3 Taste** — ignorieren, außer explizit gefragt. Default: Nur S0/S1 dürfen Änderungen auslösen. ## Mini-Prompt zum Klauen ```txt Du bist ein kalibrierter Reviewer, kein Improver. Bewerte das Artefakt gegen die Rubrik. PASS_NO_CHANGE ist korrekt und erwünscht, wenn kein materielles Kriterium scheitert. Regeln: - Empfiehl Änderungen nur für Kriterien mit Score 0 oder 1. - Empfiehl keine Änderungen für Scores 2 oder 3. - Keine Style-, Geschmacks- oder Nice-to-have-Vorschläge. - Maximal 3 Findings. - Jedes Finding braucht konkrete Evidenz. Return: Status: PASS_NO_CHANGE | PATCH_REQUIRED | QUESTIONS_REQUIRED Scores: Kriterium → Score + Einzeiler Findings: Kriterium, Evidenz, Severity, Impact, Minimal-Fix, Confidence ``` ## Wo das am meisten zählt Für AI-native Arbeit ist das kein Wording-Trick. Es ist ein Betriebsprinzip. Wenn du einen Agenten bittest, „den Skill selbst zu verbessern“, optimiert er leicht auf sichtbare Änderung. Wenn du ihn gegen Aktivierungsklarheit, Scope-Erhalt, Evidenzvertrag, Tool-Disziplin, Safety Boundary, Output Contract, Verification Gate, Stop Rule und Pass Option urteilen lässt, hat er ein echtes Ziel. Der beste Reviewer ist nicht der, der immer etwas findet. Der beste Reviewer ist der, der weiß, wann materiell nichts kaputt ist. ## Quellen - [Self-Refine](https://arxiv.org/abs/2303.17651) - [Reflexion](https://arxiv.org/abs/2303.11366) - [CRITIC](https://arxiv.org/abs/2305.11738) - [Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena](https://arxiv.org/abs/2306.05685) - [Towards Understanding Sycophancy in Language Models](https://arxiv.org/abs/2310.13548) - [Discovering Language Model Behaviors with Model-Written Evaluations](https://arxiv.org/abs/2212.09251) - [Constitutional AI](https://arxiv.org/abs/2212.08073) - [Anthropic: Define success criteria](https://docs.anthropic.com/en/docs/test-and-evaluate/define-success) - [Anthropic: Evaluation Tool](https://docs.anthropic.com/en/docs/test-and-evaluate/eval-tool) - [LangSmith Evaluation](https://docs.langchain.com/langsmith/evaluation) ## FAQ ### Warum überarbeitet KI beim Selbstcheck so oft zu viel? Weil Formulierungen wie kritisch prüfen nahelegen, dass Fehler existieren. Eine Liste mit Verbesserungen wirkt dann hilfreicher als ein kalibriertes PASS. ### Sollten Teams KI-Review vermeiden? Nein. Sie sollten offene Kritik durch Review nach Rubrik ersetzen: mit Evidenzpflicht, Severity-Schwellen und einem gültigen PASS_NO_CHANGE. ### Was ist der einfachste Ersatzprompt? Bewerte das gegen diese Rubrik. PASS_NO_CHANGE ist gültig. Schlage nur evidenzbasierte, materielle Fixes vor — keine Nice-to-have-Verbesserungen.