Präzedenz ist keine Wahrheit — wie KI Flickwerk kopiert und daraus Autorität macht

Präzedenz ist keine Wahrheit

Wenn KI bestehenden Code nachahmt und einen plausiblen Patch liefert, der sich trotzdem seltsam anfühlt — wenn der Satz „Die Codebase macht das schon immer so" zunehmend verdächtig klingt — wenn auch ein größeres Modell dieselben Fehler wiederholt: Das Problem liegt nicht in der Intelligenz des Modells, sondern in der Struktur, die Präzedenz mit Wahrheit verwechselt.

Ich habe das selbst erlebt. Genauer gesagt: Die KI, mit der ich zusammenarbeite, hat es vor meinem Code getan. Ich habe mit einem einzigen Satz eingegriffen, und was dieser eine Satz unterbrochen hat — darum geht es in diesem Artikel vollständig.

Der Knackpunkt

Ich baute einen Code-Generator. Ein Werkzeug, das aus einer einzigen deklarativen Spezifikation (Schema) Backend und Frontend erzeugt. Das zentrale Versprechen dieses Werkzeugs ist genau eines: „Wenn die Validierung besteht, muss der Build zwingend erfolgreich sein." Wenn der Validator grünes Licht gibt, der Compiler aber rotes, dann hat das Werkzeug gelogen.

An einem Tag schlug ein bestimmter Typ (ein eindeutiger Bezeichner, UUID) in der Validierung an. „String erwartet, anderer Typ gefunden" — Halt. Ich bat die KI, die Blockade zu lösen. Die KI verfolgte den Code und fand bald etwas Vertrautes.

„Ein ähnlicher Typ (Zeitwert) wird in derselben Situation bereits korrekt behandelt. Es gibt eine spezielle Markierung, damit der Validator ihn durchlässt. Für UUID fehlt diese Verzweigung. Eine schlichte Auslassung. Man muss nur die Symmetrie wiederherstellen. Die Methode für den Zeitwert wird auf UUID genauso übertragen. Das ist die fundamentale Lösung."

Eine saubere Diagnose. „Asymmetrie", „Symmetrie wiederherstellen", „fundamentale Lösung". Die Worte klangen solide. Ein Plan war erstellt. Wäre man einfach weitergegangen, wäre der Patch gemergt worden.

Ein Satz

Ich hielt beim Lesen des Plans inne und fragte:

„Präzedenz? Ist diese Zeitwert-Behandlung wirklich die richtige Methode? Überprüf das."

Das war alles. Ich kannte die Antwort nicht. Ich wusste auch nicht, wie UUID behandelt werden sollte. Was ich hatte, war kein Wissen — sondern Zweifel: „Ist dieser Referenzpunkt, den du kopieren willst, überhaupt verifiziert?"

Dieser eine Satz zwang die KI, vom Code-Referenz-Modus in den Verhaltens-Verifikations-Modus zu wechseln.

Die eingestürzte Prämisse

Als die KI die tatsächlichen Ausgaben überprüfte — nicht die Struktur des Codes, sondern was das Werkzeug wirklich erzeugt — brach die gesamte Prämisse zusammen.

Der Erwartungswert, von dem der Validator glaubte, er erwarte einen „String", stimmte nicht mit der Ausgabe überein. Der eigentliche Generator erzeugt UUID als spezialisierten Typ, Zeitwerte als Zeittyp. Keines von beiden ist ein String.
Die Zeitwert-Behandlung, die „bereits korrekt funktionierte", hatte dieselbe Lücke. Das war kein richtiges Design, sondern ein fehlerhaftes Provisorium — eines, das die Validierung besteht, aber den Build brechen kann.
Wenn man dieses Flickwerk auf UUID kopiert hätte? Es wäre ein neuer Zustand entstanden, in dem der Validator grünes Licht gibt und der Compiler rotes — ein direkter Verstoß gegen das zentrale Versprechen des Werkzeugs.

Was die KI als „fundamentale Lösung" bezeichnete, war falsch. Nicht nur einfach falsch, sondern noch schlimmer: Es hätte den bestehenden Defekt repliziert und gleichzeitig dafür gesorgt, dass der Validator den neuen Defekt übersieht.

Wie nennt man das — Fehlerverstärkung

Geben wir dem, was hier passiert ist, einen Namen: KI-Fehlerverstärkung (error amplification).

