TL;DR
Ein Coding-Agent, der Rückmeldung über Fehler erhält, behebt sie. Bekommt er keine, meldet er Erfolg, auch wenn noch viele Fehler im Code stecken. Nur Checks, die er ausführen kann oder besser noch ausführen muss, stellen die Qualität der Resultate sicher. Trag die Befehle für Build, Tests und Gates in die Anweisungsdatei des Projekts ein (CLAUDE.md oder AGENTS.md). Dadurch gelten sie für das gesamte Repository, und niemand muss daran denken, sie in einem Prompt oder einem Skill zu wiederholen. Am besten werden die Checks nicht durch den Agenten ausgelöst, sondern durch einen deterministischen Trigger. Ein Pre-Commit-Hook ruft die Checks auf, ohne dass ein Agent etwas über sie wissen muss.
Der Code liess sich nicht kompilieren. So höre ich die Geschichte am häufigsten, und gemeint ist sie meist als Urteil über den Agenten: Er habe eine Methode erfunden, die es in der Bibliothek nie gab. Der Agent hat halluziniert. Das kommt vor, und ein Gerücht ist es nicht. Nur hat derselbe Satz eine zweite Hälfte, und die ist die interessantere: Ausgeführt wurde der Code nie, und nichts im Setup hatte je danach verlangt.
Bekommt ein Agent nach getaner Arbeit keine Rückmeldung zur Qualität, hält er seine Aufgabe für erledigt.
#Ein Agent hat kein Problem damit, seine Aufgabe als abgeschlossen zu betrachten, auch wenn noch zahlreiche Fehler vorhanden sind. Er hat eine Aufgabe erhalten, und die hat er aus seiner Sicht irgendwann erfüllt.
Dass der Code nicht kompiliert, fällt ihm nicht auf. Gehört das Kompilieren jedoch zu seiner Aufgabe und schlägt es fehl, betrachtet er die Aufgabe erst als abgeschlossen, wenn der Code tatsächlich kompiliert.
Das bei jeder Aufgabe eigens als Ziel mitzugeben, ist aber mühsam.
Eine Regel in der Anweisungsdatei gilt, ohne dass jemand an sie denken muss.
#Anweisungen, die allgemein gelten sollen, will man nicht in jedem Prompt und jedem wiederholen. Die Anweisungsdatei des Projekts (CLAUDE.md oder AGENTS.md) macht diese Wiederholung überflüssig. Was dort steht, gilt für das ganze Projekt, nicht für eine einzelne Aufgabe. Solche Anweisungen muss man sorgfältig formulieren, denn sie wirken auf alles, was der Agent im Projekt tut.
Es gibt auch globale Anweisungsdateien, die für alle Projekte gelten. Mit ihnen ist Vorsicht geboten: Sie dürfen nur Regeln enthalten, die wirklich für alle bestehenden und künftigen Projekte gelten sollen.
Ein Pre-Commit-Hook führt den Check aus, selbst wenn der Agent ihn nie eingeplant hat.
#Auch ein Befehl in der Anweisungsdatei verlangt vom Agenten noch eine Entscheidung, nämlich die, ihn auszuführen. Diese Entscheidung trifft er meistens richtig, aber nicht immer.
Ein Pre-Commit-Hook nimmt ihm die Entscheidung ab. Übrig bleibt eine einzige Anweisung: «Committen». In diesem Moment laufen die Checks von selbst. Schlägt einer fehl, blockiert das den Commit; der Agent merkt es und korrigiert die Fehler selbständig.
Ob die Checks laufen, hängt damit nicht mehr vom Urteil des Agenten ab, sondern von einem deterministischen Trigger. Das ist deutlich besser als jede Regel, die dem Agenten mitgegeben wird.
Automatisierte Checks müssen es dem Agenten möglichst einfach machen, Fehler zu erkennen.
#Wie auch immer der Check ausgelöst wird, seine Ausgabe muss maschinenlesbar sein.
Entscheidend ist, wie einfach ein Agent an konkrete Informationen zu einem Fehler kommt. Ein Check gibt mindestens «bestanden» oder «fehlgeschlagen» zurück. Kommt eine klare Fehlermeldung dazu, lässt sich das Problem gezielt angehen, und das spart Kosten. Zudem müssen die Checks deterministisch sein.
Jede Regel, die sich als Check formulieren lässt, ist eine Fehlerklasse weniger. Naheliegend sind Build, Type-Check, Testlauf und Lint. Dazu kommen die Checks, an deren Automatisierung seltener gedacht wird: ob eine Architekturgrenze überschritten wird, ob jede generierte Datei zu ihrer Quelle passt, ob es zu jedem Übersetzungsschlüssel eine Übersetzung gibt.
Je mehr solcher Checks vorhanden sind, umso höher ist die Qualität der Resultate eines Coding-Agenten.
Dreissig projektspezifische Checks laufen bei jedem Commit, und das Gate ist auf den Agenten zugeschnitten, der es liest, nicht auf den Menschen, der es geschrieben hat: Ein bestandener Check gibt nichts aus. Kein Check bricht beim ersten Fund ab. Sobald der Code kompiliert und die Tests grün sind, zeigt ein Commit-Versuch also alle verletzten Regeln auf einmal statt eine nach der anderen, Runde um Runde.
Wenn alle Checks bestehen, heisst das nur, dass der Code bestimmte Regeln erfüllt, nicht aber, dass die Änderung richtig war.
#Hier hört die Technik auf, und die Grenze gehört klar benannt, weil viele bestandene Checks eine trügerische Sicherheit vermitteln können.
Die Checks sagen nichts darüber, ob eine Änderung überhaupt berechtigt und fachlich wie technisch sinnvoll ist.
Deshalb müssen im Agentic Engineering die Aufgaben, die ein Agent erhält, sorgfältig geplant werden.
Findet sich ein Agent in einer Umgebung schnell zurecht und kommt er einfach an die relevanten Regeln und Informationen, spricht man von einer guten (AX). Ein wichtiger Teil der AX sind die automatisierten Checks.
Weiter erkunden