Die Einführung des Koordinators

Die Modelle liefern schneller, als ich lese. Schon die Menge der erzeugten Dateien macht es schwer, jeden Arbeitsschritt nachzuvollziehen, und wer an dieser Stelle die eigene Kontrolle aufgibt, merkt zunächst gar nichts davon, weil die Berichte weiter gut aussehen und die Tests weiter grün sind. Deshalb hängt für mich alles am fachlichen Nachweis am Ende.

Fachliche End-to-End-Tests prüfen anhand vorgegebener Aufgaben, ob das fertige System leistet, was ich von ihm erwarte. Liegt dieser Nachweis vor, nehme ich die Codeerzeugung durch Agenten als Blackbox hin, solange sich das fachliche Ergebnis deterministisch prüfen lässt. Die produktnahen Tests während der Entwicklung haben daneben ihre eigene Aufgabe.

Als Zwischenschritt dorthin habe ich meinen Entwicklungszyklus um einen Koordinator erweitert. Er hilft mir beim Entscheiden. Dahinter steht eine verbreitete Praxis: Modelle und Agenten verschiedener Hersteller für die Teilaufgaben einzusetzen, zu denen sie passen.

Aktualisiert am 26. September 2026: Der Entwicklungsablauf erhält brauchbaren Versuchscode, begrenzt den gesamten Reparaturaufwand und richtet zusätzliche Prüfungen am Risiko aus. Die Modellbesetzung und die beschriebenen Betriebserfahrungen stammen aus der ursprünglichen Fassung.

Welche Arbeit ich dem Koordinator übergebe

Aus den Grenzen menschlicher Freigaben folgt für mich, genauer zu bestimmen, was ich überhaupt noch selbst entscheide. Als Auftraggeber lege ich das fachliche Ziel fest und sage, wann ich ein Ergebnis abnehme. Der Koordinator richtet die laufende Arbeit daran aus.

Fachlich end-to-end prüfen wir unser Agentic-CLI mit Terminal-Bench 2.0. Menschen haben die Aufgaben kuratiert, jede bringt ihre eigene Ausführungsumgebung mit, dazu eine von Hand geschriebene Referenzlösung und Tests, die das Ergebnis prüfen, wie das Terminal-Bench-Paper beschreibt. Daraus habe ich das North-Star-Zielbild abgeleitet: einen generischen Agentic-CLI, der unter realen Modell-, Werkzeug- und Fehlerbedingungen korrekt arbeitet und seine Ergebnisse nachweist. Das ist die harte Messlatte.

Für jeden abgegrenzten Produktauftrag setze ich einen PO ein, einen Agenten in der Rolle des Product Owners. Technisch ist er ein KI-Agent wie jeder andere. Die Rollenbezeichnung sagt, welche Aufgabe er im Entwicklungsprozess hat und welche Entscheidungen ich ihm übertrage. Er führt den Auftrag bis zum unabhängig geprüften Ergebnis. Drei POs arbeiten bei uns gleichzeitig an ihren Themen, und jeder verantwortet sein eigenes Ergebnis.

Innerhalb meines Mandats wählt der PO den Arbeitsansatz und schneidet die Aufgaben zu. Er entscheidet, welche Teile fachlich zusammengehören und wo nachgearbeitet wird, und er beauftragt Entwickler und unabhängige Prüfer selbst. Den isolierten Versuch beauftragt er innerhalb seines Mandats. Hat der Plan die unabhängige Prüfung bestanden, gibt er die weitere Umsetzung frei, ohne mich jedes Mal zu fragen. Was er entschieden hat, steht mit Begründung im Ticket. Ich kann es ändern oder die Vollmacht widerrufen.

Das Mandat selbst steht im Repository. Es nennt den Produktauftrag, die erlaubten Entscheidungen und die Grenzen, etwa für Kosten und für Aktionen nach außen, dazu die Prüfungen, an denen kein Weg vorbeiführt, und die Fälle, in denen ich selbst entscheide. Zwei Dinge sind dem PO verwehrt: seine eigene Arbeit abzunehmen und die Abnahmebedingungen eigenmächtig zu lockern. Ich übertrage ihm die laufende Führung eines Produktauftrags. Für das Produkt hafte ich.

Braucht ein PO einen Baustein des anderen, vereinbaren die beiden direkt, was geliefert und wie übergeben wird, der liefernde verantwortet seinen Beitrag, der empfangende die Integration und das Ergebnis seines eigenen Auftrags. Alles andere läuft daneben weiter. Keiner der POs steht über dem anderen. Jeder betreut einen Implementierungsstrang mit seinen Entwicklern und Prüfern.

Was er schuldet, trägt der zuständige PO im bestehenden Ticket ein, zusammen mit den Beiträgen, die er von anderen erwartet. Die allgemeine Rollenregel steht einmal in den Arbeitsanweisungen und wird im Ticket nur noch angewendet. Wer ein Thema hat, behält es. Und wer eine Teilaufgabe weitergibt oder seinen Umsetzungsschritt verkleinert, wird die offene Zusage dadurch nicht los.

Der Koordinator hat eine eigene Vollmacht für die Fragen zwischen diesen Aufträgen. Er achtet darauf, dass die Zuständigkeiten klar sind und hinter jeder Fertigmeldung der vereinbarte unabhängige Nachweis steht. Fehlt der, führt er den Auftrag als offen und schickt den PO zurück an die Arbeit.