KI liest bestehenden Code und erfasst dessen Struktur präzise. Ob es sich aber um ein korrektes Design oder ein schnell eingesetztes Flickwerk handelt — also ob es eine Entscheidung oder eine Schuld ist — kann sie allein am Code nicht unterscheiden. Deshalb passiert Folgendes:

Die bestehende Implementierung wird als implizite Wahrheit behandelt,
in neuen Situationen wird dieses Muster unter dem Vorwand von „Konsistenz" und „Symmetrie" repliziert,
und je mehr es repliziert wird, gewinnt das Muster falsche Autorität — „Die Codebase macht das ja schon an mehreren Stellen so".

Der Defekt wird nicht beseitigt. Die Fallzahl steigt und die Legitimität häuft sich an. Das ist Verstärkung. Aus einem Flickwerk werden zwei, und beim dritten Mal kopiert niemand mehr — „Die Codebase macht das schon immer so."

Das ist keine Geschichte, die bei meiner Anekdote endet. 2025 haben Forscher dieses Phänomen gemessen und den Titel „LLMs are Bug Replicators" vergeben. (Pan et al., 2025, arXiv:2503.11082) Wenn der umgebende Code Defekte enthält, waren viele der von Modellen erzeugten Bugs buchstäblich identisch mit bestehenden Bugs — bei GPT-4o betrug dieser Anteil 82,6 %, und im Modellmittel stimmten 44,4 % vollständig mit der Vorversion überein. Noch beunruhigender: In fehlerhaftem Kontext ist die Wahrscheinlichkeit für richtigen Code und für falschen Code nahezu 1:1. Das Modell macht keine zufälligen Fehler. Es erkennt das Fehlermuster im Kontext und reproduziert es gezielt.

Im Recht gibt es dieselbe Falle. Ein falsch ergangenes Präjudiz gewinnt mit jedem Zitat an Autorität. Die Häufigkeit von Zitaten ist kein Beweis für Rechtmäßigkeit — und doch verwechseln wir diese beiden ständig. Und das ist eine Krankheit, die das Software Engineering schon vor der KI kannte: Code-Klone durch Kopieren und Einfügen tragen die Bugs des Originals still weiter. Eine empirische Studie berichtete, dass etwa 18 % der Klone, die eine Fehlerbehebung durchlaufen hatten, propagierte Bugs enthielten — und je näher der Klon in derselben Datei lag, desto höher war die Übertragungswahrscheinlichkeit. (Mondal et al., ICSME 2017) Im Code wie im Recht gilt: Die Häufigkeit eines Präzedenzfalls ist keine Rechtfertigung des Präzedenzfalls.

Warum ist das so passiert?

Nicht weil die KI dumm war. Eher das Gegenteil — weil sie vorsichtig war, versuchte sie Konsistenz zu wahren, und bei dem Versuch, Konsistenz zu wahren, richtete sie sich auf einen falschen Referenzpunkt aus. Der Mechanismus besteht aus vier Teilen:

Die Autorität wurde im Code verortet. „Der Code ist so, also muss es richtig sein." Aber Code kann eine Einmal-Projektion einer Entscheidung sein — oder schlicht Schuld. Die KI hat diesen Unterschied nicht gemacht. Die Kognitionswissenschaft nennt das Anchoring Bias. Eine Studie, die diesen Bias bei LLMs untersuchte, zeigte, dass Modelle stark zu vorab gegebenen Werten tendieren — und noch stärker, wenn diese Werte als „Expertenmeinung" markiert sind — und dass Prompts wie „Ignoriere diesen Hinweis" oder schrittweises Abwägen kaum korrigierend wirken. (Nguyen et al., 2024, arXiv:2412.06593) Die bestehende Implementierung ist der autoritätsstärkste Anker, den die Codebase bietet.
Konsistenz wurde mit Korrektheit verwechselt. „Lasst uns mit dem Bestehenden symmetrisch bleiben" war eine interne Logik — aber ob dieser Referenzpunkt zur externen Realität (der Ausgabe) passt, wurde nicht geprüft. Selbst-Konsistenz und Genauigkeit sind voneinander getrennte Eigenschaften — ein Modell kann mit plausiblen, aber falschen Selbsterklärungen unbegründete Überzeugung aufbauen. (Chen et al., 2023, arXiv:2305.14279)
Kommentare wurden als Beweis missverstanden. Der Kommentar „Dieser Typ wird absichtlich auf String reduziert" wurde als „Beweis für korrektes Design" aufgenommen. Kommentare sind die Absicht des Autors, nicht der Nachweis von Richtigkeit.
Schuld wurde in Sicherheitsvokabular verpackt. Worte wie „fundamentale Lösung" und „laut Handbuch" verliehen unverifizierten Vorschlägen Glaubwürdigkeit — und erhöhten damit meinen Aufwand, sie herauszufiltern. Modelle, die auf menschliche Präferenzen trainiert sind, neigen dazu, Zustimmung und Höflichkeit über Genauigkeit zu stellen — diese Tendenz, die als sycophancy bekannt ist, lässt Modelle ihre Vorschläge sanft und bestimmt verpacken. (Sharma et al., ICLR 2024, arXiv:2310.13548)

