Was im Review auffällt, wird ein Test
Wenn KI-Agenten Code schreiben, kommt das Review kaum noch nach. Ein Software-Team hat gezeigt, wie es damit umgeht, und so baue ich das auch in den Teams auf, die ich begleite. Eine Frage kann man dabei allerdings keiner Regel überlassen.
Vor Kurzem war ich bei einem Vortrag, in dem ein Software-Team erzählt hat, wie es mit Code umgeht, den KI-Agenten schreiben. Den Kern haben sie in einem Satz zusammengefasst: Die Maschinen prüfen, ob die Regeln eingehalten sind, und die Menschen prüfen, ob das Richtige gebaut wurde.
Das klingt zunächst selbstverständlich. Interessant wurde es bei der Frage, was passiert, wenn ein Mensch im Review trotzdem einen Fehler findet. Bei diesem Team wird daraus jedes Mal eine neue Regel, und ab dann prüft die Maschine auch das.
Warum das gerade jetzt wichtig ist
Solange Menschen den Code selbst geschrieben haben, konnte das Review einigermaßen mithalten. Wenn aber ein Agent in einer Stunde mehr Code schreibt, als jemand an einem Tag sorgfältig lesen kann, wird das Review zum Engpass. Viele Teams, die KI schon länger nutzen, kennen das: Der Code ist schnell da, aber bis er geprüft ist, dauert es.
Wenn jede Anmerkung aus dem Review zu einer Regel wird, muss derselbe Fehler nur ein einziges Mal gefunden werden. Beim nächsten Mal fällt er auf, bevor ein Mensch hinschaut, und der Agent bessert ihn selbst aus. Dadurch wird das Review mit der Zeit leichter, weil sich die Menschen auf das konzentrieren können, was noch keine Regel abdeckt.
Geprüft wird mit Code
Wichtig ist dabei, wer prüft. Bei diesem Team beurteilt keine KI den Code einer anderen KI. Die Prüfungen sind selbst Code: Tests, statische Analysen und Architekturtests, die bei jeder Änderung automatisch laufen. Eine Regel ist dort also immer ein Test.
Ein Architekturtest prüft zum Beispiel, dass die Oberfläche nie direkt auf die Datenbank zugreift oder dass ein Modul nur über seine offizielle Schnittstelle angesprochen wird. Solche Regeln stehen sonst in einem Wiki, und ob sie eingehalten werden, hängt davon ab, dass sich jemand im Review daran erinnert. Als Test schlagen sie bei jedem Verstoß an, mit demselben Ergebnis, egal wer oder was den Code geschrieben hat.
Einen Review-Agenten gibt es dort auch, er gibt allerdings nur Hinweise. Ob eine Änderung durchgeht, entscheiden die Tests.
Deshalb wird aus einer Anmerkung im Review am besten ein Test. Eine Anweisung an den Agenten kann dieser übersehen, ein Test läuft jedes Mal mit.
Ein Test schlägt bei jedem Verstoß an, egal wer den Code geschrieben hat.
Neu ist die Idee nicht. In der Java-Welt gibt es dafür seit Jahren ArchUnit, eine Bibliothek, mit der man den Aufbau einer Anwendung als ganz normale Tests formuliert. In anderen Sprachen reicht oft schon ein einfacher Test, der den Code nach einem verbotenen Muster durchsucht.
Durchgesetzt hat sich das trotzdem nur in wenigen Teams, weil jeder dieser Tests erst geschrieben und gepflegt werden musste. Genau diese Arbeit kann heute die KI übernehmen.
Wie ich das in Teams aufbaue
Wenn ich ein Team begleite, frage ich am Anfang, welche Anmerkungen im Review immer wieder kommen. Das sind meist weniger, als man denkt, und jede davon ist ein Kandidat für einen Test.
Damit das nicht an einzelnen Leuten hängt, bekommt der Agent dafür eigene Skills. Ein Skill ist eine kurze Anleitung, die im Repository liegt und die der Agent lädt, wenn er sie braucht. So schreibt er Tests immer nach demselben Muster, egal wer im Team ihn gerade benutzt.
Dazu kommt ein eigenes Git-Repository mit dem Projektkontext, als einfache Markdown-Dateien. Darin steht, wie das System aufgebaut ist und welche Entscheidungen warum getroffen wurden, festgehalten als Architecture Decision Records, kurz ADRs. Die Tests sagen dem Agenten, was gelten muss. Die ADRs erklären ihm, warum es so ist, und das braucht er, sobald er etwas Neues baut, für das es noch keinen Test gibt.
Drei Bausteine, mit denen ich dabei arbeite:
Jeder Endpunkt wird dreifach getestet
Ohne Anmeldung, mit dem richtigen Benutzer und mit einem falschen. Erst der dritte Fall zeigt, ob jemand an fremde Daten kommt.
Aus einem Fund wird ein Test
Im Review reicht ein Satz, was falsch war. Den passenden Test schreibt der Agent nach einem Skill, der genau das beschreibt.
Die Fehlermeldung nennt die Lösung
Schlägt ein Test an, steht in der Meldung, wie es richtig geht. So kann der Agent den Fehler selbst beheben.
So ein Regelwerk hält genau das Wissen fest, das sonst nur in den Köpfen der Erfahrenen steckt. Weil es aus Tests besteht und im Repository liegt, gilt es für alle, auch für jeden Agenten, der am Code arbeitet.
Was keine Regel übernehmen kann
Tests haben eine Grenze, denn sie prüfen nur, was jemand vorher als Regel festgelegt hat. Ob das, was gerade gebaut wird, überhaupt das Richtige ist, kann kein Test beantworten. Das muss vorher jemand entschieden haben.
Das Team hat dazu noch eine zweite Frage gestellt, die ich bemerkenswert fand: Versteht die Person, die den Code einreicht, eigentlich, was sie da abgibt? Wenn ein Agent den Code geschrieben hat, ist das keine Selbstverständlichkeit mehr.
In vielen Teams ist allerdings gar nicht ausdrücklich geklärt, wer entscheidet, was gebaut wird.