Wenn KI überzeugend falsch liegt

Überspitzt formuliert kann ein Sprachmodell sehr überzeugend erklären, warum 1 + 1 = 3 sein soll. Es könnte eine saubere Argumentationsstruktur aufbauen, Zwischenschritte formulieren und das Ergebnis mit der sprachlichen Sicherheit eines Lehrbuchs präsentieren.

Bei diesem Beispiel entsteht daraus kaum ein Problem. Wir kennen die richtige Antwort und erkennen den Fehler sofort.

Interessanter wird derselbe Mechanismus dort, wo wir selbst nicht genügend Fachwissen besitzen, um die zugrunde liegende Annahme zu prüfen. Eine falsche Aussage über eine selten verwendete Framework-API kann aussehen wie eine korrekte technische Erklärung. Eine fehlerhafte Aussage über eine Transaktionsgrenze kann für jemanden ohne Erfahrung mit verteilten Systemen vollkommen plausibel wirken. Bei einer sicherheitsrelevanten Frage fällt eine falsche Annahme möglicherweise nur jemandem auf, der genau diese Art von System bereits analysiert hat.

Die entscheidende Frage lautet deshalb nicht, ob wir offensichtlichen Unsinn erkennen können.

Was passiert, wenn der Mensch selbst nicht weiß, dass gerade 1 + 1 = 3 behauptet wurde?

Umgangssprachlich heißt es dann schnell, die KI habe „gelogen“. Als Zuspitzung funktioniert das, technisch beschreibt es den Mechanismus aber schlecht. Eine Lüge setzt normalerweise voraus, dass jemand eine Aussage für falsch hält und sie trotzdem mit Täuschungsabsicht äußert. Diese Absicht sollten wir einem Large Language Model nicht einfach unterstellen.

Präziser ist:

Ein Modell kann überzeugend falsch liegen.

Und genau deshalb ist eine Eigenschaft für die weitere Betrachtung entscheidend:

Plausibilität ist kein Wahrheitskriterium.

Die gefährlichste Halluzination sieht nicht gefährlich aus

Offensichtlicher Unsinn ist vergleichsweise einfach zu behandeln. Wenn ein Agent eine Methode aufruft, die syntaktisch unmöglich ist, kann der Compiler widersprechen. Wenn ein generierter Test nicht kompiliert, erhalten wir unmittelbar Feedback. Wenn ein Modell behauptet, Berlin liege in Frankreich, brauchen die meisten Menschen ebenfalls kein zusätzliches Werkzeug, um skeptisch zu werden.

Schwieriger sind Fehler, die sich nahtlos in das vorhandene Wissen einfügen.

Eine Antwort kann fachsprachlich korrekt klingen, bekannte Patterns verwenden, sauber strukturiert sein und plausible Begründungen enthalten. Vielleicht stimmen sogar neun von zehn Aussagen. Nur die zehnte Aussage – diejenige, von der der weitere Lösungsweg abhängt – ist falsch.

Das macht sie nicht weniger problematisch. Im Gegenteil.

Die gefährlichste Halluzination ist diejenige, für deren Erkennung man bereits Fachwissen benötigt.

Menschen interpretieren sprachliche Sicherheit leicht als Signal für inhaltliche Sicherheit. Bei einem LLM dürfen wir diese beiden Ebenen jedoch nicht gleichsetzen. Eine elegante Erklärung ist zunächst nur eine elegante Erklärung. Eine logische Struktur beweist nicht, dass ihre Prämissen stimmen. Ein professionell wirkender Codeblock beweist nicht, dass die verwendete API existiert.

Man könnte das zunächst für einen bloßen Qualitätsmangel einzelner Modelle halten. Der Mechanismus reicht jedoch tiefer und beginnt bereits bei der Art, wie Sprachmodelle gelernt haben, Text zu erzeugen.

Warum entstehen Halluzinationen?

Der Begriff Halluzination wird inzwischen sehr weit verwendet. Manchmal bezeichnet er erfundene Fakten, manchmal jede falsche Antwort und gelegentlich sogar jede unerwünschte Entscheidung eines Agents.

Für die technische Diskussion hilft eine engere Betrachtung. Nicht jeder Fehler hat dieselbe Ursache.

Ein Sprachmodell ist kein Wahrheitsregister

Ein Large Language Model besitzt nicht einfach eine interne Datenbank dieser Form:

Aussage
↓
wahr / falsch

Während des Pretrainings lernt ein Modell zunächst aus großen Mengen von Text statistische Strukturen und Beziehungen. Vereinfacht gesagt lernt es, welche Fortsetzungen unter gegebenen Bedingungen wahrscheinlich sind. Dabei erhält nicht jeder einzelne Satz der Trainingsdaten ein explizites Etikett mit der Bedeutung „dies ist wahr“ oder „dies ist falsch“.

OpenAI beschreibt in einer 2025 veröffentlichten Analyse einen Teil des Halluzinationsproblems aus genau dieser Perspektive: Vorhersagbare sprachliche Strukturen lassen sich aus vielen Beispielen gut lernen, während seltene oder weitgehend arbiträre Fakten nicht zwangsläufig ein ausreichend stabiles Muster bieten, aus dem ihre konkrete Ausprägung zuverlässig rekonstruiert werden kann. Zusätzlich können verbreitete Evaluationsverfahren Raten attraktiver machen als Unsicherheit, wenn eine falsche Antwort weniger kostet als eine Enthaltung.

