KI als Orakel: Warum Verifizierungskultur wichtiger ist als Prompting

Über KI wird oft als Werkzeug, Assistent, Kollege oder Ersatz gesprochen. Diese Metaphern sind nicht völlig nutzlos, aber sie lenken Ingenieurinnen und Ingenieure oft in die falsche Richtung. Sie verlagern die Aufmerksamkeit auf Delegation, Antwortgeschwindigkeit und den Eindruck von Produktivität statt auf die Prüfung der Ergebnisse.

Ein nützlicheres technisches Denkmodell ist das Orakel.

Der Punkt dieser Analogie ist nicht Mystik. Es geht um operative Disziplin.

Was ein Orakel ist

In der theoretischen Informatik ist ein Orakel eine hypothetische Blackbox, die eine bestimmte Klasse von Fragen beantworten kann, ohne offenzulegen, wie sie zu ihrer Antwort gelangt.

In der Kryptografie wird der Begriff praktischer verwendet, etwa für Dienste wie Verschlüsselungs- oder Entschlüsselungsorakel. Ein Aufrufer kann eine Eingabe senden und die Ausgabe beobachten, während der innere Mechanismus verborgen bleibt.

Ein LLM ist in keinem dieser beiden Sinne buchstäblich ein formales Orakel. Es ist weder Teil eines Beweismodells noch ein klar abgegrenztes kryptografisches Primitive.

Aus technischer Sicht verhält es sich in der Praxis aber oft wie ein Orakel:

• man stellt eine Frage
• man erhält eine plausible Antwort
• die inneren Abläufe bleiben weitgehend undurchsichtig
• die Antwort kann nützlich sein, ohne vertrauenswürdig zu sein

Gerade der letzte Punkt ist entscheidend.

Warum die Orakel-Analogie besser ist

Das Orakel-Modell lenkt den Blick auf die richtigen technischen Fragen.

Das Modell ist intransparent. Selbst wenn wir etwas über Trainingsdaten, Kontextabruf, Werkzeuge oder das umgebende Systemdesign wissen, haben wir in der Regel keine belastbare Erklärung dafür, warum genau diese Antwort erschienen ist.

Die Antworten können wertvoll sein, aber sie sind nicht garantiert korrekt. Sie können unvollständig, übermäßig selbstsicher, kontextabhängig oder subtil falsch sein, und solche Fehler werden oft erst später entdeckt.

Das bedeutet, dass Ausgaben als Hypothesen und nicht als Fakten behandelt werden sollten.

Es bedeutet auch, dass Verifizierung kein nachgelagerter Schritt ist. Sie gehört in den Arbeitsablauf selbst.

Hier liegt der eigentliche kulturelle Wandel. Das Problem ist nicht, dass Ingenieurinnen und Ingenieure bessere Prompt-Techniken brauchen. Das Problem ist, dass vielen Teams noch immer eine starke Verifizierungskultur für KI-gestützte Arbeit fehlt.

Verifizierungskultur statt Prompting-Kultur

Prompting ist wichtig, aber nicht der Kern des Problems.

Eine enge, klar abgegrenzte Frage ist hilfreich, weil sie die Verifizierung erleichtert.

Ein zu breiter Prompt ist gefährlich, weil er zu viel Vertrauen in die Antwort fördert.

Wenn ein Team die Arbeit mit KI vor allem als Prompting-Kunst versteht, optimiert es meist auf:

• sprachliche Glätte
• Geschwindigkeit
• selbstsicheren Ton
• den Eindruck von Vollständigkeit

Wenn ein Team KI dagegen als Orakel nutzt, optimiert es eher auf:

• klare Fragen
• begrenzten Umfang
• explizite Annahmen
• unabhängige Prüfungen
• festgehaltene Begründungen
• wiederholbare Validierung

Die zweite Liste liegt näher an echter technischer Disziplin.

Wie das in der Praxis aussieht

Spezifikationsgetriebene Entwicklung

Spezifikationsgetriebene Entwicklung geht bereits davon aus, dass schnelle Ausgabe nicht mit korrekter Ausgabe gleichzusetzen ist. Eine schriftliche Spezifikation definiert Zweck, Grenzen, Arbeitsabläufe und Abnahmekriterien, bevor generierte Ausgaben als gültige Änderung akzeptiert werden.

Das ist Orakel-Disziplin. Die Antwort muss an einem vorher festgelegten Standard gemessen werden.

KI-gestützte Wissensarbeit

KI-gestützte Wissensarbeit wird verlässlicher, wenn es rund um das Modell dauerhafte Unterlagen, explizite Reviews und nachvollziehbare Standards gibt. Konversation allein ist keine stabile Wahrheitsquelle.

Dokumentations-Governance

Gute Teams trennen Produktspezifikation, Implementierungsleitlinien, öffentliche Dokumentation, Source Maps und erzeugte Artefakte. Diese Trennung ist wichtig, damit nicht eine plausible Antwort stillschweigend zur akzeptierten Wahrheit wird.

Validatoren und Tests

Teams führen Validatoren ein, weil Gedächtnis und Selbstsicherheit schwache Kontrollen sind. Link-Prüfungen, Strukturprüfungen, Paritätsprüfungen, Metadatengenerierung, Tests und Publikationsvalidatoren machen Verifizierung zu Infrastruktur.

Kontext und Begründung bewahren