Ein Koordinator, der jede Übergabe bestätigt oder jedes Review wiederholt, macht die Arbeit zweimal. Er greift ein, wenn die POs einen Konflikt allein nicht lösen. Außerdem kümmert er sich um gemeinsame Werkzeug- und Providerprobleme und führt geprüfte Änderungen zusammen.

Für einen Auftrag beginne ich mit einer verantwortlichen Umsetzung und einer unabhängigen Ergebnisprüfung. Den Agenten für die Abnahme nenne ich Judge. Bei einem konkreten Risiko prüft er schon früh als Gegenspieler, welche Fehler die vorgesehenen Tests übersehen. Diese beiden Aufgaben erfordern nicht automatisch zwei Agenten. Der Prüfer bleibt vom Autor unabhängig und hält die Vorgaben zur Modellbesetzung ein. Weitere Beteiligte brauchen eine eigene fachliche Frage.

Eine Anfrage an den Koordinator nennt den zuständigen PO, die offene Frage und den Commit. Der bisherige Prüfbericht gehört dazu. Bei Bedarf liest er die zugrunde liegenden Dateien und Rohprotokolle nach. Eine unveränderte Statusmeldung löst keine erneute Vollprüfung aus.

An mich geht, was ich nicht delegiert habe. Dafür brauche ich den betroffenen Arbeitsstand und die möglichen Folgen einer Änderung. Der Koordinator legt seine Empfehlung daneben und benennt, was noch ungeklärt ist, damit ich eine konkrete Frage beurteile, ohne mir den ganzen Vorgang aus den Protokollen zusammenzusuchen.

Auch dieser Agent irrt. Er schreibt deshalb kein negatives Prüfurteil in ein positives um. Akzeptiere ich ein bekanntes Risiko, steht meine Entscheidung neben dem ursprünglichen Urteil. Zugriffssperren und Kostenlimits gelten weiter. Vor einer Veröffentlichung oder Standardaktivierung verlange ich weiterhin eine Entscheidungsvorlage, soweit ich diese Befugnis behalten habe.

Welche Vorbilder diese Agentenrollen haben

Agenten in solchen Rollen werden bereits untersucht. Unserem Aufbau am nächsten kommt Effective Strategies for Asynchronous Software Engineering Agents vom 23. März 2026. Im dort beschriebenen CAID-Verfahren zerlegt ein Manager-Agent die Arbeit und teilt sie zu, während die Entwickler in getrennten Git-Arbeitsverzeichnissen sitzen und er anschließend ihre Beiträge zusammenführt und die weitere Planung anpasst. Geprüft haben die Autoren das auf Commit0 und PaperBench. Das ist ungefähr, was PO und Koordinator bei uns tun. Ein Unterschied fällt auf: Im Hauptablauf prüfen die Entwickler ihre Änderungen zunächst selbst. Diese Stelle besetze ich mit einem eigenen Prüfer.

Drei weitere Arbeiten beschreiben dieselben Rollen aus anderer Richtung. Coordination Without Judgment, online seit dem 17. Juli 2026, lässt Agenten in 19 simulierten Szenarien als Product Owner, Scrum Master und Entwickler auftreten und dabei Backlogs und Sprintpläne erzeugen, zugänglich ist mir davon allerdings nur der Konferenzabstract. Toward Agentic Software Project Management vom 23. Januar 2026, angenommen für den AGENT-Workshop bei ICSE 2026, entwirft einen koordinierenden Agenten mit spezialisierten Unteragenten und vier Arbeitsmodi, die regeln, wie selbstständig diese handeln. Software Engineering in the Agent Era vom 4. September 2026 trennt die delegierte Ausführung von der Befugnis, ein Restrisiko zu akzeptieren. Empirisch geprüft ist keine der drei.

Die letzte Trennung habe ich übernommen. Bei jeder Rolle steht jetzt ausdrücklich, welche Entscheidungen ich abgebe und welche ich behalte. Unsere POs sind damit eine konkrete Ausgestaltung dieser Ansätze, ergänzt um die Freigabe nach unabhängiger Planprüfung und um einen Koordinator für die Fragen zwischen den Aufträgen.

Wie ich die Modelle auf die Rollen verteile

Für den Koordinator wähle ich künftig das neueste Spitzenmodell, das ich für diese Aufgabe bekomme. Die POs bekommen ein bewährtes Modell der vorletzten Generation. In Entwicklung und Review arbeiten schnelle Modelle, die Code bearbeiten und über mehrere Schritte hinweg mit Werkzeugen umgehen. Ein Modellwechsel ändert nichts an den Befugnissen der Rolle.

Beim Koordinator lohnt der Aufwand, weil ihm die schwierigen Fälle zufallen: zu erkennen, dass zwei POs dieselbe fehlende Schnittstelle unterschiedlich beschreiben, oder zu beurteilen, welche Teile einer zugesagten Funktion noch ausstehen, nachdem der Auftrag verkleinert wurde. In meinen Codex-Registrierungen steht dafür GPT-6 Astra mit der Reasoning-Einstellung xhigh, die den vorgesehenen Denkaufwand des Modells steuert. OpenAI führt GPT-6 Astra als sein leistungsfähigstes Modell für komplexe Aufgaben. Was die Wahl taugt, sehe ich an den Ergebnissen des Koordinators.