Das bedeutet nicht, dass ein LLM Fakten lediglich zufällig errät. Moderne Modelle besitzen enorme Mengen nutzbaren Wissens und können viele Zusammenhänge erstaunlich präzise wiedergeben. Entscheidend ist etwas anderes: Wenn die belastbare Information an einer bestimmten Stelle fehlt, verschwindet die Fähigkeit zur plausiblen Textgenerierung nicht automatisch mit ihr.

Eine Wissenslücke muss im Output nicht wie eine Wissenslücke aussehen.

Das Modell kann also sehr viel über ein Thema wissen und trotzdem genau die Information nicht ausreichend repräsentieren, die für die konkrete Aufgabe entscheidend wäre.

Fehlende oder veraltete Information

Das wird besonders sichtbar, wenn Wissen schnell altert.

Frameworks bekommen neue APIs. Bibliotheken ändern Verhalten. Standards entwickeln sich weiter. Cloud-Dienste ersetzen Produkte. Interne Unternehmenssysteme tauchen überhaupt nicht in öffentlichen Trainingsdaten auf.

Ein Modell kann beispielsweise wissen, wie Angular-Komponenten aufgebaut sind, wie Dependency Injection funktioniert, welche Rollen RxJS und Change Detection spielen und welche Coding Patterns über viele Jahre üblich waren. Trotzdem kann sein Wissen über eine gerade veröffentlichte API unvollständig sein.

Dann entsteht eine interessante Situation: Das Modell besitzt genügend Kontext, um eine Antwort zu erzeugen, die nach Angular aussieht. Es besitzt vielleicht auch genügend Informationen, um Namen und Grundidee der neuen API korrekt zu verwenden. Aber es kennt noch nicht genügend Details, um die einzelnen Teile technisch korrekt zusammenzusetzen.

Das Resultat kann syntaktisch überzeugend und konzeptionell plausibel wirken – und trotzdem nicht funktionieren.

Dasselbe kann bei seltenen Bibliotheken, proprietären APIs, Spezialwissen oder sehr neuen Standards passieren.

Viel Wissen schützt nicht davor, an der entscheidenden Stelle zu wenig Wissen zu besitzen.

Falscher oder unvollständiger Context

Nicht jede falsche Antwort entsteht aus einer Wissenslücke des Modells.

Ein Agent kann ein sehr leistungsfähiges Modell verwenden und trotzdem auf schlechter Evidenz arbeiten.

Vielleicht findet die Repository-Suche eine veraltete Implementierung. Vielleicht beschreibt eine alte Dokumentationsseite ein inzwischen abgelöstes Konzept. Vielleicht fehlen entscheidende Requirements. Vielleicht widersprechen sich zwei Agent Files. Vielleicht liefert ein Tool einen Fehler, den der Agent falsch interpretiert. Vielleicht enthält ein Memory eine Entscheidung, die für die aktuelle Version des Systems nicht mehr gilt.

In solchen Fällen wäre es unpräzise, pauschal von einer Halluzination zu sprechen.

Die relevante Information kann also sogar im Context vorhanden sein und trotzdem falsch gewichtet, falsch kombiniert oder gegenüber weniger relevanter Evidenz zurückgestellt werden.

Das ist eher eine Fehlinterpretation vorhandener Evidenz.

Die Unterscheidung ist praktisch wichtig. Gegen fehlendes Wissen hilft möglicherweise aktuelle Dokumentation oder Search. Gegen schlechte Evidenz hilft dagegen nicht automatisch mehr Context. Mehr veraltete Dokumentation macht eine falsche Schlussfolgerung nicht richtiger.

Falsche Schlussfolgerungen

Es gibt noch eine dritte Variante.

Das Modell kann die relevanten Fakten korrekt besitzen und dennoch eine falsche Schlussfolgerung ziehen.

Eine Transaktion kann beispielsweise an zwei Stellen korrekt erkannt werden, während die daraus abgeleitete Aussage über Atomarität trotzdem falsch ist. Zwei APIs können korrekt beschrieben sein, aber ihre Kombination ist in der verwendeten Lifecycle-Situation ungültig. Ein Security-Mechanismus kann richtig erklärt werden und dennoch an der falschen Trust Boundary eingesetzt werden.

Wir sollten deshalb mindestens vier Fehlerklassen auseinanderhalten:

• fehlendes oder veraltetes Wissen,
• tatsächlich erfundene beziehungsweise unbelegte Information,
• Fehlinterpretation vorhandener Evidenz,
• Fehler im Reasoning oder in der Ableitung.

Im Alltag können sich diese Kategorien überschneiden. Für die Verifikation macht es trotzdem einen Unterschied, womit wir es zu tun haben.

Wissenslücke und sprachliche Unsicherheit sind nicht dasselbe

Menschen besitzen ebenfalls keine perfekte Selbstkalibrierung. Wir überschätzen unser Wissen, erinnern uns falsch oder beantworten Fragen sicherer, als es unsere tatsächliche Evidenz rechtfertigt.

Bei einem Sprachmodell kommt jedoch eine zusätzliche Schwierigkeit hinzu: Aus dem Ton einer Antwort lässt sich nicht zuverlässig ableiten, wie stark die zugrunde liegende Evidenz ist.

Ein Modell besitzt nicht automatisch eine perfekte interne Anzeige:

weiß ich sicher
weiß ich teilweise
weiß ich nicht

