Verification-first: Autonomie ist eine Infrastruktur-Frage.

Warum hängt die Autonomie an der Verifikation?

Ein Agent arbeitet in Zyklen: ändern, prüfen, weiterarbeiten. Kann er den Prüfschritt selbst ausführen, läuft der Zyklus ohne Menschen weiter. Kann er es nicht, wartet er nach jedem Schritt auf Freigabe, und der Geschwindigkeitsvorteil ist weg. Deshalb ist jede Investition in schnelle, lokale Prüfungen direkt eine Investition in Agenten-Autonomie.

Die drei Befehle

• make check: Formatierung, Linting, Typprüfung. Unter 30 Sekunden.
• make test: Unit-Tests. Unter 2 Minuten.
• make dev: die komplette Umgebung inklusive Testdaten, ein Befehl.

Die Namen sind egal, die Eigenschaften nicht: schnell, lokal, deterministisch. Die CI führt exakt dieselben Befehle aus. Wer pusht, um herauszufinden, ob die CI grün wird, hat kein Disziplinproblem, sondern ein Setup-Problem.

Der stärkste Beweis

Unit-Tests prüfen Teile. Der Test, der agentischen Code wirklich merge-fähig macht, bedient den Browser wie ein Nutzer und kontrolliert danach die Datenbank: Ist die Zeile wirklich da, gehört sie wirklich diesem Nutzer? Ein solcher Test pro Feature ersetzt viel Review-Diskussion.

Erzwingen statt erbitten

Regeln, die immer gelten sollen, gehören in Technik, nicht in Prosa: automatische Formatierung nach jeder Änderung, ein Stop-Gate, das den Agenten erst fertig sein lässt, wenn die Prüfungen grün sind, Sperren für generierte Dateien. Eine erzwungene Regel kostet nichts mehr, eine erbetene wird irgendwann ignoriert.

Selbsttest für Ihr Team

• Gibt es einen Befehl, der in unter 30 Sekunden sagt, ob der Code formal in Ordnung ist?
• Startet die komplette Entwicklungsumgebung mit einem Befehl, inklusive Testdaten?
• Läuft in der CI dasselbe wie lokal?
• Gibt es pro Kernfeature einen Test, der Browser und Datenbank gemeinsam prüft?

Viermal Ja: Ihr Team ist bereit für agentische Entwicklung. Auch nur ein Nein: Fangen Sie dort an, nicht beim Werkzeugvergleich.

Häufige Fragen

Warum begrenzt die Verifikation die Agenten-Autonomie und nicht das Modell?

Weil ein Agent nur so lange selbstständig weiterarbeiten kann, wie er selbst prüfen kann, ob sein letzter Schritt korrekt war. Ohne schnelle, lokale Prüfungen muss nach jedem Schritt ein Mensch schauen, und aus dem Agenten wird ein Diktiergerät. Mit guter Prüf-Infrastruktur kann derselbe Agent stundenlang allein arbeiten.

Was ist eine gute Ziel-Latenz für die Prüfungen?

Formatierung, Linting und Typprüfung zusammen unter 30 Sekunden, Unit-Tests unter 2 Minuten, die komplette Entwicklungsumgebung mit einem einzigen Befehl. Alles darüber unterbricht den Arbeitszyklus des Agenten so oft, dass der Geschwindigkeitsvorteil verschwindet.

Reichen Unit-Tests?

Nein. Die überzeugendste Prüfung ist ein End-to-End-Test, der den Browser bedient und danach die Datenbank kontrolliert. Er beweist, dass das Feature wirklich funktioniert, nicht nur, dass seine Teile isoliert korrekt sind. Genau diese Art Beweis erlaubt es, agentisch geschriebenen Code zügig zu mergen.