Ein PO arbeitet über längere Zeit am selben abgegrenzten Auftrag, und dafür behalte ich lieber ein bewährtes Modell bei, auch wenn inzwischen eine neuere Generation erschienen ist und auf dem Papier besser abschneidet. In meinen OpenAI-Besetzungen steht GPT-5.6 Sol unterhalb von GPT-6 Astra, bei Anthropic habe ich POs mit Claude Opus besetzt. „Vorletzte Generation“ meint immer das Angebot eines einzelnen Herstellers. Aus Versionsnummern verschiedener Anbieter folgt keine gemeinsame Rangfolge.

Für Entwickler und Judges will ich kurze Rückmeldeschleifen, aber Geschwindigkeit hilft nur, wenn das Modell die Aufgabe auch erfüllt. Der Entwickler ändert vorhandenen Code und korrigiert ihn anhand der Tests. Beim Judge kommt hinzu, dass er die verlangten Kontrollen selbst wiederholt, wozu er genug Kontext und Zugriff auf die Werkzeuge hat. Gelingt das nicht, nehme ich für diesen Auftrag ein anderes Prüfmodell.

Was die jüngere Forschung zur Modellaufteilung zeigt

Für diese Aufteilung finde ich Belege in Arbeiten aus den zehn Monaten vom 13. November 2025 bis zum 13. September 2026. Am anschaulichsten ist der Sakana Fugu Technical Report vom 19. Juni 2026. In einem dokumentierten Terminal-Bench-2.1-Lauf baut GPT einen Server, anschließend prüft Claude Opus die Implementierung und findet dabei einen falschen Erreichbarkeitsnachweis, worauf GPT die Umsetzung korrigiert. In anderen Aufgaben tauschen die Modelle die Rollen.

Die übrigen Arbeiten liefern die Messungen dazu. Learning to Orchestrate Agents in Natural Language with the Conductor, erstmals am 4. Dezember 2025 erschienen und für die ICLR 2026 angenommen, verteilt Teilaufgaben mit einem trainierten Koordinationsmodell unter anderem auf GPT-5, Claude Sonnet 4 und Gemini 2.5 Pro. Die Autoren stellen diesem gemischten Pool eine Variante gegenüber, die alle Teilaufgaben GPT-5 zuweist, und bei BigCodeBench und GPQA Diamond schneidet der gemischte Pool besser ab. Agent-as-a-Router vom 22. Juni 2026 wählt unter acht Modellen aus und verbessert diese Wahl über einen Verifier und ein Gedächtnis früherer Aufträge. SWE-Router vom 30. Juni 2026 lässt erst ein günstigeres Modell einige Schritte laufen und entscheidet dann anhand des Verlaufs, ob ein stärkeres übernimmt, geprüft auf SWE-Bench und SWE-Smith.

Die gezielte Kombination verschiedener Modelle halte ich damit für belegt. Meine feste Zuordnung der Generationen zu Koordinator, PO und Entwicklung ist dagegen nur eine Umsetzung im eigenen Projekt. Der Conductor etwa arbeitet mit einem eigens trainierten Modell mit sieben Milliarden Parametern, während mein Koordinator zusätzlich Konflikte zwischen Aufträgen aufnimmt und Entscheidungen für mich vorbereitet. Dafür wähle ich ein aktuelles Spitzenmodell.

Verwendete Modelle und Zugangswege

Die Tabelle zeigt dokumentierte Besetzungen aus Projektläufen und registrierten Steuerthreads bis zum 13. September 2026, frühere Varianten eingeschlossen. Sie hält fest, was bisher lief. Die neue Auswahlregel galt noch nicht für alle diese Aufträge, und gleichzeitig liefen die Sessions auch nicht.

Claude Code nutze ich mit direktem Zugang zu Anthropic. In Codex bestimmt ein lokales Providerprofil, welchen Anbieter die Kommandozeile anspricht: Mein OpenAI-Profil ruft die GPT-Modelle auf, ein anderes verbindet Codex mit OpenRouter, etwa für die Modellkennung z-ai/glm-5.2, und OpenRouter vermittelt von dort den Zugang zu GLM 5.2. Das Werkzeug ist in beiden Fällen dasselbe.

Mit Muse kommt ein weiterer Coding-Agent hinzu. Einen Entwicklerlauf habe ich über muse exec --provider meta --model muse-spark-1.3 mit hoher Reasoning-Einstellung beauftragt, das Modell läuft bei Meta, das es für Coding und längere agentische Aufgaben beschreibt. Verglichen habe ich diese Modelle unter gleichen Bedingungen nie. Ein Urteil darüber, welches schneller arbeitet, steht mir deshalb nicht zu.

Unabhängige Prüfung nach einem Modellwechsel

Eine Besetzung bestand aus Claude als PO und Planer, Muse Spark als Entwickler und GLM als Judge über Codex und OpenRouter. Vor einem Ersatz prüft der Koordinator zweierlei: ob die Unabhängigkeit hält und ob der Lauf ins freigegebene Budget passt.

Claude Opus steht in der Tabelle als Entwickler und als Judge, weil es verschiedene Aufträge übernommen hat. Kein Agent darf seine eigene Implementierung abnehmen. Für das Plan-Gate verlange ich zusätzlich verschiedene Modellfamilien für Planung und Review, eine andere Versionsnummer derselben Familie reicht nicht. DeepSeek V4 Flash war in den herangezogenen Belegen ein früher Gegenspieler und hat nie eine abschließende Abnahme erteilt.

