Das Glossar der KI-Coding-Verifikation

Verification Debt. Die wachsende Lücke zwischen dem Tempo, mit dem KI-Tools Code erzeugen, und der Zuverlässigkeit, mit der ein Team ihn vor dem Merge prüft. Sie akkumuliert lautlos, während Durchsatz-Metriken glänzen, und taucht später als Nacharbeit, Incidents und verlorenes Vertrauen auf – Definition, Daten, Gegenmaßnahmen.

Verification Gap. Der gemessene Abstand zwischen Misstrauen und Sorgfalt: 96 % der Entwickler misstrauen KI-Code, nur 48 % prüfen ihn konsequent (Sonar, 2026). Die Lücke ist Verhalten, nicht Technik – die Checks existieren, sie werden übersprungen.

Review-Engpass. Das Kapazitäts-Missverhältnis, das entsteht, wenn KI Code schneller erzeugt, als Menschen ihn lesen: fast doppelt so viele gemergte PRs bei +91 % Review-Zeit pro PR. Der Engpass der Lieferkette wanderte vom Schreiben zum Prüfen – Mechanik und Zahlen.

Technical Debt. Bewusst oder fahrlässig aufgeschobene Codequalität, die als künftiger Änderungsaufwand Zinsen kostet. Das klassische Geschwister der neueren Debt-Begriffe – verschieden, weil der Code funktioniert und alle wissen, dass abgekürzt wurde.

Comprehension Debt. Die Lücke zwischen dem Code, den ein Team ausliefert, und dem mentalen Modell, das seine Menschen davon halten. Verwurzelt in Naurs Theory-Building-Sicht des Programmierens, beschleunigt durch KI-Generierung – Herkunft und Folgen.

Vibe Coding. Eine KI prompten und das Ergebnis weitgehend ohne Review Zeile für Zeile ausliefern – 2025 von Andrej Karpathy als Beschreibung von Prototyp-Arbeit geprägt. Rational für Wegwerf-Code, teuer als Produktions-Default – die gemessene Rechnung.

Durchwinken (Rubber-Stamping). Änderungen ohne echte Prüfung freigeben – Review als Ritual. Der typische Fehlermodus von Teams, deren Review-Kapazität vom KI-Volumen überholt wurde; die Freigaben fließen weiter, Korrektheit shipped auf Vertrauen.

Code Churn. Der Anteil Code, der kurz nach dem Merge revidiert oder zurückgenommen wird – üblich gemessen im 14-Tage-Fenster. GitClears 211-Millionen-Zeilen-Analyse zeigt Churn Richtung 5,7 % bei wachsender KI-Nutzung – ein vorlaufender Indikator übersprungener Verifikation.

Scope Creep (KI-Runs). Ein Agent ändert mehr, als der Auftrag verlangte – extra Dateien, unbestellte Refactorings, Nebenbei-Fixes. Wohlgeformter Code außerhalb des Mandats besteht jedes Nur-Qualitäts-Review; deshalb gibt es Grenzen und Umfangs-Checks.

KI-Coding-Verifikation. KI-generierte Änderungen gegen expliziten Auftrag, Validierungsplan und Belege prüfen, bevor sie übernommen werden – die Dachmethode dieser Seite, Schritt für Schritt.

Soll-Ist-Abgleich. Eine Änderung gegen einen schriftlichen Auftrag prüfen statt gegen die Erinnerung an den Prompt. Löst die Zirkularität, Code nur anhand von Code zu beurteilen – die fünf Schritte.

Prüfbare Vorgabe (Machine-Checkable Specification). Ein Auftrag, dessen Erfüllung mechanisch prüfbar ist: Ziel, Grenzen, Ja/Nein-Akzeptanzkriterien, Validierungsplan – die vier Bausteine.

Akzeptanzkriterien. Binäre Bedingungen, die eine Änderung erfüllen muss. „Behandelt leere Eingabe mit leerer Liste als Rückgabe“ ist prüfbar; „behandelt Randfälle gut“ nicht.

Auftragsgrenzen. Der deklarierte Radius eines KI-Runs – welche Dateien, Verzeichnisse, Systeme er anfassen darf. Vor dem Run deklariert, danach prüfbar; die mechanische Antwort auf Scope Creep.