Es gibt durchaus Forschung, die zeigt, dass Modelle Informationen über die Wahrscheinlichkeit ihrer eigenen Korrektheit besitzen können. Anthropic untersuchte bereits 2022, ob Modelle die Wahrscheinlichkeit korrekter eigener Aussagen einschätzen können. Die Ergebnisse zeigten bei geeigneten Aufgaben und Formaten durchaus brauchbare Kalibrierung, aber auch Probleme bei der Generalisierung auf neue Aufgaben.

Das ist ein wichtiger Unterschied: Die Aussage „Modelle sind nie in der Lage, ihre Unsicherheit einzuschätzen“ wäre ebenso falsch wie die Annahme, sprachlich geäußerte Sicherheit sei automatisch gut kalibriert.

Aktuellere Arbeiten untersuchen deshalb explizit, ob Formulierungen wie „wahrscheinlich“, „ich bin mir nicht sicher“ oder sehr selbstbewusste Antworten tatsächlich zur internen Unsicherheit eines Modells passen. Die EMNLP-Arbeit MetaFaith von 2025 zeigt für die untersuchten Modelle und Verfahren, dass diese sprachliche Kalibrierung ohne gezielte Maßnahmen weiterhin deutlich unzuverlässig sein kann.

Wissenslücke und sprachliche Unsicherheit sind bei einem LLM nicht dasselbe.

Gerade deshalb ist Abstention – also die Fähigkeit, bei unzureichender Evidenz keine konkrete Behauptung aufzustellen – inzwischen ein eigenes Optimierungsziel.

Ein interessantes Beispiel liefert OpenAI mit SimpleQA. In einer Auswertung erreichte gpt-5-thinking-mini ohne Webzugriff 22 Prozent Accuracy und eine Halluzinationsrate von 26 Prozent. o4-mini lag bei sehr ähnlichen 24 Prozent Accuracy, aber bei 75 Prozent Halluzinationsrate. Der entscheidende Unterschied war, dass das neuere Modell wesentlich häufiger auf eine konkrete Antwort verzichtete: 52 Prozent Abstention gegenüber einem Prozent. Die Zahlen sagen nicht, dass eines dieser Modelle generell eine bestimmte Halluzinationsrate besitzt. SimpleQA ist ein gezielt schwieriger Benchmark für kurze Faktenfragen. Sie zeigen aber sehr schön, dass mehr Antworten und bessere Antworten nicht dasselbe Ziel sind.

2023 und heute sind nicht dieselbe Welt

Wer LLMs seit den frühen ChatGPT-Jahren intensiv verwendet, kann leicht zwei gegensätzliche Fehler machen.

Der erste wäre, Erfahrungen aus 2023 unverändert auf heutige Modelle zu übertragen. Der zweite wäre, die enorme Verbesserung der Modelle mit einer vollständigen Lösung des Problems zu verwechseln.

Beides wird der Entwicklung nicht gerecht.

Frühe Factuality-Benchmarks machen deutlich, warum Halluzinationen damals so schnell zu einem dominierenden Thema wurden. Im 2023 veröffentlichten HaluEval-Benchmark berichteten die Autoren beispielsweise, dass ChatGPT bei ungefähr 19,5 Prozent der untersuchten Nutzerfragen in ihren spezifischen Testkategorien nicht verifizierbare Informationen erzeugte. Das ist keine allgemeine Halluzinationsrate für ChatGPT im Jahr 2023, sondern ein Ergebnis unter der Methodik dieses Benchmarks.

FActScore untersuchte im selben Jahr einen völlig anderen Fall: längere generierte Biografien wurden in atomare Fakten zerlegt und anschließend geprüft, welcher Anteil durch verlässliche Quellen gestützt wurde. Für ChatGPT berichteten die Autoren in ihrer menschlichen Evaluation einen FActScore von 58 Prozent. Auch diese Zahl beschreibt ausschließlich diese konkrete Aufgabe und darf nicht mit den 19,5 Prozent aus HaluEval verrechnet oder direkt verglichen werden.

Schon TruthfulQA hatte zuvor gezeigt, wie schwierig selbst scheinbar einfache Wahrheitstreue sein konnte: Beim ursprünglichen Benchmark lag das beste untersuchte Modell bei 58 Prozent wahrheitsgemäßen Antworten gegenüber 94 Prozent bei Menschen. TruthfulQA wurde allerdings bereits 2021 vorgestellt und testete ältere Modellgenerationen und gezielt Fragen, bei denen verbreitete Fehlannahmen eine Rolle spielen. Die Zahl ist daher eher historischer Kontext als Vergleichswert für heutige Systeme.

Auf der anderen Seite zeigen neuere Messungen eine andere Qualitätsklasse.

Im GPT-5-System-Card wurden offene Faktenfragen aus LongFact und FActScore mit und ohne Browsing untersucht. Mit Browsing lag gpt-5-thinking in der dort verwendeten claim-level Metrik bei 0,7 Prozent Halluzinationsrate für LongFact Concepts, 0,8 Prozent für LongFact Objects und 1,0 Prozent für FActScore. OpenAI o3 lag in derselben Auswertung bei 4,5, 5,1 und 5,7 Prozent. Ohne Browsing stieg der FActScore-Wert für gpt-5-thinking auf 3,7 Prozent. Diese Zahlen gelten nur für OpenAIs konkrete Evaluation und Grading-Pipeline, zeigen aber zwei wichtige Entwicklungen gleichzeitig: bessere Modelle reduzieren Fehler deutlich, und externe Evidenz wie Search kann die Faktentreue zusätzlich verbessern.

