Der Soll-Ist-Abgleich

Die Zahlen beschreiben ein merkwürdiges Gleichgewicht: In Sonars State-of-Code-Umfrage 2026 sagen 96 % der Entwickler, sie vertrauten KI-generiertem Code nicht voll - aber nur 48 % prüfen ihn immer vor dem Commit, und 53 % berichten von KI-Code, der korrekt aussieht, aber nicht zuverlässig ist. Gleichzeitig stammen laut derselben Umfrage bereits rund 42 % des committeten Codes von KI. Misstrauen ohne Methode wird zu Resignation.

Der Fehlermodus ist spezifisch: KI-Code scheitert selten laut, sondern in der Lücke zwischen dem, was die Anforderung meinte, und dem, was das Modell darunter verstanden hat. Ein Diff-Review kann diese Lücke nicht fangen, denn der Diff zeigt nur, was gebaut wurde - nicht, was beauftragt war. Das fehlende Artefakt ist der schriftliche Auftrag, und jeder Merge ohne ihn zahlt auf die Verification Debt ein.

Der naheliegende Fix - die KI testet und reviewt ihren eigenen Output - hat einen strukturellen Haken: Beide Seiten des Vergleichs entstammen denselben Annahmen. Tests, die das generierende Modell schreibt, prüfen, was das Modell angenommen hat - und das ist subtil etwas anderes als das, was gefordert war. Aktuelle Forschung zu KI-gestütztem Review kommt zum selben Schluss: die Spezifikation ist das Quality Gate, gerade weil sie eine Referenz einführt, die unabhängig vom Modell existiert - ohne sie prüft das Review den Code gegen sich selbst.

Wie groß die Selbstbewertungslücke werden kann, ist dokumentiert: Ein Team hat 449 KI-Code-Reviews nachgemessen - das System bewertete sich selbst mit 98,6 % Validität, die unabhängige Validierung ergab 69 %. Dreißig Punkte zwischen Selbstbild und Realität. Die Konsequenz heißt nicht „kein KI-Review“, sondern: Referenz und Generator trennen.

Tool-agnostisch - funktioniert mit Claude Code, Cursor, Copilot und jedem anderen Agenten:

1. Das Soll vor dem Run aufschreiben. Ein Zielsatz, die Grenzen (welche Dateien und welches Verhalten tabu sind) und 3-7 Akzeptanzkriterien. Fünf Minuten, Klartext.
2. Jedes Kriterium prüfbar machen. „Liefert bei 429-Antworten einen korrekten Retry-After-Header“ ist prüfbar; „verbessert das Rate-Limiting“ nicht. Wer keine Ja/Nein-Frage formulieren kann, schärft das Kriterium nach.
3. Das Tool unverändert laufen lassen. Die Methode stellt nichts zwischen euch und den Agenten - gleiche Prompts, gleiches Tempo.
4. Das Ist gegen das Soll abgleichen. Den Diff Kriterium für Kriterium durchgehen. Änderungen außerhalb des Scopes sind Befunde, auch wenn sie wie Verbesserungen aussehen - im Scope Creep verstecken sich die stillen Regressionen.
5. Das Ergebnis festhalten. Welche Kriterien bestanden, was übersprungen wurde, was offen bleibt - wenige Zeilen, beim Code gespeichert. Genau diese Notiz formalisiert ein Prüfbericht.

Das ganze Artefakt bleibt auf einen Blick lesbar:

SOLL (vor dem Run geschrieben)
Ziel:      Korrekten Retry-After-Header bei 429-Antworten liefern
Grenzen:   nur api/middleware/* · Rate-Limit-Logik unangetastet
Kriterien: [1] Header bei jeder 429        [2] Wert = Rest des Fensters
           [3] 2xx/4xx-Pfade unverändert   [4] Unit-Tests grün

IST (nach dem Run geprüft)
[1] BESTANDEN  [2] BESTANDEN
[3] NICHT BESTANDEN - 403-Handler mitgeändert (außerhalb des Scopes)
[4] BESTANDEN (61 grün, 3 neu - vor dem Run geschrieben)

Ergebnis:  VERWORFEN → neuer Run mit Grenz-Hinweis · [3] erneut prüfen

• Soll-Theater. Ein Soll, gegen das niemand abgleicht, ist Ritual statt Verifikation. Der Abgleich ist der Punkt - das Dokument nur sein Input.
• Überspezifikation. Wer die Implementierung statt der Absicht beschreibt, produziert Vorgaben, die schlecht altern und übersprungen werden. Festhalten, was gelten muss - nicht, wie es zu bauen ist.
• Der Abgleich fängt nicht, was das Soll vergisst. Geprüft wird die formulierte Absicht. Anforderungen, an die niemand gedacht hat, bleiben ungeprüft - deshalb behandelt die Forschung Intent-Formalisierung als offene Grand Challenge, nicht als gelöstes Problem.
• Das Festhalten überspringen. Ein nicht dokumentierter Abgleich verdunstet. Einen Monat später kann niemand einen verifizierten Merge von einem glücklichen unterscheiden.

Alles oben funktioniert manuell - mit einer Textdatei und Disziplin. Reality Graph systematisiert genau diese Methode: Das Soll wird zu einer strukturierten Auftragsdatei mit festgelegten Grenzen, das Ist wird nach dem Run dagegen geprüft, und das Ergebnis landet in einem prüfbaren Bericht - eingebettet in den größeren Verifikations-Loop.