Zum Inhalt springen

Wissensbasis

Verification Literacy

Was Engineers brauchen, um generierten Code gut zu reviewen, und warum dieser Code eine andere Art Review verlangt. Für alle, die Output von Agents prüfen.

Verfasst von

Aktualisiert:

Einstieg 2

Unsere Position. Wir setzen auf testgetriebene Entwicklung mit Agents.

Der Output eines Modells bleibt ein dauerhaftes Risiko. Kein noch so großer Kontext senkt die Wahrscheinlichkeit eines erfundenen Details auf null. Deshalb wägt ihr bei jedem Einsatz Auswirkung, Wahrscheinlichkeit und eure Chance ab, den Fehler zu finden.

Was verlangt Verification Literacy?

  • Fragt euch, bei welcher Änderungsgröße ihr Code deployen würdet, den ihr nicht gelesen habt, und behaltet mindestens den Testcode im Blick.
  • Rechnet mit erfundenen Details neben bekannten Konzepten, etwa bei einer internen Library oder einer gerade veröffentlichten API-Version.
  • Liefert den Feedback-Loop für Security selbst. Funktionale Fehler zeigen sich von allein, Sicherheitslücken nicht.

Warum braucht generierter Code Verifikation?

Ein Essay aus der Praxis argumentiert von der Seite des Codes her. LLMs schließen per Inferenz, sie kompilieren nicht. Ihr Output wird deshalb nie zur gesicherten Schicht, die man ignorieren kann, wie einst Assembler. Jeder Einsatz bleibt eine laufende Risikoabwägung: die Auswirkung eines Fehlers, seine Wahrscheinlichkeit bei eurem Setup und Kontext und eure Chance, ihn vor dem Release zu finden (I still care about the code (öffnet in einem neuen Tab), 9. Juli 2025). Eine Frage gibt dem Urteil Halt: Wärt ihr für dieses System on call, ab welcher Änderungsgröße würdet ihr ungelesenen Code mit gutem Gefühl deployen? Für die meisten Engineers erzwingt die ehrliche Antwort eine Untergrenze. Laut dem Essay solltet ihr mindestens den Testcode im Blick behalten.

Zu diesem Urteil gehört das Wissen, wo das Modell am ehesten erfindet. Halluzinationen häufen sich, wenn eine Anfrage zu einem bekannten Konzept sehr spezifische Details verlangt. Genau so sieht echte Arbeit aus, etwa eine interne Library oder eine gerade veröffentlichte API-Version, die das Modell nie im Training gesehen hat. Genau so sehen die beruhigenden One-Shot-Demos nicht aus (AI Native Dev - A Developer’s Guide to Not Getting Replaced by Agents (öffnet in einem neuen Tab), 10. März 2026). Halluzination ist das Kernverhalten eines Inferenzsystems und kein gelegentlicher Bug. Deshalb senken weder Kontext noch Modellstärke die Fehlerwahrscheinlichkeit auf null. Damit ändert sich die ganze Aufgabe. Programmieren war eine Frage der Menge, also genug Code zu schreiben. Jetzt wird es eine Frage des Vertrauens, also genug von dem zu validieren, was die Maschine geschrieben hat (The Practitioner’s Guide to Agentic Software Engineering (öffnet in einem neuen Tab)). Entsprechend verschiebt sich der Bottleneck.

KI schreibt einen wachsenden Anteil des Codes. GitHub hat 46 % des neuen Codes als KI-generiert gemeldet, und Stimmen aus der Branche sehen den Weg in Richtung 90 %. Damit wandert der Engpass vom Schreiben zum Outer Loop, also zum Reviewen, Testen und Mergen. Review wird so zur tragenden menschlichen Fähigkeit statt zur Nebensache (WeAreDevelopers – Evaluating AI models for code comprehension (öffnet in einem neuen Tab), 6. Juni 2025, Vendor). Anthropics Founder’s Playbook warnt, dass agentische Tools funktionierenden Code erzeugen, aber keinen sicheren. Funktionale Fehler zeigen sich von selbst, Sicherheitslücken bleiben unsichtbar, bis jemand sie ausnutzt. Deshalb muss der Mensch den Feedback-Loop liefern, der dem Tool fehlt (Anthropic – The Founder’s Playbook: Building an AI-Native Startup (öffnet in einem neuen Tab), Vendor).

Verwandte Seiten

Quellen

Artikel

Talks und Videos