Im Prüfbeleg steht, welches Modell über welchen Provider mit welcher Reasoning-Einstellung aufgerufen wurde, dazu der geprüfte Commit und die Eingabe. Ich nehme dafür den protokollierten Aufruf. Was ein Modell selbst über seinen Namen sagt, zählt nicht. Zeigt ein Alias auf wechselnde Versionen, muss ich für den einzelnen Lauf nachlesen, welche es war.

Wie POs und Koordinator Nachrichten austauschen

Bei meinem früheren Versuch mit drei Claude-Sessions habe ich gesehen, wie Claude-Agenten einander Nachrichten schickten. Claude Code bietet dafür ListAgents und SendMessage, die Sessions finden einander über ihre Registrierung und schicken Text über Unix-Domain-Sockets. Die empfangende Session liest eine zugestellte Nachricht zwischen zwei Werkzeugaufrufen, und ruht sie gerade, startet die Nachricht einen neuen Turn. Anthropic nennt das Cross-Session Messaging.

Für unsere Codex-Sessions haben wir die Nachrichten an die Arbeitsdokumente im Repository gebunden. Ein PO schreibt seine Übergabe dorthin und schickt dem Empfänger über die Queue nur einen Verweis darauf. Ein eigener Helfer stößt ruhende Sessions wieder an, sobald sich etwas ändert. Nach einer Unterbrechung findet der PO seinen Auftrag deshalb auch dann wieder, wenn der frühere Nachrichtenaustausch längst aus seinem Kontext gefallen ist.

Codex bietet daneben Subagenten für delegierte Teilaufgaben. Die PO- und Koordinator-Sessions sind etwas anderes, sie laufen länger und führen jeweils einen eigenen Auftrag. Für diese Steuerthreads haben wir den Nachrichtenweg gebaut.

Arbeitsstand und Empfänger müssen zusammenpassen

Für jeden PO ist festgehalten, welcher Codex-Thread seine Rolle ausübt und in welchem Arbeitsverzeichnis er arbeitet. Adressiert wird er über die UUID des Threads. Nach einem Neustart prüfe ich diese Zuordnung, weil unter demselben Rollennamen noch alte, pausierte Sessions herumliegen können.

Die Übergabe steht im Ticket oder im Handoff. Sie nennt, was fertig ist, dazu Commit und Branch, den Prüfbericht und die Arbeit, die noch offen ist. Das gemeinsame Koordinationsregister verweist darauf und führt Zuständigkeiten und ungelöste Fragen. Ändert sich etwas, ersetzen die Agenten den Kopf des Registers, ältere Einträge rutschen darunter oder ins Archiv.

Jede dieser Dateien beantwortet genau eine Frage. Die Reihenfolge steht in der Backlog-Tabelle. Wie weit die Arbeit ist, steht im Ticket, der erlaubte Umfang in der Freigabe, und das unabhängige Review urteilt über einen bestimmten Commit, dessen Nummer im Bericht steht. Wer eine Fertigmeldung bekommt, liest die verlinkten Dateien in der angegebenen Fassung nach.

Bei getrennten Git-Arbeitsverzeichnissen ist das nötig, denn eine neue Übergabenotiz liegt vor der Integration nur auf dem Branch des Absenders, und ein Dateipfad ohne Branch und Commit führt den Empfänger im Zweifel zu der älteren Fassung, die in seinem eigenen Verzeichnis liegt.

Die Queue stellt im bestehenden Thread zu

Für einen adressierten Hinweis verwenden wir codex queue. Als Adresse nimmt der Unterbefehl die UUID des Ziel-Threads oder dessen exakten Sessionnamen, und welche UUID zu welcher Rolle gehört, lese ich aus der Prozessliste und den Rollout-Dateien, die genau dieser Prozess geöffnet hat. Die Angaben in spitzen Klammern sind Platzhalter:

codex queue --thread "<UUID des Empfängers>" \
  --message "PO1 an PO2: Übergabe auf Branch <branch>, Commit <sha>. Lies <Ticketpfad#Abschnitt>. Offene Frage: <Frage>."

PO1 erreicht damit PO2. Bei einem ungelösten Konflikt adressiert er stattdessen den Koordinator, der im bestehenden Thread des zuständigen POs antwortet. Texte zwischen Terminals kopiere ich dabei nicht. Die Queue nimmt die Nachricht auf, und die schon geöffnete Terminaloberfläche verarbeitet sie im Originalthread, sobald der laufende Turn zu Ende ist.

Einen gemeinsamen Codex-Daemon im Hintergrund gibt es dafür nicht. Eingereiht wird ausschließlich über die CLI, in die lokale Queue-Datenbank schreibt niemand.

Lesen darf ein Agent dort allerdings, und das hat den Weg verändert. An einem sicheren Punkt seiner Arbeit sieht er selbst nach, was in der Datenbank für seine eigene Thread-Kennung eingereiht ist, statt darauf zu warten, dass ihn jemand weckt. Die Kennungen der bereits bearbeiteten Einträge merkt er sich, damit dieselbe Nachricht bei späterer Zustellung keinen zweiten Auftrag auslöst.