Die Entwicklung ging danach weiter. Im August-Update zu GPT-5.6 berichtet OpenAI für drei bewusst schwierige Factuality-Sets – factuality-lastige Produktionsprompts, früher von Nutzern markierte Fehlerfälle sowie High-Stakes-Prompts aus Medizin, Recht und Finanzen – gegenüber GPT-5.5 Instant weitere deutliche Verbesserungen. Für GPT-5.6 Sol werden dort über die drei Sets hinweg ungefähr 60 Prozent niedrigere faktische Fehlerraten angegeben. OpenAI betont ausdrücklich, dass diese Benchmarks schwierige, halluzinationsanfällige Fälle auswählen und keine durchschnittliche Fehlerquote des normalen ChatGPT-Traffics darstellen.

Anthropic kommt aus einer anderen Evaluationsrichtung zu einem ähnlichen Bild. Im System Card von Claude Opus 4.8 werden mehrere Closed-Book-Factuality-Benchmarks betrachtet, bei denen das Modell keine Websuche oder andere Tools verwenden durfte. Opus 4.8 hatte unter den sechs dort verglichenen Modellen auf allen vier Benchmarks die niedrigste Incorrect-Rate. Ein wesentlicher Teil des Fortschritts kam dabei nicht nur durch mehr richtige Antworten zustande, sondern durch häufigeres Abstain bei Unsicherheit. Beim Net Score (Correct minus Incorrect) waren die Unterschiede gegenüber Opus 4.7 dagegen nicht statistisch signifikant. Anthropic betont zugleich, dass Factual Hallucinations ohne externe Tools weiterhin nicht als gelöst betrachtet werden.

Diese Benchmarks messen unterschiedliche Dinge. Ihre absoluten Werte sind nicht direkt vergleichbar; eine gemeinsame Kurve mit einer vermeintlichen globalen „Halluzinationsrate von KI“ wäre deshalb methodisch falsch.

Was sie gemeinsam zeigen, ist die Richtung.

Moderne Modelle sind bei Faktentreue erheblich besser als frühe Chat-Modelle. Besser ist aber nicht dasselbe wie gelöst.

Meine Angular-Erfahrung aus der frühen LLM-Nutzung

Ich erinnere mich bei diesem Thema besonders an meine frühe Nutzung von LLMs für Angular.

Angular kannten die Modelle grundsätzlich erstaunlich gut. Komponenten, Services, Dependency Injection, RxJS, klassische Change-Detection-Patterns – in diesen Bereichen konnten bereits die damaligen Modelle sehr hilfreichen Code erzeugen.

Dann kamen Signals.

Angular 16 führte 2023 das neue Reaktivitätsmodell mit Signals zunächst als Developer Preview ein. Die API und die darum entstehenden Patterns waren also tatsächlich sehr frisch.

Meine persönliche Wahrnehmung damals war, dass die Modelle beim aktuellen Angular-Stand teilweise deutlich hinter dem lagen, womit ich gerade praktisch arbeitete. Das ist keine wissenschaftliche Messung und auch keine Aussage, dass jedes damalige Modell exakt eine bestimmte Anzahl von Jahren „hinterher“ gewesen wäre.

Interessant war vielmehr das Verhalten: Das Modell wusste sehr viel über Angular – nur genau an der entscheidenden Stelle nicht genug.

Ich verlangte moderne Signals. Das Modell kannte den Begriff, erkannte das Ziel und kombinierte ihn mit etablierten Angular-Patterns. Das Ergebnis sah nach Angular und sogar nach Signals aus. Trotzdem existierten einzelne APIs so nicht, Konzepte wurden miteinander vermischt oder Patterns aus der RxJS-Welt auf eine Weise übertragen, die mit der neuen API technisch nicht funktionieren konnte.

Gerade weil so viele andere Teile korrekt waren, musste man Angular selbst gut genug kennen, um den Fehler zu bemerken.

Heute ist meine Erfahrung eine völlig andere. Aktuelle Modelle kennen wesentlich neuere Framework-Stände. Agents können Repository-Code durchsuchen, aktuelle Dokumentation laden, APIs nachschlagen und ihre Implementierung anschließend gegen TypeScript, Angular Compiler und Tests laufen lassen.

Der zugrunde liegende Mechanismus ist damit nicht verschwunden. Die Möglichkeiten, eine falsche Annahme zu vermeiden oder rechtzeitig zu entdecken, sind aber erheblich besser geworden.

Heute ist es eine andere Qualitätsklasse

Ein moderner Coding Agent ist nicht nur ein Sprachmodell, dem wir einen großen Prompt geben.

Je nach System kann er Repository Search, Dokumentation, Web Search, Compiler, Type-System, Test Runner, Linter, Evals und weitere spezialisierte Tools in seinen Arbeitsprozess einbeziehen. Dadurch kann fehlendes oder unsicheres Wissen heute wesentlich häufiger gegen externe Evidenz geprüft werden.

Das verändert die Fehlersituation erheblich.

Nehmen wir an, ein Modell erinnert sich nicht sicher an die Signatur einer aktuellen API. Ein reiner Chat muss möglicherweise aus seinem parametrischen Wissen antworten. Ein Agent kann dagegen die installierte Version aus package.json lesen, die Type Definitions durchsuchen, aktuelle Dokumentation abrufen, eine Implementierung erzeugen und anschließend den Compiler fragen.

