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: 1,6%
- Metrikschlüssel:
ai_verify_loop
Wie der Wert berechnet wird
| Komponente | Gewicht | Beleg |
|---|---|---|
| Ein-Befehl-Bootstrap | 18 | Makefile, Taskfile, justfile, mise oder noxfile erhalten die volle Punktzahl; eine Toolchain, die den Befehl selbst definiert (Cargo.toml, go.mod, mix.exs, Maven, Gradle, .csproj), erhält den Großteil davon |
| Automatisierte Tests | 22 | eine Testsuite, die der Agent zur Selbstkontrolle ausführen kann (geteilt mit den Engineering-Praktiken) |
| Lint-/Format-Konfiguration | 11 | geteilt mit dem Linter-Signal des Engineering |
| Statische Typprüfung | 11 | eine statisch typisierte Sprache oder eine Typprüf-Konfiguration (mypy, pyright, tsconfig, py.typed) |
| Reproduzierbare Umgebung | 10 | devcontainer, Dockerfile, Nix oder ein Abhängigkeits-Lockfile |
| Nachgewiesene Agentenpraxis | 10 | Anteil der jüngsten Commits, die von einem Coding-Agenten verfasst oder mitverfasst wurden; volle Punktzahl ab 5% |
| Automatisierte Wartung | 8 | im Sample beobachtete Commits eines Abhängigkeits-Update-Bots; eine Konfiguration ohne beobachtete Commits erhält Teilpunkte |
| OpenSSF Scorecard: Pinned-Dependencies | 10 | Scorecard-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.
Belege, nicht nur Ausstattung
Jede andere Komponente hier liest die Dateien des Repositorys: Ein Task-Runner existiert, ein Lockfile existiert. Jede ist ein Stellvertreter für einen Kreislauf, den niemand hat laufen sehen.
Commits, die von einem Coding-Agenten verfasst oder ihm in einem Co-authored-by-Trailer zugeschrieben sind, sind der einzige verfügbare Nachweis, dass der Kreislauf tatsächlich geschlossen wurde. Eine Änderung wurde vorgeschlagen, verifiziert und mit einem Agenten im Kreislauf gemerged — und die eigene Historie des Projekts sagt das.
Der Pull Request eines Abhängigkeits-Bots ist ebenfalls maschinenverfasst und muss dieselben Hürden nehmen: Die Tests laufen, die Checks bestehen, er wird gemerged. Ein Projekt, das diesen Verkehr bereits aufnimmt, hat den Pfad gezeigt, den ein Agent braucht — deshalb wird automatisierte Wartung neben der Agentenpraxis bewertet und nicht in sie eingefaltet: Jede kann ohne die andere vorhanden sein.
Was zählt, sind die beobachteten Commits, nicht die Konfigurationsdatei. Eine dependabot.yml kann in einem Repository liegen, dessen Integration abgeschaltet ist, und Renovate wird häufig gänzlich außerhalb des Repositorys konfiguriert: Zwei weit verbreitete Projekte fahren es über rund ein Drittel ihrer Commits, ohne überhaupt eine erkennbare Konfigurationsdatei zu führen. Nur Bots, die eigene Inhalte verfassen, qualifizieren sich — ein Roboter, der fremde Arbeit merged, schreibt keine Änderungen.
Dieselben Commits zählen in der Entwicklungsaktivität gegen ein Repository, wo Automatisierung, die menschliche Arbeit verdrängt, ein Warnzeichen ist. Das ist Absicht. Die beiden Metriken stellen verschiedene Fragen: ob Menschen ein Projekt noch pflegen, und ob Maschinen dazu beitragen können. Beide Antworten können zugleich zutreffen.
Das belegt Adoption, nicht Autonomie. Eine Maintainerin, die interaktiv mit einem Agenten arbeitet, hinterlässt dieselbe Spur wie ein unbeaufsichtigter Lauf, und öffentliche Daten können beides nicht unterscheiden — weshalb die Komponente ein bescheidenes Gewicht trägt und nichts darüber behauptet, wie viel der Arbeit der Agent geleistet hat. Die Erkennung kennt zudem nur die Agenten, die ihr bekannt sind, sodass ein Projekt mit einem nicht erkannten Werkzeug schlicht als beleglos gelesen wird — nie als gescheitert.
Die Komponente wird ausgeschlossen statt als null bewertet, wenn kein Commit-Sample erhoben wurde.
Warum die Toolchain als Bootstrap zählt
cargo test und go test ./... sind die kanonischen Verify-Loops ihrer Sprachen. Nur Task-Runner anzurechnen, belastete diese Ökosysteme für ihre besseren Voreinstellungen — gut geführte Rust-Projekte erzielten bei dieser Komponente null, weil sie kein Makefile ausliefern. package.json und pyproject.toml werden bewusst nicht angerechnet: npm und Python definieren keinen universellen Testbefehl, und ob ein bestimmtes Projekt einen definiert, steckt in Dateiinhalten, die diese Metrik nicht liest.
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,testundlintergä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.
- Wo Agenten bereits eingesetzt werden, den
Co-authored-by-Trailer behalten, den die Werkzeuge standardmäßig setzen. Ihn zu entfernen tilgt den einzigen öffentlichen Beleg dafür, dass sich der Kreislauf in der Praxis schließt.
Verwandt: AI-Code-Lesbarkeit · Engineering-Praktiken