An Modell und Berechtigungen des Empfängers ändert so ein Aufruf nichts. Er arbeitet mit seinem Kontext und den Kindagenten weiter, die er schon beauftragt hat. Ein Hinweis an einen PO startet also keinen zweiten Prüfer, während der erste noch läuft.

Die Queue überträgt Text, sonst nichts. Verlinkte Dateien liest der Empfänger selbst, in der richtigen Fassung, und er prüft den Hinweis gegen seinen erlaubten Auftrag. Im Protokoll erscheint die Queue-Nachricht als Nutzernachricht, obwohl kein Mensch sie geschrieben hat. Eine zusätzliche menschliche Freigabe entsteht daraus nicht.

Was sich über die Queue nicht steuern lässt

Am 19. September habe ich einen unabhängigen Prüfer nachsehen lassen, ob sich eine laufende Codex-Oberfläche auch direkt ansprechen lässt, über die Prozesskennung oder über den Thread. Das Ergebnis war negativ. Keiner der drei laufenden Prozesse stellte einen Socket bereit oder verwies auf einen Control-Socket, und ein separat laufender App-Server war mit keiner dieser Oberflächen verbunden.

Die naheliegenden Befehle helfen nicht weiter. codex app-server proxy setzt einen bereits laufenden Control-Socket voraus, codex remote-control start startet ausdrücklich einen Daemon, und codex debug app-server send-message-v2 kennt weder Prozess- noch Thread- noch Socket-Auswahl. Der Versuch, direkt auf das Pseudoterminal des Vordergrundprozesses zu schreiben, endete beim Betriebssystem mit „Permission denied“. Geprüft wurde gegen Codex CLI 0.155.1.

codex queue bleibt damit der einzige unterstützte Weg. Er reiht ein. Einen Schalter zum Unterbrechen, Anhängen oder sofortigen Wecken gibt es nicht, und ein laufender Turn läuft zu Ende, bevor die Nachricht an der Reihe ist.

Ein Helfer weckt ruhende Sessions

Ein lokaler Wiederaufnahmehelfer beobachtet, was sich im Repository ändert. Ein macOS-LaunchAgent ruft ihn alle fünf Minuten auf, solange der Rechner wach und der Benutzer angemeldet ist. Zu jedem registrierten Steuerthread sind Rolle, Arbeitsverzeichnis und die zu beobachtenden Dateien hinterlegt. Wer ausdrücklich pausiert wurde, wird nicht geweckt.

Er vergleicht Fingerabdrücke der lokalen Branch-Stände und der beobachteten Dateien, zu denen die Arbeitsregeln, das Koordinationsregister und die Tickets des Auftrags gehören. Hat sich etwas geändert, prüft er, ob der Thread gerade ruht und ob die zugehörige Terminaloberfläche noch offen ist, denn nur sie darf in diesen Thread schreiben. Ist sie geschlossen oder der Zustand unklar, wartet er. Vor dem Zustellen vergleicht er außerdem Modell, Berechtigungen und Arbeitsverzeichnis mit dem Registereintrag.

Der Weckauftrag selbst sagt nur: aktuelle Quellen lesen, offenen Auftrag fortsetzen. Ein PO sieht dann nach, was ansteht, der Koordinator nach einer übergreifenden Frage oder einem geprüften Kandidaten für die Integration. Aus einer Dateiänderung folgt kein neuer Produktauftrag. Findet die Session nichts Zulässiges, wartet sie weiter.

Zustellung und Erledigung werden getrennt geprüft

Ein erfolgreicher Queue-Aufruf bestätigt nur eines: Die Nachricht ist eingereiht. Wie schnell eine ruhende Session sie danach aufnimmt, habe ich am 19. September einmal gemessen. Der laufende Turn endete um 09:02:34,469 Uhr UTC, der automatische Folgeturn begann vier Millisekunden später, und um 09:02:34,488 Uhr stand die eingereihte Nachricht als Nutzereingabe im Thread. Kein Timer, kein zweiter Controller, kein Tastendruck von mir. Vor jeder automatischen Zustellung legt der Helfer deshalb eine eindeutige Markierung ab und merkt sich die aktuelle Position im Laufprotokoll, um später dort nach der Markierung und dem zugehörigen Turn zu suchen. Erst dessen Start und Abschluss zeigen, dass die Session den Weckauftrag verarbeitet hat.

Irgendein abgeschlossener Turn genügt dafür nicht. Auch nach dem passenden Turn ist der fachliche Erfolg offen, den belegen die Ergebnisse und Kontrollen aus dem Ticket. Ein Auftrag kann korrekt verarbeitet sein und trotzdem im Wartestatus enden.

Bei Timeout oder unklarer Zustellung gleicht der Helfer zuerst Queue und Laufprotokoll ab und entscheidet erst danach über einen erneuten Versand. Eine gemeinsame Sperre und höchstens eine offene automatische Zustellung verhindern überlappende Weckaufträge. Für die Dateien selbst hilft diese Sperre nicht: Bevor ein Agent dort selbst schreibt, prüft er weiterhin, ob er zuständig ist, denn gegen manuell gestartete Arbeit reserviert der Helfer nichts.

Als verarbeitet vermerkt der Helfer den Dateistand von vor dem Versand. Trifft während des Turns eine weitere Übergabe ein, sieht er sie im nächsten Durchlauf noch.

