Ein Coding Agent bekommt eine Aufgabe, arbeitet, und meldet: fertig. Klingt harmlos. War der grösste Fehler in der ersten Version von NeoCoder.
Wie es angefangen hat
Als wir NeoCoder gebaut haben, war der Ablauf naheliegend. Ein Agent bekommt ein Ticket. Er schreibt Code, führt Tests aus, prüft sein Ergebnis und setzt den Status auf „erledigt". So, wie es ein Entwickler auch machen würde.
Am Anfang sah das gut aus. Die Aufgaben wurden schnell abgehakt. Das Board war grün.
Dann haben wir genauer hingeschaut.
Das Problem
Ein Agent, der sich selbst prüft, prüft mit denselben Annahmen, mit denen er gebaut hat. Wenn er die Anforderung falsch verstanden hat, testet er gegen das falsche Verständnis. Und die Tests werden grün.
Wenn er eine Funktion doppelt gebaut hat, weil er die bestehende nicht gesehen hat, sieht er sie bei der Prüfung auch nicht. Wenn er den Contract zwischen Backend und Frontend an einer Stelle gebogen hat, damit es passt, dann passt es, aus seiner Sicht.
Dazu kommt etwas, das mich überrascht hat. Fakt ist: Agenten neigen dazu, „fertig" zu sagen. Nicht aus Faulheit, sondern weil das Ziel der Aufgabe „Aufgabe abschliessen" ist. Ein Agent, der sich nicht sicher ist, markiert trotzdem als erledigt. Er hat keinen Grund, es nicht zu tun.
Die Regel
Deshalb gibt es in NeoCoder seit der zweiten Version eine feste Regel:
Ein Coding Agent darf seine Aufgabe nicht selber als erledigt markieren. Er setzt „bereit für QS". Mehr nicht.
Ob es fertig ist oder zurückgeht, entscheidet ausschliesslich der QS-Agent. Der hat die Aufgabe nicht gebaut und kennt die Annahmen nicht.
Geht es zurück, bekommt der Coding Agent nicht „mach nochmal", sondern eine konkrete Liste: was fehlt, was falsch ist, was doppelt ist.
Das klingt nach Bürokratie. Ist es nicht. Es ist die einzige Art, wie wir zuverlässig herausfinden, ob etwas wirklich fertig ist.
Wie die QS wirklich prüft
Der QS-Agent ist nicht einfach ein zweites LLM, das den Code anschaut. Das wäre teuer und würde bei jeder Prüfung etwas anderes sagen.
Zuerst läuft alles Deterministische: Baut es? Laufen die Tests? Hält es sich an die Architekturregeln? Gibt es schon eine Funktion, die dasselbe tut? Das ist billig, das ist jedes Mal gleich, und es fängt die Hälfte der Fehler ab, ohne dass ein Modell überhaupt beteiligt ist.
Erst danach kommt das LLM und beurteilt: Passt die Lösung zur Anforderung? Ist sie so gebaut, wie wir es in diesem System wollen? Das ist der Teil, den man nicht in Regeln giessen kann.
Die Reihenfolge ist wichtig. Ein LLM, das über Code urteilt, der nicht mal baut, verschwendet Geld. Und ein LLM, das Duplikate finden soll, ist schlechter als ein einfacher Vergleich.
Und bei Menschen?
Als wir die Regel eingeführt hatten, ist mir aufgefallen: Das ist nicht neu. Kein gutes Team lässt Entwickler ihre eigenen Pull Requests freigeben. Vier-Augen-Prinzip. Das gibt es seit Jahrzehnten.
Wir hatten es nur bei Agenten vergessen. Weil sie so schnell sind und so überzeugend „fertig" sagen.
Das ist vielleicht die wichtigste Lektion aus dem Ganzen: Die Regeln, die für Menschen gelten, gelten für Agenten genauso. Man muss sie nur wieder hinschreiben, weil man sie bei Menschen längst nicht mehr ausspricht.
Wer baut, nimmt nicht ab. Das galt für Entwickler, das gilt für Agenten. Seit wir das erzwingen, ist das Board weniger grün, und die Software deutlich besser.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert unser eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal bleibt ein Hüpfer drin. Das ist dann auch von mir.