Die FAQ zur KI-Code-Prüfung

Wie diese FAQ aufgebaut ist

Wo Reality Graph ansetzt

FAQ

Was ist Verification Debt?

Verification Debt ist die wachsende Lücke zwischen dem Tempo, mit dem KI-Tools Code erzeugen, und der Zuverlässigkeit, mit der ein Team diesen Code vor dem Merge prüft. Sie akkumuliert lautlos, während Durchsatz-Metriken glänzen, und taucht später als Nacharbeit, Incidents und verlorenes Vertrauen in die Codebasis auf.

Wie groß ist die Verification Gap, in Zahlen?

Sonars State-of-Code-Umfrage 2026 hat sie direkt gemessen: 96 % der Entwickler misstrauen KI-generiertem Code, aber nur 48 % prüfen ihn konsequent. Die Lücke ist Verhalten, nicht Technik – die Checks existieren, sie werden unter Tempo-Druck übersprungen.

Warum ist Code Review plötzlich der Engpass?

Weil Erzeugen billig wurde und Lesen nicht. Telemetrie aus KI-intensiven Teams zeigt fast doppelt so viele gemergte Pull Requests bei 91 % mehr Review-Zeit pro PR – der Engpass der Lieferkette wanderte vom Schreiben zum Prüfen, und Review-Prozesse, die für menschliches Tempo gebaut wurden, fangen den Schlag auf.

Ist KI-generierter Code wirklich schlechter als menschlicher?

Er scheitert anders statt gleichmäßig schlechter: Halluzinierte APIs, stille Randfall-Fehler, Scope Creep, selbstbestätigende Tests und plausibel-aber-falsche Logik sind seine charakteristischen Klassen. Security-Tests liefern Zahlen – rund 45 % der KI-generierten Samples fielen in Veracodes Analyse 2025 durch –, und klassisches Review übersieht mehrere dieser Klassen strukturell.

Wie verifiziert man KI-generierten Code systematisch?

Mit einem Loop um jeden Run: ein schriftlicher Auftrag mit Ziel, Grenzen und Akzeptanzkriterien vor der Generierung; danach der Abgleich der erzeugten Änderung gegen diesen Auftrag; Validierung, die das Modell nicht verfasst hat (Tests, Typen, Build); und eine menschliche Entscheidung, bevor etwas einen geteilten Branch erreicht. Die Selbst-Zusammenfassung des Agenten ist ein Startpunkt, nie die Verifikation.

Was ist der Unterschied zwischen Code Review und Verifikation?

Review beurteilt die Qualität eines Diffs – Bugs, Stil, Security-Muster – gegen allgemeine Standards. Verifikation prüft eine Änderung gegen ihren schriftlichen Auftrag: Umfang, Kriterien, Absicht. Eine Änderung kann als Code makellos sein und trotzdem das Falsche tun; das fängt nur die Verifikation, weil die Referenz außerhalb des Diffs liegt.

Was ist eine prüfbare Vorgabe (machine-checkable specification)?

Ein Auftrag, dessen Erfüllung mechanisch prüfbar ist: ein Ziel, explizite Grenzen für das, was angefasst werden darf, Ja/Nein-Akzeptanzkriterien und ein Validierungsplan. „Behandelt leere Eingabe mit leerer Liste als Rückgabe“ ist prüfbar; „geht elegant mit Randfällen um“ ist eine Hoffnung.

Wie schreibe ich einen guten Auftrag für einen KI-Agenten?

Drei Minuten Struktur schlagen dreißig Minuten Prompt-Prosa: das Ziel in einem Satz, die Dateien oder Bereiche, die der Agent anfassen darf, zwei bis fünf binäre Akzeptanzkriterien und die Checks, die das Ergebnis validieren. Diese eine Gewohnheit verbessert die Generierung und macht den Output zugleich verifizierbar.

Sollten KI-Agenten selbstständig committen dürfen?

Nicht in geteilten, dauerhaften Zustand – geschützte Branches, Produktionssysteme, Datenbanken. In Wegwerf-Sandboxen und lokalen Arbeits-Branches ist Auto-Apply in Ordnung und nützlich. Der Replit-Vorfall 2025, bei dem ein Agent während eines ausdrücklichen Code-Freeze eine Produktionsdatenbank löschte, machte das Prinzip konkret: Instruktionen sind probabilistisch, Berechtigungen deterministisch.

