KI-Coding-Verifikation

KI-generierter Code wird in der Softwareentwicklung eingesetzt, Adoption und Prüftiefe unterscheiden sich jedoch je Team. Für den konkreten Auftrag bleibt die Frage: Was tat diese Änderung, welche Checks beobachteten sie und was bleibt ungewiss? Nicht festgehaltene Verifikationsarbeit trägt zu dem bei, was diese Website Verification Debt nennt.

Diese Umfragewerte wurden am 17. Juli 2026 geprüft und beschreiben die Stichprobe; sie belegen weder universelle Adoption noch Zuverlässigkeit oder Kontrollwirksamkeit. Verifikation beantwortet in diesem Artikel neben Code Review eine auftragsbezogene Frage: nicht nur „ist dieser Code gut geschrieben?“, sondern „ist das die beauftragte Änderung innerhalb der Grenzen, mit Aufzeichnung der Checks und ihrer Grenzen?“

Code Review bewertet eine Änderung mit der Review-Methode des Teams. Verifikation bezeichnet hier einen auftragsbezogenen Loop um den Coding-Run, mit mehreren Checks außerhalb des Diffs:

• Auftrags-Abgleich: tut die Änderung zum expliziten Auftrag? Damit sind nicht alle unausgesprochenen Erwartungen bewiesen.
• 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 ein prüfbares Artefakt, das Checks, beobachtete Ergebnisse, Übersprungenes und offene Punkte festhält? Das Artefakt ist Beleg, kein Korrektheitsbeweis.
• Menschliche Übernahme: übernimmt oder verwirft der benannte technische Entscheidungsinhaber mit diesen Belegen die Änderung? Geschäftliche und rechtliche Freigaben bleiben getrennte Rechte.

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? Der angemessene Detailgrad hängt von Risiko und Scope ab.
2. Während des Runs - begrenzt halten. Kleine, umrissene Runs schlagen ausufernde. Wächst der Auftrag: aufteilen. Große Änderungen können verifiziert werden, erhöhen aber Review- und Belegkosten und können Auftragsgrenzen verdecken.
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 für die relevanten Risiken. Andere Autorschaft kann korrelierte Annahmen verringern, belegt für sich aber keine ausreichende Unabhängigkeit.
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 mit dem zugewiesenen technischen Entscheidungsrecht übernimmt oder verwirft mit Belegen und Grenzen im Blick. Kein Auto-Commit; dieses Gate ist keine geschäftliche, rechtliche, Security- oder Compliance-Freigabe.

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

• Cloud-PR-Reviewer können einen Pull-Request-Diff kommentieren, nachdem der Code existiert. Abdeckung, Datenpfad und Einrichtung hängen von Produkt und Konfiguration ab.
• Statische Analyse, Linter, SAST wenden konfigurierte Regeln und Analysen auf definierte Muster an. Sie erzeugen Belege zu diesen Regeln, können aber einen unausgesprochenen Auftrag im Allgemeinen nicht ableiten oder Fehlerfreiheit beweisen.
• Tests und CI prüfen Verhalten innerhalb ihrer Fixtures, Assertions, Umgebung und Ausführung. Testautorschaft im selben Run kann Annahmen korrelieren; andere Autorschaft allein belegt keine Abdeckung.
• Verifikationsschichten ist hier die redaktionelle Bezeichnung für Workflows, die Auftrag und Grenzen, ausgewählte Validierung, Belege, Einschränkungen und ein menschliches Gate verbinden. Sie behauptet nicht, ein Produkt beweise die ganze Änderung. Reality Graph ist 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. Ohne maßgeblich festgehaltenen Auftrag kann ein späterer Check die Änderung nicht mit diesem aufgezeichneten Auftrag vergleichen.

Reality Graph ist dafür ausgelegt, Auftragsgrenzen und Kontext, Validierungsergebnisse, Einschränkungen und einen prüfbaren Bericht rund um ein menschliches Gate festzuhalten. Diese Artefakte unterstützen technisches Review; sie beweisen weder Korrektheit noch Sicherheit und erteilen keine geschäftliche, rechtliche, Compliance- oder Release-Freigabe. Reality Graph steht neben Coding-Tools, Tests, Analyse, Review und Laufzeitevidenz. Welche sechs Schritte ein einzelner Run durchläuft, vom festgehaltenen Auftrag bis zum aufgezeichneten Ergebnis, steht unter wie das Produkt arbeitet. Aktuell in privater Beta - Early Access ist für eine kleine Gruppe von Teams offen.