Eine nützliche Orakel-Antwort reicht für sich allein noch nicht aus. Wenn Arbeit Zeit und Teamwechsel überstehen soll, müssen Annahmen, Belege, Review-Notizen und Gründe für Annahme oder Ablehnung sichtbar bleiben.

Lokalisierung und semantische Parität

Lokalisierung ist ein gutes Beispiel dafür, warum Verifizierung wichtig ist. Eine Übersetzung kann flüssig wirken und trotzdem bei Modalität, Terminologie, Unicode-Korrektheit, Barrierefreiheits-Texten oder semantischer Parität mit der Quelle scheitern. In diesem Ablauf ist KI-Ausgabe keine veröffentlichungsreife Fassung. Sie ist ein Entwurf, der geprüft werden muss.

Konkrete Beispiele

Das Orakel-Modell wird klarer, wenn die Fragen konkret werden.

Wenn man KI bittet, Code zu erklären

Ein LLM kann schnell und schlüssig eine Funktion, einen Datenfluss oder einen Fehler erklären.

Was geprüft werden muss:

• ob die Erklärung dem tatsächlichen Codepfad entspricht
• ob Randfälle ausgelassen wurden
• ob aktuelle und beabsichtigte Logik verwechselt wurden
• ob Spezifikationen, Tests oder Kommentare ignoriert wurden

Nützliche Prüfung:

• den referenzierten Code lesen
• die Antwort mit vorhandenen Tests vergleichen
• prüfen, ob die Erklärung zum dokumentierten Ablauf passt

Wenn man KI bittet, einen Validator zu schreiben

Ein LLM kann einen Validator erzeugen, der sauber und überzeugend aussieht.

Was geprüft werden muss:

• ob der Validator die echte Regel prüft oder nur einen vereinfachten Ersatz
• ob die Regel falsche Sicherheit erzeugt
• ob wichtige Fehlerfälle fehlen
• ob der Validator die dokumentierte Regel korrekt abbildet

Nützliche Prüfung:

• positive und negative Testfälle erstellen
• den Validator gegen bekannte Fehler laufen lassen
• prüfen, ob er tatsächlich die relevante Fehlerklasse schützt

Wenn man KI bittet, Dokumentation zu übersetzen

Ein LLM kann sehr schnell eine glatte Übersetzung liefern.

Was geprüft werden muss:

• semantische Parität mit der Quelle
• terminologische Konsistenz
• Schrift- und Unicode-Korrektheit
• Barrierefreiheits-Texte und Metadaten
• ob Beispiele, weiterführende Links und Begleitmaterial abgestimmt bleiben

Nützliche Prüfung:

• Lokalisierungs- und Paritätsvalidatoren ausführen
• die Abschnittsstruktur von Quelle und Zielsprache vergleichen
• bei wichtigem Material Review durch Muttersprachler einholen

Wenn man KI bittet, Architektur vorzuschlagen

Ein LLM kann eine Schichtenarchitektur, Service-Zerlegung oder ein Integrationsmuster vorschlagen, das vernünftig klingt.

Was geprüft werden muss:

• ob der Vorschlag zum tatsächlichen Produktumfang passt
• ob er nicht verhandelbare Anforderungen respektiert
• ob er unnötige Komplexität einführt
• ob er Infrastruktur, Budgets oder operative Reife voraussetzt, die nicht existieren

Nützliche Prüfung:

• den Vorschlag mit der Produktspezifikation vergleichen
• ihn an Umfangsgrenzen und Abnahmekriterien prüfen
• vor der Übernahme die Trade-offs festhalten

Wie Verifizierung praktisch aussieht

Verifizierung bedeutet nicht immer einen formalen Beweis. In echter technischer Arbeit bedeutet sie meist die Kombination mehrerer schwächerer, aber nützlicher Prüfungen.

• die Antwort mit der Spezifikation vergleichen
• relevante Dateien prüfen
• Tests ausführen
• Validatoren ausführen
• Links und erzeugte Artefakte prüfen
• Review-Notizen und Begründungen bewahren
• eine engere Folgefrage stellen, wenn die erste Antwort zu breit ist

Deshalb skaliert Verifizierungskultur langfristig besser als bloße Prompting-Fertigkeit. Sie schafft wiederverwendbare Kontrollpunkte, die einzelne Gespräche überdauern.

Praktische Schlussfolgerung

• Enge Fragen stellen.
• Annahmen festhalten.
• Behauptungen prüfen.
• Tests und Validatoren verwenden.
• Begründungen bewahren.
• KI-Ausgabe als Beleg behandeln, nicht als Wahrheit.

Fazit

KI ist weder Kollege noch Suchmaschine.

Sie ist eher ein Orakel: eine Blackbox, die erstaunlich schwierige Fragen beantworten kann, sofern man sorgfältig fragt und die Antworten überprüft.

Die Herausforderung KI-gestützter Technik besteht nicht darin, zu lernen, wie man das Orakel benutzt. Sie besteht darin, zu lernen, ihm nicht zu sehr zu vertrauen.

Weiterführende Seiten

• ../../wiki/ai-assisted-knowledge-work.md
• ../../wiki/spec-driven-development.md
• ../../wiki/validation-layers.md
• ../../wiki/documentation-traceability.md
• ../../wiki/localization-governance.md
• ../../wiki/let-books-localization-case-study.md
• ai-workflows-beyond-software.md
• spec-driven-development-for-ai-projects.md
• documentation-is-part-of-the-product.md