Die Antwort geht an den zuständigen PO

Angenommen, PO1 hat einen Baustein fertig, den PO2 in seinem Auftrag verwendet. PO1 legt die Übergabe mit Branch, Commit und Prüfbericht ab und weist PO2 darauf hin, PO2 liest sie und prüft, ob der Baustein seine Anforderung erfüllt. Für die zugesagte Lieferung haftet weiterhin PO1. PO2 weist nach, dass sie in seinem eigenen Auftrag funktioniert. Einen Detailkonflikt klären die beiden direkt, und PO3 arbeitet daneben an seinem Auftrag weiter.

Geht es um den Zuschnitt der Arbeit, schicken sie die Frage an den Koordinator. Er liest die Belege und hält seine Entscheidung innerhalb der Vollmacht fest. Nach der Integration meldet er den gemeinsamen Commit an die betroffenen POs, PO2 übernimmt diesen Stand und prüft, was sich an seiner Anbindung geändert hat.

Entwickler und Reviewer gehören dem PO, der sie beauftragt hat. Der Koordinator wendet sich an diesen PO und startet dessen Kindagenten nicht selbst. Wird ein Steuerthread ersetzt, wandern der offene Auftrag und die Steuerung der Kindagenten mit. Der alte Thread wird pausiert.

Register und Zustellkontrolle sind in diesem Aufbau eigene Werkzeuge, die wir selbst pflegen müssen. Ein Fehler im Helfer kann die Zusammenarbeit lahmlegen, auch wenn alle Modelle erreichbar sind und der Produktcode funktioniert.

Was ich an meiner bisherigen Bilanz korrigiere

In meiner Bilanz des Spec-Driven Development habe ich End-to-End-Tests und unabhängige Audits als Mittel gegen Drift beschrieben, gegen das Auseinanderlaufen von Spezifikation und Code, das niemandem auffällt, solange die Tests grün sind. Ein Satz darin ging zu weit: Ein ausführbarer Test drifte nicht, weil er rot bleibe, bis der Code passe. Das stimmt so nicht. Ein Test kann dieselbe falsche Annahme enthalten wie der Code und trotzdem grün bleiben.

Vorgeführt haben uns das die eigenen produktnahen Tests. Sie stellten die erwarteten Ergebnisse selbst her. Aus dem Produkt kam dabei nichts, und der Weg von der Eingabe bis zur Ausgabe blieb ungeprüft. Nach dieser Korrektur fehlten immer noch die Kontrollen dafür, ob zwei verglichene Läufe überhaupt zusammengehörten, zu welchem Modell sie gehörten und mit welcher Eingabe sie gestartet worden waren. Ein formal einwandfreier Prüfbericht stützte damit eine Aussage über den falschen Lauf.

Gefunden haben die Fehler die unabhängigen Reviews, aber erst nach mehreren Runden Nacharbeit, an deren Ende wir den Umfang der Umsetzung verkleinert haben, um überhaupt zu einem abnehmbaren Stand zu kommen. Dann fiel auch noch ein Modellanbieter aus. Der Quotenfehler, der zuletzt auf dem Bildschirm stand, erklärte deshalb nur einen Teil der Verzögerung, der Rest ging auf die Prüfarchitektur, die wir ebenfalls korrigiert haben.

Ein immer längerer Katalog kleiner Arbeitsanweisungen kommt dabei nicht heraus. Kehren dieselben Probleme wieder oder steht ein Auftrag still, überprüft der PO seinen Ansatz. Der Koordinator verlangt eine begründete Entscheidung und verfolgt, ob sie auch umgesetzt wird. Was der PO gewählt hat, steht mit Begründung im bestehenden Ticket.

Die fachliche Prüfung liegt beim unabhängigen Reviewer. Er hat einen eigenen Maßstab und Zugang zu den ursprünglichen Ausgaben. Frischer Kontext allein schützt ihn nicht davor, mit derselben Prüflogik denselben Fehler zu bestätigen.

Der Spike vor dem Plan-Gate

Mein früherer Ablauf begann mit einem Ticket und einer Machbarkeitsprüfung, danach kamen immer genauere Pläne, und ob deren Kontrollen überhaupt funktionieren, stellte sich häufig erst im Review heraus. Eine Mutation, ein absichtlich eingebauter Fehler, traf dann einen unbenutzten Codezweig oder stoppte schon den Compiler. Über die fachliche Kontrolle sagte so ein roter Lauf nichts.

Für neue Funktionen beginnt die Arbeit mit einem zeitlich begrenzten Versuch auf einem eigenen Branch. Er führt die kleinste zugesagte Nutzerwirkung von der Eingabe bis zum sichtbaren Ergebnis aus. Die frühere Wegwerfpflicht habe ich aufgehoben: Nach Herkunfts-, Diff- und Risikoprüfung darf brauchbarer Versuchscode als derselbe Code zum Umsetzungskandidaten werden. Die Planprüfung und die vorgesehene Freigabe bleiben Voraussetzung für die weitere Umsetzung. Vor der Übernahme in den Hauptzweig folgt die unabhängige Abnahme. Weshalb ich diesen Übergang geändert habe, beschreibe ich im Bericht über den Stillstand trotz vieler Tests.

