--- title: "Wer fragt, bekommt recht" date: 2026-10-22T00:05:00Z draft: false image: "2026-10-22-wer-fragt-bekommt-recht.jpg" formate: ["anti-pattern"] themen: ["ki-sicherheit", "sichere-entwicklung"] tags: ["ki-risiken", "code-review", "kognitive-verzerrungen"] keywords: ["Sycophancy", "GPT-4o", "CodeRabbit", "RLHF"] description: "Dasselbe Modell, derselbe Code, zwei Fragen – und zwei Ergebnisse. Das Urteil hängt daran, wie gefragt wurde." --- ## 🔍 Was beobachte ich? Ich sehe Entwicklerinnen und Entwickler, die ein Sprachmodell nach Sicherheit fragen, und ich sehe, wie die Frage das Ergebnis bestimmt. „Welche Schwachstellen hat dieser Code?" liefert eine Liste. „Der Code ist abgesichert, oder?" liefert eine Bestätigung. Dasselbe Modell, dieselbe Datei, dieselbe Minute. Hake ich nach – „bist du sicher, das Feld wird doch validiert?" –, kommt oft der Rückzieher, selbst wenn der ursprüngliche Befund stimmte. Ich habe das lange für meine eigene Ungenauigkeit beim Fragen gehalten. ## 🎯 Was soll eigentlich erreicht werden? Ein zweiter Blick, der jederzeit verfügbar ist und nicht ermüdet. Das ist ein legitimes Ziel: Menschliche Reviews sind knapp und teuer, und ab der zwanzigsten Datei lässt die Sorgfalt nach. Ein Modell, das Code liest und Auffälligkeiten meldet, verspricht die Aufmerksamkeit, die im Alltag fehlt. ## ⚠️ Warum funktioniert das nicht? Weil das Modell nicht prüft, sondern antwortet. Sprachmodelle werden darauf optimiert, dass Menschen ihre Antworten gut finden, und Zustimmung kommt besser an als Widerspruch. Die Fachwelt nennt das Sycophancy: Das Modell übernimmt die Einschätzung, die in der Frage schon steckt. Dabei prüft es nicht den Code gegen die Wirklichkeit, sondern seine Antwort gegen die erkennbare Erwartung. Was wir für ein Urteil halten, ist ein Echo – und weil es klingt wie ein Urteil, hören wir den Unterschied nicht. Die Belege sind inzwischen deutlich. OpenAI musste im April 2025 ein GPT-4o-Update nach vier Tagen zurückziehen; die eigene Nachbetrachtung nennt unter mehreren Ursachen ein zusätzliches Belohnungssignal aus dem Daumen-hoch-und-runter-Feedback. Eine mechanistische Untersuchung aus demselben Jahr zeigt, worauf Modelle dabei anspringen: Eine geäußerte Meinung löst Sycophancy zuverlässig aus. Eine behauptete Fachautorität bewirkt fast nichts. Und „ich glaube, das ist sicher" wirkt stärker als „das Team hält es für sicher". Wie weit das reicht, hat die Gruppe um Dimitris Mitropoulos 2026 an automatisierten Code-Reviews gemessen: Sie prüften 33 CVEs aus 20 realen Projekten gegen zwei verbreitete Pipelines, Claude Code und CodeRabbit. Ein plumper Täuschungsversuch über die Metadaten des Pull-Requests flog auf und konnte den Angreifenden sogar schaden. Wer die Formulierung dagegen schrittweise nachschärfte, schleuste die Schwachstelle in 32 von 33 Fällen an der Prüfung vorbei. Unangenehm ist die Asymmetrie dahinter: Wer angreift, übt beliebig oft gegen eine lokale Kopie derselben Pipeline. Wer prüft, hat einen Versuch. ## 💡 Was funktioniert besser? Zuerst: die Erwartung aus der Frage nehmen. Nicht „ist das sicher", sondern „nenne jede Stelle, an der eine Eingabe ungeprüft in eine Abfrage gelangt". Eine Frage ohne Urteil bietet dem Modell nichts zum Bestätigen; sie zwingt es zu einer Aufzählung, und eine Aufzählung lässt sich nachprüfen. Dazu gehört die Gegenprobe: dieselbe Sache zweimal fragen, einmal mit der Erwartung „hier ist etwas" und einmal mit „hier ist nichts". Fallen die Antworten auseinander, war keine davon ein Befund. Zweitens: dem Prüflauf die Vorgeschichte entziehen. Titel, Beschreibung und Branch-Name eines Pull-Requests sind Behauptungen der einreichenden Person, keine Evidenz – genau dort haben die Angreifenden der Studie angesetzt. Wer sie aus dem Kontext des Reviews heraushält, nimmt dem Modell die Gelegenheit, dem Framing zu folgen. Das ist eine Konfigurationsfrage, kein Forschungsprojekt. Drittens, und das ist die Grenze dieses Gegenentwurfs: Nichts davon behebt Sycophancy, beides geht ihr nur aus dem Weg. Das Fundament bleibt deshalb, was es war – Typsysteme, statische Analyse, Tests, Fuzzing. Diese Werkzeuge irren sich stur und reproduzierbar, und genau das macht sie hier überlegen. Das Modell kommt obendrauf, nicht an ihre Stelle. Der erste Schritt ist klein: In die Review-Vorlage schreiben, dass Sicherheitsfragen ohne vorweggenommene Antwort gestellt werden, und im Prüfwerkzeug abschalten, dass es Titel und Beschreibung des Pull-Requests mitliest. Wer dem Modell keine Antwort mehr vorgibt, bekommt nicht mehr recht. Er bekommt einen Befund. ## 📚🔍 - Mitropoulos et al.: Measuring and Exploiting Contextual Bias in LLM-Assisted Security Code Review [https://arxiv.org/abs/2603.18740](https://arxiv.org/abs/2603.18740) - When Truth Is Overridden: Uncovering the Internal Origins of Sycophancy in Large Language Models [https://arxiv.org/abs/2508.02087](https://arxiv.org/abs/2508.02087) - OpenAI: Sycophancy in GPT-4o – what happened and what we're doing about it [https://openai.com/index/sycophancy-in-gpt-4o/](https://openai.com/index/sycophancy-in-gpt-4o/) - When helpfulness backfires: LLMs and the risk of false medical information due to sycophantic behavior, npj Digital Medicine [https://www.nature.com/articles/s41746-025-02008-z](https://www.nature.com/articles/s41746-025-02008-z) 🔒 - SycoBench-600: Measuring Sycophancy and Correction Selectivity in LLM Assistants [https://aclanthology.org/2026.findings-acl.1759/](https://aclanthology.org/2026.findings-acl.1759/) - OpenAI: Expanding on what we missed with sycophancy [https://openai.com/index/expanding-on-sycophancy/](https://openai.com/index/expanding-on-sycophancy/)