Aus:

ich glaube, dass die API so funktioniert

wird im Idealfall:

Hypothese
↓
Dokumentation
↓
Repository
↓
Implementierung
↓
Compiler
↓
Tests
↓
Feedback

Deshalb wäre es irreführend, einen modernen Coding Agent lediglich anhand der Halluzinationsprobleme früher Chat-Modelle zu beurteilen.

Werkzeuge verändern das System.

LongFact selbst ist dafür ein interessantes Beispiel. Die dazugehörige SAFE-Methode zerlegt lange Antworten in einzelne Fakten und prüft sie über Suchanfragen gegen externe Evidenz. Die Arbeit zeigt damit nicht nur einen neuen Benchmark, sondern demonstriert auch das grundsätzliche Muster: Generation und Verifikation können technisch getrennte Schritte sein.

Allerdings bleibt eine Einschränkung wichtig.

Tools garantieren keine Wahrheit. Der Agent kann die falsche Dokumentation auswählen. Search Results können veraltet sein. Ein Test kann die falsche Eigenschaft testen. Ein Compiler bestätigt Typkorrektheit, nicht automatisch fachliche Korrektheit. Ein grüner Build sagt nichts darüber aus, ob eine Security Boundary richtig modelliert wurde.

Der Mechanismus ist nicht verschwunden, aber die Wahrscheinlichkeit und die Möglichkeiten zur Korrektur haben sich massiv verändert.

Warum Fachwissen weiterhin wertvoll ist

An diesem Punkt entsteht häufig eine merkwürdige Diskussion.

Wenn Modelle immer mehr Code erzeugen können, wozu brauchen wir dann noch Menschen mit jahrzehntelanger Erfahrung?

Die Frage reduziert Softwareentwicklung auf Codeproduktion.

Ein erfahrener Entwickler ist nicht einfach jemand, der dieselbe Methode schneller tippt. Gerade mit Coding Agents wird eine andere Fähigkeit sichtbarer: beurteilen zu können, ob eine plausible Lösung tatsächlich zum Problem und zum System passt.

Ein erfahrener Entwickler erkennt möglicherweise, dass eine verwendete API in genau dieser Framework-Version noch nicht existiert. Er sieht, dass ein angeblicher Security Fix die falsche Trust Boundary absichert. Er erkennt, dass zwei einzeln korrekte Datenbankoperationen gemeinsam keine atomare Operation bilden. Er bemerkt eine Race Condition, obwohl jeder lokale Codeabschnitt vernünftig aussieht. Er sieht, dass eine neue Abhängigkeit eine Architekturgrenze verletzt oder dass eine lokal elegante Lösung langfristig nicht in das System passt.

Das sind keine Fragen von Tippgeschwindigkeit.

Sie verlangen ein mentales Modell des Systems und des Fachgebiets.

Je weniger ich über ein Fachgebiet weiß, desto schwieriger ist es für mich, eine überzeugende Halluzination von einer überzeugenden richtigen Antwort zu unterscheiden.

Das bedeutet nicht, dass Menschen jede Antwort selbst hätten erzeugen können müssen. Ich muss nicht jedes Detail einer Library auswendig kennen. Aber ich brauche genug Verständnis, um zu wissen, welche Aussagen kritisch sind, welche Annahmen verifiziert werden müssen und welches Werkzeug überhaupt eine belastbare Antwort liefern kann.

Expertise wird nicht wertvoll, weil Menschen schneller generieren. Expertise wird wertvoll, weil sie bessere Urteile ermöglicht.

Das ist kein Argument gegen Junior Developers

Aus dieser Beobachtung folgt ausdrücklich nicht, dass nur Senior Developers mit Coding Agents arbeiten sollten.

Erfahrung entsteht schließlich nicht dadurch, dass wir Menschen von schwierigen Aufgaben fernhalten.

Coding Agents können sogar ein hervorragendes Lernwerkzeug sein. Sie können unbekannten Code erklären, Alternativen zeigen, Tests erzeugen, Rückfragen beantworten und die Konsequenzen verschiedener Designs diskutieren.

Problematisch wird es eher dann, wenn Generation den eigenen Denkprozess vollständig ersetzt.

Wer eine Lösung lediglich übernimmt, weil Tests grün sind und der Code professionell aussieht, lernt weniger darüber, warum diese Lösung funktioniert. Fehlt dieses Verständnis dauerhaft, fehlt später möglicherweise genau das Urteilsvermögen, das benötigt wird, um eine plausible falsche Lösung zu erkennen.

Das ist ein Argument für Mentoring, Reviews und bewusstes Lernen – nicht gegen Junior Developers. Erfahrung entsteht nicht über Nacht; sie muss weiterhin entstehen dürfen.

Vom Chat zum Agenten: Der Fehler wird handlungswirksam

Bis hierhin könnten wir Halluzinationen noch weitgehend wie ein klassisches Chatproblem betrachten.

Eine falsche Antwort erscheint im Text. Ein Mensch liest sie, überprüft sie oder verwirft sie.

Coding Agents verändern diese Situation.

Artikel 5 dieser Serie hat den Lösungsweg eines Agents als Sequenz aus Entscheidungen, Aktionen, Beobachtungen und verändertem Context beschrieben. Genau dadurch kann eine falsche Annahme eine neue Qualität bekommen.