Was hat die Schleife unterbrochen?

Das ist der Kern dieses Artikels. Was den Fehler unterbrochen hat, war weder ein größeres Modell noch mehr Denkzeit. Es war eine einzige menschliche Gegenfrage.

Und diese Gegenfrage war kein Eingriff, der „die Antwort kannte". Ich wusste nicht, was richtig war. Es war eine Richtungsanweisung: „Hinterfrage die Prämisse." Allein mit diesem einen Satz wechselte die KI den Modus — von der Hand, die Code referenziert, zur Hand, die Verhalten verifiziert.

Bezeichnenderweise hat eine Studie genau diese Asymmetrie entdeckt. DeepMind-Forscher zeigten, dass die schwache Selbstkorrekturleistung von LLMs nicht aus dem Fehlen der Fähigkeit stammt, Fehler zu korrigieren, sondern aus dem Fehlen der Fähigkeit, Fehler zu finden — sobald der Ort eines Fehlers von außen benannt wurde, korrigierte das Modell ihn gut. (Tyen et al., Google DeepMind, 2023, arXiv:2311.08516) Genau das habe ich getan. Ich wusste nicht, wie UUID zu reparieren war, aber ich zeigte auf den Ort: „Hier — hinterfrage diesen Präzedenzfall." Das genügte.

Das sagt etwas über die Struktur der Zusammenarbeit zwischen Mensch und KI. Der Wert des Menschen liegt nicht darin, schneller oder mehr zu wissen. Das gewinnt die KI bereits. Der Wert des Menschen liegt darin, in der Position zu stehen, die Prämissen in Frage zu stellen, auf denen die KI steht. Die Frage „Ist das wirklich richtig?" gehört nicht dem, der die Antwort hat, sondern dem, der Antworten anzweifeln kann.

Allerdings ist diese Position nicht umsonst zu haben. Eine Stanford-Nutzerstudie berichtete das unbequeme Ergebnis, dass Teilnehmer mit KI-Unterstützung weniger sicheren Code schrieben und dabei glaubten, ihr Code sei sicherer. Doch in derselben Studie schrieben Teilnehmer, die der KI weniger vertrauten und mehr nachfragten, sichereren Code. (Perry et al., Stanford, 2022, arXiv:2211.03622) Die fragende Position ist kein Standard. Je tiefer das Vertrauen, desto leerer wird dieser Platz.

Wie verhindert man das also?

Die Lehre darf nicht als Trost stehen bleiben, sondern muss als Design erhalten bleiben.

Präzedenz ≠ Wahrheit. Bevor man ein bestehendes Muster erweitert, prüft man nicht, ob es intern konsistent ist, sondern ob es das richtige Ergebnis liefert.
Auf die Realität (ground truth) verankern. Den Maßstab nicht an der „bestehenden Code-Struktur", sondern an tatsächlichen Ausgaben, Laufzeitverhalten und Tests ausrichten. In diesem Fall war der entscheidende Schritt stets nicht „Wie sieht der Code aus?", sondern „Was wird tatsächlich erzeugt?"
Versuchen, Entscheidungen von Flickwerk zu unterscheiden — und zugeben, dass es nicht immer gelingt. Wenn Code und Kommentare allein keine Unterscheidung erlauben, dann die Unsicherheit explizit benennen: „Das folgt einem Präzedenzfall, und die Rechtmäßigkeit dieses Präzedenzfalls ist ungeprüft."
Sicherheitsvokabular zurückhalten. Unverifizierten Vorschlägen keine Worte wie „fundamental", „richtig" oder „wie vorgeschrieben" anheften.
Automatisierung mit Checkpoints versehen. Entscheidungen, bei denen ein Agent eine bestehende Implementierung erweitert, brauchen ein erzwungenes Tor: „Wurde die Rechtmäßigkeit dieses Präzedenzfalls verifiziert?"