Der Versuch folgt der Eingabe bis zu der Komponente, die das Ergebnis verwendet. Gehört ein gespeicherter Laufnachweis dazu, erzeugt ihn der Produktcode. Der Test bereitet seine Eingaben und die erwarteten Sollwerte vor, die beobachtete Ausgabe stammt aus dem Produkt.

Bei kritischen Daten-, Rechte- oder Wiederanlauffällen führt der Entwickler einen korrekten Fall aus und baut einen fachlichen Fehler ein, der an der vorgesehenen Testaussage scheitert. Ein zulässiger Gegenfall besteht weiterhin. So lässt sich erkennen, ob die Kontrolle Fehler unterscheidet oder pauschal alles ablehnt. Der mögliche Schaden bestimmt die Gegenprobe. Eine reine Textkorrektur benötigt eine Quellen- und Konsistenzprüfung, keine künstliche Mutation pro Tabellenzeile.

Für solche Risiken prüft der Gegenspieler bereits den frühen Lauf anhand von Code und Rohbelegen. Er sucht nach falschen Ausführungen, die der Test durchgehen ließe. Übernimmt derselbe unabhängige Prüfer später die Abnahme, knüpft er an die gesicherten Ergebnisse an und prüft die betroffenen Änderungen erneut. Welche kritischen Kontrollen er selbst reproduziert hat, steht im Bericht zum jeweiligen Kandidaten.

Woher die geprüften Werte stammen

Der Plan enthält die ausgeführten Kontrollen samt Ergebnissen, dazu die fachliche Absicht und die Begründung der Architekturentscheidungen. Für die Werte, von denen das Urteil abhängt, kommt eine Herkunftstabelle hinzu: Sie verweist auf die freigegebene fachliche Definition, nennt die schreibende Produktkomponente und den Empfänger, führt die erlaubten Abweichungen auf und verlangt eine Kontrolle mit absichtlich falschen Daten.

Beim Vergleich mit ein- und ausgeschalteter Funktion bekommen beide Läufe dieselbe Aufgabe und dieselbe Eingabe, alle übrigen Einstellungen sind gleich, und nur der untersuchte Schalter unterscheidet sie. Der Nachweis gehört zum jeweiligen Versuch, und welches Prüfmodell das Urteil gesprochen hat, steht ebenfalls dabei. Vertauschte Nachweise fallen der Kontrolle auf, auch wenn jede einzelne Datei für sich gültig ist.

Ein Schalter kann korrekt eingelesen sein und später trotzdem nicht wirken. Das Produkt kann eine Modellantwort verwerfen, obwohl der Aufruf gelungen ist. Deshalb reicht die Prüfung bis an die Stelle, an der die zugesagte Wirkung entsteht.

Die fachlichen Erwartungen lege ich fest, bevor die Agenten urteilen. Freigegebene Anforderungen bestimmen das Soll, Code und Laufzeit belegen das Ist. Einige Abnahmeszenarien bekommt der Entwickler nie zu sehen. Technische Tests schreibt er selbst, ob sie taugen, prüft der unabhängige Reviewer. Gemeinsam genutzter Code zum Lesen eines Dateiformats ist vertretbar. Über die fachliche Gültigkeit entscheiden die beiden Seiten getrennt.

Wenn dieselbe Fehlerklasse zum zweiten Mal auftritt

Automatische Checks finden Lintfehler, fehlende Tests und falsche Dateiverweise vor dem Modellreview. Ihre Reparatur zählt zum Gesamtbudget des Versuchs, ebenso wie fachliche Reviews, Delta-Prüfungen, Werkzeug- und Umgebungsarbeit sowie fehlgeschlagene Aufrufe. Die Unterscheidung der Fehlerklassen bleibt für die Diagnose nützlich. Sie nimmt keinen Aufwand von der Begrenzung aus. Ein neues Ticket setzt die Zählung nicht zurück.

Tritt dieselbe Fehlerklasse ein zweites Mal auf, ändert der PO begründet den Ansatz. Vor jedem weiteren Lauf nennt er eine Änderung oder eine andere Hypothese und die Beobachtung, die sie beurteilen hilft. Identische Wiederholungen brauchen eine eigene Frage zur Reproduzierbarkeit oder Streuung. Fehlt weiterer Erkenntnisgewinn oder ist das Budget erschöpft, sichert er den letzten brauchbaren Stand und bereitet einen anderen Ansatz oder fachliche Hilfe vor. Der Produktauftrag bleibt offen. Einen kleineren Lieferumfang oder einen Teilabschluss genehmige ich ausdrücklich.

Der Reviewer prüft den gesamten vorgelegten Umfang und bündelt die Korrekturen. Geschlossene Punkte öffnet er wieder, wenn sich etwas Relevantes ändert oder neue Belege dagegen sprechen. Ein zusätzlicher Bericht über unveränderten Code löst keine vollständige Wiederholung aus.

Nach einem Provider-Ausfall weiterarbeiten

Fällt die vorgeschriebene Prüfung aus, weil eine Anbieterquote erschöpft ist, lautet ihr Urteil „inconclusive“. Für eine Entscheidung reichen die Belege dann nicht. Auch in einer knappen Fortschrittsmeldung will ich diesen Zustand von einer gescheiterten Produktkontrolle unterscheiden.