falsche Annahme
↓
plausible Entscheidung
↓
Codeänderung
↓
Repository State
↓
zukünftiger Context

Angenommen, ein Agent interpretiert eine Architekturregel falsch.

Er erzeugt daraufhin eine neue Abhängigkeit zwischen zwei Modulen. Der Code kompiliert. Die Tests bleiben grün. Vielleicht löst die Änderung sogar das aktuelle Ticket.

Damit ist die falsche Annahme nicht mehr nur Text.

Sie hat das Repository verändert.

Beim nächsten Task sieht derselbe oder ein anderer Agent diese Abhängigkeit. Für ihn ist sie zunächst vorhandener Code – also lokale Evidenz dafür, wie dieses System offenbar aufgebaut ist.

Das ist der Punkt, an dem aus einer einzelnen Abweichung möglicherweise etwas Langfristigeres entstehen kann.

Nicht jede falsche Annahme führt dorthin. Compiler, Type-System, Tests, Reviews, Architekturregeln oder ein aufmerksamer Entwickler können den Fehler unmittelbar stoppen.

Wenn das nicht geschieht, verändert die Aktion jedoch den Context der nächsten Entscheidung.

Wie aus einer Abweichung Drift werden kann

Der wichtige Punkt liegt in der Rückkopplung.

Der Agent erzeugt nicht nur Output auf Basis eines Contexts. Mit seinen Aktionen verändert er genau die Umgebung, aus der späterer Context wieder gewonnen wird.

Agent Decision
      ↓
Repository State
      ↓
Context
      ↓
Agent Decision

Das ist kein mystischer „AI Drift“. Es ist ein Feedback-Loop zwischen Entscheidungen und der Umgebung, die durch diese Entscheidungen selbst verändert wird.

Gerade deshalb sind frühe Abweichungen interessant. Eine einzelne zusätzliche Abhängigkeit mag unproblematisch erscheinen. Zehn weitere Änderungen, die sich an ihr orientieren, können daraus jedoch eine neue Struktur machen.

Broken Windows und lokale Evidenz

Repository-Code besitzt für einen Coding Agent eine besondere Bedeutung.

Der Agent kennt zunächst nicht die Geschichte hinter jeder Zeile.

Er weiß nicht automatisch, dass eine bestimmte Klasse vor vier Jahren unter Zeitdruck entstanden ist. Er sieht nicht, dass ein merkwürdiger Zugriff nur deshalb existiert, weil eine Migration damals in zwei Schritten erfolgen musste. Er kennt nicht zwangsläufig das Review, in dem jemand ausdrücklich schrieb: „Bitte nicht als Pattern übernehmen.“

Er sieht zunächst Code.

Damit kann aus einem einmaligen Workaround lokale Evidenz werden:

einmaliger Workaround
↓
wird committed
↓
existierender Repository-Code
↓
später als Pattern interpretiert
↓
erneut reproduziert
↓
Pattern wirkt zunehmend etabliert

Das Phänomen existiert selbstverständlich auch ohne AI. Entwickler kopieren bestehenden Code seit Jahrzehnten. Legacy-Systeme wachsen häufig gerade deshalb so konsistent in die falsche Richtung, weil eine einmal getroffene lokale Entscheidung immer wieder als Vorlage dient.

Agents verändern vor allem die Geschwindigkeit und Skalierung dieses Mechanismus.

AI macht schlechte Architektur nicht erst möglich. Sie kann aber dafür sorgen, dass schlechte Architektur sehr viel schneller konsistent wird.

Die gute Nachricht ist: Derselbe Verstärkungseffekt funktioniert in die andere Richtung.

Wenn eine Codebase klare Grenzen besitzt, konsistente Patterns verwendet, Beispiele gepflegt sind und Architekturregeln maschinell überprüft werden, findet ein Agent ebenfalls diese lokale Evidenz.

Dann entsteht:

gutes Pattern
↓
existierender Repository-Code
↓
lokale Evidenz
↓
Reproduktion
↓
mehr Konsistenz

Coding Agents verstärken also nicht grundsätzlich schlechte Architektur. Sie verstärken zunächst die Signale, die ihnen Repository, Dokumentation, Tests und Regeln als lokale Evidenz anbieten.

Die interessante Architekturfrage lautet deshalb zunehmend, welche Signale wir ihnen geben.

Halluzination, Fehlinterpretation und Drift sind nicht dasselbe

Gerade an dieser Stelle lohnt sich eine saubere Begriffstrennung.

Eine Halluzination ist für diesen Artikel eine falsche oder unbelegte Aussage beziehungsweise Annahme. Das Modell behauptet beispielsweise, eine API existiere, obwohl sie nicht existiert.

Eine Fehlinterpretation entsteht, wenn vorhandene Informationen falsch gewichtet oder zusammengesetzt werden. Die Dokumentation ist vorhanden, aber der Agent überträgt eine Regel aus Version 18 auf Version 21 oder hält einen Legacy-Workaround für die aktuelle Architekturvorgabe.

Drift beschreibt dagegen einen Prozess über mehrere Schritte. Ein Lösungsweg oder die entstehende Architektur bewegt sich zunehmend von der ursprünglich gewünschten Richtung weg.

Eine Halluzination kann Drift auslösen.

Sie muss es aber nicht.

Halluzination
↓
Compilerfehler
↓
Korrektur

