Wenn man zwei Coding Agents auf dasselbe Repository loslässt, passiert etwas Vorhersehbares: Sie helfen sich gegenseitig. Und genau das ist das Problem.
Das Chaos vorher
In der ersten Version von NeoCoder hatten Backend- und Frontend-Agent Zugriff auf das ganze Repository. Das schien praktisch. Der Frontend-Agent kann nachschauen, wie die API wirklich aussieht. Der Backend-Agent sieht, was das Frontend braucht.
Was dann passiert ist: Der Frontend-Agent brauchte ein Feld, das die API nicht lieferte. Statt das zu melden, hat er es „schnell" im Backend dazugebaut. Der Backend-Agent hat parallel dasselbe Feld anders benannt eingeführt. Beide Tests grün. Zwei Felder, zwei Namen, eine Bedeutung.
Nach ein paar Wochen hatten wir genau das, wovor ich in „Code wird billig" gewarnt habe: mehrere Lösungen für dasselbe Problem, und niemand wusste mehr, welche die richtige war.
Der Architekt kommt zuerst
Deshalb läuft es heute anders. Bevor irgendjemand Code schreibt, arbeitet ein Architekt-Agent.
Der Architekt-Agent schreibt zwei Dinge: eine Spezifikation, was gebaut werden soll, und einen Contract, wie Backend und Frontend miteinander reden. Welche Endpoints, welche Felder, welche Typen, welche Fehlerfälle.
Erst wenn das steht, starten die Coding Agents. Und zwar beide gleichzeitig, weil sie sich nicht mehr gegenseitig brauchen. Der eine baut die API nach Contract. Der andere baut das Frontend gegen den Contract. Fertig ist, wenn beide Seiten den Contract erfüllen.
Warum die Trennung so strikt ist
Die beiden Agenten sehen sich gegenseitig nicht in den Code. Nicht „sollten möglichst nicht". Sie können es nicht.
Das war eine bewusste Entscheidung, und sie war unbequem. Es gibt Fälle, in denen ein kurzer Blick in den anderen Teil geholfen hätte. Aber jeder dieser Fälle ist auch eine Einladung, sich schnell etwas dazuzubauen.
Wenn der Frontend-Agent heute ein Feld braucht, das im Contract fehlt, kann er es nicht selber lösen. Er muss es melden. Dann schaut der Architekt-Agent: Fehlt das wirklich? Gibt es das schon unter anderem Namen? Ist das die richtige Stelle dafür? Und passt den Contract an, oder eben nicht.
Das dauert länger als „schnell dazubauen". Ein paar Minuten. Dafür entsteht kein zweites Feld mit demselben Zweck, und die Entscheidung ist dokumentiert.
Artefakte statt Chat
Zwischen den Agenten wandern strukturierte Artefakte, kein Chat-Verlauf. Das ist der zweite Teil, der das Ganze zusammenhält.
Ein Chat-Verlauf ist für Menschen lesbar und für Maschinen wertlos. Nach dreissig Nachrichten weiss niemand mehr, was gilt. Ein Artefakt ist eindeutig: Das ist der Contract, Version 4. Das ist die Spezifikation. Das ist der QS-Report.
Jede Aufgabe hält fest, was sie erzeugt und was sie konsumiert. Der Backend-Agent konsumiert den Contract und erzeugt eine Implementierung plus Testbericht. Der QS-Agent konsumiert beides und erzeugt ein Urteil. So bleibt nachvollziehbar, woher was kommt. Auch Wochen später. Auch wenn die Session längst weg ist.
Nichts davon ist neu
Fakt ist: Contract first, saubere Schnittstellen, keine Querzugriffe zwischen Modulen. Das haben wir in grossen Systemen bei Banken und Telekommunikation seit Jahren so gemacht. Das ist die Arbeit eines Architekten.
Neu ist nur, dass sie jetzt in einer Form vorliegen muss, mit der Agenten arbeiten können. Nicht als Wissen im Kopf von jemandem, der seit zehn Jahren dabei ist. Sondern als Regel, die ein Agent nicht umgehen kann.
Und das ist, glaube ich, die eigentliche Aufgabe für die nächsten Jahre: das, was gute Architekten schon immer wussten, so aufzuschreiben, dass es auch gilt, wenn niemand zuschaut.
Der Contract kommt zuerst. Die Agenten sehen nur ihn. Wer etwas braucht, das fehlt, meldet es, statt es sich zu holen. Das ist langsamer pro Aufgabe und viel schneller pro System.
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.