Repository-Metriken

AI-Verify-Loop

Wie inspect.software den Verify-Loop für Agenten misst — Ein-Befehl-Bootstrap, Tests, Lint, Typprüfung, reproduzierbare Umgebungen. Die gewichtigste AI-Readiness-Metrik.

Methodik v1.13.0Aktualisiert 2026-07-13

AI-Verify-Loop misst, ob ein KI-Coding-Agent das Projekt aufsetzen, ausführen und seine eigene Änderung ohne menschliche Hilfe verifizieren kann. Das ist der Kern autonomer Agentenarbeit — ein Agent, der seine Arbeit prüfen kann, baut Fortschritt auf Fortschritt; einer, der es nicht kann, erzeugt lediglich plausiblen Text — und die Metrik trägt das höchste Gewicht im AI-Readiness-Badge.

  • Kategorie: AI Readiness (40% innerhalb der Kategorie)
  • Gewicht im Gesamtindex: 0% — Teil des unabhängigen AI-Readiness-Badges
  • Metrikschlüssel: ai_verify_loop

Wie der Wert berechnet wird

KomponenteGewichtBeleg
Ein-Befehl-Bootstrap22,5Makefile, Taskfile, justfile, mise oder noxfile
Automatisierte Tests27eine Testsuite, die der Agent zur Selbstkontrolle ausführen kann (geteilt mit den Engineering-Praktiken)
Lint-/Format-Konfiguration13,5geteilt mit dem Linter-Signal des Engineering
Statische Typprüfung13,5eine statisch typisierte Sprache oder eine Typprüf-Konfiguration (mypy, pyright, tsconfig, py.typed)
Reproduzierbare Umgebung13,5devcontainer, Dockerfile, Nix oder ein Abhängigkeits-Lockfile
OpenSSF Scorecard: Pinned-Dependencies10Scorecard-Ergebnis 0–10, skaliert auf 10 Punkte

Pinned-Dependencies ist geteilte Evidenz: Es fügt dem Verifikationskreislauf des Agenten Information über die Reproduzierbarkeit der Lieferkette hinzu und bleibt zugleich eine vollwertige Sicherheitskomponente. Es wird ausgeschlossen, wenn Scorecard nicht verfügbar ist oder n/a meldet.

Warum dieser Kreislauf über die Nützlichkeit von Agenten entscheidet

Jede Komponente beseitigt einen Fehlermodus autonomer Arbeit:

  • Bootstrap — der Agent kommt vom Klon zum laufenden System ohne Archäologie.
  • Tests — der Agent kann belegen, dass eine Änderung das Beabsichtigte bewirkt hat.
  • Lint und Typen — ganze Fehlerklassen werden mechanisch abgefangen, vor dem Review.
  • Reproduzierbare Umgebung — „läuft in der Sandbox des Agenten“ heißt: läuft auch anderswo.

Bemerkenswert ist, dass dies dieselbe Infrastruktur ist, die menschlichen Beitragenden dient — die Metrik belohnt keine agentenspezifischen Exotika über das hinaus, was ein diszipliniertes Projekt ohnehin hat. Ein Projekt mit starker Engineering-Qualität startet hier typischerweise stark.

Das Ergebnis lesen

  • Die Signale bestätigen die Existenz des Kreislaufs, nicht seine Geschwindigkeit oder Abdeckung — die präsenzbasierte Ehrlichkeitsregel des gesamten Badges.
  • Ein hoher Verify-Loop bei einem Stub als Agentenkontext bedeutet meist ein gut konstruiertes Projekt, das schlicht noch keine Anleitung für Agenten geschrieben hat — die günstigste mögliche Verbesserung.

Den Wert verbessern

  • Ein Makefile (oder justfile/Taskfile) mit den Zielen install, test und lint ergänzen.
  • Eine automatisierte Testsuite lokal mit einem Befehl ausführbar halten.
  • Typprüfung einführen — schon eine minimale mypy-/tsconfig-Konfiguration zählt.
  • Ein Lockfile, Dockerfile oder einen devcontainer für die Reproduzierbarkeit der Umgebung einchecken.

Verwandt: AI-Code-Lesbarkeit · Engineering-Praktiken

Von inspect.software veröffentlichte Ergebnisse sind Signale, keine Garantien — siehe wie sie zu lesen sind. Die vollständige Methodik ist versioniert und öffentlich: Methodik v1.13.0.