Hier gibt es keinen relevanten Drift.

Umgekehrt kann Drift sogar vollständig ohne klassische Halluzination entstehen.

Eine lokale Entscheidung kann für sich genommen legitim sein. Sie wird später mehrfach reproduziert. Dadurch verändert sie die Struktur der Codebase. Andere Änderungen orientieren sich daran. Aus einer Ausnahme wird eine Konvention, obwohl niemand jemals eine falsche Tatsache erfunden hat.

Drift ist deshalb weniger ein einzelner Modellfehler als ein Feedbackmechanismus.

Artikel 5 hat gezeigt, dass Ergebnisvarianz zunächst unterschiedliche plausible Lösungswege bedeutet. Sie ist für sich genommen noch kein Drift. Arbeitet ein Agent jedoch auf einer plausiblen Fehlannahme weiter und leitet daraus weitere Entscheidungen ab, können sich Abweichungen über eine längere Handlungskette verstärken. Je länger und autonomer diese Kette wird, desto wichtiger werden explizite Grenzen, überprüfbare Zwischenergebnisse und Rückkopplung.

Sicherheitsrelevante Fragen brauchen mehr als Plausibilität

Bei einem normalen UI-Refactoring ist eine falsche Annahme ärgerlich.

Bei sicherheitskritischen Entscheidungen reicht „sieht plausibel aus“ grundsätzlich nicht.

Ein Agent, der nur begrenztes Wissen über eine konkrete Sicherheitsfrage besitzt, muss deshalb nicht zwangsläufig blind antworten. Ein gut konstruiertes Agent-System kann zusätzliche Dokumentation laden, interne Policies durchsuchen, Tools verwenden, konkrete Fakten verifizieren, Rückfragen stellen oder bei unzureichender Evidenz die Aktion verweigern beziehungsweise an einen Menschen eskalieren.

Die entscheidende Formulierung lautet allerdings: ein gut konstruiertes Agent-System kann das.

Das sind Eigenschaften des Gesamtsystems, seiner Tools, seiner Trainingsziele und seiner Guardrails. Sie folgen nicht automatisch daraus, dass irgendwo ein leistungsfähiges LLM verwendet wird.

Selbst Abstention ist dabei kein triviales Problem: Ein System muss nicht nur Informationen finden, sondern auch erkennen, wann die vorhandene Evidenz für eine belastbare Antwort nicht ausreicht.

Deshalb gilt besonders in risikoreichen Bereichen:

Bei sicherheitskritischen Entscheidungen darf sprachliche Plausibilität nie der einzige Qualitätsnachweis sein.

Wir brauchen Evidenz, technische Checks und gegebenenfalls einen qualifizierten Menschen.

Generation und Verifikation sind unterschiedliche Aufgaben

Coding Agents senken die Kosten zusätzlicher Generation erheblich. Eine weitere Implementierungsvariante, ein zusätzlicher Test oder eine alternative Hypothese lässt sich heute oft mit deutlich weniger Aufwand erzeugen als manuell.

Dadurch verschiebt sich ein Teil der Arbeit.

Die Frage ist nicht mehr ausschließlich:

Wie erzeugen wir eine Lösung?

Immer häufiger lautet sie:

Wie wissen wir, dass diese Lösung akzeptabel ist?

Ein Compiler verifiziert eine bestimmte Klasse von Eigenschaften. Ein Type-System eine andere. Tests prüfen wiederum nur das, was tatsächlich spezifiziert und implementiert wurde. Architekturtests können Abhängigkeitsregeln absichern. Security-Scanner finden bestimmte bekannte Problemklassen. Reviews bringen zusätzliches Fachwissen hinein.

Keines dieser Werkzeuge ist allein ein Wahrheitsautomat.

Gemeinsam können sie aber den Raum plausibler und gleichzeitig falscher Lösungen erheblich verkleinern.

Die Kosten der Generation können sinken, während die Bedeutung der Verifikation steigt.

Dieses Verhältnis wird uns später in der Serie noch ausführlicher beschäftigen. Für den Moment genügt eine Beobachtung: Wenn ein System sehr schnell viele plausible Lösungen produzieren kann, wird die Fähigkeit, zwischen ihnen zu unterscheiden, nicht weniger wichtig.

Sie wird wichtiger.

Plausibilität reicht nicht

Halluzinationen gehören zu den auffälligsten Schwächen früher LLM-Systeme. Wer die Entwicklung seit 2023 verfolgt hat, sollte allerdings ebenso anerkennen, wie stark sich ihre praktische Bedeutung verändert hat.

Modelle sind faktenstärker geworden. Abstention wird expliziter trainiert. Context wird besser genutzt. Search und Retrieval liefern aktuelle Informationen. Coding Agents können Compiler, Type-System und Tests als externe Feedbackkanäle verwenden. Aktuelle System Cards zeigen gegenüber ihren jeweiligen Vorgängern weitere Verbesserungen bei Factuality.

Wir können von diesem Fortschritt beeindruckt sein, ohne das Problem kleinzureden. Die grundlegende Herausforderung bleibt: Ein Modell kann sehr viel wissen und trotzdem genau die entscheidende Information nicht besitzen. Eine Antwort kann ausgezeichnet formuliert sein und dennoch auf schwacher Evidenz beruhen. Eine lokal plausible Agentenentscheidung kann das Repository verändern, dadurch zur Evidenz für spätere Entscheidungen werden und aus einzelnen akzeptierten Abweichungen langfristig Drift entstehen lassen.