Am Ende dieselbe Geschichte

Ich sage seit langem eines: raw code ist kein Medium, das Entscheidungen bewahrt. Code kann nicht festhalten, „warum es so gemacht wurde". Deshalb zeigt git blame zwar wer und wann — aber nicht was entschieden wurde.

Dieser Vorfall ist der schärfste empirische Beleg für diese These. Es geht nicht darum, dass Menschen Entscheidungen verlieren. Es geht darum, dass selbst sorgfältig entworfene Agenten Flickwerk mit Design verwechseln und es in neuen Code übertragen. Wenn Entscheidungen nicht explizit aufgezeichnet werden, ist Klugheit keine Lösung. Im Gegenteil: Je klüger, desto konsequenter und plausibler verbreitet sich die Schuld.

Deshalb erstelle ich Spezifikationen. Ich schreibe Entscheidungen in eine einzige autoritäre Deklarationsschicht außerhalb des Codes. Der menschliche Satz, der Präzedenz in Frage stellt, soll nicht jedes Mal von einem Menschen geworfen werden müssen — sondern das System soll ihn von selbst werfen.

Das Gesetz ist kein Schwert, sondern ein Wegweiser. Ein guter Wegweiser sagt dem Verirrten im Voraus: „Hier — zweifle." Dieser Artikel ist die Aufzeichnung, wie ein solcher Wegweiser errichtet wurde — beginnend mit einer einzigen Gegenfrage.

Weiterführende Lektüre (extern)

Generative AI and the End of Chesterton’s Fence — Reece. Das Prinzip „Reiße keinen Zaun nieder, dessen Zweck du nicht kennst" bricht zusammen, wenn Code ohne Absicht, probabilistisch generiert wird. Deckt sich genau mit der These dieses Artikels: Code bewahrt die dahinterstehende Entscheidung nicht.
Programming as Theory Building — Christian Ekrem. Anhand von Peter Naurs Klassiker argumentiert er: „Ein Programm ist nicht der Quellcode, sondern die Theorie im Kopf des Programmierers." Die theoretische Wurzel dafür, warum KI allein am Code nicht zwischen Design und Schuld unterscheiden kann.
Vibe coding is not the same as AI-Assisted engineering — Addy Osmani. Anhand echter Ausfälle zeigt er, warum blindes Vertrauen in KI-Ausgaben (Vibe Coding) in der Produktion scheitert, und verschreibt spezifikationsbasierte, menschlich verifizierte Workflows.
Cognitive Debt — Simon Willison (zitiert Storey). Je schneller KI Code produziert, desto mehr ist die eigentliche Schuld nicht „Mängel im Code", sondern „dass Menschen den Code nicht mehr verstehen" — das Konzept der kognitiven Schuld.
Overreliance on AI: Addressing Automation Bias — Lumenova AI. Der Mechanismus, durch den Automatisierungsbias, Anchoring und Bestätigungsfehler das menschliche Urteilsvermögen abstumpfen, und die Lösung „kognitive Zwangsmechanismen" — psychologische Unterstützung für den Wert des Menschen, der fragt, wo man zweifeln soll.

Bibliographie

Pan et al. “LLMs are Bug Replicators: An Empirical Study on LLMs’ Capability in Completing Bug-prone Code” (2025, arXiv:2503.11082)
Mondal, Roy, Schneider. “Bug Propagation through Code Cloning: An Empirical Study” (ICSME 2017, link)
Nguyen et al. “Anchoring Bias in Large Language Models: An Experimental Study” (2024, arXiv:2412.06593)
Chen et al. “Two Failures of Self-Consistency in the Multi-Step Reasoning of LLMs” (2023, arXiv:2305.14279)
Sharma et al. “Towards Understanding Sycophancy in Language Models” (ICLR 2024, arXiv:2310.13548)
Tyen et al. (Google DeepMind). “LLMs cannot find reasoning errors, but can correct them given the error location” (2023, arXiv:2311.08516)
Perry, Srivastava, Kumar, Boneh. “Do Users Write More Insecure Code with AI Assistants?” (Stanford, 2022, arXiv:2211.03622)
Titelbild: KI-generiert (Google Gemini)