KI-Coding-Verifikation

KI-generierter Code ist strukturell Teil der Softwareentwicklung geworden — mit weiter steigendem Anteil. Nicht mitgewachsen ist die Fähigkeit, verlässlich zu sagen, was eine generierte Änderung wirklich tut. Diese Lücke hat einen Namen: Verification Debt.

Verifikation beantwortet eine Frage, für die Code Review allein nie gedacht war: nicht „ist dieser Code gut geschrieben?“, sondern „ist das die Änderung, die wir beauftragt haben, innerhalb der gesetzten Grenzen, mit Nachweis der Prüfung?“

Ein Code Review betrachtet einen fertigen Diff. Verifikation umspannt den ganzen Coding-Run — und das meiste davon passiert außerhalb des Diffs:

• Auftrags-Abgleich: tut die Änderung, was der Auftrag verlangt hat — und nichts anderes?
• Scope-Treue: ist der Run in den vorgegebenen Dateien und Grenzen geblieben, oder hat er „hilfsbereit“ Dinge angefasst, die tabu waren?
• Validierung: liefen Checks, die das generierende Modell nicht selbst geschrieben hat — Tests, Linter, Typprüfung, Build?
• Belege: gibt es einen prüfbaren Nachweis, was validiert wurde, was übersprungen wurde und was offen ist?
• Menschliche Übernahme: trifft ein Mensch — mit diesen Belegen vor Augen — die finale Entscheidung?

Ein praktischer Loop, der mit jedem KI-Coding-Tool funktioniert:

1. Vor dem Run — Auftrag definieren. Ziel, Grenzen (welche Dateien, welches Verhalten unantastbar ist) und den Validierungsplan festhalten: Woran erkennt ihr, dass es funktioniert hat? Fünf Minuten hier sind der wirksamste Schritt im ganzen Loop.
2. Während des Runs — begrenzt halten. Kleine, umrissene Runs schlagen ausufernde. Wächst der Auftrag: aufteilen. Ein Run, der 40 Dateien geändert hat, ist nicht verifizierbar — nur mergebar.
3. Nach dem Run — gegen den Auftrag prüfen. Das Ergebnis gegen den aufgeschriebenen Auftrag diffen, nicht gegen die Erinnerung daran. Off-Scope-Änderungen sind Befunde — auch wenn sie wie Verbesserungen aussehen.
4. Unabhängig validieren. Den Validierungsplan ausführen: bestehende Tests, Typprüfung, Lint, Build — plus gezielte Checks, die das Modell nicht verfasst hat.
5. Belege anhängen. Ein kurzer Nachweis pro Run: Auftrag, Änderungen, Validiertes, nicht Validiertes, offene Fragen. Genau das braucht der Reviewer — und das zukünftige Ich.
6. Menschliches Gate. Ein Mensch übernimmt oder verwirft die Änderung, mit den Belegen im Blick. Kein Auto-Commit.

Mehrere Tool-Kategorien decken Teile dieses Loops ab — die meisten Teams kombinieren sie:

• Cloud-PR-Reviewer kommentieren Pull Requests mit starken Modellen und null Setup — sie decken den Schritt „Diff lesen“ ab, nachdem der Code existiert, als externer Dienst.
• Statische Analyse, Linter, SAST finden bekannte Fehlermuster und Sicherheitsprobleme deterministisch — notwendig, aber blind für den Auftrag: Sie können nicht wissen, was die Änderung tun sollte.
• Tests und CI verifizieren Verhalten — so weit die Tests reichen, und nur, wenn sie nicht vom selben Run generiert wurden, den sie prüfen sollen.
• Verifikationsschichten (die Kategorie von Reality Graph) umschließen den Loop selbst: Auftrag und Grenzen vor dem Run, unabhängige Validierung und Belege danach, ein menschliches Gate am Ende — konzipiert für den lokalen Betrieb, neben den vorhandenen Coding-Tools.

Keine dieser Kategorien ersetzt die anderen. Der Fehler, den es zu vermeiden gilt: nur die nachgelagerten Schritte abzudecken. Wurde der Auftrag nie festgehalten, kann kein Tool später dagegen prüfen.

Reality Graph setzt diesen Verifikations-Loop als lokale Schicht neben Claude Code, Cursor, GitHub Copilot und vergleichbaren Tools um: Auftragsgrenzen und Kontext vor dem Run, sichtbare Validierung und ein prüfbarer Bericht danach, dazwischen ein menschliches Freigabe-Gate. Aktuell in privater Beta — Early Access ist für eine kleine Gruppe von Teams offen.