Validierungsplan. Die vorab deklarierte Liste der Checks, die über die Übernahme entscheiden – Tests, Typen, Build, Soll-Ist. Vorher deklarieren verhindert, dass validiert wird, was zufällig besteht.

Zwei-Phasen-Review. Eine maschinelle Vorprüfung räumt die mechanische Ebene ab, danach menschliches Review für Architektur und Trade-offs – was in welche Phase gehört.

Spec-Driven Development (SDD). Erst die Spezifikation schreiben, dann Code daraus erzeugen – Tooling wie Spec Kit und Kiro hat das Muster für KI-Agenten populär gemacht. Auch Specs brauchen Verifikation gegen das Ergebnis – ehrliche Einordnung.

Session-Übergabe (Handoff). Stand, Entscheidungen und offene Prüfpunkte in einem Artefakt sichern, wenn eine KI-Session endet und die nächste beginnt – weil Kontextfenster vergessen – Methode und Vorlage.

Generierungs-zu-Prüfungs-Verhältnis. Gemergte KI-Zeilen gegenüber Zeilen mit echter Verifikation – die oberste Verification-Debt-Kennzahl, berechenbar aus Git- und PR-Daten.

Review-Tiefe. Reviewer-Aufmerksamkeit pro geänderter Zeile (Kommentare, Zeit). Fallende Tiefe bei steigendem Volumen ist die messbare Signatur des Durchwinkens.

Quote ungeprüfter Merges. Der Anteil Änderungen, die ohne Validierung ohne Modell-Autorschaft mergen. Der direkteste Debt-Indikator – Formeln und Schwellen.

14-Tage-Churn. Der Anteil gemergten Codes, der binnen 14 Tagen nachgearbeitet wird – billig zu berechnen, schwer zu gamen, die nachlaufende Bestätigung der drei vorlaufenden Kennzahlen.

Prüfbericht (Evidence Report). Ein Nachweis pro Run über Auftrag, Änderungen, Validierung mit Ergebnis, bewusst Übersprungenes und Offenes – gespeichert beim Code – Struktur und Beispiel.

Audit-Trail (KI-Code). Die akkumulierten Nachweise pro Änderung, die beantworten: Wer/was hat gehandelt, auf welchen Auftrag, was änderte sich, was wurde geprüft, wer gab frei. Git allein beantwortet nur die mittlere Frage – die fünf Auditor-Fragen.

Provenance (Herkunft). Wissen, woher eine Änderung stammt – welches Tool, Modell, welche Version, welcher Auftrag. Voraussetzung für Incident-Zuordnung und Lizenz-/Audit-Antworten in KI-gestützten Codebasen.

Menschliches Gate. Der Punkt, an dem ein Mensch die Belege liest und entscheidet, ob eine Änderung in geteilten Zustand geht. Der eine Schritt, den keine Automatisierung ersetzt.

KI-Coding-Richtlinie. Das Team-Dokument, das Tools, Datenregeln, Auftragsregeln, Verifikationspflichten, Belege, Agenten-Rechte, Ausnahmen und Verantwortung festlegt – vollständige Vorlage.

Advisory by default. Eine Agenten-Haltung, in der das Tool vorschlägt und nie unbeaufsichtigt anwendet – die Architektur-Form von „der Mensch entscheidet“.

No Auto-Commit. Die Regel, dass KI-Agenten nie unbeaufsichtigt in geteilten, dauerhaften Zustand schreiben (geschützte Branches, Produktion). Least Privilege auf Agenten angewandt – die Rechte-Leiter.

Least Privilege (Agenten). Einem Agenten nur den Zugriff geben, den sein Auftrag braucht – gescope-te Credentials, keine Produktions-Reichweite. Deterministische Sicherheit, die hält, wenn Instruktionen versagen.

Unabhängige Verifikation. KI-Output mit einer Instanz prüfen, die ihn nicht erzeugt hat – möglichst ein anderes Modell und immer eine andere Referenz (der schriftliche Auftrag, nicht der Diff) – die Unabhängigkeits-Leiter.