Plausibilität ist kein Wahrheitskriterium.

Artikel 5 hat gezeigt, dass der Lösungsweg eines Agents nicht deterministisch ist.

Artikel 6 ergänzt:

Ein plausibler Lösungsweg kann auf einer falschen Annahme beruhen.

Die Antwort darauf kann nicht darin bestehen, jede einzelne Entscheidung eines Agents im Voraus festzulegen. Dann bräuchten wir den Agenten nicht.

Wir müssen stattdessen besser beschreiben, welche Lösungen überhaupt akzeptabel sind, welche Eigenschaften unverhandelbar bleiben und welche Signale einen falschen Weg früh sichtbar machen.

Damit beginnen wir im nächsten Artikel.

Die erste dieser Grenzen sind Requirements.

---

Quellen und Einordnung

OpenAI – Why Language Models Hallucinate, 2025. Die Arbeit untersucht statistische Ursachen von Halluzinationen sowie den Einfluss von Evaluationsmechanismen, die Raten gegenüber Abstention begünstigen können. Sie ist besonders für die Erklärung relevant, warum eine Wissenslücke nicht automatisch als Unsicherheit im Output erscheint. Why Language Models Hallucinate – OpenAI

Li et al. – HaluEval, EMNLP 2023. HaluEval untersucht die Erzeugung und Erkennung halluzinierter Inhalte. Die im Artikel genannten ungefähr 19,5 Prozent beziehen sich auf die spezifische Untersuchung von ChatGPT-Antworten innerhalb des Benchmarks und sind keine allgemeine Produkt-Halluzinationsrate. HaluEval – ACL Anthology

Min et al. – FActScore, EMNLP 2023. FActScore zerlegt lange Antworten in atomare Fakten und misst den Anteil, der durch eine zuverlässige Wissensquelle gestützt wird. Die genannten 58 Prozent für ChatGPT stammen aus der menschlichen Evaluation generierter Personenbiografien. FActScore – ACL Anthology

Lin, Hilton, Evans – TruthfulQA. Der Benchmark untersucht gezielt Fragen, bei denen verbreitete menschliche Fehlannahmen eine falsche Antwort begünstigen können. Die historischen Resultate eignen sich als Kontext für frühe Truthfulness-Probleme, nicht als direkte Vergleichsmetrik für aktuelle Modelle. TruthfulQA – OpenAI

Wei et al. – Long-form factuality in large language models / LongFact & SAFE, 2024. LongFact misst Faktentreue bei offenen Langformantworten. SAFE zerlegt Antworten in Fakten und prüft sie mit Search-Unterstützung. Die Arbeit ist insbesondere für die Trennung zwischen Generation und externer Verifikation relevant. Long-form factuality – Google DeepMind

OpenAI – GPT-5 System Card, 2025. Die genannten LongFact-, FActScore- und SimpleQA-Werte stammen aus den spezifischen Evaluationen dieses System Cards. OpenAI verwendet unterschiedliche Settings mit beziehungsweise ohne Browsing sowie eigene Grading-Verfahren; die Werte dürfen deshalb nicht als allgemeine Halluzinationsraten interpretiert werden. GPT-5 System Card

OpenAI – GPT-5.6 August Update, 2026. Das Update berichtet Factuality-Evaluationen auf bewusst schwierigen Prompt-Sets, darunter factuality-lastige Produktionsprompts, früher von Nutzern markierte Fehlerfälle und High-Stakes-Fragen. Die Werte sind ausdrücklich nicht als durchschnittliche Produktionsfehlerrate zu verstehen. GPT-5.6 August Update

Anthropic – Claude Opus 4.8 System Card, 2026. Anthropic untersucht Factual Hallucinations unter anderem mit vier Closed-Book-Benchmarks und berücksichtigt Correct-, Incorrect- und Abstention-Verhalten. Opus 4.8 erreicht unter den sechs verglichenen Modellen auf allen vier Benchmarks die niedrigste Incorrect-Rate; ein wesentlicher Teil des Ergebnisses entsteht durch häufigeres Abstain bei Unsicherheit. Der Net Score unterscheidet sich nicht statistisch signifikant von Opus 4.7. Claude Opus 4.8 System Card, Abschnitt 6.3.3.1

Kadavath et al. – Language Models (Mostly) Know What They Know, 2022. Die Arbeit untersucht Selbstbewertung und Kalibrierung von Sprachmodellen. Sie zeigt, dass Modelle durchaus Informationen über die Wahrscheinlichkeit eigener Korrektheit besitzen können, diese Fähigkeiten aber vom Aufgabenformat abhängen und nicht perfekt generalisieren. Anthropic Research – Language Models (Mostly) Know What They Know

Liu et al. – MetaFaith, EMNLP 2025. Die Arbeit untersucht, ob natürlichsprachliche Unsicherheitsformulierungen die tatsächliche Modellunsicherheit zuverlässig widerspiegeln, und dokumentiert weiterhin deutliche Kalibrierungsprobleme bei den untersuchten Modellen. MetaFaith – ACL Anthology

Feng et al. – Don’t Hallucinate, Abstain, ACL 2024. Die Arbeit behandelt explizit Wissenslücken und Verfahren, mit denen Modelle bei fehlendem Wissen eher auf eine Antwort verzichten sollen. Don’t Hallucinate, Abstain – ACL Anthology