Wer prüft den Code der Agenten?

Wenn Agenten Code schneller erzeugen, als ein Mensch ihn gründlich lesen kann, bleiben Abweichungen wie Rohwerte, abgelöste Varianten oder falsche Abstände unbemerkt. Zusätzliche Abstimmung löst dieses Problem nicht. Die Prüfung gehört an die Stellen, die der Code ohnehin durchläuft.

Was sich automatisch prüfen lässt

Rohwerte in CSS. Das Stylelint-Plugin stylelint-declaration-strict-value lässt für festgelegte Eigenschaften wie color nur Variablen, Funktionen oder freigegebene Schlüsselwörter zu. color: #fff wird damit zum Fehler. Weil Funktionen wie rgb() standardmäßig erlaubt sind, sollte man die Option ignoreFunctions einschränken. Über die Option message lässt sich zudem ein eigener Fehlertext hinterlegen.
Unbekannte Klassen und abgelöste Bausteine. Dafür gibt es ESLint-Regeln, fertige wie eigene.

Nicht prüfen lässt sich auf diese Weise, ob das richtige Token an der richtigen Stelle eingesetzt ist. Ob eine rote Fläche tatsächlich eine zerstörende Aktion kennzeichnet, kann kein Linter beurteilen.

Meldungen, mit denen ein Agent arbeiten kann

Aktuelle Werkzeuge lesen Fehlerausgaben und bessern selbst nach. Für GitHub Copilot im Agentenmodus beschreibt Microsoft, dass er Testausgaben überwacht und fehlschlagende Tests zu beheben versucht. Claude Code arbeitet auf dieselbe Weise mit den Ausgaben im Terminal.

Daraus ergibt sich eine einfache Regel für eigene Prüfungen. Die Meldung sollte den erlaubten Weg nennen, etwa „Zeile 42: #ff0000 ist nicht erlaubt, für zerstörende Aktionen gilt var(--color-danger)“, anstelle eines allgemeinen „Stilprüfung fehlgeschlagen“.

Wie viel Verantwortung der Agent erhält

Ich unterscheide drei Stufen. Die Einteilung dient als Entscheidungshilfe und ist kein Standard:

Nur anmerken. Der Linter meldet, der Mensch entscheidet.
Selbst korrigieren. Schlägt eine Prüfung fehl, die der Agent selbst ausführt oder deren Ausgabe er bekommt, bessert er nach. Freigegeben wird weiterhin von Menschen.
Selbst mergen. Bestimmte Änderungen gehen nach bestandenen Tests ohne Freigabe durch.

Für die dritte Stufe gibt es mit dem automatischen Mergen von Abhängigkeits-Updates ein erprobtes Vorbild außerhalb der KI. Die Renovate-Dokumentation empfiehlt es für Updates, die man ohnehin einfach mergen würde, und verlangt für Produktionsabhängigkeiten gute Testabdeckung. Gemergt wird ohnehin nur nach bestandenen Prüfungen. Dieselbe Vorsicht ist hier angebracht. Dazu gehören eine eng begrenzte Liste von Änderungsarten, Tests, denen man vertraut, und ein Einstieg mit genau einer Änderungsart.

Veröffentlichte Erfahrungen dazu, ob sich Stufe 3 für Design-System-Änderungen bewährt, sind mir nicht bekannt. Begründen lässt sich derzeit Stufe 2.

Aus der Reihe „Design Systems und KI“. Zurück: Tokens statt geratener Farbwerte. Weiter: Prototypen aus dem eigenen System: was Atlassian berichtet.