Self-Preference-Bias. Die gemessene Neigung von LLM-Evaluatoren, eigene Ausgaben zu erkennen und zu bevorzugen – der Forschungskern dafür, warum Same-Model-Selbstprüfung systematische blinde Flecken hat.

LLM-as-a-Judge. Ein Sprachmodell als Bewerter von Outputs einsetzen (auch von Code anderer Modelle). Nützlich und skalierbar, mit bekannten Verzerrungen – allen voran Self-Preference –, die Unabhängigkeits-Maßnahmen ausgleichen.

Cross-Model-Review. Ein anderes Modell als den Generator reviewen lassen. Entfernt geteilte blinde Flecken; behält die Grenze, dass der Diff seine eigene Referenz bleibt.

Halluzinierte API. Eine plausibel aussehende Funktion, ein Parameter oder Endpoint, den das Modell erfunden hat. Typisierte Stacks fangen viele beim Build; dynamische liefern sie aus – die fünf Fehlerklassen.

Paket-Halluzination / Slopsquatting. Modelle erfinden Dependency-Namen – und Angreifer registrieren diese Namen mit Schadcode (Slopsquatting). Ein Lieferketten-Risiko, das es nur bei generiertem Code gibt; interne Mirrors und Dependency-Richtlinien entschärfen es.

Selbstbestätigende Tests. Tests vom selben Modell wie der Code, die das implementierte statt das geforderte Verhalten festschreiben. Sie bestehen, während die Anforderung scheitert – deshalb zählt Validierungs-Autorschaft.

Plausibel-aber-falsche Logik. Sauberer, idiomatischer Code, der die falsche Regel implementiert. Für Nur-Qualitäts-Review unsichtbar, weil der Defekt relativ zum Auftrag ist – und der steht nicht im Diff.

Prompt Injection (Coding-Agenten). Feindliche Instruktionen, versteckt in Material, das ein Agent liest (Code-Kommentare, Issues, Web-Inhalte), die sein Verhalten umlenken. Ein Grund mehr, warum Agenten-Rechte statt Agenten-Gehorsam die Sicherheit tragen.

Local-First. Eine Architektur, in der Verarbeitung per Design in eurer Umgebung stattfindet – es existiert kein Anbieter-Datenfluss zum Analysieren. Zu unterscheiden vom lokalen Prozess, der Cloud-APIs aufruft – für wen und wie.

Lokales Modell. Ein LLM auf eigener Hardware – fürs Code-Review machbar ab rund 8 GB VRAM, ernsthaft bei 24 GB – Stufen und Grenzen.

Air-Gapped. Eine Umgebung ohne Netzverbindung nach außen. Verifikation funktioniert dort nativ; Generierung ist auf lokale Modelle begrenzt – was offline geht.

Datengrenze. Die deklarierte Linie, die Daten nicht überschreiten dürfen – Umgebung, Jurisdiktion, Anbieter. Das Ordnungskonzept der Local-First-Kategorie.

Codebasis-Index. Eine vom Tool gepflegte Repräsentation eures ganzen Repositories (Embeddings, Graphen) für kontextbewusstes Review – die die Datenfrage vom Diff auf alles ausweitet.

Sandboxing (Agenten). Agenten-Arbeit in isolierten Wegwerf-Umgebungen ausführen, damit Fehler geteilten Zustand nicht erreichen. Eindämmung des Runs – verschieden von der Verifikation des Ergebnisses.

Betreiber / Anbieter (EU AI Act). Die Rollenteilung des AI Act: Anbieter bringen KI-Systeme in Verkehr, Betreiber nutzen sie beruflich. Teams mit Coding-Assistenten sind Betreiber, mit entsprechend kleinem Pflichtenpaket – was gilt.

CLOUD Act. Das US-Gesetz von 2018, mit dem Behörden Anbieter unter US-Jurisdiktion zur Herausgabe kontrollierter Daten verpflichten können – unabhängig vom Speicherort – die nüchterne Analyse.

Zero Data Retention. Eine Anbieter-Zusage, Kunden-Eingaben nicht über die Verarbeitung hinaus zu speichern. Wertvoll, wo sie echt ist – und es lohnt, sie gegen die eigene Doku des Anbieters zu prüfen, die manchmal anderes sagt.