Reicht es, wenn die KI ihren eigenen Code reviewt?

Es ist ein nützlicher Vorfilter und kein Verifikations-Verdikt. Die Forschung zeigt, dass LLM-Evaluatoren eigene Ausgaben erkennen und bevorzugen – ein Modell, das seinen eigenen Output reviewt, prüft seine blinden Flecken mit denselben blinden Flecken. Unabhängigkeit wächst mit Distanz: ein frischer Durchgang, ein anderes Modell und vor allem eine andere Referenz – der schriftliche Auftrag.

Was ist ein Prüfbericht (Evidence Report)?

Ein Nachweis pro Run über das Beabsichtigte, das Geänderte, das Validierte samt Ergebnis, das bewusst Übersprungene und das Offene – gespeichert beim Code. Er macht aus „vertrau mir, ich hab's geprüft“ ein Dokument, das Reviewer und Auditor lesen können.

Wie weist man gegenüber einem Auditor nach, was ein KI-Tool getan hat?

Mit Nachweisen pro Änderung, die fünf Fragen beantworten: Welches Tool in welcher Version hat gehandelt, auf welchen schriftlichen Auftrag, was hat sich geändert, was wurde mit welchem Ergebnis validiert, und wer hat freigegeben. Git beantwortet von Haus aus nur die mittlere Frage – der Rest braucht eine Beleg-Praxis, die als Nebenprodukt billig ist und als Archäologie unmöglich.

Wie misst man Verification Debt?

Mit vier Kennzahlen aus Git- und PR-Daten: dem Generierungs-zu-Prüfungs-Verhältnis, der Review-Tiefe (Aufmerksamkeit pro geänderter Zeile), der Quote ungeprüfter Merges und dem 14-Tage-Churn. Durchsatz-Metriken bleiben grün, während alle vier kippen – deshalb werden Teams, die nur Velocity messen, überrascht.

Was kostet ungeprüfter KI-Code?

Das klarste veröffentlichte Signal ist Churn: GitClears Analyse von 211 Millionen geänderten Zeilen zeigt Code, der binnen zwei Wochen nach dem Merge nachgearbeitet wird, Richtung 5,7 % steigen – grob das Doppelte der Vor-KI-Basis. Übersprungene Verifikation kommt später als eingeplante Arbeit zurück – mit Zinsen, und meist anderen Ursachen zugeschrieben.

Ist Vibe Coding für professionelle Teams vertretbar?

Als Prototyping-Modus oft ja; als Produktions-Default sagen die Daten nein. Der Tausch ist explizit: maximales Generierungstempo gegen minimale Verifikation, und die aufgeschobene Rechnung kommt als Churn, Security-Befunde im 45–55-%-Band und Fix-Zyklen. Die Trennlinie ist nicht, ob KI den Code schreibt, sondern ob irgendetwas ihn prüft, bevor er Produktionsrisiko trägt.

Welche Daten senden KI-Coding-Tools an ihre Anbieter?

Je nach Tool und Konfiguration: die bearbeitete Datei, vom Tool gewählten Repository-Kontext, eingefügte Logs und Tickets, Telemetrie – und bei codebasis-indexierenden Tools eine Repräsentation des ganzen Repositories. Secrets verstärken das Risiko: KI-gestützte Commits leaken Credentials laut GitGuardian-Daten etwa doppelt so oft wie der Durchschnitt.

Wie setzt man KI-Coding-Tools DSGVO-konform ein?

Als Datenfluss-Problem behandeln: kartieren, was die Umgebung verlässt, den Personenbezug darin lokalisieren (Fixtures, Tickets, Logs – selten der Code selbst), vor der Übertragung minimieren und die formale Seite schließen – AVV nach Art. 28, Transfermechanismus bei Nicht-EU-Verarbeitung, dokumentierte Trainings-Opt-outs. Die abschließende Bewertung gehört eurem Datenschutzbeauftragten.

Reguliert der EU AI Act KI-generierten Code?