Vor längeren Prüfläufen legt der Auftrag Zeit- und Kostenbudget fest, dazu die Zahl erlaubter Versuche, das Prüfmodell und einen erlaubten Ersatz. Ein ungeplanter Wechsel verlangt eine eigene Entscheidung, auch weil er die Unabhängigkeit der Modellfamilien verschiebt.

Für die Wiederaufnahme sichert der PO den geprüften Commit und die bisherigen Rohbelege und notiert, welche Arbeit noch fehlt. Vor dem nächsten Versuch muss der alte Lauf beendet und der Code nach Testmutationen wiederhergestellt sein. Pro Arbeitsbereich schreibt weiterhin nur ein einziger Agent.

Hat der ursprüngliche Prüfer seine Messungen abgeschlossen und fehlt nur das Urteil, setzt er dort fort. Ein neuer Prüfer macht kenntlich, welche Messungen er übernimmt und welche er selbst wiederholt. Ein kurzer erfolgreicher Modellaufruf sagt dabei nichts darüber, ob der Anbieter einen längeren Lauf durchhält.

Gemeinsame Ausfälle behandelt der Koordinator mit den betroffenen POs, die Wiederaufnahme einzelner Aufträge organisiert der jeweilige PO selbst. So ist auch bei einem Ersatz klar, wer den Entwickler oder Prüfer beauftragt.

Wann die Funktion als abgeschlossen gilt

Im Fortschrittsbericht will ich sehen, welcher Anwendungsfall über den vorgesehenen Produktpfad funktioniert und welche zuvor abgenommenen Fähigkeiten weiterhin nutzbar sind. Ein erster Referenzfall zeigt den Ansatz. Für den Abschluss der Story gehören alle vereinbarten Akzeptanzkriterien und die produktweiten Qualitätsanforderungen dazu. Grundlagenpakete allein erfüllen diese Zusage noch nicht.

Den Abschluss seines Auftrags verantwortet der jeweilige PO. Der Koordinator führt die unabhängig geprüften Änderungen zusammen und lässt die betroffene Integration prüfen. Vorhandene Belege gelten nur für ihren Code, ihre Konfiguration und ihren geprüften Umfang. Ändern sich Schnittstellen, Rechte, Transaktionen oder die Umgebung, prüft der Reviewer die betroffenen Aussagen erneut. Ein neuer Build erhält seine eigenen Herkunfts- und Paketnachweise.

Ist eine Funktion zunächst abgeschaltet, folgt der Aktivierungsnachweis. Der zuständige PO organisiert den realen An-/Aus-Vergleich mit passenden Laufnachweisen und das unabhängige Urteil über die beobachtete Wirkung. Was im Mandat steht, entscheidet darüber, ob sie danach standardmäßig läuft. Ein gesetztes Konfigurationsfeld genügt dafür nicht.

Die Dokumentation besteht normalerweise aus vier Teilen: Ticket oder Spezifikation, Implementierungs- und Testnotiz, unabhängiger Prüfbericht und Handoff. Sie stehen als Abschnitte in derselben Datei, solange erkennbar ist, wer was geschrieben hat. Rohprotokolle und maschinelle Laufnachweise liegen daneben, die Arbeitsanweisungen verweisen darauf.

Woran ich die Änderungen messen werde

Das alles steht jetzt in den Arbeitsanweisungen und im Methodentemplate. Für die laufenden Aufträge halte ich das Verfahren stabil und sehe mir seine Wirkung über mehrere abgeschlossene Nutzeraufträge an. Aus den bisherigen Korrekturen folgt weder eine geringere Fehlerquote noch ein dauerhafter Geschwindigkeitsgewinn.

Weitere allgemeine Vorgaben mache ich erst, wenn ein Mangel des Verfahrens belegt ist. Steht ein Auftrag still, untersucht der zuständige PO zuerst die Ursache: ob er die Aufgabe richtig verstanden hat, ob seine technische Lösung funktioniert, ob das eingesetzte Modell dafür taugt oder ob ihm schlicht das Werkzeug fehlt. Der Koordinator fordert diese Klärung ein und dazu eine begründete Änderung des Ansatzes. Fehler und Sicherheitsprobleme beheben wir weiter, sobald sie auffallen.

Ich erfasse die Zeit bis zum ersten durchgängigen Produktnachweis und bis zur vollständig abgenommenen Funktion. Das Budget enthält die gesamte Arbeit einschließlich erfolgloser Reparaturen, Provider-Wartezeiten und meiner eigenen Eingriffe. Für einen Vergleich sollen alter und geänderter Ablauf vom selben Code und Auftrag mit denselben Modellen, demselben Budget und derselben unabhängigen Abnahme starten.

Dauerhafter Fortschritt heißt außerdem, dass eine nachgewiesene Funktion spätere Änderungen übersteht. Zeigen sollen das die ohnehin vorgesehenen Abnahme- und Regressionstests. Geht eine zugesagte Fähigkeit wieder verloren, gehört dieser Rückschritt in den Bericht. Eine neue Rollenbeschreibung sagt für sich genommen nichts darüber, ob das Produkt eine Fähigkeit erreicht und behält.

Beim Koordinator achte ich darauf, welche Anfragen sich bei ihm sammeln. Warten dort Routinefragen oder fertiger Code, stimmt etwas an seiner Zuständigkeit oder seinem Entscheidungsspielraum nicht. Für meine eigenen Freigaben brauche ich weiterhin Zugang zu den Originalbelegen.