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 61 % 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 zum strukturierten Auftrag mit 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.