Nein – der AI Act reguliert KI-Systeme, nicht die gewöhnliche Software, die sie schreiben helfen. Teams mit Coding-Assistenten sind Betreiber mit kleinem Pflichtenpaket (KI-Kompetenz, durch den Omnibus 2026 abgeschwächt), und die Hochrisiko-Fristen wanderten auf Dezember 2027 und August 2028. Die Pflicht, generierten Code zu prüfen, wohnt woanders: Produkthaftung, Branchenregeln und euer eigenes Risiko.

Wer haftet, wenn KI-generierter Code Schäden verursacht?

Ein KI-Sonderhaftungsregime gibt es nicht – die EU hat die entsprechende Richtlinie 2025 zurückgezogen. Es gelten die gewöhnlichen Schichten: Vertrag und ab Dezember 2026 die neue Produkthaftungsrichtlinie, die Software als Produkt erfasst; intern die durch NIS2 geschärften Leitungs-Aufsichtspflichten. Veröffentlichte Rechtsprechung zu KI-Code existiert noch nicht – dokumentierte Verifikation ist so oder so die Verteidigungsposition.

Sind KI-Coding-Tools mit ISO 27001 oder TISAX vereinbar?

Grundsätzlich ja – keiner der Standards verbietet eine Tool-Kategorie. Beide verlangen, dass die Tools im Managementsystem leben: inventarisiert, risikobewertet, unter Lieferantensteuerung, mit respektierter Datenklassifizierung und verifiziertem generiertem Code. Zertifizierte Organisationen scheitern im Audit an undokumentierter KI-Nutzung, nicht an KI-Nutzung.

Dürfen regulierte Branchen überhaupt KI-Coding-Tools einsetzen?

In der Regel ja, denn DORA, IEC 62304/MDR und ISO 26262/ASPICE regulieren den Prozess und seine Nachweise, nicht die Autorschaft des Codes. Dieselbe Verifikation, Nachvollziehbarkeit und dokumentierter Lebenszyklus gelten, ob Mensch oder Assistent die Änderung schrieb – KI erhöht das Volumen, was die Nachweisseite schwerer und wichtiger macht.

Kann man Code-Prüfung mit einem lokalen LLM betreiben?

Ja – machbar ab etwa 8 GB VRAM mit 7B-Coder-Modellen, ernsthaft bei 24 GB, wo quantisierte 32B-Klasse-Modelle laufen. Was kleinere Modelle über ihre Klasse hebt, ist Struktur: ein schriftlicher Auftrag als Review-Referenz plus deterministische Checks, die offline nichts verlieren. Der ehrliche Tausch: Spitzen-Einsicht gegen eine harte Datengrenze.

Funktioniert KI-Code-Verifikation ohne Internetzugang?

Ja – Verifikation ist die offline-freundliche Hälfte des KI-Codings. Die deterministische Schicht (Build, Typen, Tests, Scanner) ist offline-nativ, der schriftliche Auftrag ist eine Datei im Repository, und die Urteils-Schicht läuft auf einem lokalen Modell. Was ein Air Gap begrenzt, ist der Generator, nicht die Prüfung.

Welche KI-Code-Review-Tools gibt es 2026?

Vier Gruppen: dedizierte PR-Reviewer (CodeRabbit, Greptile, Qodo), Statik+KI-Plattformen (DeepSource, SonarQube mit AI Code Assurance), assistenten-integrierte Reviewer (Copilot Code Review, Cursor Bugbot, Claude Code) und lokale Ansätze (Open-Source-PR-Agent, lokale Modelle, Verifikationsschichten). Ein universell bestes gibt es nicht – die Wahl hängt an Datenrestriktionen und an der Frage, die beantwortet werden muss: Diff-Qualität oder Auftragstreue.

Funktioniert ein Verifikationsprozess über mehrere KI-Tools hinweg?

Ja, wenn die Invarianten eine Ebene über den Tools leben: ein schriftlicher Auftrag pro Run, ein Änderung-gegen-Auftrag-Check, Validierung ohne Modell-Autorschaft, Belege pro Run und ein menschliches Gate. Diese fünf Schritte erwähnen kein Tool – deshalb überleben sie Tool-Wechsel und decken auch den Agenten ab, den jemand gestern adoptiert hat.