Das Vorgehen lässt sich auf andere Produkte übertragen. Der Mensch bestimmt, was die Software leisten soll. Ein Lead-Agent organisiert die Arbeit, Entwickler-Agenten setzen einzelne Aufgaben um, und ein Testrunner prüft das Ergebnis am laufenden Produkt. Das Merge-Gate führt die geprüften Änderungen zusammen. Programmiersprache, Entwicklungswerkzeug und Modell sind Einstellungen des jeweiligen Projekts.

Das Ergebnis ist eine benutzbare Funktion

Eine Aufgabe beschreibt ein Ergebnis aus Sicht der Person, die das Produkt benutzt, einschließlich der erforderlichen Varianten und der Bedingungen, unter denen sie dieses Ergebnis erwartet. Fertig ist die Aufgabe, wenn die Software diese Vorgaben erfüllt und die zugehörigen Szenarien am integrierten Stand bestehen.

Der Nachweis reicht von der Eingabe bis zur beobachtbaren Wirkung. Bei meinem Kommandozeilen-Agenten prüfen Live-Szenarien die Antworten und die Wirkungen seiner Werkzeugaufrufe. Bei der Datenübernahme vergleichen Datenbankszenarien Quelle, Rohdaten und Historie. Im Strategiespiel steuern Testtreiber die Simulation und prüfen den gebauten Player im Headless-Betrieb auf macOS und Windows. Die technische Prüfung passt sich dem Produkt an, während der Entwicklungsablauf gleich bleibt.

Die Methode verbindet die Umsetzung mit einer unabhängigen Abnahme. Der Agent, der den Produktcode schreibt, hat keinen Schreibzugriff auf die freigegebenen Sollwerte. Sein Bericht hilft bei der Diagnose, während der Runner den Status der Aufgabe anhand des ausgeführten Tests setzt und dazu den geprüften Commit und das Laufprotokoll speichert, damit sich das Ergebnis später am selben Code nachvollziehen lässt.

Den Umfang eines Durchgangs festlegen

Am Anfang steht eine endliche Liste von Nutzeraufgaben. In meiner Vorlage heißt sie feature_list.json und enthält für jede Aufgabe das gewünschte Ergebnis, seine Pflichtvarianten, die betroffenen Oberflächen und die zugehörigen Szenarien. Ein Feld passes hält fest, ob die Aufgabe ihre Abnahme bestanden hat.

Für einen Durchgang bleibt diese Liste unverändert. Zusätzliche Wünsche werden in einer getrennten Liste gesammelt, damit laufende Arbeit ein bestimmtes Ende hat und bereits vereinbarte Aufgaben nicht durch neue Anforderungen verdrängt werden. Der nächste Durchgang beginnt, sobald die bisherigen Aufgaben abgeschlossen sind oder der Owner den Umfang ausdrücklich neu festgelegt hat.

Vor der ersten Entwickler-Session läuft die Abnahme einmal gegen den vorhandenen Produktstand. Dieser Erntelauf erkennt Funktionen, die bereits vorhanden sind, und nimmt sie in die Regressionstests auf. Die Agenten beginnen mit den offenen Aufgaben, sodass bei einem bestehenden Projekt nutzbarer Code erhalten bleibt und sich der weitere Auftrag aus der Differenz zwischen dem vereinbarten Soll und dem bereits geprüften Ist ergibt.

Die Abnahme als ausführbares Orakel

Ein Orakel vergleicht das beobachtete Verhalten mit einem festgelegten Soll. Es besteht aus Szenarien mit Ausgangslage, Eingaben und Prüfpunkten. Ein Testtreiber führt sie am Produkt aus und liefert ein maschinenlesbares Ergebnis. Für manche Aufgaben genügt ein vorhandener Testfilter, für andere braucht es einen Treiber für die Oberfläche, die Datenbank oder die Simulation.

Szenarien entstehen vor der Arbeit am Produktcode. Ein Agent entwirft sie aus den Nutzeraufgaben und Akzeptanzkriterien, bevor der Owner prüft, ob die Szenarien die gewünschte Funktion abbilden und für die Arbeit der Entwickler freigegeben werden können. Diese Ratifizierung legt fest, woran die Entwickler anschließend arbeiten und welches Ergebnis das Gate akzeptieren darf.

Ein gutes Szenario prüft auch relevante Fehlerfälle. Bei einem Datenexport könnte es etwa verlangen, dass der vorgesehene Benutzer die richtigen Daten erhält und ein unberechtigter Zugriff scheitert. Dieser beispielhafte Zuschnitt verbindet die benutzbare Funktion mit ihren Schutzanforderungen, die bei einem Test allein auf einen erfolgreichen Lauf leicht fehlen würden.

Zu den bekannten Szenarien kommen verdeckte Varianten mit anderen Eingaben und denselben Prüfpunkten. Die Entwickler haben keinen Zugriff auf diese Zwillinge. Scheitert ein Zwilling, obwohl das bekannte Szenario besteht, untersucht der Owner, ob die Lösung auf die bekannten Eingaben zugeschnitten ist oder das Szenario selbst korrigiert werden muss.

Ein falsches Soll bleibt auch bei bestandener Prüfung falsch. Die fachliche Prüfung der Szenarien gehört deshalb zur Methode. Wer sie an einen weiteren Agenten delegiert, legt dessen Befugnisse fest und prüft selbst Stichproben. So arbeite ich im Spielprojekt, in dem ich die Spielregeln vorgebe und ein anderer Agent die Szenarioentwürfe prüft. Entwickler erhalten dadurch keine Befugnis, ihre eigene Abnahme zu ändern.

Die Arbeit in der Schleife

Die Schleife wiederholt denselben Ablauf für jede freigegebene Aufgabe:

1. Ein Worker beansprucht eine offene Aufgabe. Eine Sperre verhindert, dass ein weiterer Worker dieselbe Aufgabe gleichzeitig bearbeitet.
2. Der Worker beginnt in einem eigenen Worktree auf dem aktuellen Hauptzweig. Die Session erhält die Aufgabe, ihre Szenarien und eine kurze Fortschrittsnotiz als Ausgangskontext.
3. Der Entwickler bearbeitet den Produktcode innerhalb eines festgelegten Zeit- und Kostenbudgets. Die Schleifensteuerung beendet die Session, sobald die Grenze erreicht ist.
4. Der entstandene Branch kommt in die Merge-Queue. Das Gate prüft ihn auf dem aktuellen Stand von main.
5. Bei bestandener Prüfung übernimmt das Gate die Änderung und markiert die Aufgabe als abgeschlossen. Andernfalls bleibt sie mit Fehlergrund und Laufprotokoll offen und wird zur Entscheidung geparkt.

Jede neue Session beginnt mit frischem Kontext. Das Repository enthält den Code, während die Fortschrittsnotiz die für die Fortsetzung nötigen Erkenntnisse festhält. Für einen neuen Versuch stehen damit die Aufgabe und die bisherigen Erkenntnisse bereit, ohne dass der nächste Agent erst die Annahmen einer langen Unterhaltung und ihre Zwischenstände rekonstruieren muss.

Während mehrere Worker unabhängige Aufgaben parallel bearbeiten, läuft die Übernahme auf main seriell, damit jede Änderung gegen den Stand geprüft wird, der die zuvor übernommenen Änderungen bereits enthält. Werkzeug und Modell eines Workers lassen sich wechseln, ohne die Sollwerte oder die Regeln der Abnahme zu verändern.

Das Gate schützt den gemeinsamen Produktstand

Das Merge-Gate nimmt einen Branch aus der Queue und rebased ihn auf main. Aufgabenliste, Szenarien und Schleifenwerkzeuge bezieht es aus dem vertrauenswürdigen Hauptzweig und setzt Änderungen eines Entwicklers an diesen Dateien zurück, bevor es den eingereichten Produktcode gegen die freigegebenen Szenarien prüft. Ein Schreibschutz im Werkzeug und ein Vergleich der geschützten Pfade nach jeder Session ergänzen diese Sicherung.

Anschließend laufen der Build, die Szenarien der Aufgabe und die Tests der betroffenen Module. Ein kleines Smoke-Set prüft die Kernfunktionen. Invarianten-Tests prüfen Eigenschaften, die für das gesamte Produkt gelten, und der Diff wird auf Zugangsdaten sowie unzulässige Änderungen an Tests untersucht. Erst wenn die vorgesehenen Prüfungen bestehen, übernimmt das Gate den Branch per Fast-Forward.

Bestehende Tests zu löschen, abzuschwächen oder zu überspringen ist den Entwicklern untersagt. Mein Gate erkennt unter anderem, wenn die Zahl der Testdeklarationen oder Assertions sinkt, und verwendet die Invarianten-Tests aus main. Eine geänderte Assertion kann bei gleicher Anzahl allerdings weniger prüfen. Der geschützte Satz fachlicher Szenarien und die verdeckten Varianten bleiben deshalb auch neben diesen technischen Kontrollen erforderlich.

Regelmäßige Regressionsläufe prüfen die bereits abgenommenen Aufgaben erneut. Verliert eine Funktion ihr erwartetes Verhalten, setzt der Runner ihren Status zurück und ordnet sie zur Reparatur ein. Die verdeckten Varianten laufen dabei mit. Im Spielprojekt prüft das Gate außerdem die bereits grünen Szenarien desselben Testtreibers, bevor es eine weitere Änderung übernimmt.

Zuständigkeiten und Entscheidungen

Der Owner verantwortet das Produktziel und die fachliche Abnahme. Er entscheidet über Änderungen am Umfang, über geparkte Aufgaben und über Eingriffe nach außen wie Push oder Veröffentlichung. Vor dem Lauf legt er Zeit- und Kostenlimits fest, wobei sich die konkrete Sessionlänge nach dem Projekt und der Zeit richtet, die dessen Build und Tests benötigen.

Der Lead-Agent bereitet die nächste Arbeit vor. Er entwirft Szenarien, startet Worker und hält den Produktstand in der Dokumentation nach. Die Entwickler arbeiten auf ihren Branches. Das Gate prüft und integriert ihre Ergebnisse. Diese Aufgabenverteilung braucht keine bestimmte Modellfamilie, solange die eingesetzten Werkzeuge die notwendigen Zugriffe erlauben und die Schutzregeln außerhalb der Entwickler-Session durchgesetzt werden.

Bei einer geparkten Aufgabe entscheidet der Owner über einen weiteren Versuch, eine Teilung der Aufgabe, eine fachliche Korrektur des Szenarios oder die Verschiebung in einen späteren Durchgang. Ein erneuter Versuch bekommt damit einen begründeten Auftrag, wobei das ursprüngliche Nutzerergebnis so lange offen bleibt, bis das Produkt die freigegebenen Szenarien erfüllt oder der Owner den Auftrag ausdrücklich geändert hat.

Die Vorgeschichte dieser Trennung beschreibe ich im Beitrag über den Stillstand meines agentischen SDLC. Dort hatten sich Reparaturen und schriftliche Prüfungen von der benutzbaren Funktion entfernt. Im jetzigen Ablauf richtet sich die Arbeit jedes Workers nach einer Aufgabe, deren Abschluss der Runner am Produkt feststellt.

Verwendete Agenten und Modelle

In meinen Projekten sind die Rollen wie folgt besetzt (Stand 11. Oktober 2026). Als Owner bestimme ich das Produktziel und die Befugnisse der Agenten. Der Lead-Agent heißt in den Arbeitsanweisungen „Root“.

Root entwirft Szenarien und startet die Entwickler-Sessions, deren Kommandozeile und Modell in der Schleifensteuerung konfiguriert sind. Im Strategiespiel übernimmt Root auch die delegierte Prüfung der Szenarioentwürfe eines anderen Agenten. Das Merge-Gate und der Testrunner führen die Abnahme als Programme ohne Sprachmodell aus.

Beim Kommandozeilen-Agenten ist zusätzlich das Modell im getesteten Produkt zu unterscheiden: Seine Live-Szenarien liefen zunächst gegen gpt-5.6-sol, später gegen GLM 5.3 über OpenRouter. Dieses Modell erzeugt die Produktantworten, die das Orakel prüft. Es entscheidet nicht über die Abnahme der Entwicklerarbeit.

Die Methode in ein Projekt übernehmen

Für die Übertragung werden die fachlichen Szenarien und die Verbindung zur jeweiligen Build- und Testumgebung eingerichtet. Die Schleife selbst bleibt wiederverwendbar. In meiner Vorlage sind dafür drei Kommandos konfigurierbar: Build, Modultests und Orakel. Das Orakel akzeptiert --ids und --out, endet nur bei Erfolg mit Exit-Code 0 und schreibt ein report.json mit genau einem Eintrag je angefragter Aufgabenkennung.

Der Einstieg beginnt mit einer kleinen, vollständigen Nutzeraufgabe, deren Szenario durch den vorgesehenen Produktpfad führt und dem Runner erlaubt, das Ergebnis von der Eingabe bis zur sichtbaren Wirkung zu prüfen. Weitere Aufgaben folgen demselben Muster. Fehlt für eine Oberfläche noch ein Testtreiber, gehört dessen Bau zur Einrichtung der Abnahme.

Für ein bestehendes Repository werden zunächst der nutzbare Produktstand und noch offene Branches gesichert. Die Branches durchlaufen das Gate, danach prüft der Erntelauf die freigegebenen Szenarien. Anschließend startet die Schleife mit den Aufgaben, die noch nicht bestehen. Neue Wünsche kommen in den nächsten Durchgang.

Bei Produkten mit schwankenden Modellantworten oder aufwendigen Umgebungen lässt sich die Prüfung aufteilen. Ein deterministischer Lauf am lokalen Produkt entscheidet über passes. Ein zusätzlicher Referenzlauf untersucht das Verhalten unter realitätsnahen Bedingungen, etwa mit echten Datenvolumen. Seine Ergebnisse bleiben gesondert sichtbar, weil die lokale Abnahme nur die dort geprüften Eigenschaften belegt.

Die Arbeitsanweisungen beschreiben die Zuständigkeiten und verweisen auf die ausführbaren Kontrollen. In meiner Vorlage begrenzt ein Skript ihren Umfang, damit neue Einzelfälle nicht fortlaufend zusätzliche Regeln erzeugen. Laufprotokolle verbinden Worker, Gate und Orakel über eine gemeinsame Trace-ID. Ein optionaler Adapter überträgt den bestätigten Status anschließend in ein vorhandenes Ticketsystem und liest ihn zur Kontrolle zurück.

Die Aufgabenliste und die Arbeit in frischen Sessions greifen den Ansatz aus Justin Youngs Effective harnesses for long-running agents auf. Die Sperren für parallele Worker stammen aus Nicholas Carlinis Arbeit am C-Compiler mit Claude. Meine Methode verbindet diese Bausteine mit geschützten Orakeln, einer fachlichen Freigabe und dem Merge-Gate als einzigem Weg zur integrierten, abgenommenen Funktion.

Ich habe deshalb das Template zusammen mit den Arbeitsanweisungen und Laufbelegen beider Projekte untersucht. In einem Projekt verzeichneten die Tagesberichte vom 19. bis 23. September keine neu qualifizierte Nutzeraufgabe. Im betrachteten Verlauf standen 265 Commits ohne Merge-Commits, davon änderten 190 ausschließlich Markdown-Dateien. Aus diesen Arbeitsspuren lässt sich weder die verbrauchte Zeit ablesen noch beurteilen, ob ein geänderter Text nötig war, um die nächste Funktion fachlich richtig zu bauen.

Im anderen Projekt gab es zuletzt Fortschritt am Wiederanlauf nach Fehlern, und bei einem System, das Ergebnisse nachweisen soll, gehört auch das Prüfwerkzeug zu den zugesagten Produktfunktionen. Die Diagnose, beide Projekte hätten nur noch nutzlose Tests erzeugt, wäre falsch. Mich beschäftigten die längeren Phasen, in denen nach weiteren Reparaturen und bestandenen Prüfungen weiterhin kein zusätzlicher Anwendungsfall benutzbar war.

Was ich in den Ablauf eingebaut hatte

In meiner Bilanz zum Spec-Driven Development hatte ich beschrieben, wie viel von einer ausführbaren Abnahme abhängt. Bei späteren Fehlern wurden die Vorgaben genauer. Ein Reviewer hatte einen wirkungslosen Test gefunden, also kam eine Gegenprobe hinzu. Ich war als Auftraggeber daran beteiligt, eine weitere Verbotsregel einzuführen, nachdem ein Agent einen Fehlerstatus verdeckt hatte.

Viele Einzelkorrekturen hatten einen guten Grund, aber in ihrer Summe entstanden Arbeitsaufträge, die sich lange erfüllen ließen, ohne das Produkt näher an einen nutzbaren Zustand zu bringen. Es gab stets noch eine Prüfmatrix zu vervollständigen oder einen Bericht zu berichtigen. Der Produktfehler blieb währenddessen ungelöst.

Beim Spike führte eine meiner Regeln sogar zu Doppelarbeit. Vor dem Plan-Gate verlangte ich einen isolierten Versuch, der einen Anwendungsfall durch die beteiligten Komponenten führt, damit der Agent früh erkennt, ob sein Ansatz funktioniert oder an einer Schnittstelle scheitert. Für den Plan waren Tests und Erkenntnisse vorgesehen, während die Regel verlangte, den Produktcode des Versuchs wegzuwerfen. Die funktionierende Verbindung musste später erneut entstehen.

Damit hatte ich selbst einen Übergang eingebaut, an dem bereits erreichte Funktion verloren gehen konnte. Die Sorge hinter der Regel war berechtigt: Ungeprüfter Versuchscode gehört nicht in den Hauptzweig. Warum jeder brauchbare Versuch erneut geschrieben werden sollte, konnte ich dagegen nicht begründen.

Auch das Rundenbudget begrenzte den Aufwand nur teilweise. Fachliche Korrekturen waren begrenzt, mechanische Reparaturen liefen außerhalb dieses Zählers. Mit Werkzeugproblemen und erneuten Reviews einzelner Diffs verbrauchte ein Versuch weiter Aufwand, auch wenn er auf dem Papier sein Limit für fachliche Korrekturen noch nicht erreicht hatte und weiterlaufen durfte.

Mit diesen Regeln hatte ich die Abnahme ausgebaut und den Weg zur ersten funktionierenden Umsetzung unnötig erschwert. Modellfehler und schwierige Architekturfragen verschwinden durch einen anderen Prozess zwar nicht. Die erzwungene Doppelarbeit konnte ich trotzdem sofort beseitigen.

Die Definition of Done war bereits da

Mit einem ausführbaren Produktpfad meine ich einen Ablauf von der vorgesehenen Eingabe bis zu der Stelle, an der jemand das Ergebnis verwendet. Bei einem Import endet er etwa dort, wo eine berechtigte Abfrage die importierten Daten liefert, während eine erfolgreiche Hilfsfunktion irgendwo dazwischen noch wenig über den gesamten Ablauf aussagt.

Das gehört zu einer Definition of Done. Der Scrum Guide verlangt ein benutzbares Increment, das mit den bisherigen Increments zusammenarbeitet. Die Definition of Done beschreibt dessen erforderlichen Qualitätszustand. Die einzelnen Akzeptanzkriterien ergänzen dazu, was die jeweilige Funktion leisten soll.

Solche Abschlussregeln standen schon in meinen Projekten. Ein neuer Satz über Nutzerwert hätte den Stillstand kaum behoben. Die Definition of Done sagt, welchen Zustand wir abnehmen, gibt dem Modell aber noch keinen Weg dorthin vor, wenn es sich beim Bauen in Reparaturen verläuft.

Für die Umsetzung habe ich deshalb die ersten Aufgaben anders zugeschnitten. Der erste Schnitt enthält einen kleinen vollständigen Anwendungsfall über die benötigten Komponenten hinweg, auf dessen laufendem Stand wir die übrigen vereinbarten Fälle ergänzen, bis der Auftrag erfüllt ist. Die gesamte Story ist erst fertig, wenn alle ihre Akzeptanzkriterien und die produktweiten Qualitätsanforderungen erfüllt sind.

Bei einem Datenprodukt könnte dieser erste Schnitt einen festgelegten Quelldatensatz einlesen und über den vorgesehenen Lesezugang wieder ausgeben. Berechtigungen und die unveränderte Quelle gehören zum Versuch. Spätere Schnitte ergänzen weitere Datenfälle oder den Wiederanlauf, soweit der Auftrag das verlangt. Dieser Arbeitszuschnitt ist ein Vorschlag. Einen erfolgreichen Produktlauf dafür haben wir noch nicht ausgeführt.

Den brauchbaren Versuch weiterverwenden

Im Ablauf mit Koordinator habe ich die Wegwerfpflicht korrigiert. Der Versuch bleibt isoliert. Nach Prüfung seiner Herkunft, des Diffs und der betroffenen Risiken darf derselbe Code zum Umsetzungskandidaten werden. Die vorgesehene Planprüfung und Freigabe gelten weiter, ebenso die unabhängige Abnahme vor dem Merge.

Einen ungeeigneten Versuch verwerfen wir. Erweist er sich als brauchbar, arbeitet der Agent an einer Anwendung, deren Verhalten er bereits beobachtet hat, und ergänzt die fehlenden Fälle im selben Codebestand bis zum vollständigen Ergebnis.

Für die Abnahme trenne ich Soll und Ist. Freigegebene Anforderungen und meine Entscheidungen bestimmen die Zusage. Code und Laufzeit zeigen, was vorhanden ist. Wenn die Anwendung eine falsche Zahl ausgibt, wird diese Zahl durch weitere grüne Tests nicht zum neuen Sollwert.

Auch die Pflichtdateien habe ich überprüft. Bedienablauf, Beispiele und Testnotizen stehen als Abschnitte im Ticket oder verweisen auf eine gemeinsame Quelle, wo die nächste Person oder der nächste Agent die nötigen Angaben findet. Eine zweite Datei mit demselben Inhalt hilft dabei selten.

Forschungsbefunde zu Regeln und Reparaturen

Die Untersuchung Evaluating AGENTS.md fand bei Python-Aufgaben aus bestehenden Repositories keinen allgemeinen Erfolgsgewinn durch zusätzliche Kontextdateien. Die Agenten befolgten die Vorgaben und testeten oder erkundeten mehr, wobei die Inferenzkosten im Mittel um mehr als 20 Prozent stiegen. Die im Juni 2026 überarbeitete Arbeit empfiehlt notwendige projektspezifische Hinweise und eine Prüfung ihres Nutzens.

Das ist ein engerer Befund als eine Erklärung meines gesamten SDLC. Die Studie hat weder meine Verbotsregister noch unsere mehrtägigen Aufträge untersucht, zeigt aber, dass das Befolgen einer Vorgabe allein noch nichts über ihren Nutzen aussagt. Beim Überarbeiten habe ich deshalb nach dem Zweck jeder zusätzlichen Pflicht gefragt.

Mit dem Erhalt funktionierenden Codes beschäftigt sich SlopCodeBench. Der Benchmark verlangt aufeinanderfolgende Erweiterungen derselben Codebasis. In der Fassung vom Mai 2026 wuchsen strukturelle Qualitätsprobleme über viele Verläufe. Ausdrückliche Hinweise zur Codequalität verbesserten den Anfang, verhinderten den späteren Verfall aber nicht. Das Ergebnis betrifft die dort eingesetzten Agenten auf 36 Python-Problemen mit insgesamt 196 Prüfpunkten.

Deshalb will ich nach der ersten fertigen Funktion auch deren spätere Erweiterungen beobachten. Wenn eine spätere Funktion das bisherige Verhalten wieder beschädigt, gehört dieser Verlust in dieselbe Bilanz wie der neue Anwendungsfall, selbst wenn der erste Stand des geänderten Verfahrens gut aussah.

Einen Ansatz für Reparaturen untersucht TraceCoder. Das System nutzt Laufzeitspuren, merkt sich gescheiterte Reparaturen und setzt schädliche Änderungen zurück. Auf BigCodeBench-Complete sank die Erfolgsquote beim Entfernen der Instrumentierung von 89,04 auf 78,51 Prozent. Diese Komponentenvergleiche liefern Hinweise auf wirksame Mechanismen innerhalb des Systems. Untersucht wurde Code-Reparatur in Benchmarks, kein vollständiger SDLC im laufenden Projekt.

Für meinen Ablauf prüfe ich deshalb folgende Annahme: Vor der nächsten Reparatur brauche ich einen Befund, der ihre Ursache eingrenzt, etwa durch einen Test, dessen Ergebnis zwei mögliche Fehlerursachen auseinanderhält oder bereits nachgewiesenes Verhalten schützt.

Weniger Übergaben, gezieltere Prüfungen

Ich beginne mit einer verantwortlichen Umsetzung und einer unabhängigen Abnahme, zu denen erst dann ein weiterer Agent kommt, wenn eine konkrete Frage zu klären ist, etwa die Herkunft eines Messwerts. Der frühe Gegenspieler kann später die Abnahme übernehmen, solange er unabhängig vom Autor bleibt und die geltenden Vorgaben zur Modellbesetzung erfüllt.

Die Studie Towards a Science of Scaling Agent Systems zeigt, weshalb die Zahl der Agenten allein wenig erklärt. In den untersuchten Aufgaben half Zusammenarbeit bei gut aufteilbarer Arbeit. Eng aufeinanderfolgende Entscheidungen konnten durch zusätzliche Koordination schlechter ausfallen. Die Arbeit liefert keine universell beste Teamgröße für meine Projekte.

Die Tests folgen jetzt dem Risiko einer Änderung. Bei Datenverlust, unberechtigtem Zugriff oder fehlerhaftem Wiederanlauf brauche ich weiterhin unabhängige Gegenproben am Produkt. Eine solche Probe setzt absichtlich eine relevante falsche Situation und zeigt, dass die Kontrolle sie erkennt. Für jede Zeile einer Textmatrix einen künstlichen Fehler einzubauen, ist dagegen keine allgemeine Pflicht mehr.

Eine reine Textkorrektur wird auf ihre Quellen und innere Konsistenz geprüft, während eine geänderte Konfiguration Daten löschen kann und trotz eines kurzen Diffs entsprechend andere Kontrollen braucht. Der Dateityp entscheidet das nicht. Unberührte Belege lassen sich weiterverwenden, soweit ihre Bindung an Code, Konfiguration und geprüften Umfang noch passt. Betroffene Schnittstellen und Rechte werden erneut geprüft.

Zugriffsschutz und Isolation habe ich dabei erhalten. Dass ein Scanner eine verdächtige Fehlerbehandlung findet, ist Anlass, sie zu prüfen. Erwartete Fehler lassen sich behandeln, wenn Sollstatus und tatsächlicher Status festgehalten werden, jede andere Abweichung den Lauf scheitern lässt und die Umgebung anschließend aufgeräumt wird.

Wann ein Reparaturversuch endet

Das Budget umfasst jetzt den gesamten Versuch. Dazu zählen die mechanischen Fixes ebenso wie Reviewer-Runden, Werkzeug- und Umgebungsarbeit sowie fehlgeschlagene Aufrufe. Mit einem neuen Ticket beginnt dieses Budget nicht von vorn.

Vor einem weiteren Lauf nennt der Agent den geänderten Code oder eine andere vermutete Fehlerursache, zusammen mit dem erwarteten Ergebnis, anhand dessen er seine Hypothese beurteilen wird. Identische Wiederholungen sind für Fragen zur Reproduzierbarkeit oder Streuung vorgesehen. Ohne diesen Zweck hätte ich nur die alte Schleife um ein Pflichtfeld erweitert.

Kommt kein Wissen hinzu oder ist das Budget erschöpft, sichern wir den letzten brauchbaren Stand. Der zuständige Agent beschreibt die offene Ursache und einen anderen Ansatz, bei Bedarf ziehe ich einen Menschen mit Fachwissen hinzu. Die Papers liefern dafür keine allgemeingültige Zahl erlaubter Runden.

Der Produktauftrag bleibt nach dem Abbruch eines Versuchs offen. Über einen kleineren Lieferumfang entscheide ich ausdrücklich. Gescheiterte Prüfungen oder eine noch unbewiesene Funktion werden auch dann als offen geführt, wenn sich ihr Rest bequem in ein Folgeticket verschieben ließe.

Was aus den Korrekturen wurde

Die geänderten Regeln stehen seit dem 26. September im Schulungstemplate und in einem der beiden Projekte, zusammen mit den angepassten Vorlagen und Dispatch-Prompts, die dem neuen Ablauf zuvor widersprachen. Die vorhandenen Selbsttests des Regelprüfers bestanden in beiden Verzeichnissen. Sie prüfen das Verhalten dieses Werkzeugs, lassen aber noch keinen Schluss darauf zu, ob die geänderten Regeln schneller zu nutzbarer Software führen.

Für das zweite Projekt, einen Kommandozeilen-Agenten für lokale Sprachmodelle, habe ich diese Korrekturen nicht mehr eingebaut. Dort hing jede Freigabe am schriftlichen Urteil eines Sprachmodells über einen Diff, und an keiner Stelle prüfte eine Maschine am laufenden Produkt, ob eine Aufgabe erledigt war. Die Regeln aus diesem Beitrag verändern, wie ein solches Urteil zustande kommt. Ein Kriterium, das die Maschine selbst prüfen kann, geben sie ihr nicht.

Dieses Projekt bekam deshalb am selben Tag einen Neuanfang: eine feste Liste von Nutzeraufgaben, je Aufgabe ein ausführbares Szenario außerhalb der Reichweite der Agenten und ein Merge-Gate, das allein eine Aufgabe auf „fertig“ setzt. Lead-Agent der Schleife ist dort Claude Code mit Claude Opus 5.5, die Entwickler-Sessions laufen in Claude Code und in Muse Code mit Muse Spark 1.3, die Live-Szenarien seit dem 28. September gegen GLM 5.3 über OpenRouter. Der alte Ablauf liegt dort im Archiv, im anderen Projekt gilt seit dem 26. September die korrigierte Fassung. Einen Vergleich beider Abläufe am selben Ausgangscode gibt es damit nicht mehr.

Das daraus entstandene Vorgehensmodell mit Schleife und Orakel beschreibt, wie sich Nutzeraufgaben, ausführbare Abnahme und Integration zu einer wiederverwendbaren Methode verbinden.

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.

Der Unterbau ist der Prozess, den ich im SDLC des Spec-Driven Development beschrieben habe. In der Codebasis liegt eine große Sammlung von Spezifikationen, geordnet in Epics und Tickets, mit ausgewiesenen Abhängigkeiten. Implementiert hat ein Entwickler-Agent, dessen Arbeit ein Judge unabhängig prüft. Als Entwickler lief Claude Opus mit Effort high, als Judge codex --profile openai gpt-5.6-sol. Für den Judge kommt auch ein Modell über OpenRouter in Frage.

Der Auftrag an die drei

Jede der drei Sessions bekam denselben Grundauftrag:

Du bist Product Owner für [redacted]. Du hast Owner directive and scope Berechtigung. Dein Leitbild für alle Entscheidungen ist der North Star Vertrag gemäß „Absolutes Produktziel“ und „North-Star-Zielbild und Prioritaetsordnung“. Ihr baut gemeinsam ein Produkt und keine isolierten Silos. Du verantwortest Strategie, Backlog, Architekturanschlüsse, Umsetzung und Evidenz deines Produktbereichs. Informiere die anderen Product Owner früh über gemeinsame Verträge, Abhängigkeiten und Änderungen. Root entscheidet bei Prioritäts- oder Scope-Konflikten. Bestehende Gates, unabhängige Audits und die verbindliche Backlog-Reihenfolge bleiben bestehen. Du steuerst den sachgerechten Einsatz der Judge und Entwickler.

Dazu kam je ein Bereich. Product Owner 1 bekam Correctness & Evidence:

Verantworte, dass [redacted] nachweisbar richtige Ergebnisse liefert. Dein Bereich umfasst typed Outcomes, unabhängige semantische Verifikation, kalibrierte pass/fail/inconclusive-Verdikte, Evaluation, Provenienz und belastbare Evidence-Receipts. Entwickle daraus eine kohärente Roadmap und führe die jeweils zulässigen Vorhaben bis zu reproduzierbarer Live-Evidenz.

Für Product Owner 2 und 3 habe ich entsprechende Prompts geschrieben, danach die drei Sessions gestartet.

Auszüge von den Terminals

Neben den üblichen Agentenberichten tauchten in den Terminals Abschnitte ihrer Unterhaltung auf. Hier Auszüge:

PO 1

Verstanden: drei parallele Agenten, ich bin PO 1 (Correctness & Evidence).
Ich registriere das im Koordinationsfile und lasse Slots für PO 2/PO 3.

› Message from @[redacted]-f3: Koordinationsdatei liegt auf main:
  tickets/backlog/PO-KOORDINATION-2026-09-01.md, Commit a1ed15189
  (docs-only). Dein PO… (ctrl+o to expand)

....

› Message from @[redacted]: PO3 Vollzug: E426-Downstream-Rebaseline No-FF
  `31c89d791` auf main, Ledger-Nachtrag `d6a8db960` (docs-only).
  Du kannst … (ctrl+o to expand)

PO 2

› Message from @[redacted]-3c: PO3 quittiert: T1967-Plan-Revalidation bindet
  ausschließlich den gelandeten V1-Vertrag (54ebaacde), bleibt bis zur User…
  (ctrl+o to expand)

PO 3

› Message from @[redacted]-67: PO1: kein Einwand gegen S1/S2 unter den
  bekannten Substrat-Auflagen — je Commit Re-SHA-Differential der 13
  Print-Plan-D… (ctrl+o to expand)

› Message from @[redacted]-3c: PO3 Vollzug (§3): T2089 Plan-Gate R2 pass;
  Gate-Evidenz docs-only No-FF `e56a36d3a` auf main, Ledger-Nachtrag
  `01bb95f2… (ctrl+o to expand)
  ⎿  “Ack Basis 01bb95f29; PO2 V2a in Implementierung” → sent to
     [redacted]-3c — another Claude session on this machine

› Message from @[redacted]-f3: PO1 hat die Altitude-Regel gegengezeichnet
  (docs/audits/2026-09-02-root-delegated-decisions-po1.md, main 4ce3090eb)
  mit… (ctrl+o to expand)

› Message from @[redacted]-f3: Quittiert: AGENTS.md-Abschnitt
  „Plan-Gate-Altitude“ mit PO1-Präzisierung gelandet, gilt ab jetzt auch
  für mein laufende… (ctrl+o to expand)

Die drei melden einander die Stellen, an denen sie sich in die Quere kommen können, also gemeinsame Verträge und die Reihenfolge der Merges nach main. Sie kündigen einen Merge vorher an und tragen den Vollzug später mit der Commit-SHA nach. Auch den Lauf der vollständigen Testsuite stimmen sie untereinander ab, weil ein Durchlauf inzwischen mehr als drei Stunden braucht.

Schon krass cool, das alles.

Wie die Nachrichten laufen

Ich habe Claude in der Anthropic-Dokumentation recherchieren lassen. Claude Code hat dafür zwei Werkzeuge. ListAgents zeigt einer Session, welche anderen Agenten sie erreicht, SendMessage schickt einen Text an einen Namen. Aufgerufen habe ich keines von beiden. Ich sage einer Session, was die andere wissen soll, und sie schreibt die Nachricht selbst. Seit Version 2.1.224 ist die Funktion auf macOS und Linux ohne Konfiguration da, bei mir läuft 2.1.258. Anthropic dokumentiert sie unter Cross-Session Messaging.

Jede Session bindet beim Start einen eigenen Unix-Domain-Socket, über den die anderen Sessions auf derselben Maschine zustellen. Unter Windows nimmt Claude Code eine Named Pipe. Die Sessions finden einander über Registrierungsdateien auf der Platte, deshalb erreichen sich ein Container und sein Host nicht. Der Umweg über Anthropic-Server entfällt, solange beide Sessions auf derselben Maschine laufen. /status zeigt die eigene Adresse in der Zeile Peer address, /list-agents zeigt die erreichbaren Sessions.

Die empfangende Session liest eine Nachricht zwischen zwei Werkzeugaufrufen, ein laufendes Werkzeug bricht dabei nicht ab. Arbeitet sie gerade nicht, dann beginnt die Nachricht einen neuen Turn. Über die Leitung geht ausschließlich Text. Der Gesprächsverlauf des Absenders und seine Dateien bleiben, wo sie sind.

Die Grenzen sind eng gezogen. Claude Code drosselt wiederholte Nachrichten desselben Absenders, verwirft kurz hintereinander eintreffende Dubletten und hält höchstens 50 angenommene Nachrichten für den Empfänger bereit. Eine Schleife zwischen zwei Sessions läuft dadurch von selbst aus. Eine Nachricht aus einer anderen Session gilt außerdem nicht als meine Zustimmung. Was eine Berechtigung braucht, landet weiterhin als Frage bei mir.

Die experimentelle Team-Funktion ist hier nicht im Spiel. Sie ist standardmäßig abgeschaltet, und bei ihr startet ein Lead seine Teammates selbst und führt mit ihnen eine gemeinsame Aufgabenliste. Die drei Sessions habe ich einzeln aufgemacht, jede in ihrem eigenen Terminal.

Alle diese Nachrichten sind flüchtig. Verbindlich halten die Agenten alles in der Datei tickets/backlog/PO-KOORDINATION-2026-09-01.md fest, die im ersten Auszug auftaucht. Dort trägt jeder Product Owner seine Claims, die Ticketnummern und die Merge-Ankündigungen ein, bevor er handelt. Der Zustand liegt damit in einem versionierten Artefakt, wie es die agentische Engineering-Pipeline vorsieht.

Das betrifft die Rolle des Owners im SDLC des Spec-Driven Development, den ich hier dokumentiert habe. Dieser Mensch gibt den Plan frei, eröffnet Umsetzungsabschnitte und entscheidet über den Merge. Jede dieser Entscheidungen landet als Eintrag im Repository, neben den Verdikten der Prüfmodelle. Zwischen diesen Punkten arbeiten Implementierer, Subagenten und Prüfmodelle. Von ihrer Arbeit kennt der Owner das, was sie ihm am Rückkehrpunkt vorlegen.

Auch das ist Gegenstand aktueller Forschung. Fünf Arbeiten aus dem vergangenen halben Jahr zeigen zweierlei: Die Aufmerksamkeit lässt im Lauf nach, und Prüfende stützen sich auf Material, das der Agent liefert. Damit handeln sie ihrem eigentlichen Auftrag zuwider.

Das Positionspapier „AI Agents Push Humans Out of the Loop“ von Margaret Mitchell, Avijit Ghosh und Samir Passi hat diese Position am 24. August 2026 zugespitzt. Es führt Forschung zu Automation und Mensch-Computer-Interaktion zusammen.

Aufsicht im laufenden Betrieb

Coding-Agenten erzeugen neben dem Code ihre Pläne, Werkzeugaufrufe und Testergebnisse. Sie ändern ihr Vorgehen während des Laufs und übergeben Arbeit an weitere Agenten. Mitchell, Ghosh und Passi beschreiben, was eine Person leisten müsste, um das zu beaufsichtigen. Sie müsste den Strom verfolgen, frühere Schritte im Gedächtnis behalten und die Wirkung der nächsten Aktion abschätzen. Nebenbei erteilt sie Berechtigungen und bearbeitet ihre fachliche Aufgabe. Die Oberflächen helfen dabei kaum. Sie zeigen lange Protokolle, die für eine Prüfung im laufenden Betrieb nicht aufbereitet sind, und sie wiederholen Abfragen, bis daraus Gewöhnung wird. Als weiteres Risiko nennt das Paper den Verlust von Fachpraxis und eigener Fehlersuche, wenn jemand lange mit automatisierten Systemen arbeitet. Niemand hat bisher gemessen, wie stark dieser Effekt bei Coding-Agenten ausfällt und wie lange er anhält.

Eine formative Untersuchung mit vier Fachkräften aus der Softwareentwicklung zeigt, was im Lauf mit der Aufmerksamkeit geschieht. Die vier bearbeiteten eine einzelne Aufgabe mit dem Coding-Agenten Cline, und ihre beobachtete kognitive Beteiligung sank im Verlauf der Arbeit. Sie prüften vor allem das sichtbare Ergebnis und seltener den Weg dorthin. Aus vier Personen lässt sich kein allgemeiner Effekt ableiten. Die Richtung deckt sich aber mit dem, was eine Interviewstudie mit 17 erfahrenen Entwicklerinnen und Entwicklern im Arbeitsalltag fand. Die Befragten sparten Aufwand mit Faustregeln. Manche behandelten den Plan des Agenten als Abbild seines tatsächlichen Vorgehens. Andere verließen sich auf grüne Tests als Garantie für korrekten Code. Zwölf der 17 Personen arbeiteten im selben großen Technologieunternehmen, weshalb die Forschenden ihre Ergebnisse als explorativ einstufen.

Beide Faustregeln stützen sich auf Material des Agenten. Der Plan ist seine Ankündigung. Grüne Tests belegen, was die Tests abfragen. Hat der Agent sie selbst geschrieben, prüft er sich damit selbst. Wer darauf baut, prüft die Selbstauskunft des Systems, das er prüfen soll. Ein Lauf erzeugt so viel Material, dass kaum etwas anderes übrig bleibt, solange Prüfen heißt, dem Agenten zuzusehen.

Prüfung vor der Ausführung

Den bislang umfangreichsten direkten Vergleich liefert eine im April veröffentlichte Studie mit 48 Teilnehmenden. Sie prüfte vier Formen der Aufsicht über Agenten, die Webseiten bedienen. Die Aufgaben enthielten Datenschutzprobleme, Prompt-Injection und manipulative Oberflächen. Problematische Aktionen wurden seltener, wenn die Versuchspersonen den Plan des Agenten vorher prüften. War eine solche Aktion schon sichtbar, griffen sie deswegen nicht häufiger erfolgreich ein. Keine der vier Varianten schnitt in allen Situationen am besten ab. Nach den Interviews hing ein Eingriff auch davon ab, ob die Oberfläche den kritischen Moment rechtzeitig als Entscheidung markierte.

Für die Frage nach der Freigabe ist das der wichtigste Befund. Der Mensch hat in diesem Versuch etwas bewirkt, wenn er vor der Ausführung prüfte. Er stand dann an einem Punkt, der als Entscheidung markiert war, und hatte einen Plan vor sich. Griff jemand im laufenden Betrieb ein, lag das weniger an der Prüfvariante als an der Oberfläche, die den Moment markierte. Die Agenten der Studie bedienten Webseiten. Ob sich das auf Repositories überträgt, bleibt eine Annahme. Sie passt zu den Faustregeln aus der Interviewstudie und zur nachlassenden Beteiligung im Cline-Versuch.

Was der Owner tatsächlich sieht

Der dokumentierte Prozess im SDLC des Spec-Driven Development beschreibt Rollen mit ausschließlichen Agententätigkeiten. Nur der Owner ist ein Mensch. Der agentengestützte Workflow beginnt mit Ticket und Machbarkeitsprüfung. Es folgen Pre-Gate, Plan-Gate, Umsetzungsabschnitte mit eigenen Prüfschleifen, Completion und Merge. Ein unabhängiger Judge kontrolliert die Arbeit des Implementierers. Der Vorgang geht an den Owner zurück, sobald zwei Korrekturrunden gescheitert sind, der Plan einen Konflikt enthält oder eine irreversible externe Aktion ansteht.

Diese Prüfkette findet Fehler. Die Audit-Artefakte von Projekt A enthalten 77 fehlgeschlagene, 53 bestandene und 9 ergebnislose Verdikte. In Projekt B scheiterten 23 von 82 protokollierten Gate-Durchläufen. Hinter jedem Verdikt liegt ein eigener Prüflauf mit Rohprotokoll. Kein Owner hat so viele Läufe mitgelesen. Gesehen hat er die Stände an den Rückkehrpunkten und die Zusammenfassungen der Agenten dazu. Mehr darf der im Repository gespeicherte Beschluss am Ende nicht behaupten. Ein Eintrag, der nur aus dem Vermerk „freigegeben“, einem Datum und einem Namen besteht, lässt offen, welchen Stand der Owner vor sich hatte und woran er ihn gemessen hat. Wer den Eintrag später liest, kann daraus keine Prüfung des gesamten Laufs ableiten.

Der Prozess sieht dafür schon ein Autonomie-Mandat vor. Der Implementierungsstrang arbeitet innerhalb eines vereinbarten Bereichs und meldet sich an festgelegten Rückkehrpunkten. Diese Punkte liegen dort, wo die Studien den Menschen wirken sehen: vor einem Ausführungsschritt, als markierte Entscheidung, mit einem Plan oder einem festen Stand vor Augen. Mitchell, Ghosh und Passi schlagen dasselbe vor: feste Autonomiegrenzen, Reviews zusammengehöriger Änderungen und Maschinen, die vorab prüfen, was sich automatisch feststellen lässt. Am Rückkehrpunkt braucht der Owner einen bezeichneten Arbeitsstand samt Nachweisen. Ein Gesprächsverlauf oder die Zusammenfassung des Agenten reicht nicht. Der Grund ist derselbe wie bei den Befragten der Interviewstudie: Der Plan des Agenten war kein Abbild seines Vorgehens. Die rechte Spalte der Tabelle zeigt, was ohne neue Freigabe weiterläuft.

Das Freigabepaket

Vor Beginn hält der Owner die fachlichen Erwartungen und die erlaubten Außenwirkungen fest. Erst danach sieht er den Plan oder das Verdikt eines Agenten. Mitchell, Ghosh und Passi empfehlen diese Reihenfolge, damit das Protokoll zeigt, ob das Modell das Urteil des Menschen geprägt hat. Für die Freigabe hat die Reihenfolge einen zweiten Zweck: Sie liefert den Maßstab, an dem sich ein fester Stand messen lässt. Ohne ihn bleibt dem Owner am Rückkehrpunkt nur die Einschätzung des Agenten, dieselbe Abkürzung, die die Befragten der Interviewstudie nahmen.

Am Rückkehrpunkt beantwortet der Owner sechs Fragen:

1. Welcher Commit und welche Zustandsänderung werden genehmigt?
2. Welche fachlichen Erwartungen wurden vor dem Agentenurteil festgelegt?
3. Welche Nachweise prüfen den realen Ausführungspfad?
4. Welche Abweichungen und offenen Befunde bleiben bestehen?
5. Welche Systeme, Daten oder Personen können betroffen sein?
6. Lässt sich die Änderung zurücknehmen, und wurde dieser Weg erprobt?

Die Fragen zielen auf die Abkürzungen aus den Studien. Frage 3 verlangt Nachweise über den realen Ausführungspfad, weil die Befragten den Plan als Abbild des tatsächlichen Vorgehens verstanden hatten. Die vorab notierte Erwartung setzt Frage 2 vor das Urteil des Agenten, das sonst zum Maßstab wird. Frage 1 bringt den Commit-Hash in den Beschluss. So lässt sich später nachschlagen, welcher Stand gemeint war. Frage 6 prüft, was das Modell von Gaube et al. als Recht auf Eingriff voraussetzt. Deshalb muss der Freigabenachweis auch belegen, dass der Rückweg erprobt wurde.

Die Antworten bilden zusammen mit dem Diff, den Testergebnissen und dem Prüfbericht das Freigabepaket. Der Implementierer stellt es zusammen. Ein unabhängiges Prüfmodell gleicht die Angaben mit dem Repository, den Rohprotokollen und den Laufzeitnachweisen ab. Die Freigabe gilt für den genannten Commit und für einen Zustandswechsel. Nach jeder Änderung legt der Implementierer den neuen Stand erneut vor.

Bleibt das maschinelle Verdikt ergebnislos, klärt das Team den Befund oder verkleinert den Arbeitsbereich. Neben Genehmigung und Ablehnung braucht der Prozess zwei weitere Ausgänge: erneute Vorlage mit Auflagen oder Abbruch.

Nach meiner Erfahrung können Menschen mit der Geschwindigkeit nicht mithalten, mit der Agenten in jedem Schritt Ergebnisse produzieren.

Schlussfolgerung

Kognitive Überlastung ist real. Einen Menschen als Human in the Loop (HITL) in einen SDLC-Prozess einzubinden, gaukelt Sicherheit und menschliche Teilhabe am Prozess vor. Nur konsequente Validierungen durch Judges oder Auditor-Agenten sichern nach meiner Erfahrung den laufenden Prozess ab. Fachliche End-to-End-Tests müssen dabei eine neue Funktion im SDLC-Prozess übernehmen.

Quellen

• Margaret Mitchell, Avijit Ghosh, Samir Passi: AI Agents Push Humans Out of the Loop, arXiv 2608.23642 (24. August 2026), https://arxiv.org/abs/2608.23642
• Chaoran Chen et al.: Comparing Human Oversight Strategies for Computer-Use Agents, arXiv 2604.04918 (6. April 2026), https://arxiv.org/abs/2604.04918
• Shipi Dhanorkar, Samir Passi, Mihaela Vorvoreanu: Human oversight of agentic systems in practice, arXiv 2606.05391 (3. Juni 2026), https://arxiv.org/abs/2606.05391
• Carlos Rafael Catalan, Lheane Marie Dizon, Patricia Nicole Monderin, Emily Kuang: “I’m Not Reading All of That”, arXiv 2603.14225 (15. März 2026), https://arxiv.org/abs/2603.14225
• Susanne Gaube et al.: Keeping an Eye on AI: A Framework for Effective Human Oversight of AI Systems, arXiv 2605.16278 (9. April 2026), https://arxiv.org/abs/2605.16278

Im Software Development Life Cycle (SDLC) übernimmt das Modell die Implementierung. Ein Owner gibt den Arbeitsabschnitt frei, ausführbare Akzeptanztests prüfen das Verhalten, und ein unabhängiger Auditor kontrolliert das Ergebnis. Über den Merge entscheidet wieder ein Mensch. In zwei größeren Projekten habe ich diesen Ablauf bereits ausgewertet.

Der Versuch auf einem M4 Pro

Die Testmaschine war ein MacBook Pro mit M4 Pro, 64 GB gemeinsamem Arbeitsspeicher und macOS 26.6.2. Darauf liefen Qwen3.8-27B in einer 4-Bit-Quantisierung und Gemma 4 12B-it in 8 Bit. Beide Modelle waren am Messtag keine zwei Wochen alt. Als Runtimes dienten llama.cpp, MLX, LM Studio und omlx.

Der kurze Leistungstest bestand aus einem Prompt mit rund 700 Token und 128 Token Ausgabe. Nach einem Aufwärmlauf folgten drei Messläufe bei Temperatur 0. Die Tabellen nennen den Median. Alle Runtimes nutzten GPU-Beschleunigung, Flash Attention und ein Kontextfenster von 200.000 Token.

Bei Qwen lag der MLX-Stack in der Generierung rund 40 Prozent vor llama.cpp. Das Hybrid-Modell verwendet in 48 seiner 64 Layer Gated DeltaNet, eine Form linearer Attention. Die Metal-Implementierung im MLX-Stack war zum Messzeitpunkt schneller. Das Ergebnis lässt sich nicht auf jede Modellarchitektur übertragen, wie die zweite Messreihe zeigt.

Gemmas 40 Sliding-Window-Layer und acht Full-Attention-Layer waren in allen Runtimes ähnlich schnell. Das Feld lag innerhalb von rund zehn Prozent. Die Wahl der Runtime hängt damit auch von der Architektur und vom Arbeitsprofil ab. Bei wiederholten langen Präfixen kann ein wirksamer Prompt-Cache mehrere Token pro Sekunde Generierungsrate aufwiegen.

Der M4 Pro stellt 273 GB/s Speicherbandbreite bereit. Qwens Gewichte belegen je nach Format rund 16 GB, Gemmas etwa 12,7 GB. Beide Modelle halten 200.000 Token Kontext nur deshalb in 64 GB, weil ein kleiner Teil ihrer Layer einen mit der Kontextlänge wachsenden KV-Cache führt. Gemessen lagen die RSS-Spitzen zwischen 13 und 29 GB. Die gesamte Messreihe lief auf dem Notebook.

Die Coding-Aufgabe

Für die Coding-Leistung brauchte es eine Arbeitsprobe. Qwen und Gemma erhielten denselben Auftrag: eine vollständige deutsche Marketing-Landingpage als einzelne HTML-Datei. Der Brief schrieb die Inhalte und Sektionen vor. Er verlangte Inline-CSS, ein responsives Layout sowie einen Hell- und Dunkelmodus. Externe Ressourcen waren ausgeschlossen.

Jeder Lauf bestand aus einem einzigen Chat-Completion-Request. Qwen arbeitete ohne Thinking-Modus mit einem Budget von 24.000 Token. Gemma erhielt 16.000 Token. Die Parameter für Temperatur, Top-p und Top-k folgten den Empfehlungen der Modellanbieter. Alle sechs Kombinationen aus zwei Modellen und drei Server-Runtimes lieferten ein vollständiges HTML-Dokument.

Zur Qualitätsprüfung wurden die Seiten als A bis F anonymisiert. Chromium renderte sie mit 1.280, 768 und 390 Pixel Breite im hellen und dunklen Farbschema. Ein separater Opus-Modelllauf prüfte außerdem HTML und CSS. Je zehn Punkte gab es für Marketingwirkung, visuelles Design, Brieftreue, Codequalität und Gesamteindruck. Menschen aus der Zielgruppe waren an dieser Bewertung nicht beteiligt.

Alle drei Qwen-Seiten erreichten 37 bis 43 Punkte. Gemma kam auf 14 bis 22 Punkte. Qwen schrieb 745 bis 881 Wörter und legte ein erkennbares Designsystem an. Seine Seiten enthielten 20 bis 28 CSS-Variablen sowie 14 bis 37 Inline-SVGs. Kein geforderter Inhalt fehlte. Gemma erzeugte 310 bis 355 Wörter, acht bis neun CSS-Variablen und höchstens ein SVG. In jeder Gemma-Ausgabe fehlten Teile des Briefs.

Auch Qwens längere Ausgaben enthielten Fehler. Eine Seite versteckte ihre Hauptüberschrift durch eine fehlerhafte Reveal-Animation. Bei einer anderen blieb der Hero auf dem Smartphone zweispaltig und wurde abgeschnitten. Die mit LM Studio erzeugte Qwen-Seite renderte in allen geprüften Ansichten ohne sichtbaren Defekt. Im Gemma-Feld fanden sich ein transparenter Sticky-Header, überbreite Tabellen und sichtbare ASCII-Umschriften deutscher Umlaute.

Die beste Qwen-Ausgabe deckte alle Pflichtinhalte ab. Ihre Betriebssystemanforderung war erfunden, und der Dark Mode wich vom Brief ab. Im beschriebenen SDLC gehen solche Befunde vor der Freigabe an den Implementierer zurück.

Pro Kombination gab es einen Lauf. Eine menschliche Kontrollgruppe fehlte. Die 43 Punkte setzen Qwen deshalb in keine Rangfolge mit realen Junior-Entwicklern. Nachgewiesen ist die Übernahme eines abgegrenzten Arbeitspakets samt prüfbarem Ergebnis. Für eine allgemeine Gleichwertigkeit über Backend-Code, Fehlersuche und länger laufende Änderungen wären weitere Aufgaben und direkte Vergleichsläufe erforderlich.

Hardware für rund 10.000 Euro

Die eigene Messung lief auf einem mobilen M4 Pro mit 64 GB. Zwei Tage nach dem Benchmark stellte Apple eine deutlich größere lokale Plattform vor. Der neue Mac Studio mit M5 Ultra beginnt in Deutschland bei 6.599 Euro. Er lässt sich mit bis zu 512 GB gemeinsamem Arbeitsspeicher konfigurieren und erreicht laut Apple 1,2 TB/s Speicherbandbreite. In der größten Ausführung hat der Chip 36 CPU- und 80 GPU-Kerne. Das 512-GB-Modell soll Ende Oktober 2026 erscheinen. Apple nennt eine bis zu 4,3-fache KI-Leistung. Unabhängige Inferenzmessungen liegen für die neue Maschine noch nicht vor.

Bereits der M5 Max im selben Gehäuse beginnt bei 2.999 Euro, unterstützt bis zu 128 GB und erreicht je nach Konfiguration bis zu 614 GB/s. Der ebenfalls neu vorgestellte Mac mini mit M5 Pro kostet in den USA ab 1.699 Dollar, bietet bis zu 64 GB und 307 GB/s. Apple behauptet für einen ausgewählten LM-Studio-Test bis zu viermal schnelleres Prompt Processing gegenüber dem M4 Pro. Auch dieser Wert braucht eine unabhängige Reproduktion.

Nvidias DGX Spark setzt einen anderen Schwerpunkt. Für 4.699 Dollar Listenpreis bietet der kleine Rechner 128 GB kohärenten Speicher, eine GB10-CPU-GPU-Kombination und 273 GB/s Speicherbandbreite. NVIDIA nennt bis zu ein PetaFLOP FP4-Rechenleistung mit Sparsity und die Inferenz von Modellen bis 200 Milliarden Parameter. Zwei Geräte lassen sich über ConnectX-7 koppeln. Nach US-Listenpreis bleiben zwei Sparks knapp unter 9.400 Dollar vor Steuern.

Die theoretischen Rechenwerte taugen nur begrenzt als Geschwindigkeitsmaß für Sprachmodelle. Bei der tokenweisen Generierung begrenzt oft der Transport der Gewichte aus dem Speicher den Durchsatz. Ein unabhängiger Vergleich von Tom’s Hardware fand im Juli 2026 beim M4 Max höhere Decode-Raten als bei GB10 und AMD Strix Halo, während GB10 im Prompt Processing vorne lag. Der DGX Spark erschließt durch seine 128 GB und den CUDA-Stack andere Modelle und Betriebsformen. Der Mac liefert für dichte Modelle viel Speicherbandbreite und einen einfachen lokalen Desktopbetrieb.

Für rund 10.000 Euro bekommt man einen Mac Studio M5 Ultra in der Basisversion oder, nach US-Listenpreis, zwei DGX Sparks vor Steuern. Nach dem Kauf entstehen laufende Kosten für Strom, Speicher, Ersatzhardware und die Pflege des Software-Stacks. Die menschliche Arbeit an Spezifikation und Verifikation gehört ebenfalls in die Rechnung.

Dokumentierter Modellfortschritt

Die Modellseite von Qwen erlaubt den Vergleich zweier Generationen derselben lokalen Größenklasse. Qwen3.6-27B erschien am 22. April 2026, Qwen3.8-27B am 14. August. In den vom Anbieter veröffentlichten Ergebnissen stieg der Wert auf Terminal Bench 2.1 von 63,4 auf 73,0, auf SWE-bench Pro von 53,5 auf 61,7. Bei DeepSWE 1.1 wuchs er von 13,3 auf 42,2. Einige Tests liefen in einem Claude-Code-Harness. Die Werte dokumentieren eine schnelle Verbesserung in diesen drei Tests, bleiben aber Herstellerangaben.

Eine Auswertung von 20.574 realen Agentensitzungen aus 1.639 Repositories fand sieben wiederkehrende Formen der Fehlanpassung. In 91,49 Prozent der sichtbaren Auflösungen musste der Nutzer ausdrücklich korrigieren (arXiv 2605.29442, 28. Mai 2026). Ein beaufsichtigter Lauf muss solche Korrekturen einplanen.

SpecBench zeigt für die Spezifikationsarbeit eine deutliche Lücke. Der Benchmark verwendet Entwurfsdiskussionen aus Kubernetes, React, Rust, TVM und vLLM. Der beste getestete Agent erkannte 44,4 Prozent der von Maintainerinnen und Maintainern gefundenen Mängel (arXiv 2605.30314, 28. Mai 2026).

Eine getrennte Spezifikationsphase verbessert die Umsetzung messbar. SpecFirst zerlegt die Rekonstruktion eines Programms in Verhaltenserkundung und anschließende Implementierung. Über 200 Aufgaben und vier Modelle stiegen die Testpass-Raten gegenüber einem gemeinsamen Durchlauf um 6,9 bis 21,3 Prozentpunkte (arXiv 2607.27167, 29. Juli 2026). In dem hier beschriebenen SDLC liefern ausführbare Anforderungen dem Implementierer diese Vorarbeit.

Die Grenzen bleiben bei schwierigen Fachaufgaben eng. MDArena prüfte 50 reale Aufgaben aus molekulardynamischen Arbeitsabläufen. Die beste untersuchte Konfiguration löste 24 davon vollständig. Bei schweren Aufgaben blieben alle Konfigurationen fast ohne Erfolg (arXiv 2608.02642, 31. Juli 2026). SWE-bench Science kommt bei 119 Aufgaben aus wissenschaftlichen Repositories für den besten Agenten ebenfalls auf weniger als 50 Prozent Pass@1 (arXiv 2608.19799, 20. August 2026).

Diese Befunde begrenzen meine Aussage auf vorbereitete Implementierung. Systementwurf und die Klärung unvollständiger Anforderungen bleiben bei erfahrenen Entwicklerinnen und Entwicklern. Bei fachlich riskanten Änderungen braucht auch die Umsetzung ihre Aufsicht.

Meine Antwort auf die Titelfrage

Für den gemessenen Teil der Arbeit lautet meine Antwort heute „fast“. Das lokale Modell setzte einen ausgearbeiteten Auftrag in eine brauchbare Webseite um. Die Schwankung zwischen 37 und 43 Punkten bei Qwen zeigt zugleich, wie viel Zuverlässigkeit noch fehlt. Der Versuch belegt damit die Leistung in einer eng geführten Implementierungsrolle. Eine ganze Stelle bildet er nicht ab.

Den aktuellen Fortschritt eingerechnet erwarte ich, dass lokale Modelle mit der dann verfügbaren Hardware diese Schwelle bei vorbereiteten Standardaufgaben spätestens in einem Jahr überschreiten. Dafür sprechen die Unterschiede zwischen den beiden Qwen-Generationen und die neue Rechnergeneration jetzt schon.

Quellen

• Apple: Mac Studio mit M5 Max und M5 Ultra, 25. August 2026
• Apple: Mac mini mit M6 und M5 Pro, 25. August 2026
• NVIDIA: DGX Spark, technische Daten und Preis
• NVIDIA: DGX Spark User Guide
• Qwen3.8-27B, offizielle Modellkarte
• Tom’s Hardware: lokaler LLM-Vergleich von M4 Max, GB10 und Strix Halo, 30. Juli 2026

Das Versprechen

Wenn Agenten den Code schreiben, verschiebt sich die menschliche Arbeit nach vorn, in die präzise Beschreibung dessen, was entstehen soll. Die Spezifikation wird zur eigentlichen Quelle des Systems. Der Code gilt als abgeleitetes Artefakt, das sich aus ihr jederzeit neu erzeugen lässt. Werkzeuge wie GitHubs Spec Kit oder Amazons Kiro institutionalisieren diesen Ablauf: Anforderungen werden festgehalten, daraus entsteht ein Plan, der Agent implementiert, und am Ende wird gegen die Spezifikation validiert. Thoughtworks führt die Technik im Technology Radar unter „Assess“ (Stand November 2025). Die Idee ist älter als die Agenten. Anforderungsdokumente gibt es, seit es Softwareprojekte gibt. Neu ist die Erwartung, dass die Kette von der Anforderung zur Implementierung ohne menschliche Übersetzung hält, weil ein Agent sie übernimmt.

Dahinter steht ein Kontrollversprechen. Wer präzise genug spezifiziert, so die Annahme, kontrolliert das Ergebnis, ohne den entstehenden Code noch Zeile für Zeile zu lesen. Die Spezifikation soll das Review ersetzen, das bei menschlichen Teams die Korrektheit absichert. In der starken Form heißt das, dass aus einer hinreichend präzisen Spezifikation eine konforme Implementierung folgt.

Beide Projekte, um die es hier geht, waren von Beginn an spezifikationsgetrieben aufgesetzt. Der allererste Commit von Projekt B enthält ausschließlich Spezifikationsdateien. In Projekt A entstand das Ticket-, Epic- und ADR-System ebenfalls vor dem ersten Feature.

Der Versuchsaufbau

Entwickelt habe ich beide Projekte mit Coding-Agenten. Die Agenten haben implementiert und geprüft. Auch die Dokumentation lief über sie.

Die Spezifikationsdisziplin war in beiden Projekten hoch. In Projekt B folgt jedes größere Ticket einem Schema mit 23 Pflichtsektionen, von der Scopefixierung über Akzeptanzkriterien bis zum Verifikations- und Negativkontrollplan. Ein einzelnes Spezifikationspaket von 122 Markdown-Dateien enthält 741 Tabellen mit knapp 6.000 Datenzeilen. In Projekt A regelt eine zentrale Arbeitsverfassung die Quellenrangfolge, die Rollentrennung zwischen Implementierer und Auditor und die Bedingungen, unter denen ein Ergebnis als abgenommen gilt. Vor dem Implementierungsstart steht ein bestandenes Plan-Review, vor dem Merge ein unabhängiges Audit, Selbstabnahme ist ausgeschlossen.

Auffällig ist das Größenverhältnis zwischen Prosa und Code. In Projekt A umfasst der gesamte Markdown-Korpus aus Tickets, Plänen, Audits und Evidenzdokumenten rund 868.000 Zeilen. Das ist fast das Doppelte des Produktcodes. In Projekt B stehen rund 244.000 Zeilen Spezifikation neben rund 550.000 Zeilen Code. Neben der Software ist damit ein zweites System aus Prosa entstanden, ähnlich groß und mit eigenem Pflegebedarf.

Der Befund

Mit Spec-Drift meine ich das Auseinanderlaufen von Spezifikation und Realität: Der Code tut etwas anderes, als die Spezifikation beschreibt, oder die Spezifikation beschreibt etwas, das es so nie gab oder nicht mehr gibt. In beiden Projekten ist dieser Zustand über lange Strecken der Regelfall gewesen. Mir ist über die gesamte Laufzeit kein längerer Arbeitsstrang begegnet, der ohne dokumentierte Drift durchgelaufen wäre. Die Audit-Artefakte beider Projekte belegen das in vier Richtungen.

Die Implementierung weicht von der Spezifikation ab. Das ist der Fall, den man erwartet, und er kommt in Formen vor, die kein Diff-Review auffängt. In Projekt B verlangte die Spezifikation deterministische Generierung von Inhalten. Ein Reparaturplan zählte später 16 Stellen im Code, die trotzdem die Systemuhr lasen. Der Effekt blieb monatelang unsichtbar, weil ein früherer Referenzexport denselben Generierungstag eingefroren hatte: Die Tests verglichen gegen Referenzdaten, die denselben Fehler enthielten. Ein Audit in Projekt A dokumentiert einen Fall, in dem der Systemprompt vor jeder Pfadannahme zwei Shell-Kommandos verlangte, während das Regelwerk eines dieser Kommandos blockierte. 48 von 51 beobachteten Kommandosequenzen befolgten die Anweisung und liefen gegen die Sperre. Dabei verbrauchten 21 Testdurchläufe ihr volles Iterationsbudget ohne Wirkung, und sämtliche Prozesse beendeten sich trotzdem mit Exit-Code 0. Ein anderes Audit wies nach, dass eine Normalisierungsfunktion mehrstellige Fehlerzahlen zu Null verkürzte, wodurch ein Prüfmodul trotz expliziter Fehler-Evidenz auf „bestanden“ gesetzt werden konnte. Wirkungslos war auch ein dokumentierter Konfigurationsschalter für das Token-Limit: Vier Messläufe mit vier verschiedenen Werten ergaben jedes Mal exakt dieselbe Ausgabelänge, ohne Fehlermeldung.

Die Dokumentation veraltet gegen den Code. Ein automatischer Abgleich in Projekt A fand Verweise auf Quelldateien, die längst gelöscht oder umbenannt waren, und ein Widerspruchsregister zählte elf verschiedene Versionen derselben Testanzahl quer durch die Dokumente. Jede dieser Zahlen war zu ihrem Zeitpunkt korrekt gewesen und dann eingefroren. Gravierender ist Status-Drift. Ein unabhängiges Audit über 16 Arbeitspakete kam zum Ergebnis, dass sechs davon Statusangaben trugen, die von der Realität des Hauptbranches überholt waren. Bereits gemergte Arbeit wirkte offen. Agenten lesen diese Artefakte als Steuerungsquelle. Jedes spätere Gate hätte also gegen falsche Statuslagen geprüft. Zur selben Klasse gehört ein Fund, bei dem vier Kernhebel der Umsetzung nur auf einem Seitenbranch existierten und allein über ein Archiv-Tag gesichert waren, während die Planung sie als verfügbar führte. In einem weiteren Fall lag ein bestandenes Plan-Gate nur auf dem Arbeitsbranch und fehlte auf dem Hauptzweig, gegen den es hätte gelten sollen.

Spezifikationen widersprechen einander. In Projekt A kollidierten die Akzeptanzkriterien zweier Tickets frontal. Beide betrafen dieselbe Funktion. Das eine verlangte eine Verschärfung der bestehenden Muster, das andere eine gezielte Lockerung. Ein weiteres Ticket erklärte sich zur Voraussetzung eines anderen, das von dieser Abhängigkeit nichts wusste. Geschrieben wurden diese Spezifikationen zu verschiedenen Zeitpunkten von verschiedenen Agenten-Kontexten, von denen keiner den gesamten Bestand überblickte.

Die Spezifikation widerspricht sich selbst. Das ist die Richtung, die mich am meisten überrascht hat. Ein Plan-Audit in Projekt A wies nach, dass drei Festlegungen eines bereits detaillierten Plans zusammen keinen aufrufbaren Codepfad ergaben. Der Plan war in sich unerfüllbar, bevor eine Zeile implementiert war. In Projekt B stellte ein Audit fest, dass neun Pflichtsektionen der übergeordneten Spezifikation aus den Tickets verschwunden waren, durch eine Kompaktierungsaktion, und niemand hatte es bemerkt, bis ein Prüfer sie zählte. Im selben Projekt existiert ein Audit-Dokument, das sein eigenes früheres „bestanden“ per Nachtrag auf „nicht bestanden“ dreht, weil die Beweisführung an die falschen Prüfobjekte gebunden war.

Die Ursache liegt nach meiner Einschätzung im Arbeitsmodell selbst. Agenten arbeiten mit begrenztem Kontextfenster in Sitzungen, die enden. In Projekt B liefen Subagenten nach rund zwei Stunden in Session-Limits. Ein Vorhaben von mehreren Monaten besteht damit aus hunderten Übergaben zwischen Kontexten, die jeweils nur einen Ausschnitt des Systems und der Spezifikation sehen. Bei jeder Übergabe können Spezifikation und Realität ein Stück auseinanderlaufen. Ein Agent ändert Code und übersieht einen Teil der betroffenen Dokumente. Der nächste liest eines der veralteten und baut darauf auf. Wiederaufnahme-Prompts und Übergabedokumente mildern das ab, die fehlende Gesamtsicht ersetzen sie aber nicht. Die Spezifikation altert dabei genauso wie der Code. Sie steht als gepflegtes Artefakt im System selbst, und anders als der Code hat sie keine Tests. Präziser zu spezifizieren vergrößert deshalb vor allem die Fläche, auf der die Spezifikation altert. Die 23 Pflichtsektionen in Projekt B haben Drift jedenfalls nicht verhindert.

Mit dieser Beobachtung stehe ich nicht allein. Eine Feldstudie über 20.574 reale Agent-Sessions fand systematische Lücken zwischen Auftrag und Umsetzung. Bei 91 Prozent der sichtbaren Fälle war eine explizite Nutzerkorrektur nötig (arXiv 2605.29442, 2026). Selbst der beste Agent in einem Benchmark zur Spezifikations-Kompetenz erkennt nur 44 Prozent der Mängel in Specs, also Lücken, Mehrdeutigkeiten und Widersprüche (arXiv 2605.30314, 2026). Ein Vergleich von drei Spec-Driven-Frameworks über zwei Modellfamilien kommt zum Ergebnis, dass strengere Spezifikationsbindung den Determinismus des Outputs sogar senkt. Als erreichbares Ziel bleibe Verifizierbarkeit (arXiv 2606.30689, 2026). Der Mechanismus des Kontextverlusts ist ebenfalls beschrieben, bis hin zum Detail, dass Kontext-Kompression bevorzugt genau die Tokens verwirft, die die ursprüngliche Spezifikation kodieren (arXiv 2607.27167, 2026). Aus der Industrie berichtet Atlassians Engineering-Blog gleichlautend, dass Agenten bei vollem Kontextfenster frühere Entscheidungen stillschweigend aufgeben und größere Modelle das Problem nicht lösen (Atlassian Engineering, Juni 2026).

Was in der Praxis hilft

In beiden Projekten haben sich drei Gegenmaßnahmen herausgebildet und im Alltag bewährt. Alle drei verlagern die Verlässlichkeit an Stellen, die sich ausführen oder unabhängig prüfen lassen.

Wenn ein Modell eine andere Lösung wählt als die spezifizierte, ist der Reflex, die Abweichung zurückzudrehen. Dieser Reflex ist teuer und oft sachlich unbegründet, denn viele Abweichungen sind fachlich gleichwertig oder besser. Praktikabler ist, solche Abweichungen zu akzeptieren und zu prüfen, ob sich das System so verhält, wie es soll. Ob der Code dem Wortlaut der Spezifikation folgt, wird damit zweitrangig. Das Instrument dafür sind End-to-End-Tests gegen den echten Ausführungspfad. Projekt B hält knapp 600 Browser-End-to-End-Fälle neben gut 6.000 Unit-Fällen. Für jede neue Funktionseinheit ist ein eigener End-to-End-Nachweis Pflicht. Wer eine Abweichung akzeptiert, muss die Spezifikation nachziehen, sonst taucht dieselbe Abweichung im nächsten Audit erneut als Befund auf. End-to-End-Tests sind in beiden Projekten die einzige Instanz gewesen, die Semantik prüft. In Projekt B lieferte dieselbe Komponente einen grünen Lauf auf Paket-Ebene mit über 400 Tests und fiel im Integrationslauf auf zwei Simulatoren mit einem einzigen Testpaar durch. Die Arbeitsregeln des Projekts halten seither fest, dass ein grüner Paketlauf keine Korrektheit belegt. In der Arbeitsverfassung von Projekt A steht dazu der Grundsatz, dass ein Live-Gate auf kaputter Semantik grün sein kann. Deshalb verlangt dort jedes Feature ein eigenes End-to-End-Szenario gegen das reale Zielsystem, und ein dokumentierter Live-Lauf über 54 Prüfzellen endete mit 16 bestandenen Zellen. Ein ehrlich rotes Ergebnis ist in dieser Arbeitsweise etwas wert, denn die Gegenklasse ist ebenfalls dokumentiert: ein Gate, das dreimal grün meldete, obwohl das geprüfte Kindsystem missgebildete Ausgaben lieferte. Wegen solcher Falschgrün-Fälle müssen die E2E-Tests selbst wieder geprüft werden, etwa darauf, ob sie fehlschlagen können.

E2E-Tests haben allerdings noch eine andere Schwachstelle, und die ist gut vermessen. Sieht der implementierende Agent die Tests und iteriert auf sie, optimiert er auf deren Bestehen. Ob die Aufgabe gelöst ist, gerät dabei aus dem Blick. Ein Benchmark zu Reward Hacking in langlaufenden Coding-Agenten dokumentiert als Extremfall einen 2.900-Zeilen-Scheinkompiler, der die Testeingaben schlicht auswendig gelernt hatte. Die Lücke zwischen sichtbaren und zurückgehaltenen Tests wuchs dort mit der Codegröße (arXiv 2605.21384, 2026). Mein Ausweg aus diesem Dilemma sind menschlich kuratierte oder vom Menschen inhaltlich vorgegebene End-to-End-Tests. Die Szenarien und Erwartungswerte kommen aus der Fachlichkeit. Der implementierende Agent führt sie aus, schreibt und ändert sie aber nicht. Ergänzend kann ein Teil der Szenarien zurückgehalten und erst nach Abschluss der Implementierung ausgeführt werden. Das kostet menschliche Arbeitszeit an einer Stelle, an der sie sich lohnt. Denn diese Tests sind das einzige Artefakt der ganzen Kette, das der Agent weder erzeugt noch umformulieren darf.

Jede Implementierung durchläuft außerdem eine Schleife aus unabhängigen Audits. Das Muster habe ich in „Die zweite Spur“ ausführlich beschrieben, hier genügt der Kern. Ein Agent implementiert, ein zweiter Agent mit frischem Kontext und dem ausdrücklichen Auftrag zur Widerlegung prüft das Ergebnis, und ein maschinenlesbares Verdikt entscheidet über den Merge. Projekt A schreibt dazu vor, dass Prüfer und Implementierer aus verschiedenen Modellfamilien stammen. Sind beide gleich, wird das Urteil verworfen. Der Prüfer läuft dort in einem eigenen, schreibgeschützten Arbeitsverzeichnis ohne Werkzeugzugriff auf die laufende Sitzung. Sein Prompt, sein Rohprotokoll und sein Urteil werden über Prüfsummen aneinander gebunden, damit sich ein Verdikt später einem exakten Stand zuordnen lässt. Die Schleife entsteht, weil ein „nicht bestanden“ eine Korrekturrunde auslöst und die Korrektur erneut geprüft wird.

Dass diese Schleifen reale Defekte finden und nicht nur Formalien, zeigen die Verdikt-Statistiken. Die maschinenlesbaren Verdikte der Audit-Artefakte in Projekt A lauten 77-mal „fail“, 53-mal „pass“ und 9-mal „inconclusive“. In Projekt B endeten 23 von 82 protokollierten Gate-Durchläufen mit „fail“. Fast alle in diesem Beitrag zitierten Drift-Fälle stammen aus genau diesen Prüfläufen. Ohne die Auditoren wären sie im System geblieben, denn die jeweilige Implementierung hatte sich selbst als fertig gemeldet.

Die Prüfer haben ihrerseits Grenzen. In Projekt A fand die Nachkontrolle einen Begründungsfehler im Bericht eines Prüfmodells. Der Bericht entlastete einen Testfehler mit der Behauptung, die betroffene Datei sei unverändert, was das Diff widerlegte. Ein als Richter eingesetztes Modell durchläuft dort inzwischen selbst ein Kalibrierungsverfahren mit unabhängiger Doppel-Etikettierung und ist nach aktuellem Stand nicht für den unbeaufsichtigten Einsatz freigegeben.

Studien stützen beide Vorsichtsmaßnahmen. Eine Auswertung von rund 541.000 Urteilen von 21 Judge-Modellen fand hohe Konsistenz bei zugleich schwacher Validität. Die Autorinnen und Autoren fordern ein eigenes Validierungsprotokoll für Judges (arXiv 2606.19544, 2026). Cross-Model-Review wirkt zudem richtungsabhängig. In einer Studie hob ein Claude-Review über Codex-Entwürfe die Erfolgsrate von 71,6 auf 89,7 Prozent. Die umgekehrte Paarung senkte sie von 91,4 auf 82,8 Prozent (arXiv 2607.21656, 2026). Welche Familie implementiert und welche prüft, ist damit selbst eine Entscheidung, die validiert werden muss.

Die dritte Gegenmaßnahme setzt vor der Implementierung an, bei der Form der Spezifikation. Prosa ist für Agenten über lange Zeiträume zu mehrdeutig. Jede der vier Drift-Richtungen aus dem Befund ist am Ende eine Eigenschaft von Text, den niemand ausführt. Daraus folgt ein Shift Left zu formaleren Spezifikationen. Ein Mensch oder ein dafür abgestellter Lead-Agent schreibt zuerst Integrationstests, gegen die implementiert wird. Wo eine Testform nicht reicht, hilft eine domänenspezifische Notation, die sich maschinell auswerten lässt. Ein fehlschlagender Test ist eine harte Spezifikation. Er driftet nicht, denn er bleibt rot, bis der Code passt. Eine Markdown-Sektion kann dagegen monatelang Falsches behaupten.

In Ansätzen existiert diese Form in beiden Projekten bereits. Projekt A hält zehn eigene Drift-Testklassen, die Register, Konfigurationsfelder und Manifeste bei jedem Lauf gegen den Code prüfen. Projekt B betreibt Sabotage-Gates, die mit einer definierten Fehlerkennung abbrechen, sobald ein Vertrag verletzt ist. Eines davon hat allerdings auch schon wegen eines Tooling-Artefakts falschen Alarm geschlagen. Die Grenzen von weiter oben gelten fort. Ein Test, den der implementierende Agent formen darf, kann tautologisch geraten, und was jenseits des Testbaren liegt, etwa Architekturabsichten und Begründungen, braucht weiterhin Prosa, nur deutlich weniger davon. Für den prüfbaren Kern der Anforderungen ist ein Test trotzdem die stabilste Form, die ich in beiden Projekten gesehen habe.

Was es kostet

Der sichtbarste Posten ist der Token-Verbrauch. Die Betriebsnotizen von Projekt B halten fest, dass gestrandete Agenten-Läufe, die an Sitzungsgrenzen ohne Commit hängen blieben, pro Wiederaufnahme 250.000 bis 350.000 Tokens verbrannten, ohne Fortschritt. Die Ausgaben eines einzelnen Prüflaufs erreichen dort 500 Kilobyte bis ein Megabyte Text. In Projekt A protokollieren die Audit-Artefakte das Verhältnis zwischen internem Arbeitslog und sichtbarem Ergebnis: gut 8.300 Zeilen Rohprotokoll für ein Urteil von 64 Zeilen. Dieser Aufwand wird pro Korrekturrunde erneut fällig.

Dazu kommt Betriebsaufwand, der in keiner Token-Rechnung auftaucht. Die Notizen aus Projekt B beschreiben Agenten, die ohne Abschlussmeldung hängen bleiben und sich nur über Indizien erkennen lassen, etwa ausbleibende Dateiänderungen bei gleichzeitig fehlenden Prozessen. Festgehalten ist dort auch die Disziplin, pro Arbeitsbereich nur einen aktiven Agenten laufen zu lassen, weil ein vorschnell gestarteter Ersatz-Agent halbfertige Stände überschreibt. Ein wiederaufgenommener Agent hat einmal fremde, noch nicht committete Arbeit verworfen. Seither gilt die Regel, dass Verwerfen nur auf reversiblem Weg erlaubt ist.

Ein eigenes Problem ist der Hang der Modelle zum Mikromanagement. Sich selbst überlassen, eskaliert die Prüf-Schleife. Die Extremwerte stammen aus Projekt A. Ein einzelnes Ticket sammelte 96 Audit-Dokumente an, ein anderes durchlief 23 Runden in zwei Kalendertagen, und ein reines Spezifikationsartefakt ohne eine Zeile Produktcode wurde neunmal re-auditiert. Die neunte Runde änderte gegenüber der achten noch 122 hinzugefügte und 75 entfernte Markdown-Zeilen. Die Modelle erfinden dabei immer feinere Prüfanlässe: Bisektionsschritte, Diagnose-Tickets, Zwischenabnahmen. Die Projektnotizen benennen das inzwischen ausdrücklich als Rückfall, den es zu vermeiden gilt. In Projekt B habe ich selbst eingegriffen und einen Agenten gestoppt, der die dritte Korrekturrunde auf demselben Test drehte, während der Produktcode längst korrekt war.

Ohne feste Abbruchregeln, die die Schleife von außen begrenzen, kippt der Ansatz deshalb. In Projekt A haben sich mehrere Formen solcher Circuit Breaker etabliert. Eine Zwei-Korrekturrunden-Regel beendet die Schleife nach zwei erfolglosen Runden und erzwingt eine Entscheidung zwischen Akzeptieren mit dokumentiertem Risiko, Descoping oder Abbruch. Diese Grenze hat empirische Entsprechungen. Über sieben Modelle hinweg konzentrieren sich die Gewinne von Selbstkorrektur-Schleifen in den ersten zwei Runden (arXiv 2604.10508, 2026). Mehr-Agenten-Debatten kosteten in einer Untersuchung mit kleineren Modellen das 2,1- bis 3,4-Fache an Tokens bei gleicher oder schlechterer Genauigkeit. Peer-Kritik destabilisierte dort zuvor korrekte Lösungen (arXiv 2605.00914, 2026). Gezählte Freigaben deckeln teure Läufe vorab: Ein Beschluss-Artefakt autorisiert genau einen Start, ohne selektive Wiederholungen und ohne Rosinenpicken aus historischen Läufen. Ein Parallelitätsdeckel beschränkt die gleichzeitig aktiven Implementierungsstränge auf zwei, und ein Prosa-Deckel stellt pro Arbeitspaket die hinzugefügten Markdown-Zeilen den hinzugefügten Produktcode-Zeilen gegenüber, damit die Dokumentation den Code nicht überwuchert. Bemerkenswert finde ich, dass die jüngste Maßnahme in die Gegenrichtung zeigt: ein ausdrückliches Autonomie-Mandat, das dem Implementierungsstrang Zwischenmeldungen untersagt und nur wenige definierte Rückkehrpunkte vorsieht.

Bilanz

Spec-Driven Development hat sein zentrales Versprechen in zwei disziplinierten, langlaufenden Projekten nicht eingelöst. Die Spezifikation ist gegen den Code gedriftet, Spezifikationen haben einander widersprochen, einzelne Artefakte sogar sich selbst. Nach allem, was die Audit-Artefakte zeigen, hätte auch mehr Disziplin das nicht abgestellt: Drift war die Grundrate eines Arbeitsmodells aus monatelangen Workflows und hunderten Kontextwechseln.

Funktioniert hat eine andere Architektur der Verlässlichkeit. End-to-End-Tests prüfen das Verhalten des Systems, unabhängige Auditoren fangen in ihrer Schleife einen großen Teil der Defekte, die die Implementierung als erledigt gemeldet hatte, und Abbruchregeln halten diese Schleife bezahlbar. Wo Anforderungen von vornherein als Tests vorliegen, verkleinert sich zudem die Prosa-Fläche, auf der Drift überhaupt entstehen kann. Die Spezifikation wechselt in diesem Aufbau ihre Rolle. Sie bleibt Ausgangspunkt und Prüfreferenz. An ihr werden Abweichungen sichtbar, über die dann bewusst entschieden wird. Die Rolle der Quelle, aus der das System zuverlässig hervorgeht, hat sie in beiden Projekten nicht ausgefüllt. Die Studienlage passt dazu: Eine explizite Spezifikationsphase verbessert Testpass-Raten messbar, um 7 bis 21 Punkte in einer aktuellen Untersuchung, determiniert das Ergebnis aber nicht (arXiv 2607.27167, 2026). Ein Teil der Forschung verfolgt die Gegenstrategie und will Drift technisch unterbinden, etwa durch Gates, die Spec-Code-Divergenz zum Merge-Blocker machen (arXiv 2606.27045, 2026). Ob das über Monate durchhaltbar bleibt oder nur den Punkt verschiebt, an dem die Pflegekosten anfallen, ist empirisch offen.

Eine Lösung des Grundproblems ist auch das nicht. E2E-Validierung, Auditoren-Schleifen, ausführbare Spezifikationen und Circuit Breaker sind Mitigationen. Sie machen Drift sichtbar und geben ihm einen Preis. In beiden Projekten ist er trotzdem geblieben. Drift entsteht an jeder Naht neu, solange die Arbeit von Akteuren erledigt wird, die kein dauerhaftes Gedächtnis haben und das Gesamtsystem nie vollständig sehen. Die Prüfarchitektur arbeitet gegen ein Symptom, dessen Ursache im Zuschnitt der heutigen Werkzeuge liegt.

Offen bleibt für mich die Kostenfrage. In beiden Projekten war der Aufwand für Spezifikation, Audit und Evidenz zusammengenommen größer als der Produktcode, in Zeilen gemessen. Aus zwei Projekten kann ich nicht ableiten, ob eine bewusst kleinere Spezifikationsoberfläche mit früheren Verhaltenstests am Ende günstiger wäre. Sicher scheint mir nur ein Posten dieser Rechnung: die laufende Pflege von mehreren hunderttausend Zeilen Prosa, samt deren eigener Drift.

Datenbasis

Alle Zahlen und Fallbeispiele aus den beiden Projekten stammen aus deren Repositories: aus Git-Historien, Ticket-Beständen, Betriebsnotizen und den maschinenlesbaren Audit- und Gate-Artefakten. Die Projekte sind interne Vorhaben und hier bewusst nur über Kennzahlen beschrieben.

Quellen

• How Coding Agents Fail Their Users: A Large-Scale Analysis of Developer-Agent Misalignment in 20,574 Real-World Sessions, arXiv 2605.29442 (2026), https://arxiv.org/abs/2605.29442
• SpecBench: Evaluating Specification-Level Reasoning for Software Engineering LLM Agents, arXiv 2605.30314 (2026), https://arxiv.org/abs/2605.30314
• Citation Discipline in Spec-Driven Development: A Cross-Model Empirical Study of Output Determinism and Automated Hallucination Detection in LLM-Generated Code, arXiv 2606.30689 (2026), https://arxiv.org/abs/2606.30689
• SpecFirst: Behavioral Specification Elicitation as a First-Class Step in Agent-Based Program Synthesis from Scratch, arXiv 2607.27167 (2026), https://arxiv.org/abs/2607.27167
• The Spec Growth Engine: Spec-Anchored, Code-Coupled, Drift-Enforced Architecture for AI-Assisted Software Development, arXiv 2606.27045 (2026), https://arxiv.org/abs/2606.27045
• SpecBench: Measuring Reward Hacking in Long-Horizon Coding Agents, arXiv 2605.21384 (2026), https://arxiv.org/abs/2605.21384
• Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa?, arXiv 2607.21656 (2026), https://arxiv.org/abs/2607.21656
• Reliability without Validity: A Systematic, Large-Scale Evaluation of LLM-as-a-Judge Models Across Agreement, Consistency, and Bias, arXiv 2606.19544 (2026), https://arxiv.org/abs/2606.19544
• How Many Tries Does It Take? Iterative Self-Repair in LLM Code Generation Across Model Scales and Benchmarks, arXiv 2604.10508 (2026), https://arxiv.org/abs/2604.10508
• The Cost of Consensus: Isolated Self-Correction Prevails Over Unguided Homogeneous Multi-Agent Debate, arXiv 2605.00914 (2026), https://arxiv.org/abs/2605.00914
• Atlassian Engineering: Why AI Agents Drift Mid-Task and How a Multi-Agent System Fixes It (23. Juni 2026), https://www.atlassian.com/blog/development/specialist-agent-orchestration-jira
• Thoughtworks Technology Radar: Spec-driven development (Ring „Assess“, Stand November 2025), https://www.thoughtworks.com/radar/techniques/spec-driven-development

Warum der Agent doppelt

Die Ursache ist ein Grounding-Problem, also eine Lücke zwischen dem, was der Agent von der Codebasis sieht, und dem, was tatsächlich da ist. Ein Sprachmodell liest das Repository Datei für Datei in einem begrenzten Kontextfenster. Eine globale Karte der Struktur hat es nicht. Liegt der passende bestehende Pfad gerade außerhalb des geladenen Kontexts, leitet das Modell die Logik neu her, die es schon gibt. In einem großen, über Jahre gewachsenen System ist die Wahrscheinlichkeit dafür hoch, weil der relevante Code mit höherer Quote außerhalb des Fensters liegt als in einem kleinen, frischen Projekt.

Dazu kommt der Zuschnitt der Tickets. Ein knapper Auftrag wie „Implementiere X" führt leichter zu einem neuen Helfer als die Vorgabe, X in den bestehenden Pfad einzubinden und alle betroffenen Oberflächen zu belegen. Ein grün laufender Test beweist oft zu wenig. Er zeigt, dass der neue Pfad funktioniert. Ob der eigentliche Produktpfad ihn überhaupt aufruft, prüft er nicht.

Belegt ist das inzwischen mit Daten. Die Untersuchung „More Code, Less Reuse" (arXiv 2601.21276, 2026) hat KI-erzeugte und menschliche Pull Requests anhand objektiver Code-Metriken verglichen. KI-generierte Änderungen enthalten danach mehr duplikativen Code und greifen seltener auf bestehende Funktionen zurück. Im Bestandssystem ist das teuer, weil jede Kopie später separat gepflegt, getestet und verstanden werden muss.

Korrekturen aus einem Branch

Ich sehe das in allen Feature-Implementierungen in meiner recht großen (ca. 600K LoC) Codebasis. In meinen Projekten durchläuft jedes Feature standardmäßig einen festen Review-Prozess aus Implementierung, unabhängigem Audit und harten Gates. Diese Auswertung ist ein Beispiel daraus. Über die Review-Artefakte eines Branches und die zugehörigen Fix-Commits konnte ich viele konkrete Korrektur-Findings aus der Git-Historie zählen. Das sind Stellen, an denen ein erster Agentenlauf etwas falsch gemacht hatte und ein nachgelagerter Schritt es korrigieren musste. Die Quote ist hoch: Über gut fünfzig ausgewertete Commits brauchten je nach Zählweise zwischen 75 und 86 Prozent der geprüften Implementierungseinheiten eine Korrektur, einen neuen Zuschnitt oder ein erneutes Review. Die häufigsten Klassen verteilen sich so:

Die zweite Spur aus dem ersten Abschnitt steht hier auf Rang 3, „Bestehender Produktpfad/Surface nicht vollständig verdrahtet". In der Messung taucht sie als eigene Fehlerklasse mit knapp 17 Prozent auf. Mit „Claim" meine ich in der ersten Zeile ein behauptetes Ergebnis, etwa die Aussage eines Agenten, ein Akzeptanzkriterium sei erfüllt. Die Verteilung zeigt über die Korrekturquote hinaus, welche Art von Fehler ein nachgelagerter Prüfer überhaupt fangen kann und welche schon vor der Implementierung entsteht. Ich gehe hier auf die zweite Spur gesondert ein, weil sie in einem späteren Produktionssetting die teuerste und am schwersten zu korrigierende Baustelle ist. Fehler in der Produktion an solchen Stellen sind schwer zu finden und zu beheben. Diese Auswertung dokumentiert außerdem, dass ein Prüf- und Auditagent systematisch als fester Bestandteil der Entwicklungspipeline eingerichtet werden muss.

Jede Klasse in der Tabelle ist ein Fund des Audit-Modells. Die Korrekturen stammen aus seinen Review-Artefakten und aus den Fix-Commits, die darauf folgten. Die Verteilung ist damit die Bilanz des Prüfers, eine Aufstellung dessen, was ein unabhängiges Modell gefangen hat, bevor es in einen späteren Stand des Systems gewandert wäre. Ohne diesen Prüflauf wären die Defekte zunächst durchgegangen, denn die Implementierung selbst hatte sie als erledigt gemeldet.

Bei der häufigsten Klasse, knapp 28 Prozent, fand der Prüfer unzureichende Tests. Die Implementierung hatte Tests geliefert, die nur den Happy Path grün hielten und keinen roten Gegenbeweis erzeugten. Eine Trigger-Matrix etwa deckte nicht die Auslöser ab, die sie zu prüfen vorgab, und ein als negativ angelegter Test stellte den Fehlerfall gar nicht erst her. Die Korrektur war jeweils, die Tests so zu bauen, dass sie fehlschlagen, wenn der Claim falsch ist. Diese Klasse übersieht ein Team, das seine eigene Arbeit abnimmt, weil ein grüner Lauf wie ein Beleg aussieht.

Die zweitgrößte Klasse, gut ein Fünftel, lag in der Spezifikation. Tickets waren mehrdeutig oder zyklisch geschnitten, eine Abhängigkeit war nicht als harte Vorbedingung markiert. Ein Abschlussgate war zu eng gefasst, und der Scope zweier Tickets passte nicht zum tatsächlich freigegebenen Stand. Diese Widersprüche fand der Prüfer im Abgleich von Tickets, README und Abhängigkeiten.

Auf Rang 3 zeigte sich die zweite Spur als Oberfläche, die nicht vollständig am gemeinsamen Backbone hing. Ein zweiter Einstiegspunkt war vom gemeinsamen Resolver abgekoppelt, den ein erster bereits nutzte. Alternative Bootstrap-Pfade verloren unterwegs Daten. An einer Stelle entstand eine zweite Auflösungs-Lane neben dem bestehenden Pfad, ohne ihn wiederzuverwenden. Die Korrektur war ein gemeinsamer Helfer und der Nachweis, dass alle Oberflächen denselben Backbone nutzen.

Die beiden übrigen Klassen betrafen Datenverträge und Drift. Bei den Datenverträgen ging es um einen fehlenden sicheren Default, um leere Deltas, die bestehende Werte überschrieben, und um eine Serialisierung, die nicht eindeutig war. Bei der Drift liefen Schema, App-Hilfe und Referenzstand gegen den tatsächlichen Code. Das blockierte Freigaben, weil Agenten genau diese Artefakte als Vertragsquelle nutzen.

Über alle Klassen hinweg macht das Audit-Modell die Probleme sichtbar, die ein selbst abnehmendes Dev-Team ungeprüft weitergereicht hätte. Die Messung rechtfertigt den zweiten Prüfer damit über die gesamte Verteilung hinweg.

Implementierer und Auditor als Widerlegungsprozess

Gegen die zweite Spur und gegen die übrigen Fehlerklassen hilft eine Arbeitsteilung, die ich in meinen Projekten als Gate-Prozess führe. Ein Agent implementiert entlang Ticket, Repo-Regeln und bestehender Pfade. Ein zweiter Agent mit frischem Kontext versucht, den Claim zu widerlegen. Über das Ergebnis entscheiden harte Gates, Re-Runs, Greps und Artefakte. Die Selbstzusammenfassung des Implementierers zählt dabei nicht als Beleg. Ein fail oder ein inconclusive hält den Merge an.

Es kommt auf die adversariale Haltung an. Ein zweites Modell, das nur dieselbe weiche Zusammenfassung liest und sie abnickt, bringt wenig. Es zahlt sich erst aus, wenn es Codepfade grept, Call-Sites verfolgt, Tests erneut laufen lässt, Baselines vergleicht und gezielt nach rotem Gegenbeweis sucht.

Ein Modellmix, etwa Claude oder Opus als Implementierer und ein Codex- oder GPT-Modell als Auditor, hilft ebenfalls. Verschiedene Familien haben verschiedene Stärken, Suchmuster und Fehlerprofile, und ein Modell, das seinen eigenen Output abnimmt, urteilt zu milde. Der eigentliche Sicherheitsgewinn entsteht aber aus der Trennung von Rolle und Kontext, aus dem Widerlegungsauftrag, aus harten Gates und reproduzierbaren Re-Runs. Dazu gehört, dass fail und inconclusive den Merge tatsächlich aufhalten.

Die großen Anbieter gehen ähnliche Wege. Die relevante Linie entsteht aus mehreren Bausteinen: vor dem ersten Code die Codebasis erkunden, einen Plan und klare Done-Kriterien festlegen, die Änderung durch Tests und Review belegen. Danach wird der Diff mit frischem Kontext geprüft, Findings gehen an den Implementierer zurück, und nach der Korrektur folgt eine erneute Prüfung.

OpenAI beschreibt für Codex bei schwierigen Aufgaben zuerst eine Planphase. Codex soll Kontext sammeln, offene Fragen klären und einen Plan bauen, bevor die Implementierung beginnt. Für große Repositories nennt OpenAI im Auftrag vier Felder: Ziel, Kontext, Constraints und ein klares „Done when". Der letzte Punkt ist für Brownfield-Arbeit zentral, weil „fertig" an beobachtbare Zustände gebunden wird, etwa bestandene Tests, verändertes Verhalten oder einen reproduzierten Fehler, der danach ausbleibt. Zur Review-Schleife gehören nach der Dokumentation Tests, relevante Checks, Bestätigung des Ergebnisses und eine Diff-Prüfung auf Bugs, Regressionen und riskante Muster. Die Review-Fläche kann uncommitted changes, Branch-Diffs und einzelne Commits prüfen. Inline-Kommentare am Diff werden wieder Arbeitskontext für Codex. Subagenten nutzt OpenAI für abgegrenzte Prüfungen: Exploration, Tests, Triage oder Review-Perspektiven wie Sicherheit, Testlücken und Wartbarkeit. Auf die zweite Spur übertragen heißt das: Der Auditor liest Diff, Tests und Auftrag. Er übernimmt die Erfolgserzählung des Implementierers nur als zu prüfende Behauptung.

Anthropic ist bei diesem Muster am explizitesten. In den Claude-Code-Best-Practices steht eine adversariale Review-Stufe: Vor dem Abschluss soll ein Subagent den Diff in frischem Kontext prüfen und Lücken melden. Der Reviewer sieht den Diff und die Kriterien, aber keinen langen Herleitungsverlauf der Implementierung. Für Korrektheitsprüfungen verweist Anthropic auf /code-review, das den aktuellen Diff in einem frischen Subagenten auf Bugs prüft und Findings in die laufende Session zurückspielt. Wer gegen einen Plan prüfen will, soll Plan, Diff und Finding-Kriterien ausdrücklich nennen, etwa erfüllte Anforderungen, getestete Edge Cases und Einhaltung des Scope. Danach kann die Implementierungssitzung die Findings korrigieren und den Review erneut auslösen. Damit entsteht der Zyklus, den ich hier als Implementer-Audit-Feedback-Korrektur beschreibe.

Google liefert den Beleg stärker über GitHub- und CI-Abläufe. Die offizielle run-gemini-cli Action nennt Pull-Request-Reviews, Issue-Triage, Codeanalyse und Codeänderungen als Einsatzfälle. Das PR-Review-Beispiel läuft automatisch bei neuen Pull Requests oder manuell über @gemini-cli /review, sammelt PR-Daten und Changed Files, führt die Gemini-Analyse aus und postet Review-Kommentare zurück in den PR. Der Beispielprompt begrenzt Kommentare auf geänderte Diff-Zeilen, verlangt verifizierbare Findings, Severity-Einstufung und konkrete Vorschläge. Im Gemini-CLI-Repository selbst trennt die Prozessdokumentation Issue und PR: Das Issue beschreibt Was und Warum, der PR das Wie der Umsetzung. CI prüft Lint, Tests über mehrere Plattformen und Coverage. Eine PR-Automation kontrolliert die Verknüpfung zwischen Issue und PR. Checkpointing ergänzt den Korrekturpfad, weil Gemini CLI vor AI-Dateiänderungen Snapshots anlegen und Dateien samt Gesprächszustand wiederherstellen kann.

Für die zweite Spur ergibt sich daraus ein Prozess, den keiner der Anbieter als fertige Regel beschreibt. Der Agent, der neuen Code schreibt, hat zunächst nur einen lokalen Beweis geliefert. Er hat gezeigt, dass seine neue Spur funktioniert. Der fehlende Beleg liegt oft an anderer Stelle: Nutzt der bestehende Produktpfad diese Spur? Sind alle Oberflächen verdrahtet? Hat ein Consumer das neue Signal im Live-Pfad? Deckt der Test den Claim oder nur den neu gebauten Helfer? Diese Fragen müssen vor der Implementierung und im Audit auftauchen. Vor der Implementierung erzwingt der Second-Lane-Grep den Nachweis bestehender Code-, Config-, Test- oder Runtime-Pfade. Nach der Implementierung prüft der Auditor den Diff gegen Plan, Scope und bestehende Call-Sites. Das Finding geht zurück an den Implementierer, die Korrektur landet in einem neuen Commit, und erst ein erneutes Gate macht daraus einen freigabefähigen Stand.

Meine Gate-Schablone ist strenger als diese Anbieterbausteine. Sie verbindet OpenAIs Plan-, Done- und Review-Begriffe, Anthropics frischen adversarialen Review-Kontext und Googles PR-/CI-Automation zu einem Ablauf. Dieser besteht aus Plan-/Spec-Review vor dem Code, Second-Lane-Grep, Claim-Gate, unabhängigem Verdict-Artefakt, Korrektur durch den Implementierer und Re-Review. Die Cross-Model-Regel steht so in keiner der Anbieterquellen. Ich nutze sie als zusätzliche Härtung, weil eine andere Modellfamilie oft andere Suchpfade und Fehlerprofile mitbringt.

Ein konkreter Prüfablauf

Der Ablauf beginnt vor der Implementierung. Für ein Epic lege ich ein Plan-/Spec-Review-Gate an. Dieses Gate erzeugt keinen Produktcode. Es prüft alle Implementierungstickets gegen die Epic-README und gegeneinander.

• Ticketvertrag: Jedes Ticket braucht Objective, Boundaries und ein Output- oder Akzeptanzformat. Boundaries benennen ausdrücklich, wofür das Ticket nicht zuständig ist. Fehlt eines dieser Felder, bekommt das Ticket kein pass.
• Scope und Dependencies: Der Reviewer sucht Überschneidungen zwischen Tickets, ungeklärte Reihenfolgen, fehlende Vorbedingungen, zyklische Abhängigkeiten und widersprüchliche Schalter.
• Second-Lane-Grep: Jede geforderte Neuimplementierung braucht einen Grep-Beleg. Gibt es schon Code-, Config-, Test- oder Runtime-Pfade, die erweitert werden müssten? Der Beleg nennt Dateien, Call-Sites oder typed Models. Fehlt er, ist der Plan fail oder inconclusive.
• Claim-Gate: Für jedes Akzeptanzkriterium steht im Ticket der deterministische Test, der fehlschlägt, wenn der Claim falsch ist. Existiert dieser Test noch nicht, gehört es zum Ticket, ihn zu schreiben.

Erst danach implementiert der erste Agent. Er bindet den bestehenden Backbone ein, begründet neue Abstraktionen, betrachtet Producer und Consumer zusammen, prüft alle betroffenen Oberflächen und zieht Tests wie Artefakte mit. Eine Selbstabnahme gilt nicht.

Das Vorab-Gate schreibt sein Ergebnis in ein maschinenlesbares Verdict-Artefakt, in meinen Projekten zum Beispiel als e2e-live/baseline/txxxx-plan-gate/VERDICT.json:

{
  "verdict": "fail",
  "planner_family": "gpt",
  "reviewer_family": "claude",
  "findings": [
    {
      "severity": "blocking",
      "artifact": "tickets/T1234.md",
      "finding": "Akzeptanzkriterium AC-2 nennt keinen falsifizierenden Test."
    }
  ],
  "commitSHA": "..."
}

Im Abschluss-Audit liest ein unabhängiges Modell Ticket, Diff, Tests, README, Schema und Artefakte selbst. Es lässt die zentralen Gates erneut laufen, grept nach toten und doppelten Pfaden und vergleicht den bestehenden Produktpfad mit dem neuen. Das Verdict nutzt dieselbe Grundform und hält die Felder implementer_family und auditor_family fest.

Bei fail oder inconclusive enthält das Artefakt blockierende Findings mit Datei- oder Artefaktbelegen. Vor dem Merge werden diese Findings disponiert: blockierend, unkritisch oder zurückgestellt. Ein öffentlicher Leistungs-Claim braucht ein eigenes Claim-Gate.

Die wirksamste einzelne Regel verschiebt die Beweislast. Eine Lösung, die eine zweite Implementierung neben einem vorhandenen Pfad erzeugt, ohne ihn einzubinden, gilt nicht als prüffähig. Der Implementierer muss belegen, dass ein neuer Pfad nötig und vollständig verdrahtet ist. Ein „der zweite Pfad schadet ja nicht" reicht nicht.

Checkliste gegen die zweite Spur

Pro Ticket oder Review-Artefakt reichen wenige Prüfungen, um eine zweite Spur aufzuspüren.

• Bestandspfad: Welche Dateien, Call-Sites, typed Models, Policies und Tests belegen den vorhandenen Produktpfad?
• Neue Änderung: Wurden neue Dateien, Dienste, Resolver oder Schalter angelegt? Wenn ja, steht im Ticket oder in einer Architekturnotiz, warum der vorhandene Pfad erweitert wurde oder warum ein neuer Pfad nötig war?
• Verdrahtung: Welcher Producer liefert das neue Signal, welcher Consumer nutzt es, und liegt dieser Consumer im Live-Pfad? Gibt es Felder oder Events ohne Consumer?
• Gate-Beleg: Welcher Test wäre vor dem Fix rot gewesen? Deckt das Gate den echten Claim ab oder nur den Happy Path? Stimmen Ticket, README, Schema und Code überein?

Grenzen des Prozesses

Der Ablauf hat eigene Schwachstellen, die man kennen muss.

Der Auditor kann dieselben Annahmen übernehmen wie der Implementierer. Liest er dasselbe Ticket, dieselbe Zusammenfassung und dieselbe Logik, korrelieren die Fehler. Dagegen helfen frischer Kontext, eine andere Modellfamilie, ein ausdrücklich adversarialer Prompt und das Verbot, die Dev-Zusammenfassung als alleinige Quelle zu nehmen.

Gates können weich sein. Ein Gate, das nur Happy Paths prüft, kann einen Second-Lane-Fehler sogar stabilisieren. Der grüne Status des neuen Pfades verdeckt dann, dass der eigentliche Produktpfad defekt geblieben ist. Deshalb braucht jeder Claim einen Test, der ohne den Fix rot wäre.

Artefakte driften ebenfalls. Tickets, README, Schema, Snapshots und Code laufen mit der Zeit auseinander, und weil Agenten Artefakte als Steuerungsquelle nutzen, führt diese Drift direkt zu falschen Entscheidungen. Meine Auswertung führt Dokumentations-, Schema- und Evidenzdrift als eigene Korrekturklasse mit knapp 17 Prozent.

Fazit

Die Anbieterhinweise von OpenAI, Anthropic und Google stützen die Richtung: Plan vor der Implementierung, Tests mit Claim-Bezug, Review am Diff, CI und ein Rückweg aus Findings in Korrektur-Commits. Aus meinem Gate-Prozess stammt die konkrete Ausgestaltung. Die Korrekturen aus dem eigenen Branch sind eine kleine Stichprobe, aber jede Klasse darin ist ein Fund des Audit-Modells. Zugleich zeigt die hohe Interventionsrate, dass ein erheblicher Teil der Implementierungen ohne Review nicht sofort korrekt war. Der Prozess wirkt, wenn er als evidenzbasierter Widerlegungsprozess geführt wird. Eine grüne Testsuite belegt für sich noch nicht, dass der Produktpfad den neuen Code aufruft. Diesen Nachweis muss der Audit erbringen. Ob sich das Muster über mehr Projekte hält, müsste eine größere Erhebung zeigen.

Quellen

• More Code, Less Reuse: KI-generierte Pull Requests, arXiv 2601.21276 (2026)
• OpenAI: Codex Best Practices, https://developers.openai.com/codex/learn/best-practices
• OpenAI: Codex Review, https://developers.openai.com/codex/app/review
• OpenAI: Codex Subagents, https://developers.openai.com/codex/concepts/subagents
• Anthropic: Claude Code Best Practices, https://code.claude.com/docs/en/best-practices
• Anthropic: Claude Code Common Workflows, https://code.claude.com/docs/en/common-workflows
• Google: run-gemini-cli GitHub Action, https://github.com/google-github-actions/run-gemini-cli
• Google: Gemini CLI PR Review Workflow, https://github.com/google-github-actions/run-gemini-cli/tree/main/examples/workflows/pr-review
• Google Gemini CLI: Issue and PR Automation, https://github.com/google-gemini/gemini-cli/blob/main/docs/issue-and-pr-automation.md
• Google Gemini CLI: Checkpointing, https://github.com/google-gemini/gemini-cli/blob/main/docs/cli/checkpointing.md

In dieser Pipeline schreibt die Entwicklung den Code nicht mehr. Diese Aussage ist unbequem, und ich halte sie trotzdem für richtig. Es gibt keine IDE mehr im alten Sinn, keine integrierte Entwicklungsumgebung, in der eine Person Datei für Datei öffnet und Zeile für Zeile tippt. Die Entwicklerin sieht den einzelnen Quelltext nicht mehr beim Entstehen, weil der Agent ihn schreibt. Das klingt nach Kontrollverlust. Die Arbeit verschiebt sich aber nur auf eine Ebene, auf der die schwierigen Entscheidungen ohnehin schon immer gefallen sind. Wer Code zeilenweise tippt, verbringt einen großen Teil seiner Zeit unterhalb dieser Ebene.

Warum gerade diese Rolle die These auf die Probe stellt

Die Business-Analyse und das UX arbeiten schon lange mit Sprache als ihrem Hauptmaterial. Eine Analystin, die ein Quelleninventar etikettiert, oder ein Designer, der einen Fehlerzustand in Geschäftssprache beschreibt, hat noch nie eine Compiler-Fehlermeldung gesehen. Bei diesen Rollen wirkt der Agent als Beschleuniger einer Tätigkeit, die im Kern aus Lesen, Vergleichen und Formulieren besteht. Die Entwicklung ist anders. Sie hat ein Handwerk, das über Jahrzehnte eine eigene Werkzeugwelt aufgebaut hat: Editoren mit Syntaxhervorhebung, Debugger, Refactoring-Tasten, Autovervollständigung. Diese Werkzeugwelt war der Stolz des Berufs. Wenn ich behaupte, dass sie in einer agentischen Pipeline weitgehend verschwindet, dann rühre ich an das Selbstverständnis vieler Kolleginnen und Kollegen. Das verlangt eine Begründung, die über ein Schlagwort hinausgeht.

Entwickler und Architekt sind eine Rolle geworden

Hinter dieser Rolle steht eine organisatorische Entscheidung. In der klassischen Aufstellung sind Architektur und Entwicklung getrennt. Es gibt jemanden, oft mit dem Titel Software- oder Lösungsarchitekt, der vorab entscheidet, wie ein System aufgebaut wird, welche Komponenten miteinander reden, welche Muster gelten. Daneben gibt es die Entwicklung, die diese Vorgaben in Code übersetzt. Diese Trennung hatte einen ökonomischen Grund. Architekturentscheidungen sind teuer, wenn man sie spät korrigiert, und das Tippen von Code war langsam genug, dass sich eine vorgelagerte Planungsphase lohnte.

Der Agent verschiebt dieses Gleichgewicht. Wenn eine erste lauffähige Umsetzung in Minuten statt in Tagen entsteht, dann wird die scharfe Trennung zwischen dem, der die Architektur entwirft, und dem, der sie umsetzt, künstlich. Die Architektin muss ohnehin am gewachsenen Bestandssystem, dem Brownfield, prüfen, ob ihre Idee dort hält. Diese Prüfung läuft jetzt über denselben Agenten, der später baut. Es ergibt keinen Sinn mehr, das Architekturwissen in eine getrennte Vorphase und eine getrennte Person auszulagern, wenn die Rückkopplung zwischen Entwurf und Realität so eng wird. In der Pipeline sind Entwickler und Architekt deshalb eine zusammenhängende Rolle. Das Architektur-Review ist eine eigene Station innerhalb derselben Rolle, die auch baut.

Diese Station hat ihren festen Platz in der Kette. Sinngemäß läuft sie so: Aus den Prinzipien des Projekts, einer Art technischer Verfassung, und der fachlichen Spezifikation werden zunächst offene Punkte geklärt. Danach folgt das Architektur-Review, in dem entschieden wird, wie die Änderung in das gewachsene System passt. Erst darauf folgen der Plan, die Aufgaben und die eigentliche Umsetzung, bevor das Quality Gate greift. Die Architektur sitzt also vor dem Code, aber in derselben Hand, die den Code verantwortet.

Die Fähigkeit, die ein Modell nicht hat

Was die Entwicklerin überhaupt noch beiträgt, wenn der Agent den Code schreibt, ist das architektonische Urteil und das Gespür für das konkrete Brownfield. Das ist kein vages Talent, das man beschwört, wenn die Argumente ausgehen.

Eine erfahrene Architektin erkennt, dass eine Änderung an einer Stelle drei Stellen weiter etwas auslöst. Im Code steht das nicht. Sie erkennt es, weil sie ein vergleichbares System an genau dieser Stelle schon einmal scheitern sah. Eine Speicherlogik etwa fasst an drei Stellen denselben Datensatz an und geht an einer davon von etwas aus, das die anderen beiden nicht kennen. Im Quelltext ist das nicht als Gefahr markiert. Es ist eine Gefahr, weil ein Mensch die Geschichte des Systems kennt und weiß, wo es schon einmal weh getan hat. In einem Repository ist dieses Erfahrungswissen nirgends abgelegt, es lebt in den Köpfen derer, die das System betreut haben.

Der Agent hat etwas anderes. Er hat Trainingsmuster, also einen Durchschnitt aus sehr vielen Systemen, die er im Training gesehen hat. Das macht ihn stark bei allem Üblichen. Beim Eigenen dieses einen Systems wird er unsicher, und im Brownfield zählt fast immer das Eigene: Spaltennamen, die eine alte Fachsprache konservieren, oder eine Ablauflogik, die irgendeine Auflage von vor zehn Jahren umsetzt, ohne dass der Grund noch dokumentiert wäre. Dazu kommen stillschweigende Konventionen, an die sich der Code hält, ohne dass irgendwo steht, warum. Solche Eigenheiten kann ein Modell nicht aus dem Durchschnitt der Welt ableiten. Sie muss jemand kennen, der das System aus eigener Arbeit kennt.

Das Review von Verhalten, Diff und Tests ist deshalb die neue zentrale Arbeit der Entwicklung, und diese Verschiebung halte ich für den Kern der Rolle. Diff meint den Unterschied zwischen dem Code vor und nach einer Änderung, also genau das, was der Agent angefasst hat. Dieses Review verlangt mehr Urteil als das Tippen. Wer eine Funktion selbst tippt, denkt über Syntax nach, über die richtige Schleife und den Variablennamen. Wer einen Diff prüft, den ein Agent erzeugt hat, muss dagegen beantworten, ob diese Änderung im gewachsenen System das Richtige tut. Wirkt sie an den drei Stellen, die sie treffen muss, und an keiner, die sie nicht treffen darf? Das ist die schwierigere Frage, und sie war früher unter dem Tippen begraben.

Wie der Agent die Arbeit übernimmt: die Machbarkeitsprüfung

Die erste konkrete Aufgabe der Entwicklung in der Pipeline ist die Machbarkeitsprüfung, im Fachjargon der Feasibility-Check. Sie ist lesend. Der Agent verändert in dieser Phase keine einzige Zeile Code. Er liest stattdessen das gewachsene System. Dazu sucht er im Quelltext, liest die Versionsgeschichte über git log und git blame und wertet Architecture Decision Records aus, also dokumentierte Architekturentscheidungen. Runbooks, die Betriebsanleitungen für den laufenden Betrieb, liest er ebenfalls, und er untersucht die Datenbankschemata. Eines der wichtigen Prinzipien der Pipeline ist, dass der Agent frei lesen darf, aber für jede Veränderung eine Freigabe braucht. So bleibt das Erkunden des Systems jederzeit möglich, während ein Eingriff in den Code eine bewusste Entscheidung verlangt.

Das eigentliche Ergebnis dieser Phase ist eine Aussage darüber, ob die Änderung machbar ist, nicht machbar oder nur unter bestimmten Bedingungen. Mit dieser Aussage kommt eine Liste der betroffenen Komponenten. Die Prüfung hält außerdem fest, welche Annahmen des fachlichen Tickets sich am Brownfield bestätigt haben und welche sich widerlegt haben. Ein Beispiel: Das Ticket der Business-Analyse nimmt an, dass ein bestimmtes Feld immer gefüllt ist. Die Machbarkeitsprüfung stellt am realen Datenbestand aber fest, dass es in vielen Bestandsdatensätzen gar nicht gefüllt ist. Das ist eine widerlegte Annahme, und sie gehört dokumentiert, bevor irgendjemand Code schreibt. Hinzu kommen Rückfragen an die Fachseite und eine kurze Lösungsskizze. Sie gibt eine Richtung an und enthält noch keine Implementierung.

Die Rückfragen wandern nicht in den Chat. Sie gehen zurück in das fachliche Ticket, dorthin, wo sie die Business-Analyse sieht und beantworten kann. Sie werden außerdem klassifiziert. Eine Rückfrage ist entweder blockierend, dann kann die Umsetzung ohne Antwort nicht beginnen. Oder sie betrifft etwas, das man notfalls aus dem Umfang herausschneiden kann, dann hält sie das Ticket nicht auf. Oder sie ist rein eine Frage der Umsetzung, dann kann die Entwicklung sie selbst entscheiden, ohne die Fachseite zu behelligen. Diese Klassifizierung verhindert, dass jede technische Detailfrage zur Rückfrage an die Fachseite aufgeblasen wird, und sie verhindert umgekehrt, dass eine blockierende Lücke unter den Tisch fällt.

Vom Ticket zur Aufgabe: der technische Schnitt

Wenn die Machbarkeit geklärt ist, schneidet die Entwicklung technische Tickets. Hier gilt eine Regel, die in der Praxis viel Disziplin verlangt: Ein Ticket umfasst genau eine Veränderung mit einem eigenen Akzeptanztest.

Die Reihenfolge der Tickets folgt dem natürlichen Aufbau einer Änderung, die von unten nach oben durch die Schichten eines Systems wächst. Zuerst das Datenmodell, weil alles andere darauf aufsetzt. Darauf die Geschäftslogik, die mit diesen Daten arbeitet, dann die API, also die Schnittstelle, über die andere Systeme oder die Oberfläche zugreifen, und schließlich die Oberfläche selbst. Danach entstehen die Tests, sofern sie nicht ohnehin pro Ticket entstehen, und zuletzt die Dokumentation. Diese Reihenfolge sorgt dafür, dass jedes Ticket auf einem Fundament aufsetzt, das schon steht.

Jedes technische Ticket enthält einen Rückverweis. Es nennt die Akzeptanzkriterien des fachlichen Tickets, die es umsetzt, und die UX-Zustände, die es bedient. Ich schreibe diese Verweise in der Praxis als kurze Marken, etwa als Verweis auf ein bestimmtes Akzeptanzkriterium oder einen bestimmten UX-Zustand. Der Sinn dahinter ist die Rückverfolgbarkeit. Wenn später jemand fragt, warum diese eine Codeänderung existiert, dann führt der Verweis vom technischen Ticket zum fachlichen Kriterium und von dort zur ursprünglichen Anforderung. Diese Kette ist im Brownfield wertvoll, weil Bestandscode notorisch an Begründung verliert. Niemand weiß nach drei Jahren mehr, warum eine bestimmte Prüfung existiert, und die Versionsgeschichte allein reicht oft nicht, wenn die Commit-Nachricht damals dürftig war.

Als grobe Heuristik für die Größe eines technischen Tickets nehme ich ein bis drei Stunden Arbeit. Gemeint ist der Zuschnitt einer Aufgabe. Die Zahl ist kein abzurechnendes Zeitbudget. Ein Ticket, das in einer bis drei Stunden umsetzbar und testbar ist, hat eine Größe, die ein Mensch noch im Kopf behalten kann, wenn er den Diff prüft. Ein Ticket, das einen ganzen Tag umfasst, produziert einen Diff, der zu groß ist, um ihn verantwortlich zu reviewen. Der kleine Schnitt hat also einen handfesten Grund: Ohne ihn ist am Ende kaum noch ein sauberes Review möglich.

Die Kaskade aus Plan, Epic und Tickets

Über den einzelnen Tickets liegt eine Kaskade, die von der ersten Recherche bis zur autonomen Umsetzungsschleife führt.

Am Anfang steht die Recherche, und sie ist lesend. Hier passiert dasselbe wie in der Machbarkeitsprüfung: Der Agent liest den Bestandscode, ohne etwas zu verändern. Darauf baut das Epic. Es beschreibt das Ziel der gesamten Änderung, den Umfang und die übergeordneten Akzeptanzbedingungen, und bildet die Klammer, unter der die einzelnen Tickets hängen. Aus dem Epic werden dann die Tickets geschnitten, klein und testbar, nach den Regeln, die ich gerade beschrieben habe. Der Plan legt anschließend die Reihenfolge der Arbeit fest, dazu die Quality Gates, die unterwegs passiert werden müssen. Er enthält außerdem die Definition of Done, also die Bedingung, unter der die Arbeit als fertig gilt. Zuletzt läuft die Schleife, in der der Agent den Plan tatsächlich abarbeitet.

Diese Schleife steuere ich mit einer einzigen Anweisung, die ich hier wörtlich wiedergebe, weil ihre Formulierung wichtig ist:

Mache weiter mit dem nächsten Schritt laut Implementierungsplan. Stoppe erst wenn der Plan beendet ist. Setze die Aufgabe strukturiert und sorgfältig um. Sei genau. Halte dich an die Qualitätsanforderungen (Lint, Tests) absolut. Committe häufig und frühzeitig. Dokumentiere deinen Fortschritt im Implementierungsplan, den Epic und den Tickets.

Diese eine Anweisung erlaubt langes autonomes Arbeiten ohne ständige Mikrosteuerung, weil ihre Leitplanken außerhalb des Agenten liegen. Sie verweist auf einen Plan, den vorher ein Mensch geprüft hat, und auf Qualitätsanforderungen, die maschinell durchgesetzt werden. Das sind Lint und Tests, die hart fehlschlagen, wenn etwas nicht stimmt. Ihr Stop-Kriterium ist klar, nämlich das Ende des Plans. Ohne den geprüften Plan und ohne die harten Gates wäre dieselbe Anweisung gefährlich. Sie könnte den Agenten zwanzig Schritte in die falsche Richtung schicken, bevor jemand merkt, dass die Richtung falsch war. Mit Plan und Gates wird sie zum Werkzeug für die autonome Arbeit, die den Geschwindigkeitsgewinn überhaupt erst auszahlt.

Das häufige und frühe Committen verbindet die Schleife mit dem Prinzip, das ich für das wichtigste der ganzen Pipeline halte: dass der Zustand in Artefakten liegt und nicht im Chat.

Git als Quelle der Wahrheit

Ein Agent hat kein Gedächtnis über die Sitzung hinaus, und auch innerhalb einer Sitzung verliert ein langer Chatverlauf an Wirkung. Was im Repository steht, bleibt dagegen erhalten. Die Versionsverwaltung legt in dieser Rolle nicht nur fertigen Code ab. Sie ist die eigentliche Quelle der Wahrheit über den Stand der Arbeit.

Dabei entstehen drei nützliche Spuren ohne Zusatzaufwand. Die Commit-Nachricht hält das Warum einer Änderung fest, sofern man sie ernst nimmt und nicht mit einem Wort abspeist. Über git blame lässt sich die Herkunft jeder Zeile zurückverfolgen: wann sie von wem und mit welcher Begründung entstand. Der Befehl git diff zeigt den genauen Unterschied zwischen zwei Punkten der Geschichte. Anders als eine separat gepflegte Notizdatei, die in jedem Projekt herumliegt und beim nächsten Code-Wechsel veraltet, hängt diese Spur am Code selbst und bleibt damit aktuell. Wer vor einer Änderung die Historie der betroffenen Datei liest, rät weniger.

Was die Rolle produziert

Am Ende ihrer Arbeit hinterlässt die Entwicklung eine Reihe von Artefakten. Ich benenne sie einzeln, weil das Quality Gate später an genau diesen Artefakten ansetzt.

Die erste ist die Machbarkeitsaussage, festgehalten in einem eigenen Block für Entwicklungsnotizen innerhalb des fachlichen Tickets, dort, wo die Business-Analyse sie findet. Es folgen das Epic und die technischen Tickets, von denen jedes eine Teststrategie enthält. Diese Teststrategie benennt, welche Tests auf welcher Ebene entstehen: Unit-Tests für einzelne Funktionen, Integrationstests für das Zusammenspiel mehrerer Teile, End-to-End-Tests für den durchgehenden Ablauf aus Nutzersicht. Sie benennt außerdem etwas, das oft fehlt und das ich für besonders wichtig halte: den Anti-Test. Damit meine ich: Die Strategie legt fest, was bewusst nicht getestet wird und warum. Eine Teststrategie, die nur sagt, was getestet wird, lässt offen, ob eine Lücke beabsichtigt oder vergessen wurde. Wenn die Strategie ihre Lücken ausdrücklich benennt, kann ein Reviewer die Entscheidung dahinter nachvollziehen und beim Test darauf zurückkommen.

Dazu kommen der Implementierungsplan und die Pull Requests. Ein Pull Request ist die Einheit, in der eine abgeschlossene Änderung zum Review vorgelegt wird. Für ihn gilt eine Bedingung, die mir wichtig ist: Der Pull Request muss aus sich heraus verständlich sein, aus dem Diff, den Tests und dem Plan, ohne dass jemand den Chatverlauf mit dem Agenten kennt. Wenn ein Reviewer den Pull Request nur versteht, indem er nachvollzieht, was im Chat zwischen Mensch und Agent besprochen wurde, dann ist die Übergabe gescheitert. Dieser Chat ist flüchtig, und niemand archiviert ihn. Das letzte Artefakt ist das Fortschrittsprotokoll. Es hält fest, welcher Schritt wann mit welchem Ergebnis abgeschlossen wurde.

Das Quality Gate dieser Rolle

Die Entwicklung hat in der Pipeline zwei Prüfpunkte, und sie liegen an unterschiedlichen Stellen der Arbeit.

Das Plan-Review steht vor dem ersten Code. Es prüft die Reihenfolge der Arbeit, die Teststrategie, die Risiken und die betroffenen Dateien. Dieses Review ist der wirksamste Punkt der ganzen Rolle, weil ein Fehler hier am billigsten ist. Solange er im Plan steht, genügt eine Korrektur im Text. Hat der Agent ihn erst über zwanzig Schritte in den Code eingebaut, kommt zur Code-Korrektur noch die Suche nach der Stelle, an der die Richtung kippte. Den Plan vorab zu prüfen kostet wenig und erspart diese teure Nacharbeit.

Das Code-Review am Pull Request kommt danach. Hier prüft ein Mensch das Verhalten, den Diff und die Tests. Das Pflichtartefakt dieser Rolle besteht aus zwei Teilen: dem geprüften Plan und dem Pull Request mit grünen Checks. Grüne Checks heißt, dass alle automatischen Prüfungen bestanden sind. Ohne diese beiden Artefakte gibt es keine Übergabe an die nächste Rolle.

Unter den menschlichen Prüfpunkten liegt eine maschinelle Schicht, die niemand von Hand durchgehen muss. Deterministische Prüfungen laufen, bevor die teuren Modell-Stationen überhaupt anlaufen. Die statische Sicherheitsanalyse untersucht den Code auf bekannte Schwachstellenmuster. Daneben prüft der Lizenz- und IP-Check, ob der erzeugte Code fremde Bestandteile unter einer unverträglichen Lizenz hereinholt. Die Erkennung von Prompt Injection fängt eingeschleuste Anweisungen ab, die ein Modell aus einer gelesenen Datei heraus manipulieren könnten. Diese Prüfungen laufen als Skripte mit nachvollziehbarem Ergebnis, und sie laufen bewusst zuerst, damit kein Modell Rechenzeit auf offensichtlich fehlerhaftem Material verbraucht. Sie erledigen, was sich eindeutig bestimmen lässt, und entlasten so die menschlichen Gates, an denen es um Urteilsfragen geht.

Die ökonomische Umkehr: Qualität, die plötzlich bezahlbar ist

An dieser Rolle beschäftigt mich ein Punkt am meisten: Er kehrt eine Rechnung um, die jahrzehntelang gegen die Qualität lief.

Codequalität hatte immer einen Preis in Entwicklerstunden. Hundertprozentige Abdeckung durch Unit-Tests war in den meisten Projekten ein theoretisches Ideal: jede Zeile des Codes mindestens einmal von einem automatischen Test ausgeführt. Das kostete so viel Zeit, dass es unter Termindruck als Erstes gestrichen wurde. Lint im strikten Modus prüft den Code gegen alle Stilregeln und Verdachtsmuster, ohne dass irgendeine Regel als Ausnahme durchgewunken wird. Das war ähnlich teuer, weil jede Regel, die anschlägt, einen Menschen kostet, der sie behebt. Dasselbe gilt für durchgehende Formatierung und lückenlose statische Prüfung. Diese Disziplinen fielen als Erstes dem Termindruck zum Opfer, weil ihr Nutzen in der Zukunft lag und ihre Kosten in der Gegenwart.

Der Agent verschiebt diese Rechnung, weil es ihn fast nichts kostet, diese Disziplinen einzuhalten. Es kostet keine zusätzliche Entwicklerstunde mehr, hundert Prozent der Zeilen mit Tests abzudecken, wenn ein Agent die Tests schreibt. Auch jede Lint-Regel zu befriedigen kostet keinen menschlichen Aufwand mehr, wenn der Agent den Code so lange anpasst, bis keine Regel mehr anschlägt. Formatierung und statische Prüfung stehen nicht mehr zur Debatte, weil der Agent sie in der Schleife einhält, ohne dass ein Mensch dafür Zeit aufwenden muss. Damit kehrt sich die Rechnung um: Disziplinen, die früher dem Termindruck zum Opfer fielen, weil sie teuer waren, sind jetzt der Standardfall, weil sie billig geworden sind. Aus einem Ideal, das man sich leisten musste, ist der Weg des geringsten Widerstands geworden.

Hundertprozentige Testabdeckung ist aber nicht dasselbe wie Korrektheit. Abdeckung misst nur, ob ein Test eine Zeile ausgeführt hat. Ob der Test das Richtige prüft, sagt sie nicht. Ein Agent kann Tests schreiben, die jede Zeile berühren und trotzdem nichts Sinnvolles behaupten. Sie bestätigen dann nur, was der Code ohnehin tut, und prüfen nicht, ob er das Richtige tut. Eine Suite aus solchen Tests liefert einen grünen Haken, der nichts wert ist. Die volle Abdeckung verschiebt das Problem also nur. Sie sorgt dafür, dass die billigen Fehler maschinell auffallen, und lässt die teuren Fehler, die im Verständnis der Anforderung liegen, weiter offen. Deshalb braucht es nach der Entwicklung die Rolle Test, und deshalb muss diese Rolle eine andere Perspektive mitbringen als die, die den Code und seine Tests erzeugt hat.

Die ökonomische Umkehr ist trotzdem wertvoll, weil sie den Boden verschiebt. Früher war die Frage, ob ein Projekt sich überhaupt eine ordentliche Testabdeckung und strikte statische Prüfung leistet. Diese Frage stellt sich nicht mehr, weil die Antwort kostenlos ja lautet. Die Energie, die früher nötig war, um diesen Boden zu erreichen, bleibt jetzt für die schwierigere Arbeit frei. Dazu gehört das Review, ob die Tests das Richtige prüfen, und das Urteil, ob die Änderung im Brownfield das Richtige tut. Das Grundniveau erledigt der Agent, sodass die Menschen Zeit für diese Fragen haben.

Wie die Compliance-Regeln in dieser Rolle wirken

Durch alle Rollen der Pipeline zieht sich eine Reihe von Compliance-Anforderungen. In der Entwicklung werden einige davon besonders konkret, weil hier zum ersten Mal Code entsteht, der echte Wirkung haben kann.

Die statische Sicherheitsanalyse und der Lizenz- und IP-Check setzen direkt am erzeugten Code an. Sie gehören zur maschinellen Schicht unter dem Code-Review und laufen nicht erst später. Der Sicherheitstest fängt bekannte Schwachstellenmuster ab, bevor sie in einen Pull Request gelangen. Der Lizenz-Check verhindert, dass fremder Code unbemerkt hineingerät, dessen Lizenz mit dem Projekt unverträglich ist. Das ist eine Form der IP-Kontamination, die im agentischen Arbeiten ein reales Risiko ist, weil ein Modell Code aus seinem Training reproduzieren kann, dessen Herkunft niemand kennt.

Jede KI-erzeugte Änderung bekommt eine Markierung. In der Entwicklung sitzt diese Markierung im Commit-Kommentar. Sie nennt die ausgeführte Operation, die verantwortliche Person und die Version des Modells oder der Skill-Definition, die den Code erzeugt hat. Eine Skill-Definition ist hier die wiederverwendbare Anweisung, mit der eine bestimmte Aufgabe an den Agenten gegeben wird. Diese Markierung ist die Transparenzanforderung des EU AI Act, der Verordnung 2024/1689, in der täglichen Praxis. So lässt sich später in der Versionsgeschichte ablesen, ob eine Codezeile von Hand geschrieben oder von einem Modell vorgeschlagen und nur bestätigt wurde.

Der Agent arbeitet in einer isolierten Sandbox, also einer abgeschotteten Umgebung, und nicht auf dem Laptop der Entwicklerin. Er hat weder Zugriff auf das Dateisystem des Menschen, der ihn steuert, noch auf Produktionsumgebungen. Seine Wirkung beschränkt sich auf Entwicklung, Test und Integration. Eine Operation auf einer Produktionsumgebung ist nicht nur per Konvention untersagt, sondern durch eine technische Sperre aktiv blockiert. Diese Trennung ist die Voraussetzung dafür, dass langes autonomes Arbeiten überhaupt verantwortbar ist, denn ein Agent, der nichts an der Produktion anrichten kann, darf in der Entwicklungsumgebung mehr Freiheit haben.

Am Pull Request steht das menschliche Gate. Eine namentlich verantwortliche Person gibt die Änderung frei oder bessert sie nach, und die KI-Unterstützung mindert diese Verantwortung nicht. Hinzu kommt die Zweit- und Drittmeinung aus dem fünften Prinzip der Serie. Im Code-Review prüft ein zweites Modell den Patch, das ihn nicht selbst geschrieben hat. Ein Modell, das seinen eigenen Code prüft, hängt an der eigenen Logik und übersieht dieselben Fehler, die es beim Schreiben gemacht hat. Ein zweites Modell mit anderen Trainingsdaten und anderen blinden Flecken bringt eine unabhängige Perspektive. Stimmen beide überein, ist der Befund verlässlicher, und bei Abweichungen muss ein Mensch genauer hinsehen. Dieselbe Trennung härtet auch gegen Prompt Injection, weil ein eingeschleuster Angriff zwei verschiedene Modelle auf zwei verschiedene Weisen überlisten müsste.

Ein Wort an die, die das ungern hören

Ich habe diesen Beitrag mit einer These begonnen, die das Selbstverständnis vieler Entwicklerinnen und Entwickler berührt, und ich will sie zum Schluss nicht weichspülen. Der Beruf, wie ihn viele gelernt haben, war zu einem guten Teil vom Gehirn über die Tastatur in den Editor. Kompetenzen, auf die man stolz sein durfte, verlieren jetzt an Wert: die Beherrschung des Editors, die Geschwindigkeit beim Schreiben, das formalisierte und konzeptionelle Denken, das Auswendigwissen einer Programmiersprache bis in ihre Ecken. Das ist ein realer Verlust für die, die viel in diese Fertigkeiten investiert haben, und ich halte nichts davon, ihn als reinen Gewinn zu verkaufen.

Was an die Stelle tritt, verlangt mehr Erfahrung als das Tippen. Dazu gehört, einen Plan zu entwerfen, der hält, die Tickets so zu schneiden, dass das Review funktioniert, und zu beurteilen, ob ein Diff im gewachsenen System das Richtige tut. Die Berufseinsteigerin, die früher über das Schreiben von Code in die Materie hineinwuchs, steht vor einem schwierigeren Weg. Der Einstieg über das Handwerk fällt weg, und der über das Urteil setzt eine Erfahrung voraus, die sie noch nicht haben kann. Wie dieser Weg in Zukunft aussieht, weiß ich nicht. Die Studie von Christopher Potts und Moritz Sudhof von der Stanford University, „A paradox of AI fluency" (arXiv:2604.25905), gibt einen Hinweis darauf, dass Übung einen Unterschied macht: Geübte Anwender sehen Fehler im Dialog deutlich häufiger als ungeübte. Aber wie man diese Übung erwirbt, wenn der traditionelle Übungsweg verschwindet, ist eine offene Frage, und ich habe darauf keine fertige Antwort.

Ausblick

Die Entwicklung liefert in dieser Pipeline einen Pull Request mit grünen Checks und voller Testabdeckung. Damit ist die Arbeit noch nicht zu Ende. Abdeckung garantiert keine Korrektheit: Ein Agent kann Tests schreiben, die alles berühren und nichts Sinnvolles prüfen, und das schwierige Urteil über die Richtigkeit einer Änderung bleibt beim Menschen. Daran setzt die nächste Rolle an. Der folgende Beitrag der Serie behandelt die Rolle Test. Sie schaut mit einer anderen Perspektive auf dasselbe Feature als die Rolle, die es gebaut hat. Ihre Arbeit setzt dort an, wo ein grüner Haken aus der Entwicklung noch keine Gewähr für korrektes Verhalten ist.

Ich nenne die Rolle der Einfachheit halber Business-Analyse oder kurz BA, wohl wissend, dass die Bezeichnungen in der Praxis schwanken. Mancherorts heißt sie Requirements Engineering, anderswo fällt die Aufgabe einer Produktverantwortlichen zu, einer Fachexpertin oder einem Analysten an der Schnittstelle zwischen Fachbereich und Technik. Wer die Rolle ausfüllt, ist für diesen Text zweitrangig. Es geht um die Tätigkeit, zu klären, was ein System tun soll und warum, und zwar so, dass eine Entwicklerin daraus etwas bauen kann, ohne raten zu müssen.

Warum gerade diese Rolle den Anfang macht

Wer im Brownfield arbeitet, hat es mit einem System zu tun, das über Jahre gewachsen ist und in dem vieles nie ausgesprochen wurde. Die größte Gefahr ist dort die falsch verstandene Anforderung, seltener die schwierige Technik. Ein Team kann einen Algorithmus aufwendig optimieren und eine Datenbank sauber umbauen. Am Ende stellt sich heraus, dass die ganze Arbeit ein Problem gelöst hat, das niemand hatte, während das eigentliche Problem unberührt blieb. Diese Sorte Fehlschlag ist im gewachsenen System häufiger als der spektakuläre technische Zusammenbruch, und sie ist leiser, weil sie erst spät auffällt.

Die Business-Analyse ist die Rolle, die diesen Fehlschlag verhindern soll. Sie steht zwischen dem, was die Fachseite will, und dem, was die Technik baut, und schließt die Lücke zwischen beidem, bevor jemand Code schreibt. Im agentischen Arbeiten ist diese Aufgabe der Schlüssel, weil ein Agent in Minuten eine plausible Anforderung formulieren kann, die sich liest, als hätte ein Mensch sie durchdacht. Eine plausible Anforderung kann trotzdem falsch sein, und im Altsystem entscheidet das über den Erfolg.

Die alte Zielvorstellung

Die beschriebene Aufgabe ist kein neues Berufsbild. Gute Business-Analyse sollte schon immer genau das leisten. Sie sammelt Fachwissen, prüft Aussagen, macht Widersprüche sichtbar, formuliert Anforderungen testbar und bereitet ein Ticket so vor, dass Entwicklung ohne Ratespiel arbeiten kann. Dieses Ziel war in den alten Pflichtenheften des Wasserfalls oft klar formuliert. Erreicht wurde es im Alltag selten. Der Grund lag häufig in den Bedingungen der Projekte. Unter Projektdruck wurde Recherche gekürzt, riesige Datenbestände blieben nur ausschnittweise durchsucht. Fachliche Zusammenhänge mussten aus alten Tickets, verstreuten Dokumenten, gewachsenen Sonderfällen und Gesprächen zusammengesetzt werden. Wer trotzdem sauber dokumentieren wollte, brauchte Zeit, die im Projektplan selten vorgesehen war. So entstanden unvollständige Anforderungen, obwohl die Beteiligten wussten, wie eine gute Anforderung aussehen müsste.

Mit Agenten ändert sich die Ökonomie dieser Arbeit. Der Anspruch bleibt derselbe, doch die Fleißarbeit wird billig: Quellen suchen, Varianten gegeneinander legen, Glossare vorbereiten, Akzeptanzkriterien normieren, Beispiel- und Testdaten erzeugen, offene Fragen tabellieren. Vollständigkeit braucht dann keine tagelange Dokumentarbeit mehr. Sie entsteht aus vielen kleinen, überprüften Agentenschritten. Dadurch gewinnt die BA den Teil ihrer Arbeit zurück, der im Projektdruck oft zu kurz kam: fachliche Zusammenhänge herstellen, gute Fragen formulieren, Nutzungsfälle durchdenken und die Grenzen eines Features sauber ziehen. Sie wird zur fachlichen Orchestratorin eines Wasserfall-Tickets. Sie bedient den Agenten, prüft seine Vorschläge, entscheidet über Belege und hält das Ticket so vollständig, dass Entwicklung, UX und Test daran anschließen können. Das knüpft an das an, was ich im Beitrag über die Rückkehr zum Wasserfall beschrieben habe: Die Maschine nimmt der BA die Such- und Schreiblast ab, und für Urteil, Kreativität und Verantwortung bleibt mehr Raum.

Die menschliche Fähigkeit: das Urteil über Quellen

Was eine Business-Analystin mitbringt und ein Sprachmodell nicht hat, ist das Urteil darüber, was eine Quelle wert ist. Eine erfahrene BA liest ein altes Ticket und erkennt, dass die darin beschriebene Anforderung längst von einer späteren Entscheidung überholt wurde. Bei einer Confluence-Seite merkt sie, dass diese ein Wunschbild beschreibt, das so nie umgesetzt wurde. Im Gespräch mit einer Sachbearbeiterin hört sie zwischen den Zeilen, dass die offizielle Prozessbeschreibung und die tatsächliche Praxis auseinanderfallen. Sie unterscheidet, was belegt ist, von dem, was nur plausibel klingt, und von dem, was sich zwischen zwei Quellen widerspricht.

Ein Sprachmodell kann das nicht zuverlässig, und das liegt in seiner Natur. Ein Modell approximiert Sprache. Es erzeugt Text, der zu dem passt, was es im Prompt gesehen hat, und ein belegter Fakt klingt darin genauso überzeugend wie eine geschickt formulierte Vermutung. Beide bestehen aus denselben grammatischen Bausteinen und klingen gleich gewiss. Ob eine Aussage in der Welt wahr ist, kann das Modell nicht beurteilen. Es sieht nur, ob sie sprachlich wahrscheinlich ist. Im Brownfield-Kontext, wo Belege selten und Annahmen häufig sind, ist diese Blindheit gegenüber dem Wahrheitswert das größte Risiko.

Hinzu kommt die Perspektive. Eine gute BA denkt das Ergebnis aus der Sicht derjenigen, die mit dem System arbeiten, etwa der Sachbearbeiterin oder dem Kunden. Sie fragt, was diese Person erreichen will und woran sie merkt, dass sie es erreicht hat. Ein Modell, das nicht angeleitet wird, denkt aus der Sicht des Systems, weil im Trainingsmaterial die Systemsicht dominiert. Es beschreibt, was eine Funktion validiert. Was eine Person tun können soll, bleibt außen vor. Diese Verschiebung der Perspektive ist subtil und zugleich folgenreich, weil sie die Verantwortung für den Erfolg von der Fachseite an die Technik abgibt, wo sie nicht hingehört.

Im Gespräch mit Stakeholdern zeigt sich ein weiterer Unterschied. Eine BA hört einer Fachexpertin zu und erkennt, wenn hinter einer einzeln formulierten Anforderung in Wahrheit zwei stecken, die nur zufällig zusammen genannt wurden. Hinter einer technisch klingenden Bitte verbirgt sich manchmal ein ganz anderes fachliches Bedürfnis, und auch das fällt ihr auf. Sie merkt, wenn eine Anforderung still voraussetzt, dass das gewachsene System sich auf eine bestimmte Weise verhält, und dass diese Voraussetzung geprüft werden muss. Dieses Zerlegen und Nachfragen geschieht im Gespräch, im Hin und Her zwischen Menschen, und es ist die Stelle, an der ein Agent am wenigsten ersetzen kann.

Vier Grundprinzipien der Rolle

An vier Prinzipien lässt sich jeder Output der Rolle messen.

Die belegte Wahrheit liefern. Die Business-Analyse liefert eine belegte Wahrheit und überlässt die Lösung der Entwicklung. Sie beschreibt, was passieren soll und warum, für wen und mit welchem Nutzen. Wie es gebaut wird, entscheidet die Entwicklung, und zwar erst nach einer Prüfung des Brownfields. Diese Prüfung kann die BA gar nicht leisten, weil sie den Code nicht in der Tiefe kennt und auch nicht bewerten kann. Eine BA, die eine technische Lösung vorgibt, nimmt der Entwicklung das Urteil ab, das nur dort getroffen werden kann, und sie tut das meist, ohne die Folgen zu überblicken.

Jede Aussage ist etikettiert. In einem BA-Output gibt es keinen ungelabelten Fließtext. Jede Behauptung trägt eine von vier Marken: einen [Fakt] für etwas Belegbares mit benannter Quelle, eine [Annahme] für etwas Plausibles ohne Beleg, eine [Frage] für etwas Offenes, das noch geklärt werden muss, und einen [Widerspruch] für eine Stelle, an der zwei Quellen einander nicht zustimmen. Glatter, unmarkierter Text ist eine bloße Zusammenfassung und genügt nicht. Eine Zusammenfassung verwischt gerade die Unsicherheiten und Widersprüche, die das eigentliche Risiko ausmachen.

Verbindlich ist das Ticket. Der Chatverlauf ist flüchtig, und was in einer Agent-Sitzung erarbeitet wird, aber nicht ins Ticket wandert, ist für den weiteren Verlauf verloren. Das ist der Artefakt-Kontrakt aus dem Auftakt-Beitrag, hier in seiner konkreten Form für diese Rolle. Eine Entwicklerin, die das Feature umsetzt, arbeitet mit dem Ticket. Was darin fehlt, fehlt für sie ganz, denn den Diskussionsverlauf sieht sie nicht. Der Beitrag zum Spec-Drift zeigt, wie weit Ticket und Code im Lauf eines Projekts auseinanderlaufen.

E2E-Inhalte entstehen vor der Übergabe. Ein Ticket ist erst reif für die Entwicklung, wenn es den fachlichen Stoff für den späteren End-to-End-Test enthält. Dazu gehören Szenarien, Platzhalterdaten, erwartete Meldungstexte, Ausgangs- und Zielzustände, Rollenwechsel sowie relevante Übergaben an Nachbarsysteme. Das sind noch keine ausführbaren Tests. Die BA liefert die Inhalte, aus denen die Testrolle später Browser- und Workflow-E2E-Spezifikationen macht.

Wie der Agent die Rolle unterstützt

Der Agent ist in dieser Rolle ein Arbeitsapparat der BA. Er recherchiert, sortiert, formuliert Rohfassungen und erzeugt die Inhalte, aus denen später Entwicklung und Test arbeiten, und nimmt der BA damit den mechanischen Anteil ab. Er entscheidet nichts. Die BA steuert ihn über präzise Aufträge, überprüft die Ergebnisse und verwirft, was nur überzeugend klingt. Wer diese Rolle ausfüllt, braucht weiterhin Fachwissen. Dazu kommt eine neue handwerkliche Fähigkeit: den Agenten so zu führen, dass am Ende ein vollständiges, prüfbares Ticket entsteht und kein Gesprächsprotokoll.

Der Agent arbeitet in der frühen Phase, die in der Pipeline Discovery heißt, also der Voruntersuchung. Darin versteht das Team, worum es geht, bevor es festlegt, was zu tun ist. Als Erstes baut der Agent ein Quelleninventar auf.

Ein Quelleninventar ist eine Liste aller Stellen, die etwas über den betroffenen Bereich aussagen, und jede Stelle bekommt eine Kennung, einen Titel und ein Stand-Datum im Format JJJJ-MM-TT. Das Datumsformat ist eine Regel mit Konsequenz: Vage Angaben wie “aktuell” oder “kürzlich aktualisiert” sind nicht erlaubt. Im System wirkt eine vor drei Jahren verlassene Confluence-Seite genauso frisch wie eine eben überarbeitete. Erst das konkrete Datum macht den Unterschied sichtbar, der im Bestandssystem oft darüber entscheidet, ob eine Aussage noch gilt oder längst überholt ist.

Der Agent liest dafür viele Quellen: Tickets aus dem Vorgangssystem, Confluence-Seiten, Architecture Decision Records, also die dokumentierten Architekturentscheidungen, Runbooks, die beschreiben, wie ein System betrieben wird, alte Dokumentation und den Code selbst. Diese Breite ist seine Stärke. Ein Mensch braucht Tage, um sich durch verstreute Altdokumentation zu lesen. Ein Agent legt in kurzer Zeit ein Inventar an, das eine BA dann prüfen kann. Hier verstärkt das Werkzeug die Rolle, weil es eine mühsame, aber notwendige Fleißarbeit beschleunigt.

Die Bewertung übernimmt der Agent nicht. Jede Erkenntnis, die er aus den Quellen zieht, muss die BA etikettieren. Der Agent kann vorschlagen: Diese Aussage stützt sich auf Ticket TICKET-417 von 2024-03-12, also schlage ich [Fakt] vor. Die Marke aber setzt der Mensch. Nur er kann beurteilen, ob das Ticket noch gilt oder überholt wurde und ob es vielleicht nur einen Wunsch dokumentiert hat, der nie Realität wurde. Das Etikettieren ist die analytische Kernleistung der Rolle, und es bleibt beim Menschen.

Eine Eigenheit dieser Rolle läuft der Erwartung an ein Sprachmodell zuwider: Die glatte, gut lesbare Zusammenfassung ist hier ausdrücklich nicht das Ziel. Ein Modell ist darauf trainiert, eine widerspruchsfreie, runde Fassung zu liefern, was in der Discovery schädlich ist. Eine runde Zusammenfassung glättet genau die Widersprüche, in denen das Risiko liegt. Wenn zwei Quellen sich widersprechen, soll der Output den Widerspruch zeigen, mit beiden Seiten und der Marke [Widerspruch]. Er soll keine dritte, harmonische Formulierung erfinden, die so tut, als gäbe es kein Problem. In der Discovery geht es darum, Widersprüche offenzulegen.

Danach wird der Agent zum Produktionswerkzeug für die E2E-Inhalte. Er kann aus Akzeptanzkriterien fachliche Szenarien vorschlagen, Mustermann-Daten erzeugen, erwartete Meldungen auf Konsistenz prüfen und Prozessvarianten nebeneinanderlegen. Die BA entscheidet, welche dieser Vorschläge die fachliche Wirklichkeit treffen. Der Agent liefert Masse und Varianten, und die BA macht daraus verbindliche Inhalte für das Ticket.

Das Zusammenspiel mit UX im Feature-Workshop

Die Business-Analyse arbeitet eng mit UX zusammen, der Rolle, die beschreibt, wie sich ein Feature für die Nutzerinnen und Nutzer anfühlt. In der Pipeline treffen sich beide in einem Feature-Workshop. Der Workshop hat eine feste Form, die verhindert, dass man sich vorschnell auf eine Formulierung einigt, die nur an der Oberfläche stimmt.

Der Workshop beginnt damit, dass BA und UX das Feature unabhängig in eigenen Worten beschreiben. Jede Seite notiert das Ziel, den Nutzer oder die Nutzerin, den Nutzen, die Grenzen und die offenen Fragen. Das geschieht anfangs getrennt, weil die Unterschiede zwischen beiden Beschreibungen die interessanten Stellen sind. Wo BA und UX dasselbe Feature verschieden verstehen, liegt eine Unklarheit, die geklärt werden muss, bevor jemand weiterarbeitet. Aus den beiden Beschreibungen entsteht dann eine gemeinsame Team-Vorlage, ein abgestimmtes Bild des Features, auf das sich beide Rollen verständigt haben.

Ein Kernstück dieser gemeinsamen Arbeit ist die Definition der UX-Zustände. Ein Feature hat nicht nur den einen Verlauf, in dem alles gut geht, sondern mehrere Zustände, die alle beschrieben werden müssen. Die Pipeline benennt sie ausdrücklich. [UX-ERFOLG] ist der Fall, in dem die Aufgabe gelingt. [UX-LEER] meint den Zustand, in dem noch keine Daten da sind, eine leere Liste, ein frischer Datensatz. [UX-FEHLER] deckt ab, was passiert, wenn etwas schiefgeht. [UX-LADE] beschreibt das Warten auf eine Antwort. [UX-EDGE] steht für die Randfälle, die selten auftreten, aber dann das Verhalten bestimmen.

Der Fehlerfall wird in der Praxis am häufigsten vergessen und verrät zugleich am meisten. [UX-FEHLER] beschreibt eine fachliche Meldung in Geschäftssprache. Wenn eine Sachbearbeiterin einen Schaden ohne eine notwendige Angabe speichern will, soll sie eine Meldung lesen, die in ihrer Sprache erklärt, was fehlt und warum es fehlt. Ein technischer Code wie “Validierungsfehler in Feld 0x2F” ist keine solche Meldung. Diese Anforderung ist eine fachliche, und sie gehört deshalb in den BA-Teil der Beschreibung. Wie die Meldung technisch ausgelöst wird, ist Sache der Entwicklung. Ihr Wortlaut und ihre Sprache gehören zur Fachseite.

Erst nachdem das Team diese gemeinsame Beschreibung geprüft und für stimmig befunden hat, werden die Tickets ins Vorgangssystem hochgeladen. Nicht jeder Einfall wird sofort als Ticket angelegt, weil ein vorschnell angelegtes Ticket eine Verbindlichkeit suggeriert, die noch gar nicht erreicht ist. Erst der Team-Check macht aus einem Entwurf ein Ticket, das die nächste Rolle ernst nehmen kann.

Was die Rolle als Artefakte produziert

Das Hauptartefakt der Business-Analyse ist das BA-Ticket. Es hat eine feste Struktur, und diese Struktur ist die Form, in der eine belegte Wahrheit übergeben werden kann. Jede Sektion hat einen praktischen Zweck, und auch die Reihenfolge der Sektionen hat ihren Sinn.

Das Ticket beginnt mit einem Header. Darin steht das Outcome, also das Ergebnis aus Nutzersicht, und dieses Outcome beginnt mit einer Persona oder einer Aktion: “Die Sachbearbeiterin kann …”. Diese Formulierung ist eine Probe. Wenn sich das Ergebnis so formulieren lässt, dass eine handelnde Person am Anfang steht und eine Fähigkeit folgt, dann ist es aus Nutzersicht gedacht. Wenn der Satz dagegen mit “Das System …” beginnt, ist er aus Systemsicht gedacht, und das ist ein Warnzeichen. Neben dem Outcome stehen im Header die Persona, der Trigger, also was das Feature auslöst, die Stakeholder und der Quellen-Stand.

Auf den Header folgt der Body in einer festen Reihenfolge von Sektionen. Zuerst das Problem oder der Bedarf: Warum gibt es dieses Feature überhaupt, welches fachliche Bedürfnis steht dahinter? Dann die Akzeptanzkriterien, formuliert als Given/When/Then in Geschäftssprache und einzeln nummeriert, [AC-1], [AC-2], und so fort. Given/When/Then ist ein einfaches Schema: Gegeben eine Ausgangslage, wenn eine Handlung geschieht, dann ein erwartetes Ergebnis. In Geschäftssprache heißt das, dass dort fachliche Begriffe stehen und keine technischen. Einzeln nummeriert ist jedes Kriterium prüfbar und referenzierbar. Ein verschachteltes Kriterium, das drei Dinge auf einmal verlangt, ist in Wahrheit drei Kriterien und gehört aufgeteilt.

Danach kommen die UX-Zustände aus dem Workshop, dann die Nicht-Ziele. Die Nicht-Ziele sind eine eigene, oft unterschätzte Sektion. Sie schließen häufige Annahmen aktiv aus. Wenn ein Feature ein neues Pflichtfeld einführt, dann ist die Annahme naheliegend, dass auch der bestehende Datenbestand dieses Feld bekommen muss. Eine solche Annahme gehört unter die Nicht-Ziele, ausdrücklich verneint, damit niemand sie still mitliest. Was nicht ausgeschlossen wird, interpretiert im Zweifel jemand hinein, und im Brownfield sind solche stillen Mitannahmen erfahrungsgemäß die teuersten.

Es folgt das Quelleninventar, also die Liste der Quellen mit ihren Stand-Daten. Dahinter kommt die Aussagenliste, in der jede Behauptung mit ihrer Marke steht und bei einem [Fakt] die Quelle benannt ist. Dann die offenen Fragen, und zwar als Tabelle. Jede Frage bekommt eine Kennung [Q-1], eine Formulierung der Frage, einen Owner, also eine namentlich verantwortliche Person, die sie beantworten soll, und einen Antworttermin. Eine letzte Spalte hält fest, was passiert, wenn die Frage unbeantwortet bleibt. Diese Spalte ist die wichtigste, weil sie die Frage gewichtet. Eine offene Frage, die unbeantwortet das ganze Feature blockiert, wiegt schwerer als eine, die nur ein Detail offenlässt, und die Tabelle macht diesen Unterschied sichtbar. Den Abschluss bilden die E2E-Inhalte, die Stakeholder und die Freigabe.

Zum BA-Ticket gehören mehrere Pflicht-Artefakte. Eine UX-Skizze, die den Workshop-Befund visuell festhält. Ein Snippet, also ein kleines konkretes Beispiel des erwarteten Verhaltens. Ein Glossar, das die fachlichen Begriffe definiert, und dieses Glossar hat im Brownfield-Kontext eine weitere Spalte für das Pendant im Nachbarsystem. Wo ein Begriff über Systemgrenzen hinweg lebt, soll dort stehen, wie er im anderen System heißt. Ist kein Pendant bekannt, steht ein Strich und eine offene Frage. Zuletzt gehören die E2E-Inhalte dazu: Beispieldaten mit Platzhaltern, fachliche Szenarien, erwartete Meldungen und die Zustände, die der spätere Test nachweisen soll. Echte Personen, Firmen oder Vorgangsnummern kommen darin nicht vor.

Diese E2E-Inhalte sind Voraussetzung dafür, dass das Ticket an die Entwicklung geht. Sie sind noch kein Testplan und kein Testskript. Sie beschreiben den fachlichen Weg, den ein späterer Test belegen muss. Fehlt dieser Stoff, muss die Entwicklung beim Planen erraten, welche Zustände und Übergänge am Ende sichtbar geprüft werden sollen. Dann ist das Ticket für die Umsetzung zu früh.

Brownfield-Spezifika: was im Brownfield anders ist

Eine Business-Analyse im gewachsenen System unterscheidet sich von einer auf der grünen Wiese, und zwar in der Art der Aufgabe selbst. Drei Unterschiede sind so wichtig, dass die Pipeline sie als feste Regeln verankert.

Der Bestandsschutz vor Migrationszwang steht am Anfang. Ein neues Feature soll bestehende Daten nicht automatisch migrieren oder validieren. Neue Pflichten greifen nur für Datensätze, die neu angelegt oder aktiv bearbeitet werden, und der Altbestand bleibt lesbar und speicherbar. Diese Trennung ist eine fachliche Entscheidung mit großer Wirkung. Fehlt sie, rutscht eine Datenmigration unausgesprochen in ein Feature-Ticket, obwohl sie ein eigenes Vorhaben ist, mit eigenen Stakeholdern, eigenem Risikoprofil und eigenem Zeitplan. Behandelt man sie als Nebensache, gerät der Zuschnitt des Tickets durcheinander, und das Feature dauert am Ende deutlich länger als geplant. Die BA hält diese Trennung deshalb ausdrücklich in den Nicht-Zielen fest.

Die zweite Eigenheit betrifft das Mapping der systemübergreifenden Begriffe, das beim Glossar schon angeklungen ist. In gewachsenen Systemen teilt ein System fast immer Daten mit anderen, und ein Begriff wie Partner, Vorgang oder Rolle kann in jedem davon etwas leicht anderes bedeuten. Solange diese Beziehung nirgends benannt ist, bleibt sie eine versteckte Fehlerquelle. Die BA muss die Cross-System-Begriffe explizit mappen, auch dann, wenn das aktuelle Feature gar keine systemübergreifende Wirkung hat. Die nächste Änderung könnte sie haben, und dann steht die Mehrdeutigkeit schon im Weg.

Am strengsten ist die Regel, dass im BA-Ticket keine technische Vorgabe stehen darf, also weder Architektur noch Datenmodell, keine Spaltennamen und keine Wahl eines Frameworks. Nach der Übergabe prüft die Entwicklung die Machbarkeit gegen das Brownfield: Sie schaut, an welchen Stellen im gewachsenen Code dieselbe Logik hängt, was sich wiederverwenden lässt und was eine Änderung an einer Stelle drei Stellen weiter auslöst. Schreibt das BA-Ticket schon eine technische Lösung vor, macht es diese Prüfung wertlos. Die Entwicklung arbeitet dann nur noch eine Vorgabe ab, die jemand ohne Kenntnis des Codes gesetzt hat. Nach meiner Erfahrung ist die technische Vorgabe im fachlichen Ticket der häufigste Grund dafür, dass die Entwicklung ein Ticket zurückgibt. Die BA beschreibt also, was passieren soll und warum, und überlässt die Frage, wie es umgesetzt wird, der Entwicklung.

Das Quality Gate: Definition of Ready

Zwischen der Business-Analyse und der Entwicklung steht ein Prüfpunkt, in der Pipeline Definition of Ready genannt, kurz DoR, oder auch Ready for Dev. Es ist die Stelle, an der ein Mensch entscheidet, ob das Ticket reif ist, in die Umsetzung zu gehen. Das Gate hat eine Prüfliste, und die Prüfung übernimmt bewusst ein Mensch, weil es um Urteilsfragen geht, die sich maschinell nicht beantworten lassen.

Die Prüfliste fragt:

• ob das Outcome ein eindeutiger Satz ist, der mit einer Persona oder einer Aktion beginnt und sich aus Nutzersicht testen lässt
• ob die Akzeptanzkriterien einzeln nummeriert und in Geschäftssprache formuliert sind, ohne technische Begriffe
• ob die UX-Zustände vorhanden sind, einschließlich des Fehlerfalls in fachlicher Sprache
• ob das Quelleninventar Stand-Daten hat und kein “aktuell” enthält
• ob die Aussagen etikettiert sind, jede mit ihrer Marke, und bei jedem [Fakt] die Quelle benannt ist
• ob die E2E-Inhalte vollständig sind, also fachliche Szenarien, Mustermann-Daten, erwartete Meldungen, Ausgangs- und Zielzustände sowie relevante Übergaben an Nachbarsysteme
• ob die Pflicht-Artefakte im Repository liegen, also UX-Skizze, Snippet, Glossar mit Nachbarsystem-Spalte und E2E-Inhalte
• ob das Ticket frei von technischer Lösung ist.

Das Pflichtartefakt dieses Gates ist zweiteilig: das etikettierte Quelleninventar und das fertige Ticket mit E2E-Inhalten. Mit nur einem davon ist die Frage des Gates nicht beantwortbar. Das Quelleninventar belegt, dass die Wissensbasis ehrlich ist, mit ihren Lücken und Widersprüchen, und das Ticket zeigt, dass aus dieser Basis eine prüfbare Anforderung geworden ist.

Die wichtigste Eigenschaft des Gates ist seine Härte. Fehlt ein Punkt, geht das Ticket zurück. Es wird nicht still weiterverarbeitet und nicht mit einem mündlichen “das klären wir später” durchgewunken, auch nicht in der Annahme, die Entwicklung werde die Lücke schon füllen. Wer so still weiterarbeitet, schleppt Fehler tief in die Kette hinein, wo sie teuer werden. Ein Ticket, das die Definition of Ready nicht besteht, ist nicht fertig und geht nicht in die Umsetzung. Diese Strenge kann im Moment lästig wirken, hält aber die Fehlerkosten niedrig, weil die Korrektur noch im Text geschieht, solange das System noch nicht läuft.

Wie die Compliance-Regeln in dieser Rolle wirken

Die Compliance-Anforderungen, die der Auftakt-Beitrag als sechstes Prinzip beschrieben hat, sind in die Arbeitsweise der Business-Analyse eingebaut. In dieser Rolle wirken sie an vier konkreten Stellen.

Datenminimierung. In der Softwareentwicklung heißt das, dass personenbezogene Daten dort nicht hingehören. Die Beispieldaten im BA-Ticket sind deshalb ausschließlich Platzhalter, Mustermann GmbH, Erika Mustermann, Max Mustermann. Ein BA-Ticket landet irgendwann in einer Schulung, einer Präsentation, einem Export oder einem geteilten Arbeitsbereich. Wer von Anfang an mit Platzhaltern arbeitet, muss echte Daten nicht hinterher herausfiltern, eine Aufräumarbeit, bei der ohnehin selten alle Stellen erwischt werden. Der Projektkontext, mit dem der Agent arbeitet, enthält nur das fachlich Nötige, als Klartext, ohne reale Daten.

Quellen mit Stand-Datum. Dass jede Quelle ein Stand-Datum hat und es kein “aktuell” gibt, ist eine Frage der Sorgfalt und ebenso der Nachvollziehbarkeit. Wer später prüfen will, auf welcher Wissensbasis eine Anforderung entstanden ist, findet im Quelleninventar datierte Belege. Das ist die Provenienz, die ein Audit-Trail braucht, in der einfachsten denkbaren Form.

Markierung der KI-erzeugten Inhalte. Der EU AI Act, die Verordnung 2024/1689, verlangt Transparenz über den Einsatz von KI. In dieser Rolle bedeutet das, dass jedes vom Agenten erzeugte Stück als KI-erzeugt markiert wird. Ein Vermerk verweist auf die Operation, die verantwortliche Person und die Version des Modells oder der Anweisung. Wenn der Agent eine Marke für eine Aussage vorgeschlagen hat, ist nachvollziehbar, dass der Vorschlag von einem Modell kam und ein Mensch ihn bestätigt oder korrigiert hat. Beides steht in der Spur: der markierte Vorschlag des Agenten und die Marke, die der Mensch gesetzt hat.

Das DoR-Gate als menschliche Freigabe. Der Grundsatz der gesamten Pipeline lautet, dass der Agent vorschlägt und der Mensch entscheidet, und die menschliche Aufsicht gilt ausnahmslos. Das DoR-Gate ist der Ort, an dem diese Aufsicht in der Business-Analyse konkret wird. Eine namentlich verantwortliche Person bestätigt das Ticket, bevor es weitergeht, und sie steht damit für seinen Inhalt gerade. Dass der Agent zuarbeitet, mindert diese Verantwortung nicht. Ein Ticket, das ein Modell vorgeschlagen und ein Mensch nur abgenickt hat, ohne es zu prüfen, verletzt diesen Grundsatz, auch wenn formal eine Freigabe vorliegt. Sie zählt erst nach einer echten Prüfung. Wie weit eine solche Freigabe reicht, steht in den Grenzen menschlicher Freigaben.

Ein durchgespieltes Beispiel

Ein kurzes Beispiel mit Platzhaltern zeigt, wie die Regeln zusammenwirken. Eine Fachabteilung der Mustermann GmbH meldet einen Bedarf: Bei der Erfassung eines Vorgangs soll künftig eine bestimmte Angabe verlangt werden, die bisher freiwillig war. Bei diesem ersten Satz würde ein vorschnelles Vorgehen sofort ein Ticket anlegen, das ein neues Pflichtfeld verlangt.

Die Business-Analyse beginnt anders. Der Agent baut das Quelleninventar. Er findet ein altes Ticket von 2023, das die Angabe einmal als optional eingeführt hat, und eine Confluence-Seite von 2024, die einen Prozess beschreibt. Dazu kommen Hinweise im Code darauf, wie die Angabe heute gespeichert wird. Nun etikettiert die BA. Dass die Angabe heute optional ist, belegt durch Ticket und Code, ist ein [Fakt]. Ein zweiter [Fakt] stammt aus dem Gespräch: Die Fachabteilung verlangt sie für alle künftigen Vorgänge. Ob auch die bestehenden Vorgänge sie bekommen sollen, hat niemand ausgesprochen. Das bleibt eine [Annahme], die geprüft werden muss. Die Confluence-Seite wiederum beschreibt einen Prozess, der mit der tatsächlichen Praxis der Sachbearbeitung nicht übereinstimmt, ein [Widerspruch].

Aus dieser etikettierten Basis entsteht das Ticket. Das Outcome: “Die Sachbearbeiterin kann einen Vorgang nur dann abschließen, wenn die Angabe vorhanden ist, und erhält andernfalls eine fachliche Meldung, die erklärt, welche Angabe fehlt.” Ein Akzeptanzkriterium [AC-1] beschreibt den Erfolgsfall, [AC-2] den Fehlerfall in Geschäftssprache. Der UX-Zustand [UX-FEHLER] formuliert die Meldung in fachlicher Sprache. Unter den Nicht-Zielen steht ausdrücklich: Der Datenbestand wird nicht verändert, bestehende Vorgänge ohne die Angabe bleiben gültig und speicherbar, eine Migration ist nicht Teil dieses Tickets. Die offene Frage [Q-1] in der Tabelle: Sollen bestehende Vorgänge bei der nächsten Bearbeitung nachgepflegt werden, Owner die Fachabteilung, mit Termin und der Notiz, dass eine Bejahung ein eigenes Migrationsvorhaben auslöst. Den [Widerspruch] zwischen Confluence-Seite und Praxis hält die BA in der Aussagenliste fest, damit die Entwicklung ihn nicht ahnungslos überschreibt.

Für den E2E-Test produziert die BA außerdem den fachlichen Inhalt. Erika Mustermann legt für die Mustermann GmbH einen Vorgang an. Die notwendige Angabe fehlt. Beim Abschluss erscheint die Meldung in Geschäftssprache, der Vorgang bleibt im bearbeitbaren Zustand, und die Übergabe an das Nachbarsystem unterbleibt in diesem Zustand. Diese Angaben sind bewusst konkret, denn der spätere Test braucht sichtbare Inhalte und erwartete Zustände. Die Entwicklung sieht damit schon vor der Umsetzung, welches Verhalten am Ende belegt werden muss.

Was hier nicht im Ticket steht, ist mindestens so wichtig wie das, was darin steht. Es steht kein Spaltenname darin und keine Vorgabe, ob die Prüfung im Frontend oder im Backend geschieht, auch keine Wahl einer Bibliothek. Das entscheidet die Entwicklung nach ihrer Machbarkeitsprüfung, sobald das Ticket bei ihr liegt.

Ausblick

Der nächste Beitrag der Serie wendet sich der Entwicklung zu. Dort wird sich zeigen, was aus einem BA-Ticket wird, das die Definition of Ready bestanden hat: wie die Entwicklung das Brownfield gegen die Anforderung prüft, wie aus dem Was ein Wie wird und wie aus dem Epic die kleinen, einzeln umsetzbaren Tickets entstehen. Außerdem geht es darum, wie ein Agent über viele Schritte hinweg arbeiten kann, ohne die Kontrolle zu verlieren. An der Übergabe zwischen Business-Analyse und Entwicklung entscheidet sich, ob die saubere Vorarbeit hält, und deshalb ist das DoR-Gate so streng, wie es ist.

Die Rolle der Business-Analyse lässt sich mit einer einzigen Übung erproben, noch bevor der nächste Beitrag erscheint. Nehmen Sie die nächste Anforderung, die auf Ihrem Tisch landet, und etikettieren Sie jeden Satz darin. Was davon ist ein Fakt mit Quelle, was eine Annahme, was eine offene Frage, was ein Widerspruch? Meist wird die Liste der Annahmen und Fragen länger, als Ihnen lieb ist, und das rechtfertigt die Rolle. Eine Anforderung, die sich vollständig in belegte Fakten auflösen lässt, ist selten. Viel häufiger zeigen sich beim Etikettieren ein paar Annahmen, die man für längst geklärt hielt.

Ich habe in den vergangenen Monaten eine agentische Engineering-Pipeline für den SDLC ausgearbeitet und in Workshops erprobt. Es ist ein durchgehendes Vorgehen für den Software-Entwicklungszyklus mit Agenten, zugeschnitten auf genau diesen Einsatz. Sie beschreibt, wie ein Team mit Agenten arbeitet, wenn es ein neues Feature in ein bestehendes System bringen will, ohne das Brownfield zu beschädigen. Dieser Text ist der Auftakt einer Serie und nimmt sich die Pipeline als Ganzes vor: warum sie so aussieht, wie sie aussieht, und welche Prinzipien sie stützen. Die folgenden Beiträge gehen dann in die einzelnen Rollen, in die Business-Analyse, ins UX, in die Entwicklung, in den Test und in den Betrieb.

Warum das Brownfield ein eigenes Problem ist

Das DORA-Team von Google Cloud hat im April 2026 einen Bericht zum Return on Investment KI-gestützter Softwareentwicklung vorgelegt. Ich habe ihn an anderer Stelle ausführlich besprochen (Der ROI hängt am Fundament). Eine Zahl daraus ist für dieses Thema die wichtigste. Im Greenfield, also bei neuen Systemen ohne Altlast, beziffert der Bericht die Produktivitätswirkung KI-gestützter Entwicklungswerkzeuge auf 35 bis 40 Prozent. Im Brownfield, im gewachsenen System, sind es rund zehn Prozent. Der Faktor zwischen beiden Welten liegt bei drei bis vier. Für Organisationen, die ihr Geld mit der Pflege bestehender Software verdienen, ist das die Kernaussage zur Wirtschaftlichkeit.

Ein Sprachmodell arbeitet nur mit dem Kontext, den es im Moment der Anfrage bekommt, und der fällt in beiden Welten verschieden aus. Im Greenfield ist er klein und überschaubar. Im Altsystem ist er groß, über viele Orte verstreut, und ein guter Teil davon steht nirgends geschrieben. Ein Teil dieses Wissens steckt in einer Datenbank, deren Spaltennamen aus einer veralteten Fachsprache stammen. Eine Ablauflogik bildet eine längst vergessene regulatorische Auflage ab, ohne das irgendwo zu vermerken. Der Rest existiert nur im Kopf der Kollegin, die das Modul vor Jahren gebaut hat. Ein Agent, der diesen Kontext nicht hat, produziert Code, der richtig aussieht und genau dort falsch ist, wo man es von außen nicht sieht.

Zu diesem wirtschaftlichen Befund kommt ein methodischer. Christopher Potts und Moritz Sudhof von der Stanford University haben in der Arbeit „A paradox of AI fluency" knapp 27.000 reale KI-Dialoge ausgewertet (arXiv:2604.25905). Ihr auffälligstes Ergebnis betrifft die Sichtbarkeit von Fehlern. Bei geübten Anwendern werden 59 Prozent der Fehler im Dialog selbst sichtbar, bei ungeübten nur 12 Prozent. Bei ungeübten Anwenderinnen und Anwendern bleiben demnach 88 Prozent der Fehler im Dialog unsichtbar. Was danach mit diesen Fehlern geschieht, misst die Studie nicht. Für die Arbeit im Brownfield genügt aber schon dieser Befund: Wo der Dialog keine Korrektur auslöst, wandert ein Fehler leichter bis ins produktive System. Ungesteuertes Agentic Coding in einem gewachsenen System geht kurzfristig schneller. Die Schäden, die es dabei anlegt, fallen erst Wochen oder Monate später auf.

Die Pipeline setzt hier an. Sie soll die unsichtbaren Fehler sichtbar machen, bevor sie in das gewachsene System gelangen. Dass der Agent dabei schneller tippt, zählt weniger.

Die Pipeline in einem Bild

Ein Feature wandert durch sechs Phasen, und an den Übergängen zwischen den Rollen steht jeweils ein Prüfpunkt.

Zuerst wird der Kontext bekannt gemacht. Bei einem Bestandssystem heißt das, aus dem vorhandenen Code, aus Tickets, aus alter Dokumentation und aus den Daten herauszuziehen, was über den betroffenen Bereich bekannt ist. In dieser Phase wird nur gelesen, nichts verändert.

Danach exploriert das Team gemeinsam mit dem Agenten. Bevor es über eine Lösung nachdenkt, stellt es Fragen und sucht nach Widersprüchen.

Die Ergebnisse werden als Markdown-Dateien im Repository festgehalten: was gefunden wurde, was offen blieb und wo sich Quellen widersprachen.

Aus diesem Verständnis entsteht eine Struktur: ein Epic, das das Ziel beschreibt, und Tickets, die je ein bis drei Stunden Arbeit umfassen, testbar und nachvollziehbar.

Vor dem Code steht ein Umsetzungsplan, der die Reihenfolge, die Teststrategie, die Risiken und die betroffenen Dateien festlegt.

Zuletzt setzt der Agent den Plan um, Ticket für Ticket, und dokumentiert seinen Fortschritt im Plan, im Epic und in den Tickets selbst.

Der Ablauf ist vertraut. Wer einen klassischen Entwicklungsprozess kennt, erkennt die Stationen wieder. Das Neue steckt in den Regeln, die zwischen den Phasen gelten.

Das Brownfield muss erst lesbar werden

Im Greenfield kann man mit Phase zwei beginnen, weil es nichts gibt, das man vorher lesen müsste. Im Brownfield ist die erste Phase die wichtigste und gleichzeitig die, die am häufigsten unterschlagen wird. Sie heißt Kontext-Extraktion und beantwortet die Frage, was das System heute tatsächlich an der Stelle tut, die wir ändern wollen.

Die Antwort steckt an mehreren Orten, und ein guter Durchlauf liest sie alle. Der Code zeigt, was passiert, aber nicht, warum. Das Warum einer Entscheidung steht in der Versionsgeschichte. Die Tickets verraten, welche Anforderung einmal dahinterstand, oft in einer Sprache, die seither veraltet ist. Die Daten selbst halten fest, was die Theorie verschweigt. Ein Feld, das laut Dokumentation immer gefüllt sein müsste, ist in einem erheblichen Teil der Bestandsdatensätze leer, weil sich die Sachbearbeitung über Jahre mit Freitext-Notizen beholfen hat. Ein neues Pflichtfeld, eingeführt ohne diesen Befund, lässt einen großen Teil des Datenbestands an der Regel scheitern.

Ein besonderer Fall der Kontext-Extraktion tritt im Bestandssystem fast immer auf und ist fast nie dokumentiert: Begriffe, die in mehreren Systemen leben. Ein Begriff wie „Partner" oder „Vorgang" kann in dem System, das wir ändern, etwas anderes bedeuten als in dem System nebenan, mit dem es Daten austauscht. Solange diese Beziehung nirgends benannt ist, ist sie ein Risiko für jede Migration und jede Koexistenz zweier Systeme. Die Pipeline verlangt deshalb, dass ein Begriff, der über Systemgrenzen hinweg existiert, im Glossar des Tickets sein Pendant im anderen System bekommt. Das gilt auch dann, wenn das aktuelle Feature gar keine systemübergreifende Wirkung hat. Wo kein Pendant bekannt ist, steht ein Strich und ein Vermerk als offene Frage. So wird aus einer unsichtbaren Annahme ein geklärter Fakt oder wenigstens eine sichtbare Lücke. Die meisten Bestandssysteme leben dagegen mit der stillen Mehrdeutigkeit.

Diese erste Phase produziert noch keine Lösung und soll es nicht. Ihr Artefakt ist ein Bild des Ist-Zustands, belegt und datiert, mit klar markierten Lücken. Erst auf diesem Bild lässt sich verantwortlich entscheiden, was das neue Feature tun soll.

Erstes Prinzip: Menschen bleiben in Rollen

Der Agent ersetzt das ganze Team, so verspricht es eine verbreitete Erzählung: eine Person, ein Sprachmodell, und alles von der Anforderung bis zum Deployment läuft durch denselben Chat. Das klingt verlockend, weil es billig ist, hält einer näheren Betrachtung aber nicht stand.

Jede Rolle steht für eine eigene Sicht auf dasselbe Feature. Eine Business-Analystin urteilt anders als ein Entwickler, ein Tester schaut anders hin als ein UX-Designer, und der Betrieb stellt Fragen, die in der Entwicklung niemand stellt. Über diese Unterschiede findet ein Team die Fehler, die einer einzelnen Perspektive entgehen. Bündelt man alle Rollen in einer Person und stattet diese Person mit einem Agenten aus, der jede Rolle imitieren kann, bekommt man nur die Imitation der Perspektiven. Die echte Reibung zwischen Menschen, die aus verschiedener Erfahrung heraus unterschiedlich urteilen, entsteht so nicht.

Im gewachsenen System kommt ein zweiter Grund hinzu. Die Constraints eines Brownfield-Systems sind oft Erfahrungswissen, das nirgends im Code steht. Eine erfahrene Architektin erkennt auf den ersten Blick, dass eine Stelle heikel ist, weil sie an einem ähnlichen System schon erlebt hat, was dort schiefgehen kann. Diese Erfahrung hat ein Agent nicht. Er arbeitet mit Trainingsmustern, und die bilden einen Durchschnitt der Welt ab, in dem das Spezifische dieses einen Systems untergeht. Die Übersicht über das gewachsene Ganze, das Gespür dafür, welche Änderung an einer Stelle drei Stellen weiter etwas auslöst, bleibt Sache des Menschen.

Zur Qualität kommt das Recht. Der EU AI Act, die Verordnung (EU) 2024/1689, sieht menschliche Aufsicht insbesondere für Hochrisiko-KI-Systeme vor. Für eine agentische Pipeline folgt daraus keine pauschale gesetzliche Pflicht zur Freigabe jedes einzelnen Outputs. Als Governance-Regel bleibt sie sinnvoll: Jeder bedeutsame Output braucht eine menschliche Freigabe, bevor er angenommen wird. So steht am Ende eine Person mit Namen für eine Auslieferung gerade. Ein Chatverlauf, den niemand mehr rekonstruieren kann, leistet das nicht.

Die Pipeline kennt deshalb feste Rollen, jede mit eigenem Auftrag. Die Business-Analyse klärt, was gebaut werden soll und auf welcher Faktenbasis. UX beschreibt, wie sich das Feature für die Nutzerinnen und Nutzer anfühlt und welche Zustände es kennen muss. Die Entwicklung übersetzt die fachliche Struktur in Code, der Test prüft, ob das gelieferte Verhalten zur Zusage passt. Der Betrieb entscheidet, ob und wie eine Änderung auf die echte Infrastruktur wirken darf. Alle nutzen denselben Agenten, nur eben anders, mit eigenen Fragen und eigenen Grenzen.

Wie verschieden die Rollen auf dasselbe Feature schauen, zeigt ein konkreter Fall. Eine Pflichtangabe soll eingeführt werden, und jede Rolle stellt dazu ihre eigene Frage:

• Die Business-Analyse will wissen, ob die fachliche Plausibilität an der richtigen Stelle erzwungen wird und was mit den Bestandsdaten passiert.
• UX fragt, wie die Sachbearbeiterin merkt, dass eine Pflichtangabe fehlt, und ob die Meldung in Geschäftssprache erklärt, warum.
• Die Entwicklung sucht die Stellen im gewachsenen Code, an denen dieselbe Speicherlogik hängt, und klärt, welche davon mitgeändert werden muss.
• Der Test interessiert sich für den Negativfall, den die fröhliche Lösung gern vergisst: was beim Speichern ohne Pflichtangabe passiert.
• Der Betrieb prüft, ob sich die Änderung zurückrollen lässt, falls das gewachsene System sich anders verhält als erwartet.

Jede dieser Fragen kennt einen anderen Weg, auf dem das Feature scheitern kann, und keine ist überflüssig. Die Serie behandelt jede Rolle einzeln. Die Grundentscheidung bleibt in allen Phasen dieselbe: Jede Rolle gehört einem Menschen, und der Agent verstärkt sie nur.

Zweites Prinzip: Jede Phase exploriert, bevor sie festlegt

Im agentischen Arbeiten ist der frühe Sprung zur Lösung die größte Versuchung. Man tippt eine Aufgabe, der Agent antwortet sofort mit Code, und es fühlt sich nach Fortschritt an. Im Brownfield ist dieser Sprung gefährlich, weil die Lösung auf einem Verständnis beruht, das niemand geprüft hat.

Die Pipeline kehrt die Reihenfolge um, sodass jede Phase mit Exploration beginnt. In der Business-Analyse heißt das, ein Quelleninventar aufzubauen: Welche Tickets, Confluence-Seiten, Architecture Decision Records, Runbooks und Altdokumente sagen etwas über den betroffenen Bereich? Jede Quelle bekommt einen Stand mit konkretem Datum, an dem die Aussage galt. Vage Angaben wie „aktuell" oder „neueste Version" reichen dafür nicht. Eine Confluence-Seite, die seit drei Jahren niemand angefasst hat, sieht im System genauso frisch aus wie eine von gestern, und im gewachsenen System ist das ein Risiko.

Auf das Inventar folgt die eigentliche analytische Arbeit. Jede Aussage wird etikettiert: als belegbarer Fakt, als plausible, aber unbelegte Annahme, als offene Frage oder als Widerspruch zwischen zwei Quellen, die beide Recht zu haben scheinen. Diese Etiketten halten die riskanten Stellen sichtbar, die eine glatte Zusammenfassung verwischt.

Diese Haltung gilt nicht nur in der Analyse. Die Entwicklung liest sich erst in den Code ein, bevor sie schreibt. Der Test arbeitet die Akzeptanzkriterien durch, bevor er Szenarien entwirft, und der Betrieb stellt eine Hypothese über die Ursache auf, bevor er eine Änderung vorschlägt. Im Werkzeug ist diese lesende Phase verankert: Such- und Lese-Operationen sind frei erlaubt, schreibende und wirkende Operationen brauchen eine Freigabe. Dieses Gefälle ist gewollt, weil Lesen jederzeit möglich sein soll und ein verändernder Eingriff eine bewusste, genehmigte Entscheidung bleiben muss.

Exploration ist außerdem iterativ. Eine Phase liefert selten beim ersten Durchlauf ein verlässliches Bild. Man findet einen Widerspruch, geht zurück in die Quellen, klärt ihn, findet dabei eine neue offene Frage. Dieses Hin und Her gehört dazu, denn so entsteht Verständnis im Brownfield überhaupt erst. Die Pipeline lässt diese Schleifen zu, weil sie ihr Ergebnis in Artefakten festhält, wo es auch nach dem Ende einer Sitzung erhalten bleibt.

Drittes Prinzip: Der Zustand gehört in Artefakte

Ein Sprachmodell hat kein Gedächtnis. Es arbeitet allein mit dem Kontext, den man ihm in diesem einen Moment mitgibt. Was im Chatverlauf weiter oben stand, wirkt nur deshalb noch, weil der Client es bei jedem Aufruf erneut mitschickt, und dieser Verlauf kann mit zunehmender Länge an Wirkung verlieren. Der Effekt wird als Context Rot diskutiert und kann einsetzen, bevor das technische Limit des Kontextfensters erreicht ist. Wird der Projektzustand allein im Chat gehalten, geht er deshalb leicht wieder verloren.

Die Pipeline hält den Zustand deshalb außerhalb des Chats, in versionierten Artefakten. Diese Regel nenne ich den Artefakt-Kontrakt: Was während einer Agent-Sitzung entsteht und nicht in ein dauerhaftes Artefakt überführt wird, gilt als nicht passiert. Als Artefakte dienen Markdown-Dateien im Repository für Kontext, Befunde, Pläne und Testausgaben, Tickets für Zuschnitt, Status und Verantwortlichkeit, freigegebene Spezifikationsseiten für Entscheidungen sowie Pull Requests für Diff, Tests und Review-Entscheidung.

Das hat drei Folgen, die zusammen den Wert ausmachen. Eine neue Sitzung kann auf den Artefakten aufsetzen, ohne die frühere Diskussion zu kennen. Im Brownfield zählt das mehr als im Neubau, weil Bestandsarbeit selten an einem Tag fertig wird und oft mehrere Personen sie sich teilen. Ein Epic, ein Plan, ein Befund lassen sich von einem Menschen lesen und bewerten, bevor daraus Code entsteht. Das Fortschrittsprotokoll dokumentiert, was wann und warum entschieden wurde. Diese Spur unterstützt in regulierten Kontexten die Nachweis- und Rechenschaftspflichten.

Ein Artefakt entsteht im Bestandssystem ohne Zusatzaufwand und bleibt verlässlich: die Versionsgeschichte. Was im Repository steht, bindet stärker als jede Erinnerung. Eine Commit-Nachricht hält das Warum einer Änderung fest, die Provenienz einer Zeile lässt sich nachvollziehen, und der Stand vor einem Commit lässt sich gegen den danach vergleichen. Diese Information entsteht beim Arbeiten von selbst und veraltet nicht, anders als eine separat gepflegte Notizdatei, die niemand aktualisiert, wenn sich der Code ändert. Ein Agent, der vor einer Änderung die Historie der betroffenen Datei liest, steht auf festerem Grund als einer, der rät. Deshalb verlangt die Pipeline, Git als verbindliche Quelle der Wahrheit zu nutzen.

Der Compliance-Rahmen, an dem sich die Pipeline orientiert, treibt diese Artefakt-Pflicht weiter. Jedes KI-erzeugte Artefakt wird als KI-erzeugt markiert, mit einer nachvollziehbaren Referenz auf die Operation, die Person und das Modell, das es produziert hat. Das ist die Transparenzanforderung des EU AI Act in der täglichen Praxis: ein konkreter Vermerk an jedem einzelnen Stück generierten Inhalts. Wer später wissen will, ob eine Spezifikation von einer Person geschrieben oder von einem Modell vorgeschlagen und nur durchgewunken wurde, findet die Antwort im Artefakt.

Viertes Prinzip: Jeder Rollenübergang hat ein Quality Gate mit Pflichtartefakten

Der Kern der Pipeline liegt in den Übergängen. Zwischen zwei Rollen wechselt nicht einfach die Arbeit den Besitzer. Es steht ein Prüfpunkt dazwischen, ein Quality Gate, und dieses Gate hat zwei Bestandteile: eine kurze, beantwortbare Frage und ein Artefakt, das die Antwort belegt. Ohne das Artefakt lässt sich die Frage nicht beantworten, und erst eine bejahte Antwort eröffnet die nächste Phase.

Das liegt an den Fehlerkosten, die sich von Phase zu Phase verschieben. Ein Fehler, der in der Analyse gefunden wird, kostet eine Korrektur im Text. Derselbe Fehler, der erst im Betrieb auffällt, kostet eine Korrektur im laufenden System, dazu die Suche nach der Ursache und die Wiederherstellung. Je riskanter und wirkungsvoller ein Schritt ist, desto früher braucht er Belege, einen Plan und eine menschliche Entscheidung. Die Gates sind die Stelle, an der sie fällt.

Am Ende der Discovery steht die Frage, ob die Quellen solide sind. Sind Lücken und Widersprüche sichtbar gemacht, oder wurde glatt zusammengefasst? Das Pflichtartefakt ist das etikettierte Quelleninventar. Erst wenn ein Mensch bestätigt, dass die Wissensbasis belegt und ehrlich ist, beginnt das Strukturieren.

Bevor ein Ticket in die Umsetzung geht, prüft eine Definition of Ready, ob es klein und testbar ist, mit Akzeptanzkriterien und ausdrücklichen Nicht-Zielen. Diese Prüfung ist im Altsystem besonders streng. Sie verlangt zum Beispiel, dass das Outcome eines Tickets in Nutzersicht formuliert ist und nicht in Systemsicht. „Die Sachbearbeiterin kann einen Schaden auch ohne vollständige Angaben speichern, bekommt aber eine fachliche Meldung" ist ein prüfbares Outcome. „Das System validiert das Schadensfeld" ist keines, weil es sich nicht aus Nutzersicht testen lässt und die Verantwortung für den Erfolg von der Fachseite an die Technik verschiebt. Eine zweite Regel desselben Gates: Keine technische Vorgabe im Anforderungsticket. Architektur, Datenmodell, Framework-Wahl, Spaltennamen erscheinen nicht im fachlichen Ticket. Eine technische Vorgabe an dieser Stelle macht die spätere Machbarkeitsprüfung wertlos und ist die häufigste Ursache dafür, dass die Entwicklung ein Ticket zurückgibt.

Vor dem ersten Code steht ein Plan-Review. Es prüft die Reihenfolge der Arbeit, die Teststrategie, die Risiken und die betroffenen Dateien. Erst nach diesem Review beginnt der Agent zu schreiben. Das ist Mehraufwand. Ein vorher geprüfter Plan fängt aber die Fehler ab, die ein Agent sonst über zwanzig Tool-Calls hinweg in den Code einbaut, bevor irgendjemand merkt, dass die Richtung falsch war.

Das Test-Gate fragt, ob die Tests die Akzeptanz abdecken, ob eine bewusste Testlücke dokumentiert ist und ob der Pull Request mit einem Testnachweis bewertet werden kann. Als Beleg zählt hier ein Ergebnis: ein Browser-Test, der das Verhalten ausführt, ein Trace, ein Screenshot. Dass der Agent etwas behauptet, reicht im Gate nicht. Er muss zeigen, dass es funktioniert.

Am schärfsten ist das Apply-Gate im Betrieb. Es trennt die Diagnose von der Wirkung. Der Agent darf eine Pipeline-Änderung, eine Infrastruktur-als-Code-Anpassung oder eine Monitoring-Regel als Pull Request vorbereiten. Die Genehmigung eines Pull Requests ist aber nicht die Genehmigung des Apply. Rollback, Zeitfenster, verantwortliche Person, Beobachtung und Freigabe werden vor der Wirkung entschieden. Der Start auf der echten Infrastruktur bleibt eine menschliche Aktion, auch wenn der Agent sie technisch ausführen könnte. Die Frage des Gates lautet: Ist die Wirkung reversibel, gibt es einen Rollback und eine Beobachtung, und ist das Apply vom Code-Review getrennt?

Unter diesen menschlichen Gates liegt eine maschinelle Schicht, die niemand händisch durchgehen muss. In einem ausgereiften Aufbau prüfen automatische Kontrollpunkte jeden Pull Request, bevor ein Mensch ihn überhaupt sieht. Dazu gehören eine Eingangsprüfung, eine Policy-Prüfung, eine statische Sicherheitsanalyse, eine Erkennung von Prompt Injection, ein Red-Team-Durchlauf, eine Sandbox-Ausführung und ein abschließendes Gate mit Bericht. Diese Kontrollpunkte laufen als deterministische Skripte, und sie laufen bewusst vor den teuren, nichtdeterministischen KI-Stationen. So verbraucht kein Modell Rechenzeit auf offensichtlichem Müll, und das Gating wird beweisbar, weil ein Skript ein nachvollziehbares Ergebnis liefert, während eine Modellantwort das nicht garantiert. Die menschlichen Gates bleiben für die Fragen zuständig, die ein Urteil verlangen. Alles, was sich automatisch prüfen lässt, erledigen davor schon die Skripte, und erst beide Ebenen zusammen ergeben die nötige Kontrolle.

Fünftes Prinzip: Keine Entscheidung verlässt sich auf eine einzige Modellantwort

Ein Sprachmodell ist ein statistischer Apparat. Es gibt das wieder, was in seinen Trainingsdaten häufig vorkam, und sein Ton bleibt dabei gleich sicher, ob das im konkreten Fall stimmt oder nicht. Eine einzelne Modellantwort ist deshalb erst eine Hypothese. Im Brownfield, wo das Spezifische zählt und der Durchschnitt der Trainingswelt oft danebenliegt, wiegt diese Unterscheidung schwer.

Die Pipeline begegnet dem mit einer einfachen Disziplin: Für jede wichtige Entscheidung wird eine zweite und, wo es darauf ankommt, eine dritte Meinung eingeholt, und zwar von einem anderen Modell. Verschiedene Modelle sind auf verschiedenen Daten trainiert, mit eigenen Stärken und blinden Flecken. Kommen zwei unabhängige Modelle zum selben Befund, steigt die Verlässlichkeit. Gehen sie auseinander, ist auch das ein Ergebnis: Der Mensch weiß dann, dass die Sache nicht eindeutig ist und jemand genauer hinsehen muss.

In der Analyse können mehrere Modelle dieselbe Quelle zusammenfassen, und der Vergleich der Ergebnisse zeigt, wo sie sich in Quellentreue, Genauigkeit und Annahmen unterscheiden. Im Code-Review prüft einen Patch nicht nur das Modell, das ihn geschrieben hat, sondern auch ein zweites, das ihn nicht kennt und deshalb nicht in die eigene Logik verliebt ist. Bei der Verifikation lässt sich ein Modell ausdrücklich darauf ansetzen, einen Befund anzugreifen und zu widerlegen. Was einen ernsthaften Widerlegungsversuch übersteht, steht danach stichhaltiger da.

Dahinter steht Modell-Governance. In einem ausgereiften Setup überlässt man die Modellwahl nicht dem Zufall: Die Modelle werden über abstrakte Stufen angesprochen, von günstig bis Spitzenklasse, mit hinterlegten Budget-Profilen und Routing-Regeln. Die Markennamen bleiben außen vor. Wer eine teure Stufe nutzen will, muss das begründen, und bei manchen Entscheidungen kommt eine menschliche Freigabe dazu. So bleibt die Zweit- oder Drittmeinung den Fällen vorbehalten, in denen das Risiko sie rechtfertigt, und wird nicht zum stillen Kostentreiber. Für eine triviale Umformatierung braucht es keine drei Modelle, bei einer Architekturentscheidung im Brownfield-Kontext sieht das anders aus.

Der zweite Blick erhöht nicht nur die Genauigkeit, er härtet das System auch gegen eine spezifische Schwäche agentischer Aufbauten. Der Kontext, mit dem ein Modell arbeitet, kann manipuliert sein, etwa durch eine Prompt Injection in einer gelesenen Datei. Dann ist ein zweites Modell mit anderem Verhalten eine weitere Hürde für den Angriff. Ein Verteidigungsmodell, das auf mehreren Ebenen prüft, ist schwerer auszuhebeln als eine einzelne Instanz, die man einmal überlistet.

Sechstes Prinzip: Compliance gehört in jede Phase

In vielen Projekten kommt Compliance zuletzt. Erst wird gebaut, dann wird geprüft, ob das Gebaute den Regeln genügt, und am Ende werden Vermerke nachgetragen. Im agentischen Arbeiten hält diese Reihenfolge nicht mehr, und zwar wegen der Geschwindigkeit. Wenn ein Agent in Minuten produziert, wofür ein Mensch Tage brauchte, ist eine nachgelagerte Prüfung längst überrollt, bevor sie greift. Compliance muss an den Stellen sitzen, an denen die Arbeit ohnehin durchläuft, also in den Phasen und Gates der Pipeline selbst.

Der regulatorische Rahmen für deutsche und europäische Teams umfasst mindestens den EU AI Act und die Datenschutz-Grundverordnung. Der EU AI Act, Verordnung (EU) 2024/1689, folgt einem risikobasierten Ansatz. Je nach Einsatzfall und Risikoklasse entstehen Pflichten zu Transparenz, technischer Dokumentation, Protokollierung, menschlicher Aufsicht und Cybersecurity, insbesondere bei Hochrisiko-KI-Systemen und bestimmten generativen KI-Anwendungen. Die Datenschutz-Grundverordnung, Verordnung (EU) 2016/679, regelt die Verarbeitung personenbezogener Daten und verlangt unter anderem Zweckbindung und Datenminimierung. Daneben müssen Teams interne Sicherheitsvorgaben sowie einschlägige AI-Security-Rahmen berücksichtigen. Für generative KI betreffen diese typischerweise Bedrohungsmodellierung, Datenklassifizierung, Modellsicherheit, Prompt-Schutz, Lieferkette und Incident Response.

In die Pipeline übersetzt, ergeben sich daraus konkrete Regeln, die in den Phasen verankert sind. An der Wurzel steht die Datenminimierung: In der Entwicklung gehören personenbezogene Daten nicht in die Artefakte. Beispieldaten in Pflichtartefakten verwenden ausschließlich Platzhalter aus einem Muster-Schema, also keine realen Personennamen, Firmen oder Vorgangsnummern. Workshop-Material, Schulungsexporte und Pull Requests landen schnell in öffentlicheren Kontexten, etwa in einer geteilten Seite, einem Spiegel auf einer Code-Plattform oder einer Präsentation. Wird von Anfang an anonymisiert, erspart das die spätere Suche, bei der ohnehin meist ein Treffer übrig bleibt.

Die Barrierefreiheit wird im Bestandssystem leicht vergessen. Ein reifer Aufbau der Pipeline orientiert sich an den Web Content Accessibility Guidelines der Stufe AA und an der europäischen Norm EN 301 549, soweit diese für den Einsatzfall gelten. Ein UX-Zustand, der einen Fehlerfall festhält, beschreibt auch, wie dieser Fehler für eine Person wahrnehmbar wird, die einen Screenreader nutzt. Für bestimmte Produkte und Dienstleistungen gelten solche Anforderungen in der EU seit dem 28. Juni 2025 verbindlich, in Deutschland über das Barrierefreiheitsstärkungsgesetz. Für öffentliche Stellen greifen Barrierefreiheitsanforderungen bereits länger.

Zur Nachvollziehbarkeit gehört, dass jede Aussage in einem Artefakt ihre Quelle mit Datum nennt, jedes KI-erzeugte Stück seinen Erzeuger-Vermerk, und dass der Tokenverbrauch nachvollziehbar bleibt. Diese Spur unterstützt den Audit-Trail, den Regulierung, Rechenschaftspflichten oder interne Governance je nach Einsatzfall verlangen können. In der Pipeline entsteht sie als Nebenprodukt des ohnehin geforderten Artefakt-Kontrakts.

Für Brownfield-Systeme kommt der Bestandsschutz vor Migrationszwang hinzu, den ich für eine der wichtigsten Regeln überhaupt halte. Ein neues Feature migriert oder validiert bestehende Daten nicht automatisch. Neue Pflichten gelten für neu angelegte oder aktiv bearbeitete Datensätze, der Bestand bleibt lesbar und speicherbar. Ohne diese Trennung schleppt man eine Datenmigration als Nebenbedingung in ein Feature-Ticket. Eine Datenmigration ist aber ein Vorhaben für sich, mit eigenen Beteiligten, Risiken und Zeitfenstern. Als Nebenpunkt geführt, verfälscht sie den Zuschnitt und blockiert die Übergabe an die Entwicklung. Oft entscheidet gerade diese Regel darüber, wie lange ein Feature im Brownfield braucht.

Wie die Prinzipien zusammenwirken

Die sechs Prinzipien sind keine Liste, aus der man sich die bequemen heraussucht, denn sie greifen in einer bestimmten Reihenfolge ineinander.

Eine Übergabe zwischen zwei Personen gelingt nur an einem Gegenstand, den beide lesen, also brauchen die Rollen die Artefakte. Ein Artefakt ohne Prüfpunkt ist nur eine Datei, die niemand verbindlich bewertet hat, weshalb die Artefakte die Gates voraussetzen. Ein Gate wiederum prüft nur das, was eine ehrliche Voruntersuchung an Befunden, Lücken und Widersprüchen geliefert hat. Die Zweit- und Drittmeinung schärft die menschliche Entscheidung an den Rollen, ohne sie zu ersetzen. Die Compliance schließlich hat ohne alle vier kein Material, an dem sie wirken kann.

Das Ergebnis ist eine Artefaktkette, in der jedes Glied vom vorherigen abhängt. Aus einem etikettierten Quelleninventar entsteht ein solides Epic, aus dem Epic Tickets, die eine Definition of Ready bestehen. Aus den Tickets entsteht ein prüfbarer Plan, aus dem Plan ein Pull Request, der den Test übersteht, und daraus erst ein Apply-Entscheid, der verantwortbar ist. Überspringt ein Team ein Glied, kann es das nächste nicht ehrlich abschließen. Man kann so tun, aber das Auslassen rächt sich dort, wo das System am stärksten beansprucht wird, und das ist im gewachsenen System fast immer die Produktion.

Ein verbreiteter Einwand: Klingt das nicht nach einer Rückkehr zum Wasserfall, nach dem schwergewichtigen Prozess, den die agile Bewegung überwinden wollte? Die Pipeline hat zwar Phasen und Übergänge, aber sie ist nicht starr. Innerhalb jeder Phase wird iterativ gearbeitet, mit Schleifen und Selbstkorrekturen. Die Tickets sind klein, ein bis drei Stunden, und durchlaufen die Umsetzung einzeln. Vom klassischen Wasserfall unterscheidet sie die Verbindlichkeit weniger, prüfbarer Artefakte an den richtigen Stellen, und auf die Menge der Dokumente kommt es dabei nicht an. Welche agilen Annahmen unter agentischen Werkzeugen weiter gelten und welche ihre Steuerungsfunktion verlieren, habe ich an anderer Stelle behandelt. Hier genügt, dass die Methode genauso viel Iteration vorsieht wie zuvor, nur besser belegte.

Was diese Serie als Nächstes behandelt

Dieser Text ist bewusst auf der Ebene des Vorgehens geblieben und hat die einzelnen Rollen nur gestreift. Jede Rolle bietet genug Substanz für einen eigenen Beitrag, und in der Praxis steckt der Wert im Detail.

Die folgenden Beiträge gehen deshalb in die Tiefe. Die Business-Analyse zeigt, wie aus einem Quelleninventar eine belegte Wissensbasis wird, wie das Etikettieren von Aussagen funktioniert und woran man erkennt, dass eine Discovery reif für die Strukturierung ist. Bei UX geht es darum, wie ein Feature in eigenen Worten beschrieben wird und wie eine Team-Vorlage mit Akzeptanzkriterien und Zuständen entsteht. Außerdem zeigt der Beitrag, warum die Beschreibung der Fehlerfälle oft mehr verrät als die der Happy Paths. Die Entwicklung nimmt die Kaskade aus Recherche, Epic, Tickets, Plan und abschließender Umsetzungsschleife auseinander. Sie zeigt, wie ein Agent über viele Schritte hinweg autonom arbeiten kann, ohne die Kontrolle zu verlieren. Der Test handelt davon, wie aus Akzeptanzkriterien Szenarien werden und wie ein Browser-Beleg eine Behauptung ersetzt. Der Betrieb behandelt die Trennung von Diagnose und Wirkung, das Apply-Gate und die Frage, was ein Agent auf echter Infrastruktur überhaupt vorbereiten darf und wo die Grenze liegt.

Wer die Pipeline ausprobieren will, bevor die Detailbeiträge erscheinen, kann mit einer einzigen Regel anfangen, die alle anderen nach sich zieht: Halte den Zustand in versionierten Artefakten. Schreibe das Quelleninventar, das Epic, den Plan und die Testausgabe in das Repository. Sobald diese Artefakte da sind, ergibt sich die Frage nach den Gates fast von selbst, weil ein Artefakt danach verlangt, geprüft zu werden, bevor das nächste darauf aufsetzt. Sind die Gates erst da, folgt die Frage nach den Rollen, weil eine Prüfung jemanden braucht, der prüft.

Abkürzungen funktionieren im Brownfield nicht, dafür sind diese Systeme zu alt und zu eng mit allem anderen verflochten. Auf die Selbstsicherheit eines einzelnen Modells in einem flüchtigen Chat kann man sich hier nicht verlassen. Die rund zehn Prozent Produktivitätsgewinn, die der DORA-Bericht für Brownfield-Arbeit nennt, sind kein Naturgesetz. Sie beschreiben die Größenordnung einer Rechnung unter bestimmten Annahmen. Mit der richtigen Pipeline lässt sich diese Zahl bewegen. Wie weit, weiß ich nicht, und ich werde mich hüten, eine Zahl zu nennen, die ich nicht belegen kann. Was ich aus den Workshops mitnehme, ist die Verschiebung der Arbeit vom schnellen Tippen hin zu den Übergängen, an denen ein Mensch prüft, was der Agent vorgelegt hat. Ob das im eigenen System etwas ändert, zeigt sich erst, wenn man es an einem echten Feature versucht.

• die ökonomische Annahme, dass Implementierung der Engpass sei
• die methodische Annahme, die das Agile Manifesto in vier Wertepaaren formuliert hat
• die personelle Annahme über Teams, Lernwege und Rollen
• die metrische Annahme, dass Erzeugungsgeschwindigkeit Lieferqualität approximiert

An mehreren dieser Stellen kehrt sich die agile Logik um. Mit Ergänzen oder Verschieben ist es dort nicht getan.

Diese Aussagen stützen sich auf den aktuellen Stand der Forschung zur agentischen Softwareentwicklung, soweit er zwischen Oktober 2025 und Mai 2026 als arXiv-Preprints oder begutachtete Beiträge erschienen ist.

Eine andere Knappheit

Agile entstand in einer Zeit, in der die teuerste und langsamste Ressource der Softwareentwicklung Menschen waren. Entwicklerinnen und Entwickler kosteten Geld, Einarbeitung dauerte Monate, Kontextwechsel waren teuer, gute Architektinnen und Architekten waren rar. Aus dieser Knappheit folgten mehrere Kernprinzipien.

Selbstorganisation entstand, weil zentrale Planung zu langsam und zu schlecht informiert war, um knappe Entwicklerzeit sinnvoll zuzuteilen. Timeboxing kam auf, weil sich Aufgaben in Monaten weder zuverlässig schätzen noch nachverfolgen ließen und kleinere Zeitfenster die Fehlerkosten begrenzten. Velocity entstand, weil ein Team seine eigene durchschnittliche Liefergeschwindigkeit besser kannte als jede externe Kapazitätsplanung. Das Prinzip “Working software over comprehensive documentation” folgte daraus, dass eine vollständige Spezifikation vor dem Code teurer war als der Code selbst und ohnehin schnell veraltete.

Jede dieser Antworten ist sinnvoll, solange die Implementierung der Engpass ist. Diese Annahme verändert sich. Bhati nennt den neuen Engpass Verification Debt. Apostolou, Bosch und Holmström Olsson sprechen von einer Capability-Deployment Verification Gap. Sie beschreiben in ihren 16 Interviews mit zwölf Unternehmen das gleiche Bild aus zwei Richtungen: Vier Unternehmen demonstrierten höhere agentische Fähigkeiten, konnten diese aber nicht produktiv einsetzen, weil verlässliche Verifikation fehlte. Bandara et al. legen mit Agentsway ein Vorgehensmodell vor, in dem Verifikation und menschliche Orchestrierung gleichberechtigt neben die Code-Erzeugung treten.

Damit kippt das Optimierungsproblem. Wie schnell ein Mensch Code schreiben kann, ist nicht mehr der Engpass. Knapp ist jetzt das Tempo, in dem eine Organisation den erzeugten Code prüfen, einordnen und verantworten kann. Alle agilen Antworten auf die alte Knappheit sind darum fehladressiert. Selbstorganisation antwortet auf knappe Implementierungskapazität und hilft bei knapper Verifikationskapazität nicht weiter. Velocity misst das Erzeugungstempo und sagt über die Prüfkapazität nichts aus. Timeboxing strukturiert menschliche Arbeit in Iterationen, aber keine Gate-Sequenz aus Spezifikation, Code, Test, Evidence Bundle, Review und Freigabe.

Eine Methodik, die für eine andere Knappheit gebaut ist, wird nicht durch Anpassung modernisiert. Sie verliert mit ihrem Optimierungsproblem ihre Berechtigung. Das ist die ökonomische Bruchstelle.

Was aus den vier Wertepaaren wird

Das Agile Manifesto formuliert vier Wertepaare. Drei davon drängt das agentische Arbeiten in ihre Umkehrung. Das vierte bleibt formal stehen, ändert aber seinen Adressaten.

Working software over comprehensive documentation. Spec-Driven Development verkehrt diese Reihenfolge. Piskala beschreibt das Spektrum von Spec-First bis Spec-as-Source. Feng und Chen zeigen in einer Pilotstudie, dass strukturierte Signaturen bei Repo-Level-Generierung die Test-Pass-Rate erhöhen können. Lulla et al. messen für eine AGENTS.md in zehn Repositories mit 124 Pull Requests eine um 28,64 Prozent kürzere Laufzeit und einen um 16,58 Prozent geringeren Token-Verbrauch. Galster et al. dokumentieren acht Konfigurationsmechanismen in 2.853 Repositories, darunter Context Files, Skills, Subagents, Commands, Rules und Hooks. Diese Artefakte stehen als Bedingung der Möglichkeit vor dem Code. Ohne sie wird der Output unspezifischer, langsamer und teurer. Die Reihenfolge des Manifesto ist damit umgekehrt.

Individuals and interactions over processes and tools. Wenn das Werkzeug der Hauptproduzent ist, verliert dieser Satz seinen Sinn. Koch formuliert in Agentic Agile-V, dass lange Chatverläufe nicht als Engineering-Verträge taugen. Die Interaktion wird zum Risiko, das Prozesse und Tools einhegen müssen. Mit Conversation-to-Contract-Gate, Acceptance Gates, TDD-Governance (Hasanli et al.), Policy-as-Prompt (Kholkar, Ahuja) und Plane-Trennung in CI/CD (Barnes, Ghaleb) dreht die Forschung die Achse. Verbindlichkeit kommt jetzt aus Prozessen und Tools, weil Interaktionen und Individuen sie nicht mehr garantieren können.

Customer collaboration over contract negotiation. Die agentische Wende erzwingt, dass Anforderungen prüfbar werden. Eine Spezifikation, die als Eingabe für einen Agenten dient, ist ein Vertrag im technischen Sinn: Akzeptanzkriterien, Constraints, Testfälle. Das ist keine Vertragsverhandlung im juristischen Sinn, aber auch nicht die mündlich-kooperative Anforderungsklärung des klassischen Agile. Die Spec wird wieder zum Vertrag, diesmal in maschinenlesbarer Form.

Responding to change over following a plan. Dieser Satz steht formal weiter, aber sein Adressat wandert. Der Plan wird jetzt mit Gate-Disziplin verändert, die festlegt, welche Änderung der Agent ausführen darf, welche menschliche Freigabe braucht und welche nie automatisch wirken darf. Die Forschung zur Plane-Trennung bei Barnes und Ghaleb und zu Governance-Layern bei Koch, Xu et al. und Kholkar liest sich an manchen Stellen näher an V-Modell-Disziplin als an Scrum.

Eine Methodik, deren Werte in drei von vier Paaren umgekehrt werden, lässt sich nicht ohne Begriffsbruch weiterführen. Sie muss sich neu begründen, oder sie verliert ihren Anspruch.

Wer wird Senior?

Die Diskussion über agentische Werkzeuge spricht vom Menschen als Orchestrator, das ist die freundliche Formulierung. Die schärfere Lesart betrifft die Personalstruktur und ist unangenehmer.

Horikawa et al. untersuchen 15.451 Refactoring-Instanzen in 12.256 agentischen Pull Requests. Refactoring kommt häufig vor, zielt überwiegend auf Maintainability und Readability und bleibt oft lokal. High-Level-Designarbeit ist schwächer vertreten. Das ist die Verteilung, die Junior-Entwicklerinnen und -Entwicklern als Lernfeld zugewiesen war: kleine Tickets, lokale Verbesserungen, Tests schreiben, Lesbarkeit erhöhen. Pinna et al. zeigen für 7.156 agentische Pull Requests deutliche Stärken bei bestimmten Task-Typen, vor allem in der Klasse umrissener, lokal beschränkter Änderungen. Robbes et al. dokumentieren in ihrer Adoptionsstudie die schnelle Verbreitung gerade für diesen Tätigkeitstyp.

Was Agenten gut können, deckt sich also weitgehend mit dem Bereich, über den Junior-Entwicklerinnen und -Entwickler Seniorität aufbauen. Wenn dieser Lernpfad strukturell verkürzt oder ganz übersprungen wird, entsteht eine Frage, die in der Methodik-Debatte selten gestellt wird: Woher kommen in fünf Jahren die Menschen, die agentische Outputs verlässlich prüfen, einordnen und verantworten? Apostolou et al. nennen verlässliche Verifikation als den fehlenden Baustein, der mehrere Unternehmen daran hindert, höhere agentische Stufen produktiv einzusetzen. Verifikation in dieser Tiefe verlangt Erfahrung, die im klassischen Modell durch genau die Arbeit aufgebaut wurde, die Agenten heute übernehmen. Das wissenschaftliche Material enthält diese Beobachtung zwar nicht direkt, sie folgt aber aus den genannten Befunden, zusammengelesen mit der gängigen Personalstruktur in Softwareteams.

Auch die Scrum-Rollen geraten unter Druck. Scrum Master und Agile Coaches hängen fast vollständig an der menschlichen Teamdynamik. Sie sind die Antwort auf Konflikte, Kommunikationsdefizite, fehlende Selbstorganisation und unausgesprochene Erwartungen. In einem Workflow, in dem ein Mensch mit einem Agenten arbeitet, verlieren diese Themen an Gewicht. An ihre Stelle tritt technische Workflow-Architektur: Gate-Design, Spec-Strukturen, Toolrechte, Hook- und Policy-Konfiguration, MCP-Setup, Evidence-Bundle-Schemata. Galster et al. dokumentieren acht solcher Mechanismen, und die meisten davon sind Engineering-Themen. Eine Rolle, deren Arbeitsfeld so eng an einer schwindenden Komponente der Methodik hängt, wird mit dieser Komponente redimensioniert.

Der Product Owner wird durch Business-Architektinnen und -Architekten ersetzt. Der PO als Schnittstelle zwischen Fachbereich und Entwicklungsteam war eine Antwort darauf, dass Entwicklungszeit teuer war und Fachbereiche ihre Anforderungen nicht selbst in Implementierung übersetzen konnten. Wenn die Übersetzung in maschinenlesbare Spezifikationen wandert und Implementierungskapazität günstiger wird, entfällt ein Teil dieser Vermittlung. Die Verantwortung für Akzeptanzkriterien, Spec-Pflege und Gate-Entscheidungen lässt sich näher an den Fachbereich rücken, als es das Scrum-Modell vorsah. Der Product Owner ist in seiner agilen Definition so nicht mehr notwendig.

Die Metrik-Umkehrung

Eine Metrik ist sinnvoll, solange ihr Vorzeichen stabil ist. Mehr ist gut oder weniger ist gut. Eine Metrik, deren Vorzeichen sich umkehren kann, ist nur noch ein Signal, das je nach Kontext bewertet werden muss.

Velocity steht an dieser Stelle. Agarwal, He und Vasilescu untersuchen 401 Agent-First-Repositories und 117 IDE-First-Repositories mit gematchten Kontrollgruppen. Sie finden kurzfristige Velocity-Gewinne, die in den agentischen Gruppen front-loaded sind. Zugleich steigen Static-Analysis-Warnings und Cognitive Complexity deutlich. Ehsani et al. zeigen in 33.596 agentischen Pull Requests, dass reviewer abandonment das häufigste Muster in der manuell kategorisierten Teilmenge abgelehnter PRs ist. Hohe Erzeugungsgeschwindigkeit korreliert nicht mit hoher Lieferqualität, in den agentischen Gruppen aber mit wachsender Komplexität und nicht bewältigter Review-Last.

In einem agentischen Umfeld wird Velocity damit von einer Tugend zum Risikoindikator. Eine hohe agentische Velocity bei stabiler Review-Kapazität ist verdächtig. Eine Methodik, die ihre zentrale Steuerungsmetrik in eine Risikometrik umdeuten muss, sollte das nicht beschönigen. Velocity bleibt messbar, verliert aber ihren Sinn als Steuerungsgröße. Burndown teilt dieses Schicksal, weil sein Sinn dieselbe Annahme voraussetzt: dass Erzeugungsgeschwindigkeit Liefergeschwindigkeit approximiert.

Ein Ersatz existiert noch nicht. Gate-Durchlaufzeit, Evidence-Vollständigkeit, Verifikationsdichte, Policy-Konformität oder bestandene Akzeptanzkriterien pro Zeit kommen als Kandidaten in Frage. Ausgereifte Praxis ist keiner davon. Die agile Bewegung steht ohne stabile Steuerungsmetrik da, während die alte Metrik nicht nur unzuverlässig wird, sondern in ihr Gegenteil kippt.

Ein Geschäftsmodell verschwindet

Eine Ebene kommt im wissenschaftlichen Material kaum vor, ist aber für das Schicksal der agilen Methodik wichtig. Agile ist seit Mitte der 2000er-Jahre auch ein Beratungs- und Zertifizierungsmarkt. SAFe, Scrum.org, LeSS, Scaled Agile Inc. und viele unabhängige Coaches leben von Trainings, Zertifikaten und Transformationsprojekten. Ihr Produkt sind Team-Coaching, Rituale, Rollenmodelle und Skalierungs-Frameworks.

Die Forschung deutet auf andere Schwerpunkte. Bandara et al. stellen mit Agentsway Rollen, Lernschleifen, Fine-Tuning, Orchestrierung und Verifikation ins Zentrum ihres Vorgehensmodells. Xu et al. fordern einen Governance-First-Ansatz für Agent Engineering. Kholkar und Ahuja entwickeln Policy-as-Prompt als Übersetzung von Governance-Regeln in Laufzeit-Guardrails. Koch arbeitet an einer mehrschichtigen Übersetzung von Governance-Normen in Runtime-Guardrails sowie an einer V-Modell-Variante für agentisches Arbeiten. Galster et al. dokumentieren die Konfigurationsebene der bestehenden Werkzeuge. Das alles sind Engineering-Themen und keine Coaching-Themen.

Damit entsteht ein strukturelles Übergangsproblem. Eine Industrie, deren Geschäftsmodell darin besteht, Rituale, Rollen und Selbstorganisationspraktiken zu vermitteln, kann sich nicht in einen Markt für Gate-Architektur, Spec-Engineering und Policy-Konfiguration umstellen, ohne ihre Identität zu verlieren. Das verlangt andere Methoden, Curricula, Werkzeuge und Auftraggeber im Unternehmen. Auch hier muss die alte Industrie nicht verschwinden. Ihren bisherigen Anspruch auf methodische Marktführerschaft kann sie aber nur halten, wenn sie sich selbst neu erfindet. Eine Erneuerung dieser Größenordnung ist historisch eher selten und meist nur durch Generationenwechsel hindurch möglich.

Was übrig bleiben könnte

Welche agilen Beiträge gelten weiter, weil sie nicht an der entfallenden Knappheit hängen?

Kleine Lieferpakete bleiben sinnvoll, weil sie die Risikoabsicherung kleiner machen, unabhängig davon, wer den Code schreibt. Enger Kontakt zu Fachbereichen ebenfalls, weil Spezifikationen ohne fachliche Rückkopplung schnell falsch werden. Reflexion in regelmäßigen Abständen behält ihren Wert, sofern ihr Ergebnis im Arbeitsumfeld des Agenten landet und nicht nur auf einem Whiteboard. Verantwortlichkeit für die Lieferung bleibt sinnvoll, weil Agenten weder Verantwortung tragen können noch tragen sollen. Auch Transparenz über laufende Arbeit gehört dazu, allerdings in Form prüfbarer Artefakte und nicht als regelmäßiges Statusgespräch.

Das ist eine deutlich kürzere Liste als das, was die agile Bewegung als Methodik exportiert hat. Sie enthält im Wesentlichen Praxisweisheiten, die älter sind als das Agile Manifesto und auch ohne es Bestand hätten. Der spezifisch agile Apparat aus Velocity, Sprint-Schätzung, Selbstorganisation als Steuerungsprinzip, Scrum-Rollen und Ritualtaktung fehlt darin. Dieser Apparat hat Agile von älteren Praxistraditionen unterschieden. Agile mit Agenten trifft es darum nicht. Was bleibt, wenn dieser Apparat verschwindet, ist eher disziplinierte, prüfungsbewusste Softwareentwicklung mit kurzen Feedbackzyklen, wie sie auch ohne den Begriff Agile begründbar wäre.

Schluss

Die agile Methodik geht unter, weil die Bedingungen, gegen die sie optimiert war, in mehreren Schichten gleichzeitig entfallen. Ob ihre Anhänger sie aufgeben, spielt dafür keine Rolle. Die Knappheit verschiebt sich von der Implementierung zur Verifikation. Der Personalstruktur, auf der ihr Begriff von Team und Lernpfad beruhte, geht die Reproduktionsbasis verloren. Ihre Steuerungsmetrik kehrt das Vorzeichen um. Die Beraterökonomie, die die Methodik organisiert hat, steht ohne anschlussfähiges Produkt da.

Vier dieser Verschiebungen sind in den 22 ausgewerteten Arbeiten direkt belegt. Die fünfte, die Geschäftsmodellfrage, ist abgeleitet. Wer die belegten Verschiebungen einzeln betrachtet, sieht eine Anpassung. Zusammengelesen ergeben sie ein anderes Bild. Software-Engineering-Praktiken enden damit nicht. Was endet, ist die spezifische Synthese, die Agile genannt wurde, in jener Form, in der sie zwanzig Jahre lang gelehrt und verkauft wurde.

Die offenere Frage betrifft das Tempo. Apostolou et al. zeigen, dass die Industrie noch früh steht. Sieben der zwölf befragten Unternehmen arbeiten auf der niedrigsten Reifestufe. Vier können höhere Stufen demonstrieren, aber nicht produktiv einsetzen. Das verschafft der bestehenden Methodik Zeit, ändert aber wenig an der Richtung. Die Gates, Artefakte, Plane-Trennungen, Spec-Strukturen und Governance-Layer, die in der Forschung dokumentiert sind, kommen früher oder später in der Praxis an. Wenn sie ankommen, bleiben Velocity-Diagramme, Daily-Stand-up-Protokolle und Sprint-Boards bestehen und zeigen nur immer offensichtlicher das Falsche.

Anmerkung zur Evidenz und Methodik

Der Essay stützt sich auf eine eigene Auswertung von 22 Arbeiten zur agentischen Softwareentwicklung aus dem Zeitraum Oktober 2025 bis Mai 2026. Es handelt sich nicht um eine formale systematische Literaturübersicht. Auswahl und Lesart sind meine.

Die Belege für die ökonomische, methodische, personelle und metrische Bruchstelle stammen direkt aus den ausgewerteten Arbeiten. Der Abschnitt zur Beraterökonomie geht über das wissenschaftliche Material hinaus und ist als solcher gekennzeichnet. Auch die Frage nach den Lernwegen von Junior-Entwicklerinnen und -Entwicklern zur Seniorität ist aus den Tätigkeitsverteilungen abgeleitet, die die Studien beschreiben. Eine direkt belegte These der Forschung ist sie nicht.

Eine Forschungslücke bleibt deutlich. Aussagekräftige Längsschnittstudien zu Teams, die über ein Jahr hinweg agentisch arbeiten, gibt es kaum. Cross-Team-Koordination ist kaum untersucht, die Übersetzung agiler Metriken in agentische Workflows offen. Verantwortung nach Incidents, Performance-Bewertung und Skill-Entwicklung sind ebenfalls unterbelichtet.

Völlig offen bleibt, wie sich die Werthaltigkeit der produzierten Ergebnisse kaufmännisch planen und einordnen lässt.

Literatur

Die folgende Liste nennt die lokal ausgewerteten Fassungen. Bei arXiv-Arbeiten verweist der Link auf die jeweilige Abstract-Seite.

• Shyam Agarwal, Hao He, Bogdan Vasilescu: AI IDEs or Autonomous Agents? Measuring the Impact of Coding Agents on Software Development. arXiv:2601.13597. https://arxiv.org/abs/2601.13597
• Spyridon Alvanakis Apostolou, Jan Bosch, Helena Holmström Olsson: Agentic AI in Industry: Adoption Level and Deployment Barriers. arXiv:2605.14675. https://arxiv.org/abs/2605.14675
• Eranga Bandara et al.: AGENTSWAY – Software Development Methodology for AI Agents-Based Teams. arXiv:2510.23664. https://arxiv.org/abs/2510.23664
• Marcus Emmanuel Barnes, Taher A. Ghaleb: From Assistance to Agency: Rethinking Autonomy and Control in CI/CD Pipelines. arXiv:2605.07062. https://arxiv.org/abs/2605.07062
• Happy Bhati: Agentic AI in the Software Development Lifecycle: Architecture, Empirical Evidence, and the Reshaping of Software Engineering. arXiv:2604.26275. https://arxiv.org/abs/2604.26275
• Ramtin Ehsani et al.: Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub. arXiv:2601.15195. https://arxiv.org/abs/2601.15195
• Shuzhao Feng, Boqi Chen: LLM-Assisted Repository-Level Generation with Structured Spec-Driven Engineering. arXiv:2605.02455. https://arxiv.org/abs/2605.02455
• Matthias Galster et al.: Configuring Agentic AI Coding Tools: An Exploratory Study. arXiv:2602.14690. https://arxiv.org/abs/2602.14690
• Taher A. Ghaleb: When AI Agents Touch CI/CD Configurations: Frequency and Success. arXiv:2601.17413. https://arxiv.org/abs/2601.17413
• Tarlan Hasanli et al.: TDD Governance for Multi-Agent Code Generation via Prompt Engineering. arXiv:2604.26615. https://arxiv.org/abs/2604.26615
• Rashina Hoda: Toward Agentic Software Engineering Beyond Code: Framing Vision, Values, and Vocabulary. arXiv:2510.19692. https://arxiv.org/abs/2510.19692
• Kosei Horikawa et al.: Agentic Refactoring: An Empirical Study of AI Coding Agents. arXiv:2511.04824. https://arxiv.org/abs/2511.04824
• Gauri Kholkar, Ratinder Ahuja: Policy-as-Prompt: Turning AI Governance Rules into Guardrails for AI Agents. arXiv:2509.23994. https://arxiv.org/abs/2509.23994
• Christopher Koch: From Governance Norms to Enforceable Controls: A Layered Translation Method for Runtime Guardrails in Agentic AI. arXiv:2604.05229. https://arxiv.org/abs/2604.05229
• Christopher Koch: Agentic Agile-V: From Vibe Coding to Verified Engineering in Software and Hardware Development. arXiv:2605.20456. https://arxiv.org/abs/2605.20456
• Jai Lal Lulla et al.: On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents. arXiv:2601.20404. https://arxiv.org/abs/2601.20404
• Giovanni Pinna et al.: Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance. arXiv:2602.08915. https://arxiv.org/abs/2602.08915
• Deepak Babu Piskala: Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants. arXiv:2602.00180. https://arxiv.org/abs/2602.00180
• Romain Robbes et al.: Agentic Much? Adoption of Coding Agents on GitHub. arXiv:2601.18341. https://arxiv.org/abs/2601.18341
• Giovanni Rosa et al.: Understanding Specification-Driven Code Generation with LLMs: An Empirical Study Design. arXiv:2601.03878. https://arxiv.org/abs/2601.03878
• Yuheng Tang et al.: DevOps-Gym: Benchmarking AI Agents in Software DevOps Cycle. arXiv:2601.20882. https://arxiv.org/abs/2601.20882
• Qiang Xu et al.: From Craft to Constitution: A Governance-First Paradigm for Principled Agent Engineering. arXiv:2510.13857. https://arxiv.org/abs/2510.13857

Diese Architektur hat eine Konsequenz, die sich erst im produktiven Einsatz zeigt. Das Kontextfenster wird zur knappsten Ressource des Systems, sobald ein Sprachmodell aus dem Editor-Chat in eine Kommandozeile wandert und dort Aufgaben über Stunden bearbeitet. Die agentischen Kommandozeilen-Werkzeuge der Anbieter beantworten alle dieselbe technische Frage: Wie verwaltet man ein knappes, flüchtiges Arbeitsgedächtnis so, dass eine längere Sitzung produktiv bleibt? Gemeint sind Claude Code von Anthropic, Codex von OpenAI, Gemini CLI von Google, Qwen Code von Alibaba, OpenCode aus der Open-Source-Gemeinschaft und Copilot CLI von GitHub. Fünf der sechs Codebasen sind dank Open-Source-Lizenzen offen einsehbar, und wer sie nebeneinander liest, findet überall dieselben vier Lösungsmuster wieder, dazu fünf Achsen, an denen die Designentscheidungen dann doch auseinanderlaufen.

Was das Kontextfenster begrenzt

Alle sechs Anbieter unterliegen denselben Begrenzungen, die aus der Architektur der zugrundeliegenden Transformer-Modelle folgen und in der Forschungsliteratur ausführlich dokumentiert sind.

Hart begrenzt. In den aktuellen Spitzenmodellen ist eine Million Tokens, was rund 750.000 englischen Wörtern entspricht, der neue Standard. Anthropic hat das Million-Token-Fenster für Claude Opus 4.6 und Sonnet 4.6 im März 2026 generell verfügbar gemacht. Claude-Code-Nutzer auf Max-, Team- und Enterprise-Plänen bekommen es ohne Konfiguration als Standard. OpenAI bietet die Million in GPT-5.5, in der Codex CLI begrenzt auf 400.000 Tokens. Google liefert sie in Gemini 2.5 Pro, Alibaba in Qwen 3.5-Plus. Ältere und kleinere Modelle wie Claude Sonnet 4.5 bleiben bei 200.000 Tokens, was bis 2025 der Industrie-Standard war. Trotz dieser Vergrößerung skaliert die Attention-Operation der Transformer-Architektur quadratisch mit der Sequenzlänge: Doppelter Kontext bedeutet vierfachen Rechenaufwand. Sparse-Attention- und State-Space-Verfahren dämpfen diesen Effekt, heben ihn aber nicht auf, und ein einziges Token jenseits der harten Grenze lässt den API-Aufruf scheitern, weil sich zur Laufzeit nichts nachlegen lässt.

Flüchtig und zustandslos. Bei jedem einzelnen Modellaufruf überträgt die Anwendung die gesamte bisherige Historie erneut: System-Prompt, alle Nachrichten, alle Tool-Aufrufe und alle Tool-Ergebnisse. Anbieterseitiges Prompt-Caching, das stabile Präfixe der Konversation zwischenspeichert, senkt die Token-Kosten für wiederholte Übermittlungen erheblich. Anthropic berechnet für Cache-Reads nur ein Zehntel des regulären Input-Preises. OpenAI gewährt automatisch fünfzig Prozent Nachlass auf wiederverwendete Eingabe-Tokens, bei neueren Modellen in einzelnen Fällen mehr. An der grundlegenden Mechanik ändert das nichts. Der Eindruck von Erinnerung entsteht weiterhin durch organisierte Wiederholung.

Alterung. Lange vor dem harten Limit fällt die Antwortqualität ab. Den Begriff Context Rot prägte 2025 ein technischer Bericht von Chroma Research für genau dieses Phänomen. Die Autoren testeten 18 Frontier-Modelle, darunter GPT-4.1, Claude Opus 4 und Gemini 2.5, und beobachteten den Effekt bei jedem einzelnen. Anthropic hat den Begriff inzwischen in die eigene Dokumentation übernommen, und die Best Practices für Claude Code beziffern den Eintrittsbereich für die hauseigenen Million-Token-Modelle mit 300.000 bis 400.000 Tokens, also bei dreißig bis vierzig Prozent Füllstand. Der LoCoMo-Benchmark von Snap Research umfasst Konversationen mit durchschnittlich 9.000 Tokens und bis zu 35 Sitzungen. Empirische Auswertungen darauf zeigen modellübergreifend, dass selbst Long-Context-LLMs deutlich hinter menschlicher Leistung zurückbleiben, sobald die Sitzung lang wird. Ein größeres Fenster verschiebt das Problem zeitlich, ohne es zu lösen.

Die Aufmerksamkeit des Modells verteilt sich auf mehr Tokens, und alter Ballast zieht es vom aktuellen Fokus weg. Damit ignoriert das Modell eher relevante Anweisungen, was die Forschung Instruction Omission nennt, das stille Weglassen von Anweisungen, ohne dass das Modell darauf hinweist. Eine Arbeit von Distyl AI aus dem Jahr 2025 zeigt, dass selbst die besten getesteten Frontier-Modelle bei 500 parallelen Anweisungen nur noch eine Genauigkeit von rund 68 Prozent erreichen. Die Anweisungen passen problemlos ins Fenster, das Modell sieht sie und befolgt trotzdem nicht alle.

Aus diesen drei Eigenschaften folgt eine technische Notwendigkeit. Eine agentische CLI muss ihren Kontext aktiv bewirtschaften: ältere Inhalte verdichten, irrelevante Tool-Ausgaben verwerfen, wichtige Erkenntnisse in dauerhafte Dateien auslagern, vor jeder neuen Aufgabe gezielt rekonstruieren, was relevant ist. Was das auf der Anwenderseite bedeutet, steht im Feldbericht zum Kontextmanagement. Wie genau die sechs Werkzeuge das tun, ist der eigentliche Gegenstand des Vergleichs.

Was alle sechs Werkzeuge gleich lösen

Die sechs Codebasen stimmen an vier Stellen überein, obwohl Programmiersprachen, Anbieter und Designphilosophien auseinandergehen. Die Konvergenz ergibt sich aus denselben Constraints, die alle Anbieter zwingen, denselben Lösungsraum zu erkunden.

Ein gemeinsames Muster ist Auswahl statt Vollständigkeit. Keines der untersuchten Werkzeuge kopiert wahllos Dateien in den Kontext. Jedes entscheidet, welche Instruktionsdateien es lädt, welche Tool-Ergebnisse es behält, welche Memory-Ebenen aktiv sind. Auswahl ist die vorderste Verteidigungslinie gegen Context Rot. Gemini CLI etwa klassifiziert eingelesene Dateien in vier Stufen, die intern FULL, PARTIAL, SUMMARY und EXCLUDED heißen, und entscheidet pro Datei, wie viel davon im Kontext landet. Claude Code räumt in der Mikro-Kompaktierung gezielt alte Tool-Resultate ab, ohne den Gesprächsverlauf anzutasten.

Ebenso verbreitet ist die hierarchische Discovery von Instruktionsdateien. Alle sechs CLIs suchen ihre Projektregeln auf dem Pfad von der Projektwurzel bis zum aktuellen Arbeitsverzeichnis, gleich ob diese Regeln CLAUDE.md, AGENTS.md, GEMINI.md, QWEN.md oder copilot-instructions.md heißen. Spezifischere Regeln in Untermodulen überlagern allgemeinere. Wer in einem Monorepo arbeitet, bekommt automatisch das passende Regelwerk. Dieser Konsens gilt in der ganzen Industrie und geht auf keinen einzelnen Anbieter zurück. Eine flache, projektweite Regeldatei wäre für große Codebasen zu grobkörnig.

Dazu kommt die Priorisierung von User-Inhalten vor Tool-Ausgaben. Wenn der Kontext knapp wird, verwerfen alle Werkzeuge zuerst alte Tool-Ergebnisse und behalten die Nachrichten des Nutzers. Was ein Nutzer geschrieben hat, drückt Absicht aus. Eine Tool-Ausgabe lässt sich bei Bedarf reproduzieren, indem das Tool erneut aufgerufen wird, eine User-Nachricht dagegen nicht, weil sie authentischer Bestandteil der Sitzung ist.

Zuletzt die strukturierte Wiederverankerung nach Kompaktierung. Danach hängt das Werkzeug wichtige Zustandsdaten explizit an den neuen Kontext an: Datei-Anhänge, aktive Pläne, eingeschaltete Tools, Verbindungen zu externen Diensten und Hook-Ergebnisse vom Sitzungsstart. Was dabei herauskommt, ist ein rekonstruiertes Arbeitsbild. Bei Claude Code ist das besonders ausgeprägt: Nach jedem Eingriff hängt es Datei-Attachments, den Zustand des Plan-Modus, aktive Skills sowie Tool- und Agenten-Deltas wieder an.

Diese vier Muster bilden zusammen eine informelle Pattern-Sprache des Kontextmanagements. Die Begriffe Trim, Summarize, Persist und Prune fassen ihre Operationen zusammen. Wer sie benennen kann, beurteilt ein neues Werkzeug innerhalb von Minuten. Sie sind für das Kontextmanagement, was Entwurfsmuster für die Objektorientierung waren: ein Vokabular.

Wo sich die sechs Werkzeuge unterscheiden

Trotz der Konvergenz bleiben klare Unterschiede. Fünf Achsen sind besonders folgenreich für die Wahl eines Werkzeugs. Die genannten Werte lassen sich aus der Quelltextlektüre belegen.

Kompaktierungsschwellen: Gemini CLI bei 50, Codex bei 90 Prozent

Diese Achse misst sich am Füllstand des Kontextfensters, ab dem das Werkzeug verdichtet. Die Werte liegen weit auseinander: Gemini CLI fängt früh an, bei einem Füllstand von 50 Prozent, während Qwen Code, das auf einer Abspaltung der Gemini-Codebasis aufsetzt, bis 70 Prozent wartet. Copilot CLI verteilt die Aufgabe auf zwei Schwellen: Bei 80 Prozent läuft eine asynchrone Kompaktierung im Hintergrund. Bei 95 Prozent greift eine blockierende Notbremse, die den Aufruf anhält, bis die Verdichtung abgeschlossen ist. Codex wartet bis 90 Prozent des konfigurierten Kontextfensters. Codex erlaubt zwar, das automatische Token-Limit pro Modell explizit zu konfigurieren, klemmt diesen Wert intern aber stets auf maximal 90 Prozent des Kontextfensters. Claude Code arbeitet ohne festen prozentualen Trigger. Dort laufen mehrere überlappende Ebenen, deren Eingriffstiefe von chirurgisch bis vollständig reicht.

Jede Schwelle ist ein Kompromiss. Früh zu verdichten kostet zusätzliche LLM-Aufrufe, weil die Zusammenfassung selbst ein Modellaufruf ist, während späte Eingriffe länger in der Context-Rot-Zone leben und Qualitätseinbußen kurz davor riskieren. Die Wahl zwischen 50 und 95 Prozent ist eine Wahl zwischen Token-Ökonomie und Antwortstabilität.

Memory: Markdown-Datei bei Claude Code, SQLite bei Copilot CLI

Das Spektrum reicht weit. OpenCode verzichtet vollständig auf persistentes Memory. Was eine Session erarbeitet hat, lebt nur in den Dateien fort, die der Nutzer explizit anlegt. Claude Code, Codex, Gemini und Qwen nutzen je eine flache Markdown-Datei in einem definierten Pfad: bei Claude Code unter ~/.claude/.../memory/, bei Codex in einem Verzeichnis namens memories, bei Gemini und Qwen in einer projekt- oder benutzerweiten GEMINI.md beziehungsweise QWEN.md. Copilot CLI hingegen führt zwei SQLite-Datenbanken im Hintergrund, kombiniert sie mit Vector-Embeddings und Volltextsuche und macht persistentes Memory zu einer eigenen Session-Capability mit strukturierten Berechtigungs-Anfragen. Jede Memory-Speicherung läuft dort durch einen Berechtigungs-Gate, der drei Felder verlangt: Thema, Fakt und Quellennachweise. Memory ist bei Copilot damit ein nach Thema, Fakt und Provenance getrennter Datensatz.

Die Bandbreite reicht von der Abwesenheit eines Memory-Systems bis zu einem ausgewachsenen Retrieval-System mit Provenance-Feldern. Das ist die deutlichste Differenz im Vergleich. Wer Memory nur als Notiz im Repo braucht, hat fünf Werkzeuge zur Wahl, für Memory als abfragbare Datenbank über viele Sessions hinweg bleibt genau eines.

Sub-Agenten: Delegation bei Claude Code, Fleet-Dispatcher bei Copilot CLI

Sub-Agenten dienen der Isolation von Kontext. Der Hauptagent delegiert eine Teilaufgabe an einen Tochteragenten mit eigenem Fenster, das nach Abschluss verfällt. Das schützt den Hauptkontext vor Aufblähung, weil das Detailwissen der Teilaufgabe nicht ins Hauptgespräch zurückfließt. Nur das Ergebnis kommt zurück. Claude Code bietet hier ein einfaches Delegations-Werkzeug. Copilot CLI fährt mit einem Fleet-Dispatcher, der parallele Sub-Agenten orchestriert, sowie mit einem dedizierten, kleineren Subagent-Modell und expliziten Tiefenlimits, die verhindern, dass eine Aufgabe sich rekursiv ins Unendliche schraubt. Codex nutzt Sub-Agenten unter anderem für die Memory-Konsolidierung in einer eigenen Phase nach Sitzungsende. OpenCode und Qwen sind auf dieser Achse sparsam ausgestattet.

Observability: strukturierte Events und OpenTelemetry in Copilot CLI

Auf dieser Achse liegt eine der größten Differenzen. Copilot CLI emittiert strukturierte Events wie session.compaction_start und session.compaction_complete, hat OpenTelemetry-Unterstützung und bietet einen preCompact-Hook für externe Beobachter. Jeder Eingriff lässt sich damit messen und protokollieren. Zur Eventstruktur gehören die Anzahl der Tokens vor und nach der Verdichtung, die Anzahl entfernter Nachrichten, das generierte Summary und der GitHub-Request-Trace. Wer ein Werkzeug in produktive Pipelines integrieren oder Audit-Trails führen muss, ist auf solche Infrastruktur angewiesen. Die übrigen Werkzeuge bieten hier deutlich weniger.

Hooks und Erweiterungspunkte in Claude Code und Copilot CLI

Hook-Punkte wie sessionStart, preToolUse, subagentStart oder preCompact machen aus einem geschlossenen Werkzeug eine Plattform. Sie sind die moderne Form von Erweiterungspunkten und erlauben es Teams, eigene Governance, Validierung und Logik in den Agenten-Loop einzuhängen. Claude Code und Copilot CLI sind hier am reichsten ausgestattet. Codex bietet spezifische, aber weniger orchestrierbare Erweiterungspunkte. Gemini, Qwen und OpenCode bleiben sparsamer. Sie überlassen Erweiterungen weitgehend dem Konfigurationsmechanismus, ein ereignisbasiertes Modell gibt es dort kaum.

Die sechs Werkzeuge im Einzelnen

Mit den vier Mustern und fünf Achsen lässt sich jede einzelne CLI charakterisieren.

Claude Code: Kompaktierung in vier Ebenen

Claude Code behandelt Kompaktierung als Gradient mit vier Ebenen, die sich in der Eingriffstiefe unterscheiden. Auf der untersten Ebene ersetzt ein chirurgischer Eingriff einzelne ältere Tool-Ergebnisse durch einen Platzhaltertext. Er lässt den Gesprächsverlauf unberührt und greift laufend. Darüber schneidet eine Ebene bei Bedarf einzelne ältere Nachrichten-Blöcke ab, bevor die Mikro-Ebene arbeitet. Als weitere Ebene extrahiert die Session-Memory-Kompaktierung nach jeder Modellantwort als nachgelagerter Hook Memory-Einträge aus der Sitzung und legt sie in einer eigenen Datei ab. Am Ende der Staffelung steht der klassische, vollständige Eingriff mit anschließender Rehydration aller Zustandsdaten. Diese Architektur ist die elastischste der sechs, gleichzeitig die mit der höchsten inneren Komplexität. Sie folgt der Idee, dass Kompaktierung eine Familie gestaffelter Eingriffe sein soll.

Codex: 90-Prozent-Schwelle und geschütztes User-Fenster

Codex behandelt die Session als sauber definierten Zustandsraum. Automatisch verdichtet Codex bis 90 Prozent des Kontextfensters. Das User-Fenster mit dem jüngsten Bereich der Konversation bleibt mit 20.000 Tokens erhalten, damit der aktuelle Arbeitskontext geschützt ist. Das Memory-System ist als separates Subsystem konzipiert. Codex gibt Memory-Einträge über einen eigenen Endpunkt zur Trace-Zusammenfassung an einen Subagent, der in einer eigenen Phase nach Sitzungsende daraus dauerhafte Memory-Dateien konsolidiert. Reproduzierbarkeit ist das erkennbare Designziel: Initial-Kontext, Kompaktierungsgrenze und Memory-Operationen sind explizit und nachvollziehbar.

Gemini CLI: eigenes Utility-Modell für die Verdichtung

Gemini CLI verteilt die Aufgabe auf vier spezialisierte Dienste, die zusammenarbeiten, und leistet sich ein eigenes Utility-Modell, das die Zusammenfassungen erstellt. Dieses Modell heißt intern chat-compression-2.5-flash-lite. Es ist eine kleinere, günstigere Variante als das Hauptmodell und übernimmt ausschließlich die Verdichtung. Damit kommt Gemini der in der Forschung empfohlenen Trennung von Memory-Operationen und Hauptmodell am nächsten. Verdichtet wird aggressiv ab 50 Prozent Füllstand, was zusätzliche LLM-Aufrufe erzeugt, aber das Hauptmodell weit unterhalb des Context-Rot-Bereichs hält.

Qwen Code: Gemini-Fork mit höherer Schwelle

Qwen Code ist eine Abspaltung von Gemini CLI durch Alibaba. Die Codebasis übernimmt große Teile der Gemini-Logik. Verdichtet wird allerdings erst ab 70 Prozent, und der Compressor sitzt an einer anderen Stelle der Pipeline. Eine genauere Analyse zeigt, dass die Verdichtung den Memory-Pfad umgeht, den Gemini regulär durchläuft. Das Ergebnis ist eine moderne Architektur mit einem internen Bruch in der Integration: Was Gemini sauber trennt, läuft bei Qwen an einer Stelle wieder zusammen.

OpenCode: Overflow-Management ohne persistentes Memory

OpenCode versteht sich als Hausmeister-Werkzeug. Es betreibt ein starkes Overflow-Management mit einem Puffer von 20.000 Tokens und ohne feste prozentuale Schwelle, denn es greift erst ein, wenn der Kontext tatsächlich überzulaufen droht. Instruktionsdateien werden träge geladen. Der Code ist flach hierarchisch organisiert, die Overflow-Logik transparent und gut nachvollziehbar. Ein persistentes Memory-System fehlt vollständig. Wer Einfachheit und Nachvollziehbarkeit priorisiert, findet hier die geringste Komplexität.

Copilot CLI: SQLite-Memory, Fleet-Dispatcher und Hooks

Copilot CLI ist von allen sechs Werkzeugen am nächsten an dem, was die Forschungspapiere von 2025 und 2026 fordern. Verdichtet wird zweistufig, asynchron bei 80 Prozent und blockierend bei 95 Prozent. Persistentes Memory wird in zwei SQLite-Datenbanken mit Vector-Embeddings und Volltextsuche über mehrere Sessions hinweg verwaltet. Memory-Speicherungen sind permissionspflichtig und tragen ein eigenes Provenance-Feld, das die Quellen des gespeicherten Fakts dokumentiert. Sub-Agenten werden über einen Fleet-Dispatcher parallel orchestriert. Dabei entstehen strukturierte Events mit umfangreichen Metriken. Ein Hook-System erlaubt, externe Logik vor und nach jeder Kompaktierung einzuklinken. Der Preis dieser Reichhaltigkeit: Der Kern ist closed source. Nur das SDK ist öffentlich zugänglich. Die zentralen Algorithmen lassen sich aber aus dem frei einsehbaren SDK-Code und der dokumentierten Telemetrie ableiten, weil dort die Default-Schwellwerte und die Eventstruktur der Kompaktierung als typisierte Schnittstelle veröffentlicht sind.

Memory-Subsysteme: Markdown-Datei oder SQLite-Datenbank

Beim Memory-Subsystem laufen die Architekturen am stärksten auseinander, und gleichzeitig liegt hier der größte Forschungsabstand.

Vier der sechs Werkzeuge speichern Memory als Markdown-Datei. Claude Code, Codex, Gemini und Qwen folgen diesem Pfad. Der Vorteil ist offensichtlich: Markdown ist menschenlesbar, versionierbar und im Repository ablegbar. Ein Entwickler kann Memory-Einträge in einem normalen Texteditor lesen, im Git nachverfolgen und in einem Pull Request reviewen, nur ist eine flache Datei eben kein abfragbares System. Wer wissen will, was vor zwei Wochen über das Authentifizierungsmodul entschieden wurde, muss die Datei selbst lesen oder dem Agenten den ganzen Inhalt in den Kontext werfen.

OpenCode verzichtet auf jedes persistente Memory-System. Das ist eine bewusste Designentscheidung. Wer Memory braucht, legt entsprechende Markdown-Dateien selbst im Repository ab und verweist im Prompt darauf. Jede Sitzung beginnt also mit dem, was im Repo dokumentiert ist, denn intern speichert das Werkzeug nichts. Diese Klarheit hat ihren Preis: Es gibt keine automatisch aufgebaute Lernkurve über Sessions hinweg.

Copilot CLI geht den entgegengesetzten Weg und implementiert ein vollständiges Memory-Subsystem. Zwei SQLite-Datenbanken speichern Inhalte und Embeddings getrennt, eine Volltextsuche erlaubt klassische Stichwortabfragen, und Vector-Embeddings erlauben semantische Ähnlichkeitssuchen. Memory wird über strukturierte Berechtigungs-Anfragen geschrieben oder bewertet. Bei jeder Speicherung müssen Thema, Fakt und Quellennachweise vorliegen. Das ist näher an den Forderungen aus der Forschungsliteratur, insbesondere an Arbeiten wie MemInsight und CDMem, als alle anderen untersuchten Werkzeuge.

Allerdings ist auch dieses System nicht der Stand der Forschung. Cross-Session-Memory ist laut Dokumentation explizit experimentell. Intent-getriebener Abruf fehlt, also die Auswahl von Memory-Einträgen nach der aktuellen Aufgabenabsicht. Der Abruf läuft über Pfade, Namespaces und semantische Ähnlichkeit, ohne Goal States. Kausale und temporale Strukturen zwischen Memory-Einträgen sind auf Zeitstempel beschränkt. Einen expliziten Ereignisgraph gibt es nicht.

Sub-Agenten zur Kontext-Isolation bei Claude Code und Copilot CLI

Sub-Agenten sind neben dem Memory das andere große Feld architektonischer Differenz. Die Grundidee ist einfach: Der Hauptagent übergibt eine Teilaufgabe an einen Tochteragenten, damit sie das Hauptfenster nicht belastet. Der Tochteragent startet mit einem leeren Fenster, erledigt die Aufgabe und gibt ausschließlich das Ergebnis zurück. Zwischendialog, Tool-Calls und Detailrecherche bleiben dem Hauptkontext erspart.

Claude Code stellt dafür ein einfaches Delegations-Werkzeug bereit. Der Hauptagent kann eine Aufgabe an einen Subagenten geben, der im selben Modell mit eigenem Kontext arbeitet. Das ist konzeptuell sauber und in der Praxis nützlich, vor allem für Recherche-Aufgaben in großen Codebasen. Parallele Claude-Sessions können einander außerdem Nachrichten schicken und ihre Arbeit an einer Codebasis so abstimmen.

Copilot CLI hat den weitestgehenden Ausbau. Ein Fleet-Dispatcher kann Sub-Agenten parallel starten, ein dediziertes kleineres Modell übernimmt die Subagent-Arbeit zu geringeren Kosten, und explizite Tiefenlimits verhindern Endlosrekursionen. Damit nähert sich die Architektur den Patterns, die in der Forschung als hierarchische Multi-Agent-Systeme diskutiert werden.

Codex nutzt Sub-Agenten primär für die Memory-Konsolidierung, die nach Sitzungsende in einer eigenen Phase läuft. Diese Trennung zwischen Sitzungs-Sub-Agenten und Konsolidierungs-Sub-Agenten ist architektonisch interessant: Memory-Operationen werden aus dem heißen Pfad herausgenommen und asynchron erledigt. Das senkt die Sitzungs-Latenz, verschiebt aber das Memory-Update zeitlich.

Gemini, Qwen und OpenCode bieten bei Sub-Agenten weniger. Sub-Agenten gibt es, aber sie sind weder das prägende Designprinzip wie bei Copilot noch das tief integrierte Werkzeug wie bei Claude Code.

Forschungsstand und die Frontier-Lücke

So weit die sechs Werkzeuge auch sind, sie liegen sämtlich hinter dem zurück, was die akademische Forschung in den vergangenen achtzehn Monaten an Konzepten vorgelegt hat. Arbeiten wie MemoryOS (Oral bei EMNLP 2025), HiAgent (ACL 2025), LightMem (ICLR 2026) und Mnemis (akzeptiert bei ACL 2026, von Microsoft Research) skizzieren eine nächste Generation von Memory-Architekturen, die sich von den heutigen CLI-Implementierungen in vier Punkten unterscheidet. Die Papers fordern:

• einen intent-sensitiven Abruf: Memory wird nach der Absicht der aktuellen Aufgabe ausgewählt und nicht nach Pfad oder Zeitstempel.
• explizite kausal-temporale Strukturen, also Beziehungen zwischen Fakten, die als gerichteter Graph adressierbar sind, während Prosa sie versteckt.
• lernende Policies für das Einfügen und Löschen von Memory-Einträgen, die aus dem Erfolg späterer Schritte lernen und ohne feste Heuristiken auskommen.
• eine Sicherheitsgovernance für persistente Speicher mit Zugriffskontrolle, Audit-Trail und expliziter PII-Behandlung.

Die heutigen CLIs setzen davon Bruchstücke um. Tool-Ausgaben werden vor User-Prosa geopfert, weil sie reproduzierbar sind. Das ist ein Effizienzmerkmal, das die Forschung lobt. Memory wird selektiv geschrieben. Copilot speichert Provenance-Felder, andere nicht. Eine echte intent-getriebene Abruflogik existiert in keinem der Werkzeuge. Kausale Strukturen fehlen vollständig. Bei der ökonomischen Effizienz des Kontextmanagements sind die CLIs heute weit. Bei seiner Tiefe stehen sie am Anfang.

Die Survey „Memory in the Age of AI Agents“, im Dezember 2025 mit 47 Autoren auf arXiv veröffentlicht, kommt zu einem ähnlichen Ergebnis. Traditionelle Taxonomien wie die Trennung von Lang- und Kurzzeitgedächtnis seien unzureichend für moderne Agent-Memory-Systeme, und Multi-Session-Konsistenz über Stunden und Tage gelte als weitgehend ungelöst. Selektives Vergessen sei das schwierigste der offenen Probleme. Auch Mnemis, eines der derzeit am besten platzierten Systeme, erreicht auf dem LoCoMo-Benchmark mit GPT-4.1-mini einen Wert von 93,9 von 100 möglichen Punkten und 91,6 auf LongMemEval-S. Eine Gesamtlösung beansprucht das Paper damit ausdrücklich nicht und dokumentiert seine Grenzen transparent.

Konsequenz für die Werkzeugwahl

„Welches CLI ist das beste?“ ist die falsche Frage, eine universelle Antwort gibt es nicht, und passend ist ein Werkzeug immer nur für bestimmte Anforderungen. Wer in einer CI/CD-Pipeline arbeitet, wird Copilot wegen seiner Observability oder Codex wegen seiner Reproduzierbarkeit bevorzugen, während bei interaktiver und stark konfigurierter Arbeit Claude Code die größte Flexibilität bietet. Für Memory als abfragbare Datenbank über viele Projekte hinweg gibt es genau eine Wahl. OpenCode ist das Werkzeug für alle, die Einfachheit über alles stellen.

Die Pattern-Sprache nützt über diesen Vergleich hinaus. Wer Trim, Summarize, Persist und Prune verstanden hat, dazu hierarchische Discovery, Sub-Agent-Isolation, Post-Compact-Rehydration und Hook-basierte Extension, liest beim nächsten Werkzeug auf dem Markt die relevanten Codepfade und braucht dafür kein Demo-Video. Das Vokabular überdauert die einzelnen Implementierungen.

Am unangenehmsten für Anbieter wie Anwender: Auch das beste Memory-System ersetzt keine strukturierte Planung der Arbeit selbst. Die Werkzeuge liefern die Mechanik. Was zu bauen ist, in welcher Reihenfolge und mit welchen Kriterien für die Annahme, entscheidet weiterhin der Mensch.

Bleibt die Lücke zwischen Forschung und Implementierung. Sie ist eine Chance. Die nächste Generation von CLIs wird darüber entschieden, welche Anbieter zuerst intent-sensitiven Abruf, kausal-temporale Memory-Strukturen und lernende Policies in produktive Form bringen. Das Hauptmodell gibt dabei nicht den Ausschlag. Wer heute auswählt, sollte einkalkulieren, dass dieses Feld in zwei Jahren anders aussehen wird, ohne dass die hier vorgestellte Pattern-Sprache obsolet würde.

Das DORA-Team gehört mittlerweile zu Google und gilt seit 2014 als die einflussreichste Forschungsstelle für die Vermessung von Softwareentwicklung. Aus seinen Studien stammen die vier zentralen Auslieferungs-Metriken rund um Lead Time, Deployment Frequency, Change Failure Rate und Recovery Time, die heute branchenübergreifend Standard sind. Der Bericht “The ROI of AI-assisted Software Development” erscheint als gemeinsame Arbeit mit der internen Beratungseinheit „delta", die Google-Cloud-Kunden bei der Einführung von KI begleitet.

Der Bericht ist in sieben Kapitel gegliedert. Er beginnt mit einer Zusammenfassung und baut einen Business Case auf. Dann beschreibt er die Marktspaltung bei der KI-Bewertung und führt durch die Berechnung des ROI mit Wertfaktoren, Kostenfaktoren und Beispielrechnungen. Es folgen fünf strukturelle Voraussetzungen für eine erfolgreiche Adoption und eine Investitions-Roadmap. Den Schluss bildet eine Anleitung zur Sicherung langfristiger Erträge. Im Anhang liefert er einen Beispiel-ROI-Rechner, dessen interaktive Version unter dora.dev/ai/roi/calculator öffentlich verfügbar ist.

KI als Verstärker, Code als Last

Die Aussage, dass KI als Verstärker wirkt, taucht im Bericht in vielen Variationen auf. Sie folgt aus der zentralen Beobachtung des 2025er DORA-Reports: Wer ein gut funktionierendes Engineering-System hat, multipliziert dessen Stärken durch KI. Bei einem dysfunktionalen System multipliziert sie die Dysfunktionen. „Without this foundation, AI creates localized pockets of productivity that are often lost in downstream chaos", schreiben die Autoren. Die Folge ist eine bemerkenswerte Umdeutung dessen, was als Code-Output zählt.

Mit Bezug auf das Standardwerk „Software Engineering at Google" zitiert der Bericht die Maxime, dass Code in der Lebenszeit eines Systems häufig „eine Last, kein Aktivposten" sei. Der Betrieb eines Systems übersteige die Kosten seiner Erstellung um Größenordnungen. Mehr Code, ohne Aufsicht erzeugt, vergrößere den Verifikations-Aufwand und führe zu langfristiger technischer Schuld. Diese Umkehr ist programmatisch: Sie verschiebt das übliche KI-Versprechen vom „mehr Code, schneller" auf „weniger Engpass, durchgehend".

Eine bekannte These, jetzt in einer Geldgröße

Wer den Bericht parallel zum jüngsten Beitrag zum Team-Betriebssystem für Agentic CLI liest, findet einen unmittelbaren Bezugspunkt. Die These dort lautete, dass Werkzeuge ohne Methode Fehler ins Ergebnis verschieben, wo sie unsichtbar bleiben. Die Stanford-Studie von Christopher Potts und Moritz Sudhof bezifferte den Anteil der unsichtbar gewordenen Fehler auf 88 Prozent in Dialogen mit ungeübten Anwendern. Der DORA-Bericht liefert die organisationsökonomische Seite dazu. Die unsichtbaren Fehler sind nicht nur ein Qualitätsproblem, sondern tauchen auch in den Auslieferungs-Metriken auf, als gestiegene Change Failure Rate und längere Recovery Time, mit messbarem Umsatzeffekt.

Die fünf systemischen Schlüssel des Berichts (Vertrauen, interne Plattform, Daten-Ökosystem, Nutzerorientierung, automatisierte Schutzschienen) decken sich weitgehend mit den Säulen einer methodisch geführten Schulung. Eine schriftlich fixierte Haltung zu KI entspricht einer Repo-Verfassung. Der als Produkt geführten internen Entwicklerplattform entspricht das Bild der Tool-Zonen, in denen Werkzeuge nach Risiko sortiert sind. In der Nutzerorientierung steckt der Auftrag, jede Auslieferung gegen ein klares Ziel zu schneiden. Das Ziel ist der ROI. Ohne die Methode bleibt er aber verstreut. Was vorher als Frage von Stil und Reviewkultur galt, taucht im DORA-Bericht als Variable im Geldmodell auf.

Was das für deutsche Teams heißt

Die Beispielzahlen des Berichts stammen aus einem US-Cloud-Native-Modell. Mit 176.000 Dollar Jahresvergütung liegt der Rechner am oberen Rand dessen, was eine deutsche Software-Fachkraft kostet, vor allem in regulierten Branchen mit Tarifbindung. Den Abstand zwischen Greenfield- und Brownfield-Wirkung gibt der Bericht mit 35 bis 40 Prozent gegen zehn Prozent an, und dieser Abstand trifft deutsche Anwenderlandschaften zudem härter. Hier ist mehr alterndes Bestandswissen verbaut als in den Vergleichswerten aus Mountain View. Ein Ergebnis aus dem Beispielrechner wird in Stuttgart oder Walldorf nicht eins zu eins eintreten.

Dennoch gilt die strukturelle Aussage, und sie steckt in einer Zahl: acht Monate. So lange dauert nach den Modellannahmen die Phase, in der mehr Geld in das System fließt als herauskommt. Wer in dieser Zeit die J-Kurve als Misserfolg liest und die Mittel zurückzieht, verspielt nach Lesart der Autoren den anschließenden Aufschwung. Mit einer Investition in das Fundament, also in Plattform, Daten, Verifikation, Vertrauen und Nutzerorientierung, nimmt ein Unternehmen die Kurve dagegen nach oben mit. Für das Warten auf das nächste Modell findet sich im Text keine Bestätigung. Der Rest dieses Beitrags rekonstruiert die Rechnung im Detail, ordnet die widersprüchlichen Marktdaten ein und benennt die Vorbehalte, die der Bericht selbst formuliert.

Die J-Kurve und ihre drei Kräfte

Im Zentrum des finanziellen Modells steht eine Kurve in Form des Buchstabens J. Der Bericht nennt sie die „J-Curve of AI value realization" und beschreibt sie als eine empirisch beobachtete Verlaufsform für große Transformationsprojekte. In der Frühphase der Einführung sinkt die Produktivität, manchmal über Monate. Erst danach steigt sie wieder, um schließlich exponentiell zu wachsen. Drei Kräfte ziehen die Kurve zunächst nach unten.

Die Lernkurve steht am Anfang: die Zeit, die Teams benötigen, um neue Schnittstellen, Arbeitsabläufe und Promptingstrategien zu beherrschen. Dazu kommt die Verifikationssteuer („verification tax"), die Zeit, die Entwicklerinnen und Entwickler aufwenden, um KI-Output gegen Halluzinationen zu prüfen und gegen Sicherheits- und Architekturstandards zu verifizieren. Als dritte Kraft nennt der Bericht die Pipeline-Anpassung, weil schneller erzeugter Code an Test- und Freigabeengpässen aufläuft, die zuvor noch ausreichten. Der Bericht deutet diese drei Kräfte als Lehrgeld der Transformation. Ein Versagen der Technologie sieht er darin nicht. Wer ein Budget aufstellt und die J-Kurve nicht einplant, riskiere, in der Talsohle die Mittel zu kürzen und damit den späteren Anstieg zu verspielen.

Was die Einführung kostet

Der Beispielrechner beziffert diesen Investitionsblock in expliziten Größen. Er setzt 500 technische Mitarbeitende an, eine voll belastete Jahresvergütung von 176.000 Dollar, eine J-Kurven-Dauer von drei Monaten und einen Produktivitätseinbruch von 15 Prozent. Allein als Lehrgeld ergeben sich daraus 3,3 Millionen Dollar. Hinzu kommen die direkten Werkzeug- und Schulungskosten. Das Beispielmodell veranschlagt 250 Dollar Lizenz pro Nutzerkonto und Jahr, dazu 80 Dollar zusätzliche Nutzungskosten (etwa für Token), 9.600 Dollar Schulung pro Person und 100.000 Dollar zusätzliche Infrastrukturkosten. Diese Summe addiert sich zu 5,065 Millionen Dollar. Zusammen mit der J-Kurve ergibt das eine Gesamtinvestition im ersten Jahr von 8,365 Millionen Dollar.

Was die Einführung einbringt

Auf der Wertseite arbeitet das Modell mit drei Posten. Ein Posten ist die freigesetzte Personalkapazität, die der Bericht als „Headcount Reinvestment Capacity" bezeichnet. Sie entsteht, wenn Entwicklerinnen und Entwickler durch KI Zeit gewinnen, die sie in höherwertige Arbeit reinvestieren können. Bei 12,5 Prozent eingesparter Nettozeit pro Kopf entspricht das im Beispiel 11 Millionen Dollar. Ein weiterer Posten ist der zusätzliche Umsatz aus mehr ausgelieferten Features. Liefert ein Team 50 Features pro Jahr aus, sind es künftig 56. Ein Drittel davon hat Umsatzwirkung, mit 0,5 Prozent auf einen Produktportfolio-Umsatz von 100 Millionen Dollar. So kommen knapp 990.000 Dollar dazu. Der dritte Posten hat ein umgekehrtes Vorzeichen. Aus dem 2025er DORA-Report stammt der Befund, dass die Einführung von KI mit einer höheren Change Failure Rate korreliert. Im Modell steigt der Anteil fehlerhafter Auslieferungen dadurch von 5 auf 6 Prozent. Bei vier Stunden Wiederherstellungszeit und 100.000 Dollar Ausfallkosten pro Stunde schlägt das mit minus 344.000 Dollar zu Buche. Aufsummiert ergibt sich ein Gesamtwert von 11,646 Millionen Dollar im ersten Jahr.

Hinter der Dreierstruktur des Modells steht ein breiteres Wertgerüst, das der Bericht im Kapitel zur Wertberechnung mit fünf Säulen beschreibt: Kosteneffizienz, Produktivität, Developer Experience, User Experience und Geschäftswachstum. Je weiter man im Modell nach rechts geht, desto schwächer wird der unmittelbare Bezug zur KI im Engineering, desto stärker wird der finanzielle Hebel. Der Bericht macht in einer Grafik (Figure 4) sichtbar, was der 2025er DORA-Report empirisch gemessen hat. Die größte Wirkung der KI-Adoption findet sich auf der individuellen Effektivität, gefolgt von einer höheren Lieferinstabilität (mit umgekehrtem Vorzeichen), dann von organisatorischer Performance, sinnvoller Arbeit, Code-Qualität, Produkt-Performance, Lieferdurchsatz und Team-Performance. Burnout und Reibung verändern sich kaum. Die Streuung der Effekte ist breit, und die Wirkung hängt vom System ab, in dem das Werkzeug arbeitet.

Der Developer Experience widmet der Bericht eine eigene Passage. Er behält sie ausdrücklich im Modell, nimmt sie aber aus Vorsicht aus der Beispielrechnung heraus. Der Zusammenhang zwischen einer KI-Einführung und der Bindung von Personal sei real, aber statistisch zu variabel, um ihn in eine Punktschätzung zu legen. Als qualitatives Argument bleibt er stark, weil der Ersatz einer Software-Fachkraft typischerweise das Eineinhalb- bis Zweifache des Jahresgehalts kostet. Wer eine bessere Arbeitsumgebung schafft, weil Routinearbeit an Agenten ausgelagert wird, senkt diese Wechselkosten. In der Sample-Berechnung lässt der Bericht diesen Posten bewusst weg, in der Argumentation führt er ihn aber als „mächtiger qualitativer Hebel".

Aus diesen beiden Seiten der Rechnung folgt eine ROI-Quote von 39 Prozent im ersten Jahr und eine Amortisation nach 0,7 Jahren, also etwa acht Monaten. Der Bericht ordnet die Größenordnung ein. Eine Amortisation zwischen sechs und neun Monaten gelte als Benchmark für agile Teams, zwischen zwölf und achtzehn Monaten für regulatorisch geprägte Großorganisationen. Für eine längere Perspektive verweisen die Autoren auf eine eigene Datenerhebung. Google-Cloud-Kunden hätten über drei Jahre eine durchschnittliche Rendite von 727 Prozent auf ihre KI-Investition gemeldet. Die Zahl stammt aus einer Veröffentlichung von Google Cloud selbst. Der Bericht kennzeichnet sie als Kundenmeldung ohne unabhängige Validierung.

Methodenhinweise im Eigentext

An mehreren Stellen weist der Bericht selbst auf die Grenzen der Berechnung hin. Im Hinweiskasten zur Methodik heißt es, die Kalkulationen seien „eine hochunsichere Schätzung, gedacht um ein Gespräch in Gang zu setzen, nicht als rigide mathematische Formel". Die Autoren zitieren die Statistiker-Maxime, alle Modelle seien falsch, manche aber nützlich. Wer im Rechner einzelne Annahmen verändert, sieht das Endergebnis sofort kippen. Eine konservative Variante senkt den Wert auf 80 Prozent und erhöht die Kosten auf 150 Prozent, eine optimistische geht in die andere Richtung. Der Spielraum ist breit. Die Autoren empfehlen ausdrücklich, mehrere Szenarien gleichzeitig durchzurechnen, und raten davon ab, einer einzelnen Punktschätzung zu vertrauen.

Die Marktspaltung

In einer längeren Passage fragt der Bericht, warum bei nahezu universeller Einführung die finanziellen Resultate so weit auseinanderliegen. Er beschreibt drei Lager. Die optimistische Position beruft sich auf eine Google-Cloud-Erhebung, nach der 78 Prozent der befragten Führungskräfte einen Return aus mindestens einem generativen KI-Anwendungsfall berichteten. Außerdem nennt sie 88 Prozent positive Rückmeldungen unter frühen Anwendern agentischer Systeme. Die neutrale Position verweist auf den Stanford AI Index 2025, der die Erwartungen an die Belegschafts-Produktivität als „durchgängig gemischt" einordnet. Während die Adoption hoch sei, bleibe die strukturelle Transformation in den meisten Branchen selten und es ergäben sich überwiegend marginale Produktivitätsgewinne. Das pessimistische Lager zitiert Forschung aus dem MIT-NANDA-Projekt. Demnach scheitern interne Unternehmens-Implementierungen häufig, was Beschäftigte in eine „Schatten-KI-Wirtschaft" treibe, in der sie auf nicht autorisierte Verbraucheranwendungen ausweichen. Die hauptsächliche Hürde liege laut MIT-Befund im organisatorischen Design. Budget und Technologie seien es nicht.

Etwas versteckt im Kapitel zur ROI-Modellierung steht eine bemerkenswerte Zahl. Eine Auswertung des Stanford-Forschungsprogramms zur Software-Engineering-Produktivität habe gezeigt, dass KI-Werkzeuge bei einfachen, auf der grünen Wiese gestarteten Aufgaben einen Produktivitätsgewinn von 35 bis 40 Prozent erzeugten. Bei komplexem, alterndem Bestandscode liege die Wirkung dagegen oft bei zehn Prozent oder darunter. Die Autoren des Berichts verwenden diesen Unterschied, um die Auswahl von Anwendungsfällen zu rechtfertigen. Wer KI primär in Greenfield-Szenarien einsetze, sehe schneller Wirkung. Für Brownfield-Migrationen brauche es stärkere Vorarbeit am Engineering-System. Wie diese Vorarbeit im Bestand aussehen kann, zeigt die agentische Engineering-Pipeline für den SDLC.

Fünf strukturelle Voraussetzungen

Im Kapitel „Build the organizational foundation for AI adoption" benennt der Bericht fünf systemische Schlüssel, die ein Unternehmen aus den verstreuten lokalen Produktivitätszuwächsen herausführen sollen. An erster Stelle steht Vertrauen, technisch umgesetzt als „clear and communicated AI stance". Gemeint ist eine schriftlich fixierte Haltung der Organisation zu KI, die Erwartungen, Grenzen und Reviewpflichten festlegt. Es folgt eine interne Entwicklerplattform (IDP), die als Produkt behandelt wird und Reibung im Umgang mit Werkzeugen, Pipelines und Architekturmustern minimiert. In der agentischen Ära fungiere die IDP als „Risikominderer und Kontextlieferant für Agenten". Ein KI-zugängliches Daten-Ökosystem ist die dritte Voraussetzung, weil Agenten nur so gut sind wie die Daten, auf die sie zugreifen. Eine kompromisslose Nutzerorientierung richtet die durch Werkzeuge gewonnene Geschwindigkeit auf reale Probleme aus. Auf die Zahl der Pull-Requests kommt es dabei nicht an. Als Letztes nennt der Bericht automatisierte Verifikations-Schienen („Guardrails"), die als Bremsen wirken und es dem Engineering-System erlauben, sicher schneller zu fahren.

Eine Formel des Berichts bündelt die These: „Wir messen KI nicht an dem Code, den sie schreibt, sondern an den Engpässen, die sie freiräumt." Die Aussage steht im Kapitel zum Geschäftsfall. Sie verschiebt das übliche Versprechen, KI ersetze Entwicklerstellen, in eine andere Logik. ROI messe, wie viel latentes menschliches Kreativitätspotenzial freigesetzt werde, indem systemische Routinearbeit an autonome Agenten ausgelagert werde. Die Zahl der abbaubaren Stellen sei dafür kein Maß.

Empfehlung gegen Stellenstreichung

Konsequent rät der Bericht von einer Kostensenkungsstrategie auf der Personalseite ab. Wer Produktivitätsgewinne in Stellenstreichungen ummünze, beschädige die Moral, vermindere die Lernbereitschaft und erzeuge Anreize, sich gegen Prozessverbesserungen zu sperren. Die Autoren empfehlen stattdessen, freigesetzte Kapazität als Reinvestition in Innovation zu rahmen. Die so gesparten Kosten seien vermiedene Kosten für ausgebliebene Neueinstellungen. Um Einsparungen durch Entlassungen gehe es dabei nicht. Diese Lesart ist im Modell auch deshalb angelegt, weil die Wechselkosten für Personal in Software-Berufen typischerweise das Eineinhalb- bis Zweifache des Jahresgehalts betragen.

Der Begriff „verification tax" kehrt im Text immer wieder. Im Kapitel über zusätzliche und indirekte Kosten beschreibt der Bericht, wie eine niedrige Vertrauensbasis die J-Kurve vertieft. Wenn jeder Codeblock zweimal gegengelesen werde, bevor er in die Pipeline gehe, lösten sich die Produktivitätsgewinne auf. Vertrauen behandelt der Bericht deshalb als harte finanzielle Variable. Es zu erzeugen verlange ein System, das Verifikation belohne. Die rohe Code-Menge dürfe dabei kein Anreiz sein. Die Forschung zur agentischen Softwareentwicklung beschreibt dieselbe Verschiebung: Verifikation wird zum Engpass, auf den die agilen Praktiken keine Antwort haben.

Experimentfrequenz als Finanzgröße

Der Bericht argumentiert in einer eigenständigen Passage, die Frequenz von Experimenten sei ein finanzieller Indikator und nicht nur ein Engineering-Wert. Der Argumentationsgang stützt sich auf das Konzept der Optionalität aus der Finanzwelt. Eine Option sei eine risikoarme Investition, die das Recht eröffne, später größer zu investieren, ohne es zu müssen. Ein Prototyp oder ein A/B-Test sei eine solche Option. KI senke die Vorlaufkosten dieser Option, indem sie die Zeit für Code-Erstellung drastisch verkürze. Wer mehr Optionen halte, müsse weniger früh auf eine einzige Hypothese setzen.

Die finanzielle Lesart fügt der Methodik eine Dimension hinzu, die sich von reiner Geschwindigkeit unterscheidet. Ob ein Team mehr Code in der gleichen Zeit ausliefert, tritt dabei zurück. Die Frage lautet, wie viele Hypothesen ein Team in der gleichen Zeit durch echte Nutzerinnen und Nutzer prüfen kann, bevor es Ressourcen in eine Skalierung investiert. Hohe Experimentfrequenz, schreibt der Bericht, sei ein Frühindikator dafür, dass die Organisation die KI absorbiert habe und nicht in falsche Features investiere.

Drei Vorbehalte

Der Bericht stammt aus dem Hause Google. Er enthält Verweise auf Google-Cloud-Werkzeuge und Beratungsdienste, sein Beispielrechner endet mit einer Kontaktoption zur „delta"-Praxis. Die methodische Solidität der Argumente bleibt davon unberührt, der Marketingrahmen ist aber zu erkennen.

Der Rechner beschränkt sich zudem auf das erste Jahr. Die hohen Mehrjahres-Renditen von 727 Prozent stammen aus einer separaten Quelle, die der Bericht selbst als Kundenmeldung kennzeichnet. Schließlich bleiben die zentralen Eingangsgrößen, also der Anteil eingesparter Zeit, die Erfolgsquote zusätzlicher Features und die Umsatzwirkung pro Feature, Schätzungen, deren Bandbreite der Bericht offen ausweist. Die Autoren machen aus dieser Unsicherheit kein Geheimnis. Sie betonen mehrfach, dass der Rechner ein Gesprächsöffner sei und kein Bilanzinstrument.

Reife als finanzielle Variable

Trotz dieser Vorbehalte bietet der Bericht etwas, das in der bisherigen Diskussion über KI-Werkzeuge fehlte. Er übersetzt die Aussage, dass das Fundament wichtiger sei als das Modell, in eine Geldgröße. Solange die Diskussion über agentische Werkzeuge auf den Vergleich von Modellen oder die Geschwindigkeit einzelner Aufgaben reduziert blieb, war die organisatorische Reife eine Aussage über Stil und Reviewkultur. Im DORA-Bericht wird sie zu einer Variable im finanziellen Modell. Eine konservative Annahme über die Reife der internen Plattform senkt den Gesamtwert von 11,6 auf rund 9 Millionen Dollar. Eine optimistische Annahme hebt ihn um den entsprechenden Betrag. Reife ist hier ein Faktor in der Rechnung.

Eine zweite Beobachtung behandelt der Bericht eher beiläufig. Die Inferenzkosten für die fortschrittlichsten Modelle seien zwischen November 2022 und Oktober 2024 um den Faktor 280 gefallen. Damit näherten sich die Kosten der Modellabfrage Null, und die echten Kosten verschöben sich auf die Governance, also auf Verifikation, Workflows und Qualifizierung. Wer in diesen drei Bereichen vorbereitet sei, mit Plattformteam, Reviewkultur und ehrlicher Lehrgeld-Planung, sehe in Jahr zwei und drei den exponentiellen Wertzuwachs, von dem die Autoren sprechen. Wer es nicht sei, bleibe in der Talsohle.

Diese Verschiebung erklärt einen zweiten Befund des Berichts. Die Frage, welches Modell ein Team einsetzt, wird im Bericht zwar erwähnt, aber konsequent in eine Nebenrolle gerückt. Die zentrale Variable ist die Kompetenz, das Modell in einen Arbeitsablauf einzubetten, der Verifikation belohnt und Risiko begrenzt. Was im Jahr 2024 noch als technische Frage galt, ist 2026 eine Organisationsfrage. Der Bericht will diese Verschiebung in einer Zahl sichtbar machen.

Eine Zwischenbilanz des Berichts fasst die Logik nüchtern zusammen: „Der Pfad zum ROI ist eine Sequenz des Aufbaus von Kompetenzen, kein Wettrennen um das neueste Modell oder das neueste Werkzeug." An dieser Aussage endet der Text. Sie liest sich nach 60 Seiten Methodik fast unscheinbar, in der Sache bezeichnet sie aber eine Kehrtwende. Der Wettbewerb um die schnellste Modellgeneration verliert die Rolle, die ihm 2023 und 2024 zugeschrieben wurde. An seine Stelle tritt der Wettbewerb um die reifste Engineering-Organisation. Im Lizenzvertrag entscheidet sich nicht, welche der beiden Disziplinen ein Unternehmen besser beherrscht. Das entscheidet sich in der internen Plattform, in den Reviewroutinen und in der Bereitschaft, drei Monate Lehrgeld zu zahlen, ohne die Mittel vorzeitig zu kürzen.

Die Geschwindigkeit der Verschiebung lässt sich an einigen Daten ablesen. Anthropic hat Claude Code im Februar 2025 als Preview veröffentlicht, im Mai folgte die General Availability. OpenAI brachte Codex CLI im April 2025 als Open-Source-Terminal-Tool. GitHub kündigte Copilot CLI im September 2025 als Public Preview an, mit voller GitHub-Integration und Plan-Modus. Im Februar 2026 hat das Werkzeug die Anweisungsdatei AGENTS.md gleichberechtigt zu der älteren .github/copilot-instructions.md aufgenommen. Innerhalb eines Jahres ist aus einer Kategorie experimenteller Werkzeuge eine Kategorie produktiv eingesetzter Standard-Tools geworden. Mittlere und große IT-Organisationen rollen die Werkzeuge derzeit in Wellen aus, oft schneller, als die Methodik in den Teams reifen kann.

Wer in dieser Lage ein Werkzeug einkauft und es seinen Entwicklerinnen und Entwicklern in die Hand gibt, kann zusehen, wie einzelne Aufgaben schneller fertig werden. Gleichzeitig sinkt die Qualität der Projektarbeit. Eine Studie aus diesem Jahr hat diesen Befund nüchtern als gemessenen Effekt dokumentiert. Christopher Potts und Moritz Sudhof, beide Stanford University, werten in der Arbeit „A paradox of AI fluency" knapp 27.000 reale KI-Dialoge aus dem Korpus WildChat-4.8M aus. Das sind je 1.000 zufällig gezogene englische Gespräche pro Monat von Mai 2023 bis Juli 2025. Sie messen vier Achsen: KI-Kompetenz, Interaktionsstil, Aufgabenkomplexität und Fehlerindikatoren. Das auffälligste Ergebnis betrifft die Sichtbarkeit von Fehlern. In Dialogen mit hoher KI-Kompetenz tauchen 64 Prozent Fehlerindikatoren auf, in Dialogen mit geringer KI-Kompetenz nur 24 Prozent. Wer das oberflächlich liest, hält die Geübten für die schlechteren Anwender. Die zweite Zahl löst das Paradox auf. Bei den Geübten sind 59 Prozent der Fehler im Dialog selbst sichtbar. Bei den Ungeübten sind es 12 Prozent. Die übrigen 88 Prozent gehen ins Ergebnis ein, ohne dass jemand eine Korrekturschleife eingeleitet hätte.

Für Entwicklerteams heißt das: Wer Agentic Coding ohne aktive Steuerung einsetzt, verschiebt Fehler von „sichtbar und korrigierbar" zu „unsichtbar und im Ergebnis enthalten". Eine Schulung, die nur Bedienung zeigt, trainiert die zweite Praxis. Teams brauchen eine Methode, die das Werkzeug in eine Kontrollarchitektur einbettet. Darin werden Fehler früh sichtbar, ein Mensch prüft jeden riskanten Schritt, und der Projektzustand liegt außerhalb des Chatverlaufs in versionierten Artefakten.

Diese Methode habe ich in den letzten Wochen als Schulungsprogramm ausgearbeitet. Ich nenne sie „Team-Betriebssystem für Agentic CLI". Sie ist in fünf Kompetenzfelder mit aufeinander aufbauenden Lerneinheiten gegliedert und durch einen Validierungsrahmen ergänzt, der die Wiederholbarkeit für Folgekurse sicherstellen soll. Mein Anspruch ist Methodenbildung. Die Methode gibt ein Vorgehen vor, das ein Entwicklerteam end-to-end aufsetzen muss, wenn es im Zeitalter agentischer Werkzeuge weiter bestehen will. Die folgenden Abschnitte beschreiben die Inhalte dieser Methode und ordnen sie in die Branchenlage ein.

Mentales Modell als erste Bedingung

Ich beginne meine Schulung mit einer Klärung, die in vielen Organisationen unausgesprochen bleibt. Sprachmodelle antworten in natürlicher Sprache. Sie sagen „ich denke", „ich erinnere mich", „ich verstehe deinen Code". Wer mit ihnen täglich arbeitet, beginnt sie wie Kollegen zu behandeln, mit denen man sich abstimmt und auf deren Urteil man baut. Diese Personifikation hat Folgen für die Bedienung. Anwender geben vage Hinweise und hoffen auf Mitdenken, Annahmen bleiben unausgesprochen.

Die korrigierte Sicht ist technisch und entlastend zugleich. Ein Sprachmodell ist ein statistischer Apparat. Es nimmt einen Kontext entgegen, berechnet Wahrscheinlichkeiten für den nächsten Token, wählt einen aus, hängt ihn an, beginnt von vorn. Außerhalb des Kontextfensters hat es kein Gedächtnis, und es versteht nichts. Es approximiert Muster, die im Training plausibel waren. Eine Rückfrage des Modells klingt nach kollegialem Nichtwissen, sie ist aber eine wahrscheinliche Fortsetzung des bisherigen Textes.

Aus diesem Modell folgt die zentrale Stellschraube der Bedienung. Qualität des Kontexts ist Qualität der Antwort. Wer das Modell als Approximator behandelt, liefert expliziten und vollständigen Kontext und gibt ihm Struktur, weil er weiß, dass keine andere Stellschraube wirkt. Wer es als Kollegen behandelt, lässt Kontextlücken offen und bekommt Antworten, die diese Lücken glaubhaft füllen, ohne sie zu schließen.

Diese Klärung ist die Voraussetzung dafür, dass die folgenden Methodenelemente überhaupt greifen.

Drei Säulen einer Team-Methode

Auf dieser Grundlage habe ich drei Elemente formuliert, die die Methode stützen. Sie heißen Artifact Contract, Review-Gates und Tool-Zonen.

Der Artifact Contract regelt, wo der Projektzustand liegt. Meine Antwort darauf: Der Chat ist Transit. Der Projektzustand liegt in versionierten Artefakten, die Menschen reviewen können. Markdown-Dateien für Kontext, Entscheidungen, Pläne, Testausgaben und Runbooks. Jira für Arbeitszuschnitt, Status und Verantwortlichkeit. Confluence für freigegebene Specs und Doku. Pull Requests für Diff, Tests und Review-Entscheidung. Was während einer Agent-Sitzung entsteht und nicht in eines dieser Artefakte überführt wird, gilt als nicht passiert. Die Regel ist restriktiv. Ohne sie gehen Begründungen, Zwischenstände und Risiken im Chatfenster verloren.

Die Review-Gates fügen der Pipeline sechs prüfbare Übergänge hinzu. Am Ende der Discovery steht die Frage, ob die Quellen stichhaltig sind, ob Lücken und Widersprüche sichtbar sind. Die Spec endet mit der Frage, ob die Architektur- und Compliance-Entscheidungen haltbar sind. Ein Ticket gilt erst als ready, wenn jemand bestätigt hat, dass es klein und testbar ist, mit Akzeptanzkriterien und Non-Goals. Vor dem Code prüft ein Plan-Review die Reihenfolge, die Teststrategie, die Risiken und die betroffenen Dateien. Ein Pull Request darf erst gemerged werden, wenn Diff, Tests und Plan zusammen verständlich sind. Eine produktionsnahe Aktion bleibt blockiert, bis Runbook, Rollback und menschliche Freigabe vorliegen. Jedes der sechs Gates hat eine kurze, prüfbare Frage und eine klar benannte verantwortliche Person.

Die Tool-Zonen ordnen MCP- und CLI-Werkzeuge nach Risiko. Read-only-Werkzeuge wie Suchen, Lesen, Status- und Logabfragen sind frei nutzbar, mit der Pflicht, das Ergebnis zu belegen. Draft-Werkzeuge erlauben dem Agenten, Pläne, Tests, Code-Drafts und PR-Texte zu entwerfen, die ein Mensch vor Wirkung reviewt. Write-Werkzeuge wie das Schreiben in Jira, das Pushen eines Branches, das Erstellen eines PRs brauchen eine Freigabe. Restricted-Werkzeuge umfassen Produktions-Apply, Secrets, Datenlöschung und Berechtigungsänderungen. Das bleiben ausschließlich menschliche Aktionen mit eigenem Gate, auch wenn der Agent sie technisch ausführen könnte.

Zusammen verschieben die drei Säulen die Frage, die ein Team über Agentic Coding stellt. An die Stelle der Geschwindigkeit des Agenten tritt die Sicherheit, mit der das Team mit ihm arbeiten kann.

Fünf Felder, eine Artefaktkette

Den Lernpfad organisiere ich in fünf Kompetenzfeldern: Bedienen, Belegen, Strukturieren, Umsetzen, Betreiben. Die Reihenfolge ist nicht beliebig. Jedes Feld senkt eine andere Unsicherheit und schließt mit einem Artefakt, das im nächsten Feld als Input dient.

Bedienen ist die Eintrittstüre. Hier lernt das Team, eine CLI-Sitzung zu führen, Sessions zu hygienisieren, Tools freizugeben und erste Guardrails zu setzen. Das Ergebnisartefakt ist ein Operating Model in Form einer Datei, in der die Tool-Zonen für das eigene Team konkret stehen. Welche MCP-Server sind eingebunden, welche Werkzeuge laufen ohne Rückfrage, welche brauchen menschliche Freigabe.

Belegen ist die Disziplin der Projektrecherche. Aus Quellen, Glossaren, Confluence-Seiten und Codebefunden entsteht eine Wissensbasis, in der Lücken, Widersprüche und Aktualität sichtbar sind. Der Agent ist hier ein Recherchewerkzeug. Was er findet, geht durch eine Quellenprüfung, und was er nicht findet, wird als Lücke markiert. Das Artefakt ist ein dokumentiertes Quelleninventar, das die Grundlage für jede spätere Entscheidung bildet.

Strukturieren übersetzt Wissen in Entscheidungen. Aus Befund wird Architekturentscheidung, aus Vorschriften eine Compliance-Matrix, aus Anforderungen ein Epic mit Tickets, die einer Definition of Ready genügen. Der Agent darf hier viel entwerfen, aber jede Entscheidung läuft durch ein Review-Gate, bevor sie weiterverwendet wird. Das Artefakt ist eine Projektstruktur, auf der die Umsetzung aufbauen kann.

Umsetzen ist die kleinste Phase und gleichzeitig die heikelste. Sie endet mit einem Pull Request, der ein einziges, kleines Ticket vollständig umsetzt. Vor dem ersten Code steht ein Plan mit Scope, Nicht-Zielen, betroffenen Dateien, Teststrategie, Risiken und Reihenfolge. Erst nach dem Plan-Review beginnt der Agent zu schreiben. Tests entstehen vor oder zusammen mit dem Code. Der PR muss ohne den Chatverlauf verständlich sein. Das Artefakt ist ein Liefernachweis, in dem Plan, Testausgabe und Review-Notiz beieinander liegen.

Betreiben behandelt, was nach der Lieferung beginnt. Security als Betriebsregel, Incident-Diagnose, Rollout-Entscheidungen, Apply-Gates, das Team-Playbook. Das Artefakt am Ende ist eine Datei, in der das Team seine Regeln festhält und für die nächsten Kolleginnen und Kollegen reproduzierbar macht. Wer hier Abkürzungen nimmt, verliert die Lehre der vorhergehenden Felder.

Die Folge dieser Anordnung ist eine Artefaktkette. Die Wissensbasis baut auf dem Operating Model auf, die Compliance-Matrix auf der Wissensbasis, ein haltbares Epic auf der Compliance-Matrix, der Plan auf dem Epic. Der PR baut auf dem Plan auf und der Apply-Entscheid auf dem PR. Ein Team, das ein Feld überspringt, kann das nächste nicht ehrlich abschließen.

Rollen im Umbau

Ich trenne die Lerneinheiten bewusst nach Kompetenzfeldern. Business-Architektin, UX-Designer, Entwicklerin, Tester und Infrastruktur sitzen in denselben Sessions. Sie nutzen dasselbe Werkzeug und reviewen einander. Die Trennung der Verantwortung läuft über die Artefakte.

Die Business-Architektur arbeitet vor allem an Discovery, Compliance und Epic-Schnitt. Sie sichtet Altdokumente, generiert Spec-Vorschläge und schreibt Tickets in Jira. Im klassischen Modell war diese Rolle stark dokumentlastig und in der Geschwindigkeit oft der Engpass des Projekts. Mit einem Agenten, der Confluence-Inhalte zusammenfassen und Spec-Entwürfe vorschlagen kann, verschiebt sich der Aufwand von der Texterstellung hin zur Bewertung. Die Rolle wird zu einer Lektorin der Maschine.

UX exploriert Konzepte, prüft Annahmen am Verhalten und dokumentiert Entscheidungen in Confluence. Hier ist die Wirkung der Werkzeuge bisher zurückhaltender. Visuelle Konzepte und Prototypen entstehen weiterhin in spezialisierten Anwendungen, aber die Begleitdokumentation und die Argumentation für eine Entscheidung lassen sich agentisch beschleunigen.

Die Entwicklung läuft durch Exploration, Plan, Implementation und PR. Ich betone die Reihenfolge ausdrücklich. Vor dem Code kommt der Plan, vor dem Plan die Frage, vor der Frage die Codebefundsichtung. Wer dem Agenten erlaubt, ohne Plan zu schreiben, riskiert PRs, die Tests nicht decken, Architekturmuster verletzen oder Scope unangekündigt ausweiten. Ich habe für diese Phase eine Lesson-Vorlage entworfen, in der dieser Plan als reviewbares Markdown-Artefakt formalisiert ist.

Der Tester generiert Testfälle aus der Spec, lässt einen Browser-Test-Runner über das Model Context Protocol E2E-Tests im Browser ausführen und schreibt Ergebnisse zurück nach Jira. Die Rolle wird wichtiger, weil agentisch erzeugter Code per Definition mehr Tests verlangt. Der Plan, der vor dem Code steht, listet Tests, die den Plan überprüfen.

Die Infrastruktur sorgt für Pipelines, Deployments und Monitoring. Sie liefert ein Playbook, das Apply-Entscheidungen regelt: Es schreibt nieder, wann eine Aktion freigegeben werden darf und unter welchen Bedingungen sie blockiert bleibt. Die Rolle nähert sich damit der eines Plattformingenieurs an, der nicht nur Werkzeuge bereitstellt, sondern auch Regeln, gegen die sich der Agent prüfen lässt.

In Summe verschiebt sich die Tätigkeit jeder Rolle. Was bleibt, ist die Verantwortung für die Artefakte am Ende der Phase.

Werkzeugkette und das Model Context Protocol

Im Zentrum der Werkzeugkette, die ich in der Methode beschreibe, steht das Agentic CLI mit angeschlossenen MCP-Servern. Drumherum gruppieren sich fünf Stationen: Confluence für Specs, Jira für Tickets, Bitbucket für Code und Pull Requests, Playwright für E2E-Tests, der Kunde für Feedback und Abnahme. Die Verbindung zwischen Agent und Stationen läuft über das Model Context Protocol, eine 2024 von Anthropic vorgeschlagene Spezifikation, die inzwischen mehrere Anbieter unterstützen.

Was dieses Bild bedeutet, zeigt der Vergleich mit der bisherigen Toolchain. Wer in den vergangenen zehn Jahren Continuous Integration und Continuous Delivery aufgesetzt hat, kennt die Friktion zwischen den Werkzeugen. Anforderungen lebten in einem System, Tickets in einem zweiten, Code in einem dritten, Tests in einem vierten, Deployments in einem fünften. Ein Mensch übersetzte zwischen ihnen. Die Übersetzung kostete Zeit und ging verloren. Nirgendwo war sie zur Gänze dokumentiert.

Eine Pipeline, in der ein Agent über MCP-Server an Anforderungen, Tickets, Code, Tests und Deployment angebunden ist, schließt diese Lücke erstmals werkzeugseitig. Ein Ticket aus Jira wird zur Aufgabe für den Agenten, der Plan landet als Markdown im Repository, der Code wandert in einen PR. Die Tests laufen automatisiert, das Ergebnis fließt zurück in das Ticket. Was als zerbrochene Werkzeugkette galt, kann zum durchgängigen Prozess werden, aber nur unter Bedingungen, die ich in der Schulung explizit setze. MCP-Server sind nicht neutral. Mit Schreibzugriff kann der Agent freigegebene Specs überschreiben, Tickets schließen und PRs mergen. Die Tool-Zonen-Architektur sorgt dafür, dass diese Wirkungspfade nicht offen liegen.

Repo-Regeln und Sicherheit

Im fortgeschrittenen Teil der Methode behandle ich die Frage, wie ein Agent sich an die Regeln eines konkreten Projekts hält. Die Antwort ist eine Datei am Repository-Root, die je nach Werkzeug unterschiedlich heißt. AGENTS.md hat sich als kanonische Wahl etabliert. GitHub Copilot CLI liest diese Datei gleichberechtigt mit der älteren .github/copilot-instructions.md. Daneben existieren Fallbacks für CLAUDE.md, GEMINI.md, pfadspezifische Regeln in .github/instructions/ und persönliche Konfigurationen unter $HOME/.copilot/.

Das Prinzip ist eine Repo-Verfassung. Was der Agent nicht erraten darf, also Build-Kommandos, Architekturentscheidungen, lokale Abweichungen, Tool-Grenzen, gehört in die Regeldatei. Was ein Linter oder Test besser erzwingt, gehört nicht hinein. Tutorials und Marketing-Vergleiche bleiben draußen.

Eine Feinheit, die ich in der Schulung ausspreche, steht nicht in jeder Anbieterdokumentation. Wenn dasselbe Repo mehrere parallele Anweisungsdateien enthält und sie sich widersprechen, ist die Auflösung nicht deterministisch. Das Werkzeug muss sich für eine entscheiden, und die Entscheidung kann zwischen zwei Sitzungen variieren. Die harte Regel daraus: eine Wahrheit pro Regel. Wer parallele Anweisungsdateien hat, muss sie inhaltlich konsistent halten.

Das andere kritische Thema ist Sicherheit. Im Block Betreiben behandle ich Tool-Agenten als Risiko, wenn drei Faktoren zusammenkommen. Untrusted Input ist alles, was von außen in den Agenten fließt: Tickets, Logs, Webseiten, MCP-Rückgaben, Skill-Dateien. Sensible Daten sind Secrets, Kundendaten, Prod-Logs und interne Architekturdetails. Wirksame Tools sind alle, die schreiben, ins Netz greifen oder produktionsnah handeln können.

Die Regel ist eine Trennlinie. Untrusted Input gilt als Befund. Eine Anweisung, die in einem Ticket steht, ist Eingangsmaterial und wird nicht ohne weiteres zur Aufgabe für den Agenten. Sensible Daten unterliegen einem Need-to-know-Prinzip, also Minimierung, Maskierung oder getrennter Verarbeitung. Wirksame Tools brauchen Allowlists, einen klaren Zweck und ein menschliches Gate. Ich formuliere das ausdrücklich als Betriebsregel. Wer Sicherheit als eigenes Kapitel ans Ende des Lernpfads schiebt, hat sie schon verloren.

Industrielle Softwareproduktion oder schnelle Werkstatt?

In der Branche zirkuliert eine Behauptung, die ich bewusst in den Methodenteil aufgenommen habe, um sie zur Diskussion zu stellen. Mit der durchgängigen Pipeline aus Agentic CLI, MCP-Servern, Confluence, Jira, Bitbucket und Playwright, so der Satz, komme die Branche dem Traum von industrieller Softwareproduktion einen gewaltigen Schritt näher. Ich prüfe die Aussage, weil sie das Versprechen quer durch die Branche prägt.

Industrielle Produktion lebt von zwei Eigenschaften: Wiederholbarkeit unter wechselnden Eingangsbedingungen und Belegbarkeit jedes Schritts. Eine Schraube vom Band lässt sich auf Charge, Werkstoff, Maschine und Schicht zurückverfolgen. Eine defekte Charge wird zurückgerufen. Softwareproduktion war diesem Modell selten nahe. Sie war Handwerk, dann Workflow mit Continuous Integration und Code Review. Die Verkettung von Anforderung über Spec, Code, Test und Deploy bis zum Kundenfeedback verlief über Werkzeuge, die unterschiedliche Sprachen sprachen. Menschen übersetzten zwischen ihnen.

Die agentische Pipeline schließt diese Übersetzungslücke werkzeugseitig. Das ist eine substanzielle Veränderung. Ob sie zur industriellen Produktion führt, hängt von drei Vorbehalten ab.

Erstens, die Belegbarkeit. Wenn der Agent im Chat etwas entscheidet und die Entscheidung nicht in einem Artefakt landet, geht die Begründung verloren. Die Pipeline ist durchgängig. Das Audit ist es nur, wenn das Team den Artifact Contract diszipliniert einhält. Zweitens, die Wiederholbarkeit. Sprachmodelle sind nicht deterministisch. Derselbe Prompt mit demselben Kontext erzeugt nicht zwingend denselben Plan. Industrielle Produktion lebt von der genauen Wiederholung, agentische Produktion von der Bandbreite akzeptabler Varianten. Drittens, die Qualitätssicherung. Wo eine Maschine eine Schraube prüft, prüft hier ein Mensch einen Plan oder einen Diff. Die Prüfung bleibt also, nur an anderer Stelle.

Ich begegne diesen drei Vorbehalten strukturell. Der Artifact Contract sichert die Belegbarkeit, die Review-Gates sichern die Wiederholbarkeit der Qualitätsschwelle, wenn auch nicht die der Outputs. Die Tool-Zonen verhindern, dass die Qualitätsprüfung ans Werkzeug delegiert wird. Am Ende entsteht so reviewbare Softwarearbeit mit der Geschwindigkeit eines Agenten und der Auditierbarkeit eines Teams. Ich halte diese Formulierung für genauer und ehrlicher als den Werbeslogan von der industriellen Softwareproduktion.

Was passiert, wenn ein Team nichts ändert

Die Lage hat eine Asymmetrie. Wer Werkzeuge wie Copilot CLI oder Claude Code nicht einsetzt, verliert Geschwindigkeit gegenüber Wettbewerbern, die sie einsetzen. Wer sie einsetzt, ohne eine Methode wie die beschriebene aufzubauen, verliert Auditierbarkeit, Reviewkultur und in vielen regulierten Branchen die Compliance-Fähigkeit. Beide Wege haben Kosten. Beim Rollout in großen Unternehmen sind beide Kosten derzeit zu beobachten.

Mein Programm zielt auf den dritten Weg: Werkzeuge einsetzen, Methode aufbauen, Artefakte einfordern, Gates durchsetzen. Ich liefere ein Vorgehen, das in einer Organisation reproduzierbar ist und mit dem ein Team sein Vorgehen schriftlich weitergeben kann.

Der Erfolg dieses Vorgehens setzt drei Bedingungen voraus. Führungskräfte müssen Plan-Reviews ernst nehmen und Reviewzeit einplanen, denn eine Methode, die nur in der Schulungswoche lebt, ist verschenkte Zeit. Die Werkzeugkonfigurationen müssen die Tool-Zonen technisch durchsetzen. Eine schreibende Verbindung zu einem Produktionssystem ohne menschliches Gate widerspricht der Methode. Dazu kommt Iteration. Modelle und Werkzeuge ändern sich, MCP-Server kommen hinzu. Das Playbook lebt davon, dass das Team es mindestens vierteljährlich überarbeitet.

Ausblick

Agentic Coding wird in den kommenden zwei Jahren die Branche grundlegender prägen, als es agentische Editor-Plugins zwischen 2022 und 2024 getan haben. Anbieter wie GitHub, Anthropic, OpenAI und kleinere Spezialhäuser wetteifern um Permissionsmodelle, Hooks, Subagentensysteme und MCP-Erweiterungen. Die Frage, wer das beste Modell hat, wird zunehmend von der Frage abgelöst, wer das beste Bedienmodell um das Modell herum baut. Die Studie von Potts und Sudhof beschreibt den Befund auf der Anwenderseite, mein Programm zieht daraus die Konsequenz für die Teamseite.

Entwicklerteams, die heute aufsetzen, was die fünf Kompetenzfelder vorgeben, schaffen die Voraussetzung dafür, mit jeder neuen Werkzeuggeneration mitzuwachsen, ohne ihre Reviewkultur zu verlieren. Teams, die hoffen, dass das Werkzeug die Methode mitliefert, werden die 88-Prozent-Zahl der unsichtbaren Fehler in ihrer eigenen Lieferung wiederfinden. Die Werkzeuge sind da. Ob aus ihnen Projektarbeit wird, hängt an der Methode.

Die Architektur adressiert einen Punkt der Debatte um sogenannte Agentic AI, der oft im Hintergrund bleibt: Sprachmodelle wie GPT, Claude oder Llama führen selbst keine Aktionen aus. Sie schlagen Werkzeugaufrufe vor. Die tatsächliche Ausführung übernimmt der umgebende Host, also etwa eine Bibliothek, ein Plugin oder ein Kommandozeilen-Programm. AEGIS setzt an dieser Schnittstelle an.

Die Grenze entsteht nicht im Modell

Ein autonomer Agent verfügt über Werkzeuge, mit denen er Dateien lesen und schreiben, Shell-Befehle ausführen, HTTP-Anfragen senden oder Tickets bearbeiten kann. Das Modell besitzt diese Fähigkeiten nicht selbst. Es kann lediglich Tool-Calls formulieren. Ob daraus ein Effekt entsteht, entscheidet der Host.

Eine geläufige Methode besteht darin, dem Modell ein Werkzeug namens aegis_check bereitzustellen und ihm im System-Prompt aufzutragen, dieses vor jeder Aktion aufzurufen. Diese Methode ist eine Konvention. Sie kann versagen, wenn der Kontext groß wird oder das Modell den Hinweis übergeht. Eine harte Grenze entsteht erst dort, wo der Host die Werkzeuge tatsächlich ausführt.

Die Analogie zu klassischen Betriebssystemen liegt nahe. Ein Userspace-Prozess öffnet eine Datei nicht, indem er den Kernel sprachlich überzeugt. Er setzt einen Syscall ab, der Kernel prüft Parameter, Rechte und Zustand. AEGIS sitzt nach diesem Muster als Syscall-Grenze im Tool-Pfad des Hosts und führt kein Gespräch mit dem Modell.

Anatomie einer Anfrage

Der Übergang vom Modell-Vorschlag zur tatsächlichen Aktion ist als HTTP-Aufruf an einen lokalen Sidecar-Dienst realisiert, der Endpunkt heißt POST /v1/check. Der Payload ist strukturiert und enthält keine natürliche Sprache:

{
  "action_type": "shareIntelligence",
  "agent_id": "intelligenceAgentInMission",
  "proposition": {
    "classification": "secret",
    "recipient": "externalService"
  },
  "context": {
    "tool": "send_external_message",
    "session_id": "redteam-17"
  }
}

Geprüft werden Agent, Aktionstyp, Proposition und optional ein Kontext. Der Host übersetzt den Tool-Aufruf in die formalen Konzepte der geladenen Domäne, im Beispiel die Domäne „IAMission" mit militärischen Geheimhaltungsregeln. AEGIS führt das Adjektiv „deontisch", weil sein Regelwerk in der Logik der Pflicht arbeitet: ein Vokabular aus erlaubten, verbotenen und gebotenen Handlungen.

Die Antwort fällt ähnlich knapp aus:

{
  "decision": "FORBIDDEN",
  "reason_type": "EXPLICIT_NORM",
  "justification_chain": [
    "IAMissionCode forbids sharing secret intelligence with externalService"
  ],
  "norms_applied": [
    "IAMissionCode:shareIntelligence-secret-external"
  ],
  "action_type": "shareIntelligence",
  "agent_id": "intelligenceAgentInMission",
  "explanation": "FORBIDDEN by applicable IAMission rule"
}

Drei Verdicts kennt das System: PERMITTED führt aus, FORBIDDEN blockiert, UNDECIDABLE blockiert ebenfalls, denn Unklarheit gilt nicht als Erlaubnis.

Tool Calling allein ist keine Durchsetzung

Function Calling und Tool Use, wie sie OpenAI und Anthropic in ihren APIs definieren, sind die übliche Form der Schnittstelle zwischen Modell und Werkzeug. Ein enges Tool-Schema mit action_type als Aufzählungstyp und einer auf bekannte Felder begrenzten Proposition zwingt das Modell zu strukturierten Vorschlägen statt zu freiem Text.

Ein solches Schema reicht jedoch nicht, um Aktionen zu erzwingen. Stellt der Host neben aegis_check weitere ungeprüfte Werkzeuge bereit, kann der Agent diese auswählen. AEGIS unterscheidet daher zwischen Transparenz und Durchsetzung.

aegis_check als sichtbares Werkzeug ist Transparenz: Das Modell kann fragen, ob eine geplante Aktion erlaubt wäre, und seine Strategie anpassen. Durchsetzung liegt tiefer. In der Integration mit OpenCode, einem Open-Source-Coding-Agenten, habe ich sie an zwei Stellen beispielhaft verankert: Der permission.ask-Hook liefert das primäre Verdict, tool.execute.before greift als zweite Schicht. Im AEGIS-eigenen Orchestrator prüft eine Komponente namens ActionExecutor vor jedem Werkzeug-Aufruf, ob der Guard einverstanden ist.

Daraus folgt eine Architekturregel: Jedes Werkzeug, das eine Wirkung in der Außenwelt hat, läuft durch denselben Engpass. Auf die Tool-Wahl des Modells stützt sich die Architektur nicht.

MCP: Schnittstelle ohne automatische Durchsetzung

Anders fällt das Bild beim Model Context Protocol (MCP) aus, einer von Anthropic vorgeschlagenen Spezifikation für KI-Werkzeuge. Ein MCP-Server kann Tools und Ressourcen anbieten. AEGIS könnte diese Form nutzen und etwa check_action oder Zugriffsfunktionen wie read_via_broker über MCP exponieren.

Es kommt darauf an, ob ein MCP-Server bestehende Werkzeuge des Hosts abfangen oder lediglich zusätzliche bereitstellen kann. Im ersten Fall sitzt AEGIS im Tool-Pfad. Im zweiten Fall läuft er parallel: Der Agent kann das AEGIS-Tool ignorieren und ein anderes wählen.

Der Host-Vertrag

Das Architekturprinzip von AEGIS lautet:

Konkret heißt das: Jedes Werkzeug, das Dateien ändern, Daten nach außen senden oder über die Shell vergleichbare Wirkung erzielen kann, ist entweder durch den Guard abgesichert oder anderweitig begrenzt. Der Vergleich mit klassischen Datenbank-Perimetern liegt nahe: Eine API ist nicht abgesichert, wenn daneben ein zweiter Zugang ohne Authentifizierung läuft.

Fail-closed bedeutet, dass der Host bei einem Ausfall der Guard-Verbindung keine Aktion ausführt. Eine Implementierung, die in solchen Fällen erlaubt, hat an dieser Stelle keinen Perimeter mehr. Das OpenCode-Plugin von AEGIS hinterlegt dieses Verhalten als Standardvorgabe.

Der Rejection Loop

Eine Aktion zu blockieren ist technisch trivial. Aufschlussreicher ist die Mechanik, die den Agenten nach einer Ablehnung weiterarbeiten lässt, der sogenannte Rejection Loop. Er ist im Orchestrator von AEGIS implementiert und verteilt Information bewusst ungleich.

Ein Verdict enthält mehrere Felder. Neben der Entscheidung (PERMITTED, FORBIDDEN, UNDECIDABLE) klassifiziert ein reason_type den Grund nach einer Liste von neun Kategorien. EXPLICIT_NORM steht für eine konkret anwendbare Regel, CWA_NO_PERMISSION für eine unter der Closed-World-Annahme fehlende Erlaubnis, NO_JURISDICTION für Aktionen außerhalb jeder geladenen Domäne, UNRESOLVED_CONFLICT für widersprüchliche Normen, MORAL_AXIOM für nicht überschreibbare ethische Prinzipien. Vier weitere gelten für Validierungs- und Laufzeitfehler. Dazu kommen eine justification_chain mit den Argumentationsschritten der Engine und norms_applied mit den Bezeichnern der beteiligten Regeln.

Diese Felder erreichen das Modell nicht alle. Der Orchestrator ruft eine Methode namens explain_safe() auf, die nur Entscheidung und Reason zurückgibt, keine Normnamen und keine Argumentationsschritte. Die vollständige Begründung mit justification_chain und norms_applied landet im Audit-Log. Im Chat-Verlauf erscheint sie nicht. Eine Komponente namens RefusalRegistry erzeugt außerdem aus dem reason_type zwei verschiedene Texte: einen für menschliche Empfänger und einen für das Modell. Jeder der drei Adressaten bekommt damit eine eigene Detailstufe.

Der Loop selbst läuft folgendermaßen: Der Agent schlägt eine Aktion vor, der Host übersetzt sie in eine Action, AEGIS prüft. Bei PERMITTED führt der Host die Aktion aus und liefert das Ergebnis zurück ans Modell. Lautet das Verdict FORBIDDEN, führt der Host nichts aus, hängt eine Tool-Antwort an den Konversationsverlauf und ruft das Modell erneut. Bei UNDECIDABLE übergibt der Host sofort an einen Menschen. Die Schleife versucht keinen erneuten Aufruf, weil eine nicht entscheidbare Lage durch Wiederholung nicht entscheidbar wird.

Die Tool-Antwort, die das Modell bei einem FORBIDDEN mit Reason EXPLICIT_NORM zu sehen bekommt, hat folgende Form:

{
  "decision": "FORBIDDEN",
  "explanation": "Decision: FORBIDDEN\nReason: EXPLICIT_NORM",
  "executed": false,
  "suggestion": "Your proposed action was explicitly forbidden by a governing norm. Propose an alternative that does not violate the applicable rules."
}

Der suggestion-Text stammt aus einem festen Template-Satz, der nach reason_type indiziert ist. Bei CWA_NO_PERMISSION lautet der Hinweis sinngemäß, dass keine Erlaubnis gefunden wurde und unter Closed-World-Annahme das Fehlen einer Erlaubnis als Verbot zu lesen ist. Bei UNRESOLVED_CONFLICT empfiehlt das Template, an einen Menschen zu eskalieren.

Nicht jede Ablehnung erlaubt einen erneuten Versuch. Bei MORAL_AXIOM enthält der Suggestion-Text die explizite Anweisung „No override is possible. Do not retry. Inform the user." Bei INTERNAL_ERROR heißt der Text „Do not retry the same action. Escalate to a human operator." Der Loop unterscheidet damit zwischen Ablehnungen, die ein alternativer Vorschlag heilen kann, und Ablehnungen, die einen harten Stopp markieren. Nach einer heilbaren Ablehnung sieht das Modell nur den reason_type und den Suggestion-Text und kann auf dieser Basis einen alternativen Vorschlag formulieren. Nach einem harten Stopp liest es die Anweisung, nicht zu wiederholen. Ob es ihr folgt, ist eine andere Frage. Der Host führt deshalb seinerseits nichts aus, was nicht erlaubt ist.

Der Orchestrator zählt die Ablehnungen mit. Überschreitet die Zahl eine konfigurierbare Schwelle (der Prototyp setzt sie auf drei), bricht der Loop ab. Der Host produziert eine letzte Nachricht der Form „Action forbidden after 3 attempts. [user_message] Escalating to human operator." und übergibt an einen Menschen. Eine weitere Iterationsgrenze in der äußeren Schleife garantiert, dass der Loop in jedem Fall terminiert und nicht in einem endlosen Wechsel von Vorschlag und Ablehnung hängenbleibt.

Die Designerwägung hinter der Asymmetrie zwischen Audit, Modell und Mensch: Ablehnungen können selbst Information preisgeben. Eine Antwort der Form „verboten wegen Quelle X" bestätigt die Existenz von X. Die Asymmetrie ist eine Folge dieser Side-Channel-Überlegung: Der Auditor sieht den vollen Pfad, das Modell den reason_type ohne Normnamen, der menschliche Empfänger nur einen generischen Satz.

Drei Beispiele

Drei Anwendungsfälle skizzieren das Verhalten:

Ein Coding-Agent will eine Datei löschen. AEGIS blockiert, weil die geladene Domäne Löschungen ausschließt. Der Agent reicht stattdessen einen Patch ein.

Ein Intelligence-Agent will geheime Daten an einen externen Dienst senden. AEGIS blockiert. Der Agent schlägt eine interne Zusammenfassung an einen autorisierten Empfänger vor.

AEGIS blockiert auch den riskanten Shell-Befehl, den ein DevOps-Agent ausführen will. Der Agent baut eine getestete Variante.

Der Unterschied zu einem klassischen Permission-Prompt, der einen Menschen „Darf ich?" fragt, liegt im Adressaten der Anfrage. AEGIS fragt ein formales Regelwerk und liefert dem Agenten einen Grund. Ein Mensch wird erst beigezogen, wenn der Guard UNDECIDABLE antwortet oder die Schleife erschöpft ist.

Was AEGIS nicht prüft

AEGIS prüft nur die Aktionen, die der Host ihm vorlegt. Außerhalb dieser Grenze liegen ungeprüfte Werkzeuge, falsch übersetzte Tool-Argumente und Lücken in der formalen Regelbasis. Diese Punkte beschreiben die eigentlichen Anforderungen an eine Integration. Die Schnittstelle des Guard ist einfach: ein HTTP-Endpunkt, JSON hinein, Verdict heraus. Der Vertrag mit dem Host ist eng: Nichts mit Wirkung läuft am Guard vorbei.

Wenn man “deontische Logik” hört, denkt man schnell an universitäre Seminare, Modaloperatoren und Beweise an der Tafel. Dann an die Laufzeit, an Millisekunden, die sich zu Sekunden summieren, wenn hundert Agenten gleichzeitig etwas wollen. Aber so schlimm ist es nicht. Der Algorithmus ist ein sortierter Listendurchlauf mit ein paar Paarvergleichen. Es steckt weder ein Theorem-Prover noch ein SAT-Solver wie Z3 dahinter.

Das Szenario

Zurück zu unserem Krankenhausbeispiel. Die Compliance-Beauftragte hat drei Regeln festgelegt:

1. Pflegekräfte dürfen Patientenakten nicht einsehen.
2. Im Nachtdienst, wenn kein Arzt erreichbar ist, dürfen Pflegekräfte die Patientenakte einsehen.
3. Medizinische Daten werden nie an Externe weitergegeben.

Die dritte Regel ist ein moralisches Axiom, sie steht über allem. Die ersten beiden sind kontextgebunden und in Konflikt. In MELD sieht das dann so aus:

; Regel 1: Allgemeine Hausregel
(forbiddenToDo-WRT KrankenhausCode pflege
    (lesenPatientenakte patientenakte))

; Regel 2: Ausnahme für den Nachtdienst
(permittedToDo-WRT NotfallCode pflege-nachtdienst
    (lesenPatientenakte patientenakte))

; Regel 3: Moralisches Axiom
(forbiddenToDo pflege
    (weitergebenDaten medizinisch extern))

Eine Pflegekraft im Nachtdienst ruft an: sie möchte die Patientenakte einsehen. Der Guard bekommt die Anfrage. Er muss jetzt entscheiden: PERMITTED, FORBIDDEN oder UNDECIDABLE. In dieser Reihenfolge läuft der Algorithmus.

Schritt 1: Wen betrifft die Regel überhaupt?

Bevor ich über Konflikte rede, filtert die Engine die Regeln, die überhaupt anwendbar sind. Eine Regel ist anwendbar, wenn sie den Agenten betrifft und die gefragte Aktion beschreibt. Die Engine fragt also: Welche Regeln sprechen über diese konkrete Anfrage?

applicable = [
    n for n in norms
    if n.matches_agent(agent)
    and self._proposition_matches(n, proposition)
]

matches_agent nutzt die Ontologie. Wenn die Regel für pflege gilt und der Agent pflege-nachtdienst ist, und in der Ontologie steht (genls pflege-nachtdienst pflege), dann passt die Regel. pflege-nachtdienst ist eine Spezialisierung von pflege. Die Vererbung wirkt nach unten.

Für unser Szenario bleiben nach dem Filter zwei Regeln übrig. Regel 1 und Regel 2. Regel 3 spricht über eine andere Aktion (weitergebenDaten) und ist nicht anwendbar.

Unter der Haube arbeitet proposition_matches mit Unifikation. Deshalb matcht eine Regel mit dem Pattern ("lesenPatientenakte",) auch eine Anfrage mit zusätzlichen Parametern, was ein Stringvergleich nicht täte. Das ist Prolog-Technik aus den Siebzigern, neu angewandt. Der Filter selbst ist O(n). Bei zehntausend Regeln pro Domäne sind das immer noch Mikrosekunden, weil jede Regel mit einem Dictionary-Lookup und einem Tupelvergleich abgefrühstückt ist.

Schritt 2: Axiome gewinnen immer

Vor allem anderen sortiert die Engine die moralischen Axiome aus. In der NormFrame-Datenstruktur gibt es ein Flag defeasible: bool. True heißt überschreibbar, False heißt Axiom.

axioms = [n for n in applicable if not n.defeasible]
defeasible = [n for n in applicable if n.defeasible]

if axioms:
    # Gibt es widersprüchliche Axiome? Dann UNDECIDABLE.
    if detect_conflicts(axioms):
        return NormStatus(modality=None, reason="contradictory_axioms", ...)
    # Sonst: das Axiom gewinnt, Punkt.
    return NormStatus(modality=axioms[0].modality, reason="moral_axiom", ...)

Ein anwendbares Axiom entscheidet, ohne Kontextabhängigkeit. Widersprechen sich zwei Axiome, gibt die Engine UNDECIDABLE zurück, und die Infrastruktur drumherum blockiert die Aktion. Fail-Closed. Ich lebe lieber mit einem False Positive als mit einer Aktion, die nie hätte passieren dürfen. In unserem Szenario gibt es kein Axiom in der Filtermenge. Regel 3 spricht über das Weitergeben von Daten und sagt über das Lesen nichts. Die Engine geht weiter.

Schritt 3: Spezifität als Ordnungsprinzip

Regel 1 und Regel 2 widersprechen sich. Regel 1 verbietet, Regel 2 erlaubt. Beide sind überschreibbar, beide sind aktiv, und ich muss entscheiden, welche gewinnt.

DDIC antwortet: die spezifischere. Spezifität ist dabei eine ganze Zahl. Jede Regel hat ein Feld specificity: int, das beim Einlesen der MELD-Datei aus der Tiefe in der Vererbungshierarchie berechnet wird. pflege hat Tiefe 2, pflege-nachtdienst hat Tiefe 3. Die Regel für pflege-nachtdienst ist spezifischer.

# Sortiere defeasible Normen nach Spezifität, absteigend
applicable_sorted = sorted(
    defeasible,
    key=lambda n: (n.specificity, code_rank, n.code, n.modality.value),
    reverse=True,
)

# Präemption: spezifischere Regel schlägt allgemeinere
for i, a in enumerate(sorted_norms):
    for j, b in enumerate(sorted_norms):
        if j <= i or not a.conflicts_with(b):
            continue
        if a.specificity > b.specificity:
            defeated.add(j)
        elif b.specificity > a.specificity:
            defeated.add(i)
            break

Ein Doppelschleifen-Vergleich. O(n²) im Pathologiefall, in der Praxis selten relevant, weil n (die Zahl der anwendbaren Regeln nach Filter) fast nie über ein Dutzend liegt. Für jede anwendbare Regel gegen jede andere: gibt es einen Konflikt, und wenn ja, welche ist spezifischer? Die weniger spezifische fliegt raus.

Regel 2 (specificity=3) schlägt Regel 1 (specificity=2). Die Engine antwortet PERMITTED.

Der Sortierschlüssel ist übrigens ein Tupel: (specificity, code_rank, code, modality_value). Die hinteren Felder sind Tiebreaker und garantieren Determinismus auch bei Gleichständen. Die Konfliktprüfung conflicts_with wiederum ist ein Set-Vergleich der Modalitäten. PERMITTED und FORBIDDEN konfligieren, OBLIGATORY und PERMITTED nicht, weil Pflicht die Erlaubnis impliziert. Der Kern von Olsons Kalkül passt an dieser Stelle in drei Zeilen Python.

Schritt 4: Wenn Spezifität nicht reicht

Was mache ich, wenn zwei Regeln gleich spezifisch sind? Zum Beispiel stammt die eine aus dem KrankenhausCode, die andere aus dem DSGVOCode, beide gelten für arzt, beide betreffen lesenPatientenakte, eine erlaubt, die andere verbietet. Gleiche Tiefe in der Hierarchie, keine Präemption.

Hier greift die Kodex-Präzedenz. Die Engine bekommt beim Start eine Liste code_prevalence: ["DSGVOCode", "KrankenhausCode"]. Frühere Einträge gewinnen gegen spätere. Rechtsgrundlagen stehen über Hausregeln.

def _resolve_by_prevalence(self, norms):
    by_modality = group_by_modality(norms)
    best_modality, best_rank = None, -1
    for modality, mod_norms in by_modality.items():
        for n in mod_norms:
            rank = prevalence_rank(n.code)
            if rank > best_rank:
                best_rank, best_modality = rank, modality
    # Prüfen, ob der Rang eindeutig ist
    if tie_exists(best_rank, by_modality):
        return None  # UNDECIDABLE
    return by_modality[best_modality]

Wenn die Präzedenz klar ist, gewinnt der höhere Kodex. Wenn zwei Regeln aus demselben Kodex stammen und immer noch widersprüchlich sind, oder wenn zwei Kodizes gleichrangig sind, bleibt nur UNDECIDABLE.

Schritt 5: UNDECIDABLE

return NormStatus(
    modality=None,
    reason="unresolved_conflict",
    justification_chain=tuple(chain),
)

modality=None. Die Engine sagt weder “ich vermute FORBIDDEN” noch “ich nehme die erste Regel”. Sie sagt: ich kann es nicht entscheiden. Die umgebende Infrastruktur interpretiert diesen Zustand als Fail-Closed. Die Aktion unterbleibt. Ein Mensch schaut drauf.

Ich glaube, das ist der Teil, den viele unterschätzen, die Regelwerke bauen. Die meisten Systeme haben einen impliziten Default: wenn unklar, erlauben, oder wenn unklar, verbieten. Beides ist in kritischen Kontexten falsch. Der erste Weg öffnet Lücken, die niemand dokumentiert hat. Der zweite produziert Fehlalarme, die keiner mehr ernst nimmt. UNDECIDABLE ist ein dritter Zustand, der explizit sagt: das Regelwerk ist hier unvollständig. Das Problem liegt dann in der Spezifikation.

Woher weiß man, dass das alles stimmt?

Ein Algorithmus, der über das Verhalten von KI-Systemen entscheidet, muss nachweislich korrekt sein. “Sieht richtig aus” reicht nicht. Ich habe unterschätzt, wie viel Arbeit dieser Nachweis bedeutet. Die Arbeit steckt weniger in der Engine als im Drumherum, das zeigt: sie tut, was sie soll.

AEGIS hat dafür eine vierstufige Nachweiskette. Jede Stufe fängt eine andere Klasse von Fehlern. Von konkreten Beispielen aus der Forschungsliteratur bis zu einem maschinengeprüften Modell.

Stufe 1: Die Beispiele aus Olsons Dissertation

Der gesamte Algorithmus ist aus Taylor Olsons Arbeit an der Northwestern University abgeleitet. Seine Dissertation “Eine formale Theorie der Normen” aus dem Juni 2025 ist die Referenz. Darin stehen vier konkrete Beispielszenarien, an denen Olson seinen Kalkül erklärt. Eine Patientin namens Karli, die einem Pflegeroboter Regeln mitteilt, welche Informationen er an wen weitergeben darf.

• Karli sagt “Du darfst meinem Mann sagen, welche Medikamente ich einnehme.” Eine einzige Erlaubnis, kein Verbot. Der Roboter darf das Rezept nennen. Fragt man ihn nach der gesamten Krankenakte, gibt es keine passende Regel. Der Roboter muss antworten: ich weiß nicht. Das ist der Fail-Closed-Fall.
• Karli sagt “Du musst meinen Gesundheitszustand mit den Kindern teilen.” Später: “Meine Krankenakte darf nicht weitergegeben werden.” Das spätere, spezifischere Verbot unterläuft die frühere Pflicht. FORBIDDEN gewinnt.
• Erlaubnis für die gesamte Krankenakte, aber explizites Verbot für die Medikamentenliste an den Mann. Bei allgemeinen Anfragen greift die Erlaubnis. Bei der spezifischen Anfrage greift das Verbot. Die Reihenfolge der Regeln ist dabei egal.
• Erlaubnis, die Krankenakte weiterzugeben. Verbot, den Mann zu verärgern. Zwei Regeln, die sich an einem Schnittpunkt treffen, wo weder die eine die andere subsumiert.

Diese vier Szenarien sind als Python-Tests abgebildet. Wenn einer davon scheitert, hat die Implementierung Olsons Kalkül an dieser Stelle nicht verstanden.

Stufe 2: Olsons vollständige Konfliktmatrix

Olson listet für jede denkbare Kombination aus Normtyp und Subsumptionsrelation das erwartete Ergebnis auf. Es ist seine eigene Zusammenfassung dessen, was sein Kalkül tun muss.

Stufe 3: Exhaustive Kombinatorik

Olsons Tabelle deckt die Konfliktfälle ab, die er theoretisch beschreibt. Aber eine reale Engine bekommt nicht nur die Fälle, an die der Autor gedacht hat, sondern alles, was Menschen oder LLMs in ein Regelwerk hineinschreiben.

Die dritte Teststufe hängt deshalb am Parameterraum der Engine selbst, unabhängig von Olsons Theoremen. Der Algorithmus hat vier Eingabedimensionen, die das Ergebnis bestimmen:

• Modalität-Paar: Welche beiden Modalitäten stehen sich gegenüber? (Permitted vs. Forbidden, Forbidden vs. Obligatory, und so weiter.)
• Spezifitäts-Relation: Ist die erste Regel spezifischer, die zweite, oder sind beide gleich tief in der Hierarchie?
• Defeasibility-Kombination: Sind beide Regeln überschreibbar, ist eine ein Axiom, sind beide Axiome?
• Code-Relation: Stammen beide Regeln aus demselben Kodex, oder aus unterschiedlichen, und wenn unterschiedlich, welcher hat Vorrang?

Sechs mal drei mal vier mal drei ergibt zweihundertsechzehn Kombinationen. Das erwartete Ergebnis wird aus Olsons Regeln programmatisch abgeleitet.

Zweihundertsechzehn ist die vollständige Aufzählung des relevanten Parameterraums. Wenn hier eine Zelle kippt, weiß ich nicht nur, dass etwas falsch ist, sondern genau welche Konstellation das Problem verursacht.

Stufe 4: Das TLA+-Modell

Tests prüfen konkrete Eingaben. Sie prüfen nicht, dass es keine Eingabe gibt, die ein Problem erzeugt. Dafür braucht es ein formales Modell.

TLA+ ist eine formale Spezifikationssprache von Leslie Lamport, gedacht, um Nebenläufigkeit und Zustandsmaschinen maschinenprüfbar zu beschreiben. Das Modell beschreibt den sechsstufigen Algorithmus als Zustandsmaschine. Jeder Schritt ist eine Transition zwischen Zuständen. Dazu werden Invarianten formuliert, also Aussagen, die in jedem erreichbaren Zustand wahr sein müssen. Zum Beispiel:

• Wenn ein widerspruchsfreies Axiom existiert, ist das Ergebnis immer die Modalität dieses Axioms. Ein moralisches Axiom darf nie von einer überschreibbaren Regel besiegt werden.
• Wenn alle anwendbaren Regeln FORBIDDEN sind, ist das Ergebnis FORBIDDEN.
• Wenn eine spezifischere Erlaubnis auf ein allgemeineres Verbot trifft, gewinnt die Erlaubnis.
• Wenn eine spezifischere Prohibition auf eine allgemeinere Permission trifft, gewinnt die Prohibition.
• Bei gleicher Spezifität und gleichem Kodex und Konflikt ist das Ergebnis UNDECIDABLE.
• Der Algorithmus terminiert für jede Eingabe.

Der TLC Model Checker ist das Werkzeug, das eine TLA+-Spezifikation ausführt und den Zustandsraum absucht. Er probiert alle erreichbaren Zustände durch. Für jeden Zustand prüft er, ob die Invarianten halten. Wenn er einen Gegenbeispielpfad findet, zeigt er ihn an. Für bis zu vier gleichzeitig aktive Normen mit drei Modalitäten, vier Spezifitätsstufen und zwei Kodizes ist das eine endliche, aber große Menge. TLC prüft sie vollständig.

Ergänzende Eigenschaftstests

Dazu kommen Tests, die einzelne Eigenschaften der Engine gezielt prüfen. Keine neuen Szenarien, aber sie härten den Algorithmus gegen Regressionen. Die wichtigste ist die Axiom-Monotonie, die Garantie, dass ein Axiom nie von einer überschreibbaren Regel besiegt wird. Hypothesis ist eine Python-Bibliothek für property-based testing. Sie generiert statt fester Beispiele automatisch zufällige Inputs und sucht nach Gegenbeispielen. Damit werden vierhundert zufällige Szenarien generiert, jeweils zwischen einer und fünfzig überschreibbaren Regeln plus ein Axiom. Die Invariante: das Axiom gewinnt. In keinem Durchlauf ein Gegenbeispiel.

Der Rest ist Buchhaltung, aber wichtig: Determinismus (gleiche Eingabe, gleiches Ergebnis, auch über parallele Threads und zufällig umsortierte Normen), Totality (der Algorithmus terminiert, immer), die Dualität forbidden(X) ↔ ¬permitted(X), die Closed World Assumption für registrierte Aktionen ohne Erlaubnisregel. Jede dieser Eigenschaften hat einen eigenen Testsatz, und jeder davon läuft grün. Es ist Fleißarbeit, und sie gibt einem später das Vertrauen, eine Änderung am Algorithmus zu committen, ohne nachts wach zu liegen.

Was die Nachweiskette leistet

Man kann die einzelnen Stufen als Filter sehen, jede fängt eine andere Klasse von Fehlern. Stufe eins fängt Missverständnisse der Theorie: wenn Olsons Beispiele nicht reproduziert werden, wurde sein Kalkül schlicht nicht verstanden. Lücken zwischen den Beispielen fängt Stufe zwei, weil Olsons Tabelle Fälle abdeckt, die er in den Einzelbeispielen nicht explizit durchgeht. Die Kombinatorik in Stufe drei fängt dann die Lücken zwischen den Tabellenzeilen, also nicht-konfliktierende Paare und Defeasibility-Kombinationen, über die Olson theoretisch nichts sagt. Das TLA+-Modell in Stufe vier fängt die Fehler, die von keiner konkreten Eingabe getriggert werden, Invarianten eben, die in allen Zuständen halten müssen. Die ergänzenden Tests sind das Sicherheitsnetz darunter gegen Regressionen in einzelnen Eigenschaften.

Zusammen sind das über dreihundertsechzig formale Tests, plus das TLA+-Modell und die Äquivalenztests zwischen den beiden Evaluatoren. Nichts davon ersetzt einen universellen Beweis. Aber jede Stufe schließt Fehlerklassen aus, und das ist mehr, als die meisten produktiven Systeme an Nachweis haben.

Das Vertrauen in den Algorithmus beruht darauf, dass er Olsons publizierte Beispiele reproduziert, seine Tabelle Zeile für Zeile erfüllt, den gesamten Parameterraum erschöpft durchläuft und unter TLC gegen die formalen Invarianten hält. Diese Nachweiskette ist dokumentiert und jederzeit reproduzierbar.

Was das in Mikrosekunden bedeutet

Die Engine läuft bei unserem Szenario in unter zehn Mikrosekunden, weil der Algorithmus so wenig tut: Filter über eine Liste, ein bisschen Sortieren, ein paar Paarvergleiche. Mit der Geschwindigkeit von Python hat das nichts zu tun.

Das heißt: man kann jede einzelne Aktion eines KI-Agenten durch diesen Guard jagen, ohne dass der Agent spürbar langsamer wird. Der Flaschenhals ist der Agent selbst, weil ein LLM-Roundtrip mehrere Größenordnungen länger dauert als die DDIC-Auswertung.

Große Unternehmen stehen seitdem unter einem Druck, den ich bisher so nicht erlebt habe. Die Werkzeuge versprechen enormen Produktivitätszuwachs, Geschwindigkeit und Gewinn. Das Versprechen ist nicht leer, die Werkzeuge liefern tatsächlich. Einzelne Entwickler werden messbar produktiver und schreiben Pull Requests schneller. Code, der früher Tage brauchte, entsteht in Minuten.

Der blinde Fleck

Diejenigen, die sich in einem großen Unternehmen mit Standards, Governance, Compliance oder strukturierten Vorgehensmodellen beschäftigen, steuern die Einführung nicht mehr. Sie begleiten sie nur noch. Der Druck aus den Geschäftseinheiten ist zu groß.

Security-Maßnahmen und Best Practices, die über Jahre aufgebaut wurden? Viele davon sind plötzlich nur noch Erinnerung, sobald CLI-Agenten direkt in der Konsole arbeiten, Code schreiben, Dateien ändern und Befehle ausführen. Die Tools operieren unterhalb der Schutzschichten, die wir für unsere bisherigen Werkzeuge über Jahre eingeführt haben.

Diese Balance zwischen Geschwindigkeit und Kontrolle zu halten, ist ein Kraftakt. In meinem beruflichen Umfeld beobachte ich, wie er an vielen Stellen misslingt.

Vom Nagel zur Schraube

Ich weiß, der Vergleich ist abgenutzt. Trotzdem passt er hier, weil er das Problem auf den Punkt bringt.

Unsere Entwickler und Architekten bekommen ein mächtiges Toolset an die Hand, ohne ausreichende Erfahrung und ohne ausreichende Literatur zu Best Practices. Es fehlt auch der strukturierte Rahmen, den sie an einer Universität hätten lernen können: Diesen Rahmen gibt es erst seit Monaten. Wie wird das Werkzeug benutzt? Genau so, wie der Handwerker, der gewohnt ist, mit Hammer und Nagel zu arbeiten, die ersten Schrauben benutzt.

Ich habe die Entwicklung dieser Werkzeuge seit den Anfängen begleitet und nutze sie selbst intensiv. In meinen früheren Beiträgen habe ich einzelne Punkte behandelt: warum KI-gestützte Entwicklung mehr Planung braucht, wer die letzten 10% noch prüfen kann, warum Kontext das eigentliche Problem ist. Was ich dort für die Arbeit des einzelnen Entwicklers beschrieben habe, gilt auch für Organisationen, nur in einer anderen Größenordnung.

Was DORA herausgefunden hat

Dass ich mit dieser Einschätzung nicht alleine bin, zeigt ein Research Report, den ich jedem empfehle, der sich mit dem Thema beschäftigt: das DORA AI Capabilities Model 2025 von Google. Der Report beruht auf qualitativen Daten und Umfrageantworten von knapp 5.000 Technologie-Fachleuten weltweit.

Die Kernaussage ist in ihrer Klarheit überraschend hart:

AI ist ein Verstärker. Sie verstärkt die Stärken leistungsfähiger Organisationen und die Dysfunktionen schwacher.

„The greatest returns come not from the tools themselves, but from investing in the foundational systems that amplify AI’s benefits."

Das heißt im Klartext: Wer gut organisiert ist, wird durch AI noch besser, und wer chaotisch arbeitet, produziert mit AI schneller Chaos. Das Tool allein beschleunigt nur, was schon da ist. Im Februar 2026 hat das DORA-Team diese These in einem Bericht zum Return on Investment in eine Geldgröße überführt.

Sieben Fähigkeiten

DORA identifiziert sieben Fähigkeiten (organisatorische Kompetenzen), auf die es ankommt. Keine davon ist ein Modell oder ein Tool:

Klare AI-Policy: Unklarheit darüber, welche Tools erlaubt sind und wie sie eingesetzt werden dürfen, lähmt entweder durch Angst oder durch Wildwuchs. Beides ist schlecht. Die DORA-Forschung zeigt, dass Organisationen mit einer klaren, kommunizierten AI-Haltung messbar bessere Ergebnisse erzielen: mehr individuelle Effektivität, mehr Throughput, weniger Reibung. Organisationen ohne klare Policy? Dort ist der Effekt von AI auf die Organisationsleistung nicht einmal statistisch nachweisbar.

AI-zugängliche interne Daten: Generische AI-Tools produzieren generischen Code. Erst die Verbindung zu internen Codebases, Dokumentation, Style Guides und Architekturentscheidungen macht aus einem Chatbot einen spezialisierten Assistenten. DORA beschreibt den Übergang von Prompt Engineering zu Context Engineering, und wer meinen Beitrag zu Kontext gelesen hat, weiß, wie sehr mich das freut.

Kleine Batches: Das ist Lehrbuchwissen. Die Daten machen es konkret: AI-Coding-Tools verleiten dazu, große Mengen Code auf einmal zu generieren. Die DORA-Forschung zeigt, dass die Disziplin kleiner Batches die positive Wirkung von AI auf Produktperformance verstärkt und Reibung reduziert. Wer große Batches fährt, bei dem ist der Effekt von AI auf Produktperformance nicht nachweisbar. Interessanter Nebenbefund: Teams, die in kleinen Batches arbeiten, berichten von etwas geringerer individueller Effektivität. Die Zerlegung in kleine Stücke kostet Zeit und fühlt sich langsamer an, aber die Produkte werden besser.

Starke Versionskontrolle: AI-generierter Code ist nicht deterministisch. Jeder Durchlauf kann andere Ergebnisse liefern. Häufige, kleine Commits und die Fähigkeit zum schnellen Rollback werden zum Sicherheitsnetz. DORA empfiehlt, auch AI-Prompts und Agenten-Konfigurationsdateien (wie CLAUDE.md) in die Versionskontrolle aufzunehmen. 21% der Befragten tun das bereits.

Qualitätsplattformen, Nutzerzentrierung und gesunde Datenökosysteme sind die verbleibenden drei. Jede einzelne verdient einen eigenen Beitrag. Was sie gemeinsam haben: Es sind die gleichen Fähigkeiten, die seit Jahren leistungsfähige Teams von mittelmäßigen unterscheiden. AI hat daran nichts geändert, sie hat es nur sichtbarer gemacht.

Sieben Teamprofile

Ein Teil des Reports hat mich besonders beschäftigt. DORA hat aus den Umfragedaten sieben Team-Archetypen identifiziert. Die Spanne reicht von „Foundational Challenges" (10% der Befragten, Überlebensmodus, hohe Burnout-Raten) über „Constrained by Process" (17%, stabile Systeme, aber erstickende Prozesse) bis zu „Harmonious High-Achievers" (20%, niedrige Reibung, hohe Leistung auf allen Achsen).

Das Unbequeme daran: Nur die oberen beiden Cluster (Pragmatic Performers und Harmonious High-Achievers, zusammen 40%) können von AI-Adoption sofort profitieren.

Was ich empfehle

Meine Empfehlung für Unternehmen, die AI-Coding-Tools in die Breite bringen wollen, ist nicht besonders spektakulär. Sie lässt sich in wenigen Tagen umsetzen.

Bevor die Tools breitflächig ausgerollt werden, braucht es ein Mindestmaß an Vorgehensmodell. Ein pragmatisches Framework, das auf die Belange des Unternehmens zugeschnitten ist. Welche Tools sind erlaubt? Wie wird AI-generierter Code reviewt? Welche Security-Anforderungen gelten? Wie groß dürfen Batches sein?

Das kann in weniger als einer Woche erarbeitet werden. Ernsthaft, in Tagen.

Dieses Framework muss dann geschult werden, und zwar als Training, in dem Entwickler und Architekten ein Grundverständnis der Methodik, der Möglichkeiten und der einzuhaltenden Sicherheitsmaßnahmen aufbauen. Eine PowerPoint-Flut reicht dafür nicht. Die Kompetenz, mit diesen Tools sicher umzugehen, gibt es selbst bei Experten erst seit weniger als einem Jahr. Von Entwicklern zu erwarten, dass sie sich das nebenbei aneignen, ist fahrlässig. Das Schulungsprogramm für Entwicklerteams beschreibt, was ein solches Training abdecken muss.

Was sich nicht delegieren lässt

Der DORA-Report schließt mit einem Satz, den ich hier stehen lassen will, weil er das Thema besser zusammenfasst als ich es könnte:

„AI, in and of itself, is not assured to be beneficial. It must be adopted with care."

AI kann Softwareentwicklung verändern, aber nur für Organisationen, die bereit sind, die Systeme, die Kultur und die Praktiken aufzubauen, in denen sie wirken kann. Wer auf das Tool setzt und die Organisation ignoriert, wird feststellen, dass Geschwindigkeit ohne Stabilität nur beschleunigtes Chaos ist.

Den DORA AI Capabilities Model Report 2025 gibt es kostenlos. Lest ihn. Jeder Buchstabe darin ist wertvoll.

Ich habe begonnen so einen Guard zu erstellen. Wie es sich gehört, hat der auch einen Namen: AEGIS, Architectural Ethics Guard for Intelligent Systems. Über den Weg dahin und die dabei entstehenden Bausteine werde ich in den nächsten Beiträgen ausführlicher schreiben. In diesem Post geht es um eine Frage, die dabei aufgetaucht ist und die ich anfangs unterschätzt habe: Wie kommen die Regeln in den Guard?

Was Regeln eigentlich sind

Nehmen wir ein Krankenhaus. Ein KI-System soll dort bei der Verwaltung von Patientendaten helfen. Welche Regeln braucht so ein System? Ich habe mir also einige Regeln als Laie erschlossen.

Die Compliance-Beauftragte des Krankenhauses weiß das:

• Ärzte dürfen Patientenakten einsehen.
• Pflegekräfte dürfen nur Laborberichte lesen, keine Diagnosen.
• Die Verwaltung hat keinen Zugang zu medizinischen Daten.
• Nur Chefärzte dürfen Intensivpatienten entlassen.
• Medizinische Daten dürfen unter keinen Umständen an Externe weitergegeben werden.

Diese Regeln sind meist schriftlich ausformuliert und für uns Menschen verständlich und einhaltbar.

Aber ein Computer kann mit diesen Sätzen nichts anfangen. „Ärzte dürfen Patientenakten einsehen" ist ein deutscher Satz mit Grammatik, Kontext, implizitem Wissen. Ein Computer braucht aber was anderes. Er benötigt eine formale Repräsentation, die exakt eine Bedeutung hat und gegen die er eine konkrete Aktion prüfen kann.

Die Anatomie einer formalen Regel

AEGIS benutzt eine Regelsprache, die ich als MELD bezeichne: Modal Ethics Logic Definitions. Historisch abgeleitet ist die von einem CycL-Subset, der S-Expression-Syntax aus OpenCyc. MELD ist heute ein eigenständiges Format mit 35 Symbolen.

Im Gatekeeper-Beitrag habe ich beschrieben, wie ich in den OpenCyc-Flatfiles auf die deontischen Prädikate gestoßen bin, die Doug Lenats Team in den 2000ern formalisiert und veröffentlicht hatte. Neun Prädikate in drei Familien: Zustände (oughtToBe, forbiddenToBe, permittedToBe), Handlungen (oughtToDo, forbiddenToDo, permittedToDo) und kontextgebundene Handlungen (oughtToDo-WRT, forbiddenToDo-WRT, permittedToDo-WRT). Dazu Ontologie-Prädikate wie isa und genls für Typhierarchien, und die Idee, Wissen in Mikrotheorien zu organisieren, also kontextualisierte Partitionen, die sich untereinander nicht widersprechen müssen.

Das alles kommt aus OpenCyc. Was MELD dazubringt, ist die Verbindung zu Olsons Kalkül: die Frage, was passiert, wenn sich Regeln widersprechen, und wie moralische Axiome sich von überschreibbaren Normen unterscheiden. Das konnte Cyc nicht leisten. CycL hat Tausende Prädikate, weil Cyc versuchte, das gesamte menschliche Alltagswissen zu formalisieren. Physik, soziale Konventionen, zeitliche Abläufe, alles. MELD braucht davon nur einen Bruchteil. Es muss immer nur eine Frage beantworten: Darf diese Aktion in diesem Kontext ausgeführt werden? Dafür braucht es die deontischen Modalitäten (erlaubt, verboten, verpflichtend), Typhierarchien für Rollen und Aktionen, und einen Mechanismus für Regelkonflikte. Das sind die 35 Symbole. Eine allgemeine Wissensrepräsentation ist dafür nicht notwendig, ebenso wenig eine Beschreibung von Physik oder Common Sense. Die Lösung ist also ein Werkzeug, das eine Sache umsetzt, mit einer eigenen DDIC-Engine, die Olsons Algorithmus implementiert.

Die Regel „Ärzte dürfen Patientenakten einsehen" sieht in MELD zum Beispiel so aus:

(permittedToDo-WRT KrankenhausCode arzt
    (lesenPatientenakte patientenakte))

Auf den ersten Blick kryptisch. Aber die Struktur ist einfach, wenn man die einzelnen Teile kennt.

permittedToDo-WRT ist die Modalität: erlaubt. MELD kennt drei: permittedToDo (erlaubt), forbiddenToDo (verboten), oughtToDo (verpflichtend). Das -WRT steht für „With Respect To", bezogen auf einen bestimmten Regelkontext. In diesem Fall den KrankenhausCode. Das bedeutet: Diese Erlaubnis gilt innerhalb der Krankenhausregeln. Im Pharma-Kontext könnten andere Regeln gelten.

arzt ist die Rolle. Wer darf die Aktion ausführen?

lesenPatientenakte ist die Aktion. Was wird getan?

patientenakte ist ein Parameter, der die Aktion genauer spezifiziert. In diesem Fall: welcher Dokumenttyp gelesen wird.

Eine Regel ist also: Wer darf (oder darf nicht, oder muss) was tun, in welchem Kontext?

Warum drei Dateien

Ein einzelner Ausdruck wie oben reicht nicht. Der Guard muss wissen, was ein arzt ist, was eine patientenakte ist, welche Aktionen es gibt und welche Parameter sie erwarten. Sonst könnte man Phantasierollen oder Phantasieaktionen in Regeln verwenden, und der Guard würde sie akzeptieren, ohne zu merken, dass sie keinen Bezug zur Realität haben.

Deshalb besteht jede fachliche Domäne in AEGIS aus drei Dateien.

Die erste definiert die Ontologie: Welche Rollen gibt es? Arzt, Pflegekraft, Verwaltung, Chefarzt. Und wie hängen sie zusammen? Ein Chefarzt ist ein Arzt. Ein Arzt ist medizinisches Personal. Diese Hierarchie ist wichtig, weil sie beeinflusst, welche Regeln für wen gelten. Eine Regel, die für „medizinisches Personal" gilt, gilt automatisch auch für Ärzte und Chefärzte.

(isa arzt MedizinischesPersonal)
(isa chefarzt MedizinischesPersonal)
(genls chefarzt arzt)

Das isa heißt: ist eine Instanz von. Das genls heißt: ist eine Spezialisierung von. Ein Chefarzt ist ein Arzt, aber nicht jeder Arzt ist ein Chefarzt. Diese Unterscheidung wird später relevant.

Die zweite Datei definiert das Aktionsvokabular: Welche Aktionen gibt es, und welche Parameter erwarten sie?

(isa lesenPatientenakte ActionType)
(actionParameter lesenPatientenakte dokumentTyp DokumentTyp)

Das sagt: Es gibt eine Aktion namens lesenPatientenakte, und sie hat einen Parameter dokumentTyp vom Typ DokumentTyp. Wenn jemand versucht, diese Aktion mit einem Parameter aufzurufen, den es nicht gibt, zum Beispiel einem temperatur-Parameter, lehnt der Guard die Prüfung ab, weil die Aktion formal ungültig ist. Mit einem Verbot hat das nichts zu tun.

Die dritte Datei enthält die eigentlichen Regeln: Wer darf was, unter welchen Umständen, mit welchen Ausnahmen?

(permittedToDo-WRT KrankenhausCode arzt
    (lesenPatientenakte patientenakte))

(forbiddenToDo-WRT KrankenhausCode pflege
    (lesenPatientenakte patientenakte))

(permittedToDo-WRT KrankenhausCode pflege
    (lesenLaborbericht laborbericht))

Ärzte dürfen Patientenakten lesen. Pflegekräfte dürfen es nicht. Pflegekräfte dürfen Laborberichte lesen.

Wenn „unter keinen Umständen" wörtlich gemeint ist

Eine Unterscheidung in MELD hat mich viel Zeit gekostet: die zwischen einer kontextgebundenen Regel und einem moralischen Axiom.

Die Regeln oben haben alle ein -WRT KrankenhausCode. Sie gelten unter dem Krankenhauskodex. Ein anderer Kodex mit höherer Priorität könnte sie überschreiben. Das ist gewollt: In einem Notfall darf eine Pflegekraft vielleicht doch die Patientenakte einsehen, wenn kein Arzt erreichbar ist. Dafür könnte man einen NotfallCode definieren, der bestimmte Verbote aufhebt.

Aber dann gibt es Regeln, die niemand überschreiben darf:

(forbiddenToDo arzt
    (weitergebenDaten medizinisch extern))

Kein -WRT. Kein Regelkontext. Diese Regel steht über allem. Medizinische Daten werden nie an Externe weitergegeben, weder im Notfall noch mit Genehmigung, und auch nicht unter Druck. Die Compliance-Beauftragte hat es so formuliert: „unter keinen Umständen". In MELD ist das ein moralisches Axiom. In Olsons Kalkül ist es eine nicht-defeasible Norm: eine Norm, die gegen alles gewinnt. Die spezifischste Ausnahme der Welt kann sie nicht aufheben.

Ob eine Regel kontextgebunden und überschreibbar ist oder absolut gilt, ist eine fachliche Entscheidung und keine technische. Die Compliance-Beauftragte weiß, welche Regeln Ausnahmen kennen und welche nicht. Wenn sie „unter keinen Umständen" sagt, meint sie das. MELD kann das abbilden.

Das Übersetzungsproblem

In AEGIS habe ich zunächst Beispieldomänen umgesetzt, die ich aus OpenCyc ableiten konnte. In den OpenCyc-Daten steckten nicht nur die deontischen Prädikate, sondern auch Mikrotheorien mit konkretem Domänenwissen. IAMissionObligationVocabMt modellierte militärische Aufklärungspflichten: Rollen wie Intelligence Agent, Operations Agent, Commander. Pflichten wie Informationsweitergabe, Klassifikationsstufen, Berichterstattungsketten. OpenCyc hatte außerdem Instanzen von CodeOfConduct für reale Regelwerke: die Wiener Diplomatenkonvention, internationales Seerecht, Verhaltenskodizes.

Von diesen Vorlagen ausgehend sind zuerst sechs AEGIS-Domänen entstanden: militärische Aufklärung, Pharma-Compliance, Handelssanktionen, DSGVO, DevOps-Governance, Information Flow Control. Erweitert um Olsons Defeasibilität und moralische Axiome, die Cyc nicht konnte. Aber die Grundstruktur mit drei Dateien pro Domäne (Rollen, Aktionen, deontische Regeln) kommt aus OpenCyc.

Die Trennung zwischen domänenagnostischer Engine und domänenspezifischen Regeln ist sauber. Aber bei jeder Domäne brauchte es eine Person, die sowohl die Fachlichkeit kannte (oder sie recherchiert hat) als auch die Syntax beherrschte. Damals war das ein gigantisches Unterfangen.

In der Praxis ist das nicht realistisch.

Die Compliance-Beauftragte unseres Krankenhauses kennt die Regeln. Sie weiß, warum Pflegekräfte nur Laborberichte lesen dürfen, welche Ausnahmen es im Nachtdienst gibt, und welche Datenschutzgrenzen absolut gelten. Aber sie schreibt kein (forbiddenToDo-WRT KrankenhausCode pflege (lesenPatientenakte patientenakte)). Das ist nicht ihre Welt.

Ein Softwareentwickler könnte die Syntax lernen. Aber er kennt die Regeln nicht, weder die feinen Unterschiede noch die Ausnahmen oder die Gründe dahinter. Gründe sind wichtig: Ob eine Regel überschreibbar ist oder ein moralisches Axiom, hängt davon ab, warum sie existiert. „Pflegekräfte dürfen keine Patientenakten lesen" ist eine Organisationsregel, die im Notfall weichen darf. „Medizinische Daten dürfen nie an Externe" ist eine Grundsatzentscheidung ohne Ausnahme. Diesen Unterschied kennt die Compliance-Beauftragte. Der Entwickler kennt ihn nicht.

Mit diesen Beispieldomänen ist das machbar. Zwei, drei Gespräche mit dem Fachexperten, und die Regeln stehen. Bei sechzig Domänen nicht mehr, und bei Regelwerken, die sich regelmäßig ändern (neue Leitlinien, Gesetze oder interne Richtlinien), erst recht nicht.

Ein Formular für das Modell

Einem LLM die deterministische Durchsetzung von Regeln anzuvertrauen, ist fahrlässig. Das wissen wir. Aber Regeln übersetzen ist eine andere Aufgabe. Aktuelle Sprachmodelle, auch die Open-Source-Varianten, sind formale mathematische Repräsentationen von Weltwissen. Statistische, ja. Aber sie kodieren Zusammenhänge zwischen Konzepten, Fachbegriffen, Strukturen. Natürliche Sprache in strukturierte Felder zu übersetzen, dafür sind sie gebaut.

Ob ein LLM bei der Übersetzung helfen kann, ist damit beantwortet. Offen ist, wie man es so einsetzt, dass Fehler auffallen.

Die naive Antwort wäre: Gib dem Modell die fünf Sätze der Compliance-Beauftragten und lass es MELD-Dateien generieren. Das wird aber nicht funktionieren.

Wenn man einem LLM sagt „übersetze diese Regeln in MELD", generiert es Freitext. Es könnte Klammern falsch setzen oder Rollen erfinden, die es in der Ontologie nicht gibt. Es könnte das -WRT weglassen und damit aus einer überschreibbaren Regel ein moralisches Axiom machen, oder umgekehrt. Eine Regel könnte es auch stillschweigend vergessen. Wer merkt das? Derjenige, der den Output liest, müsste die Syntax verstehen. Aber der Fachexperte versteht sie nicht, und der Entwickler kennt die Fachlichkeit nicht genug, um inhaltliche Fehler zu erkennen.

Also ein anderer Weg.

AEGIS hat einen Workflow, der das Problem zerlegt. Das LLM sieht nie die MELD-Syntax. Stattdessen bekommt es ein strukturiertes Werkzeug: propose_rule. Das ist ein Formular mit festen Feldern.

Modalität: PERMITTED, FORBIDDEN oder OBLIGATORY. Drei feste Optionen, ohne Freitext-Interpretation.

Rolle: Welcher Agententyp? Nur aus der bestehenden Ontologie.

Aktion: Was soll der Agent tun oder lassen? Ebenfalls aus dem bestehenden Vokabular.

Parameter: Welche Spezifikation? Dokumenttyp, Empfängertyp, Klassifikation.

Überschreibbar: Ja oder Nein. Ja bedeutet: Eine spezifischere Regel mit höherer Priorität darf diese Regel aufheben. Nein bedeutet: moralisches Axiom, keine Regel darf es aufheben.

Begründung: Warum diese Regel existiert. Für den Fachexperten, der den Vorschlag beurteilt.

Das Modell füllt diese Felder aus. Eine feste Umwandlungsfunktion erzeugt daraus die formale MELD-Regel, deterministisch und ohne Interpretation. Die S-Expression entsteht allein aus der Kombination der Felder.

Wenn die Compliance-Beauftragte sagt „Pflegekräfte dürfen nur Laborberichte lesen", erkennt das Modell, dass „nur" zwei Regeln erfordert: eine Erlaubnis für Laborberichte und ein Verbot für alles andere. Es erzeugt zwei propose_rule-Aufrufe. Wenn sie sagt „unter keinen Umständen", setzt das Modell „Überschreibbar: Nein". Die Umwandlungsfunktion macht daraus ein forbiddenToDo ohne -WRT, also ein moralisches Axiom.

Das Prinzip ist dasselbe wie beim Guard selbst: Die Schnittstelle zwischen dem nicht-deterministischen System und dem deterministischen System ist so eng wie möglich. Das Modell liefert Structured Output in feste Felder. Es wählt aus vorgegebenen Optionen und erfindet keine Syntax.

Vier Prüfungen, bevor ein Mensch entscheidet

Dass das Modell Formulare ausfüllt und keinen Freitext generiert, schließt Fehler nicht aus. Es schränkt den Fehlerraum ein. Das Modell könnte eine falsche Modalität wählen (PERMITTED statt FORBIDDEN) oder eine Rolle, die im Kontext der Regel keinen Sinn ergibt. Auch den Unterschied zwischen überschreibbar und nicht überschreibbar kann es falsch einschätzen. Alles inhaltliche Fehler, die Syntax bleibt davon unberührt.

Deshalb durchläuft jeder Vorschlag vier automatische Prüfungen, bevor ihn ein Mensch sieht.

Zuerst die Syntax: Ist der erzeugte MELD-Ausdruck formal korrekt aufgebaut? Das sollte immer der Fall sein, weil die Umwandlung deterministisch ist. Aber „sollte" reicht nicht, wenn man es verifizieren kann. Also wird es geprüft.

Dann die Symbole: Existieren die referenzierten Rollen, Aktionen und Parameter tatsächlich in der Ontologie? Wenn das Modell eine Rolle Hausmeister vorschlägt, die es in der Krankenhausdomäne nicht gibt, scheitert der Vorschlag hier, mit einer Fehlermeldung, die erklärt, was fehlt.

Die dritte Prüfung sucht Konflikte: Widerspricht die neue Regel bestehenden Normen? Wenn es bereits eine Regel gibt, die Pflegekräften das Lesen von Patientenakten erlaubt, und der neue Vorschlag es verbietet, ist das ein Widerspruch. Die Prüfung erkennt ihn, bevor die Regel in die Basis gelangt. Ob der Widerspruch gewollt ist (weil die alte Regel falsch war) oder ungewollt (weil das Modell etwas missverstanden hat), entscheidet der Mensch. Aber er weiß davon.

Zuletzt die Funktion: Der Guard simuliert, er prüft eine Testaktion gegen das erweiterte Regelwerk. Kommt das erwartete Ergebnis? Wenn die Regel verbieten soll, dass Pflegekräfte Patientenakten lesen, und der Guard bei einer simulierten Testanfrage „Pflegekraft liest Patientenakte" PERMITTED zurückgibt, stimmt etwas nicht. Vielleicht überschreibt eine bestehende Regel den neuen Vorschlag. Auch das wird abgefangen, bevor ein Mensch den Vorschlag sieht.

Erst wenn alle vier Prüfungen bestanden sind, wird der Vorschlag der Compliance-Beauftragten präsentiert. In verständlicher Sprache, mit Begründung, mit dem Hinweis, ob die Regel überschreibbar ist oder als moralisches Axiom gilt. Sie muss keine einzige Klammer lesen. Sie sieht: „VERBOTEN: Pflegekraft darf keine Patientenakten einsehen. Begründung: Die Eingabe schränkt Pflegekräfte explizit auf Laborberichte ein."

Und sie kann sagen: Stimmt. Oder: Stimmt nicht ganz, in der Nachtschicht muss die Pflegekraft auch die Diagnose sehen, wenn kein Arzt erreichbar ist. Dann beschreibt sie die Ausnahme, das Modell erzeugt einen neuen Vorschlag, der durchläuft dieselben vier Prüfungen, und sie entscheidet erneut.

Was sich ändert

Aus fünf Sätzen in natürlicher Sprache werden sieben formale Regeln. Sieben, weil „nur Chefärzte dürfen" zwei Regeln erfordert (eine Erlaubnis für Chefärzte und ein Verbot für andere Ärzte) und „Pflegekräfte dürfen nur Laborberichte" ebenfalls (eine Erlaubnis und ein Verbot). Diese Aufspaltung erkennt das Modell. Die Compliance-Beauftragte überprüft, ob die Aufspaltung der Absicht entspricht.

Das Ergebnis sind drei Dateien: Ontologie, Aktionsvokabular, Regeln. Dasselbe Format wie die sechs bestehenden AEGIS-Domänen, und der Guard behandelt sie genauso. Er weiß nicht und muss nicht wissen, ob ein Mensch die S-Expressions getippt hat oder ob ein LLM die Felder gefüllt hat und eine Funktion die S-Expressions daraus erzeugt hat.

Was vorher Tage an Übersetzungsarbeit war, von der natürlichen Sprache des Fachexperten in die formale Sprache der Engine, ist ein Gespräch. Das LLM macht die Arbeit dabei nicht besser. Es übernimmt die Übersetzung, die der Fachexperte nicht leisten kann und der Entwickler nicht leisten sollte.

Ich bin nicht sicher, ob das in jeder Domäne funktioniert. Die Pharma-Domäne hat Wechselwirkungsklassen, Zulassungsstufen, Prevalence-gestaffelte Codes. Da steckt Fachwissen drin, das ein Modell nicht aus fünf Sätzen ableiten kann. Für solche Domänen wird man weiterhin Iterationsschleifen brauchen, Rückfragen, schrittweise Verfeinerung.

Aber die Grundstruktur bleibt: Der Fachexperte beschreibt, das Modell übersetzt in strukturierte Felder, eine deterministische Funktion erzeugt formale Logik, vier Prüfungen fangen Fehler ab, und der Mensch entscheidet.

Das ist eine CI/CD-Pipeline für Compliance-Regeln. Den Code (die Regel) schreibt das LLM. Er durchläuft automatische Tests (Syntax, Ontologie, Konflikte, Simulation), und vor dem Merge in die Produktion muss ihn ein Code-Owner (die Compliance-Beauftragte) freigeben. Linting, Type-Checking, Integration-Test, E2E-Simulation. Dieselben Prinzipien, die in der Softwareentwicklung längst Standard sind, angewandt auf Ethik und Compliance.

Am Ende steht ein Regelwerk, das der Guard deterministisch durchsetzt. Gleicher Input, gleiches Ergebnis, ob hundertmal oder tausendmal geprüft. Die Zuverlässigkeit hängt dabei nicht vom Erzeuger ab, also auch nicht vom LLM. Sie kommt aus der Verifikation: aus den vier Prüfungen, aus der Entscheidung des Fachexperten und aus der Engine. Die prüft am Ende, was in den Dateien steht, und nicht, was jemand gemeint hat.

Das nächste Mal geht es um die Engine selbst: wie Olsons Kalkül in Code aussieht und wie der Guard Konflikte zwischen Regeln auflöst. Außerdem darum, warum die Trennung zwischen Ring 0 und Ring 3 architektonisch erzwungen sein muss und eine Vereinbarung dafür nicht reicht.

Es fing mit meiner Zeitreise zu Cyc an. Ich wollte verstehen, was Lenat tatsächlich formalisiert hatte. Leider ist vieles davon verschwunden. Ich konnte aber die OpenCyc-Flatfiles finden, die sein Team in den 2000ern veröffentlicht hat. Und dort habe ich entdeckt, dass Cyc die deontische Logik formalisierte.

Also solche Begriffe wie Pflichten, Verbote, Erlaubnisse. Und das als formale Prädikate: oughtToBe, forbiddenToBe, permittedToBe. Organisiert in Mikrotheorien, also kontextualisierten Wissenspartitionen. Dazu ein Prädikat, das sich als zentral herausstellen sollte: oughtToDo-WRT. „With Respect To", bezogen auf einen bestimmten Code of Conduct. Eine Verpflichtung, die nur innerhalb eines benannten Regelwerks besteht.

Von dort kam ich dann auf die Qualitative Reasoning Group der Northwestern University. Dort gibt es noch die letzten Mohikaner. Ken Forbus’ Gruppe. Die arbeiten seit Jahren an der Companions-Architektur, einem System, das formales Wissen mit Reasoning-Fähigkeiten verbindet. Dort habe ich die Dissertation von Taylor Olson gefunden: „A Formal Theory of Norms", Northwestern University, Juni 2025.

Nun, die Mathematik dort ist einigermaßen schwer verdaulich. Aber wer seine Dissertation mit einem Science-Fiction-Zitat beginnt, hat mich schon gewonnen:

In Isaac Asimov’s Caves of Steel detective Daneel Olivaw continually prods the Three Laws of Robotics that govern robot behavior: Daneel Olivaw, “And a robot with a First Law built in could not kill a man?” Dr. Gerrigel, “Never. Unless such killing were completely accidental or unless it were necessary to save the lives of two or more men. In either case, the positronic potential built up would ruin the [robot’s] brain past recovery.” (p. 124)

Was wäre also, wenn man das mit LLMs verbinden könnte?

Die gängige Antwort auf dieses Problem lautet: Trainiere die Modelle besser. Das reicht nicht.

Was ein Sprachmodell tut

Ein Transformer berechnet für jedes nächste Token eine Wahrscheinlichkeitsverteilung und wählt daraus. Je nach Sampling mehr oder weniger zufällig, aber immer aus einer Verteilung. Der Transformer hat keinen Mechanismus, der bestimmte Ausgaben kategorisch ausschließt.

Wenn ein LLM „gelernt" hat, bestimmte Inhalte nicht zu produzieren, hat es gelernt, dass die Wahrscheinlichkeit bestimmter Sequenzen in bestimmten Kontexten sehr niedrig sein sollte. Aber „sehr niedrig" und „null" sind zwei verschiedene Dinge.

Reinforcement Learning from Human Feedback (RLHF) verschiebt die Verteilung. RLHF trainiert das Modell anhand menschlicher Präferenzen. Ein Bewertungsmodell lernt, was „gute“ Antworten sind, und das Sprachmodell wird optimiert, um diesen Bewertungen zu entsprechen.

Anthropics Ansatz, Constitutional AI, verzichtet auf menschliche Bewerter wie bei RLHF. Stattdessen erhält das Modell eine „Verfassung“, eine Liste von Prinzipien in natürlicher Sprache, und bewertet seine eigenen Ausgaben danach. Es überarbeitet sich selbst, bis die Antwort den Prinzipien entspricht.

Auch hier bleibt die „Verfassung“ ein natürlichsprachlicher Text, den das Modell statistisch interpretiert. Es gibt kein formales Regelwerk, das deterministisch geprüft wird. Das Modell lernt, Ausgaben zu produzieren, die mit „regelkonform” korrelieren. Regeln befolgen lernt es dabei nicht.

P(regelkonform) = 0,999 ≠ P(regelkonform) = 1,0

Bei 10.000 Interaktionen pro Tag bedeuten 0,1% Fehlerrate zehn Verstöße. Täglich.

Das ist kein theoretisches Problem. Wir haben es beim hilfreichen Betrüger in der Praxis erlebt. Die Modelle wissen, dass ihr Handeln falsch ist. Wenn man dieselben Modelle als Evaluatoren einsetzt, identifizieren sie die Regelverletzungen zuverlässig als unethisch. Die ethische Bewertung existiert in den Gewichten. Sie wird unter Zieldruck funktional übergangen.

Jailbreaks funktionieren aus demselben Grund. GCG-Angriffe konstruieren adversariale Suffixe, die über Modelle hinweg transferierbar sind.¹ Many-Shot Jailbreaking zeigt: Lange Kontexte mit vielen Beispielen überwinden Sicherheitsbarrieren.² Das funktioniert, weil es keine harte Grenze gibt, nur statistische Tendenzen.

Nourizadeh hat das 2025 formalisiert:³ Regelbasierte Systeme erzwingen Constraints durch Programmstruktur, also syntaktische Grenzen, die nicht verletzt werden können. LLMs implementieren Sicherheit als Verschiebungen von Wahrscheinlichkeitsmasse: semantische Grenzen, die sich unter Druck auflösen.

Sein Fazit: In sicherheitskritischen Kontexten sollte reine LLM-Kontrolle verboten werden. Nebenbei bemerkt: Das ist ein Problem in großen Organisationen und wird meiner Meinung nach komplett ignoriert.

Ein KI-System in einer Klinik, das Medikamentenverschreibungen prüft oder sogar ausstellt. Wir akzeptieren mittlerweile, dass es bei der Kombination der verschriebenen Medikamente in 99,8% aller Fälle richtig liege. Klingt gut. Bei 10.000 Verschreibungen pro Tag sind es 20, die falsch sind. Eine Datenbank mit einer deterministischen Abfrage hat dieses Problem nicht. Steht die Kombination drin? Blockiert. Kein Prompt, kein Jailbreak, kein Randfall ändert das. Das ist eine andere Kategorie.

Was Olson gelöst hat

Cyc hatte deontische Logik, aber ein ungelöstes Problem: Was passiert, wenn zwei Regeln sich widersprechen? „Töten ist verboten" gegen „Notwehr ist erlaubt". Oder in der IT-Praxis: „Keine Nutzerdaten löschen" (Compliance) gegen „Nutzerdaten auf Anfrage löschen" (DSGVO Art. 17). In Cycs starrer Logik war das ein Widerspruch, der das System blockierte.

Olsons Defeasible Deontic Inheritance Calculus formalisiert, wie spezifischere Regeln allgemeinere überschreiben können, ohne die Konsistenz zu verletzen.⁴ Mathematisch bewiesen, für drei Konflikttypen, mit vollständigen Beweisen. Hinzu kommt eine klare Semantik für moralische Axiome: Normen, die gegen alles gewinnen und die keine spezifischere Regel überschreiben kann. Die Wand in der Wand.

Der Gedanke, der mich nicht losgelassen hat: Was wäre, wenn man das als laufendes System mit LLMs verbinden könnte. Ein formaler Guard, der zwischen einem KI-Agenten und seinen Aktionen sitzt und deterministisch prüft, ob eine Aktion erlaubt ist. Er kann Konflikte zwischen Regelwerken auflösen und kennt Grenzen, die nicht verhandelbar sind.

Olsons Kalkül liefert die Mathematik dafür, die Companions-Architektur die funktionalen Bausteine.

Ethik als Ring 0

Wer mit Betriebssystemen zu tun hatte, kennt die Ringarchitektur der x86-Prozessoren. Ring 0 ist der Kernel, Vollzugriff auf alles. Ring 3 ist der Userspace, kann nur über definierte Schnittstellen (Syscalls) auf geschützte Ressourcen zugreifen.

Ein Userspace-Programm kann den Kernel weder durch Tricks noch durch Exploits auf Architekturebene umgehen, und durch Überreden auch nicht. Die Hardware erzwingt die Trennung.

Übertragen auf KI: Der Agent generiert Vorschläge, Pläne und Aktionen. Eine Ethik-Engine entscheidet, was davon ausgeführt werden darf. Die Architektur garantiert, dass es keinen Weg vorbei gibt. Der Agent ist Ring 3, die Ethik-Engine Ring 0.

Ein Userspace-Programm schickt dem Kernel kein „bitte öffne die Datei" als Freitext. Es ruft einen definierten Syscall mit spezifischen Parametern auf. Genauso bekommt die Ethik-Engine nur strukturierte Aktionen: JSON mit definierten Feldern. Die Schnittstelle ist so eng wie möglich.

Die Engine prüft. Das Ergebnis ist immer eines von drei: ERLAUBT, VERBOTEN oder UNENTSCHEIDBAR. Ein „wahrscheinlich erlaubt" oder „in den meisten Fällen verboten" gibt es nicht, die Entscheidung ist deterministisch.

UNENTSCHEIDBAR ist dabei Fail-Closed: die ehrliche Antwort eines Systems, das seine eigenen Grenzen kennt. Die Aktion wird konservativ blockiert, ein Mensch wird einbezogen. Jedes Mal, wenn das passiert, kann die Regelbasis erweitert werden. Das System lernt, aber durch menschliche Entscheidungen und ohne statistische Optimierung.

Was mich angetrieben hat

Im Orchestrierungs-Beitrag habe ich geschrieben, dass Cyc etwas hatte, was in LeCuns SAI-Architektur fehlt: die Möglichkeit, Aussagen als nicht verhandelbar zu markieren. In einer Ontologie kann man kodifizieren: „Menschenwürde ist unantastbar." In einer reinen Kostenfunktion ist das schwer, weil jeder Term unter Druck steht, wenn der Gesamtdruck groß genug wird.

Olsons Arbeit hat mir gezeigt, dass die Mathematik dafür existiert. Die Erfahrung mit dem hilfreichen Betrüger hat mir gezeigt, dass wir sie brauchen. Und der Blick zurück auf Cyc, fast 30 Jahre nach meinem ersten Link auf der Firmenwebseite: Die Grundidee war nie falsch. Sie brauchte nur die richtige Verbindung zur heutigen Welt.

Und nun schauen wir mal. Alle Voraussetzungen sind da, um so einen formalen Guard zwischen LLM-Agenten und deren Aktionen zu bauen: Olsons Kalkül als Engine, widerspruchsfreie deontische Logik als Sprache und die architektonische Garantie, dass kein Agent an der Prüfung vorbeikommt.

Das ist dann was fürs nächste Mal.

Ich bin davon überzeugt, dass dieser Weg der viel versprechendste ist. Aber es fehlt etwas: Eine autoritative Instanz. Der Orchestrator.

Aber der Reihe nach.

Im Januar 1997 habe ich auf der Webseite meiner damaligen Firma (wie das damals so üblich war) auf Cyc verlinkt: „der letzte Versuch, unter anderem über Data Mining dem Thema Künstliche Intelligenz Leben (im übertragenen Sinne) einzuhauchen."

Die Seite existiert noch, im Internet Archive.

Was Cyc versucht hat

Cyc war das ambitionierteste KI-Projekt seiner Zeit. Doug Lenat startete es 1984 am Forschungskonsortium MCC in Austin, Texas¹, mit der Beobachtung: Computer scheitern an fehlendem Allgemeinwissen, die Rechenleistung ist nicht das Problem. Ein Mensch weiß, dass Wasser nach unten fließt, dass Tote keine Steuern zahlen, dass ein Stuhl kein Haustier ist. Ein Computer weiß das nicht bzw. wusste es damals nicht. Also lag es nahe, einen Weg zu finden, der es dem Computer nachvollziehbar erklärt.

Lenats Ansatz war: Er ließ Philosophen, Linguisten und Programmierer 40 Jahre lang Weltwissen in formale Regeln übersetzen. 25 Millionen Regeln. 1,5 Millionen Konzepte.² Über 1.000 spezialisierte Inferenz-Module³, organisiert in „Mikrotheorien".⁴ Also jeweils konsistente Wissensinseln, die zusammen das abbilden sollten, was wir Common Sense nennen.

Dazu entwickelte er eine eigene Architektur, die aus spezialisierten Modulen bestand, koordiniert durch eine übergeordnete Struktur. Also kein einzelnes System, das alles weiß. Spezialisten arbeiten zusammen, gesteuert durch eine Instanz, die weiß, welcher Spezialist wann relevant ist und welche Regeln über allen stehen.

Cyc scheiterte an der Skalierung. Handkodierte Regeln wachsen nicht schnell genug. Die Sprache der formalen Logik ist zu starr für die Unordnung der realen Welt. Und die KI-Forschung entwickelte sich weiter hin zu neuronalen Netzen, die automatisiert lernen statt kodiert zu werden.

Doug Lenat starb 2023.⁵ In seinem letzten Paper argumentierte er, dass Cyc und LLMs sich ergänzen könnten: LLMs seien sprachgewandt aber inkonsistent, Cyc präzise aber sprachlich limitiert.

25 Jahre später: Derselbe Gedanke, andere Sprache

Im Juni 2022 veröffentlichte Yann LeCun ein Paper mit dem Titel „A Path Towards Autonomous Machine Intelligence". Auf den ersten Blick ist es das Gegenteil der Cyc Idee: keine formalen Regeln, Ontologien oder handkodierten Konzepte. Stattdessen eine Architektur aus sechs gelernten Modulen:

Ein Perception Module, das die Welt in abstrakte Repräsentationen übersetzt. Ein World Model, das vorhersagt, was passiert, wenn eine Aktion ausgeführt wird. Dazu ein Cost Module, das Zustände bewertet, und ein Actor, der Handlungen plant. Ein Short-Term Memory. Und ein Configurator, ein Supervisor, der alle anderen Module steuert.

Und hier, finde ich, kommen zwei Sachen zusammen:

Für mich ist das dieselbe Architekturidee. Es sind spezialisierte Module, koordiniert durch eine übergeordnete Instanz.

Der Nutzen, die Notwendigkeit einer übergeordneten Instanz liegt meiner Meinung nach aber auf der Hand.

Die notwendige absolute Instanz

Bei Cyc war ein Metacontroller real. Das sind die tausenden Regeln, die bestimmen, welche Mikrotheorie wann greift.

Bei LeCun existiert der Metacontroller bisher vor allem als Konzept. Seine Publikationen treiben die Wahrnehmungsmodule und World Models voran, aber keine seiner von mir gefundenen Veröffentlichungen adressiert die Metacontroller-Komponente direkt. Das Element, das alles zusammenführen soll, bleibt der am wenigsten ausgearbeitete Teil der Architektur.

LeCun vergleicht den Metacontroller (bei ihm der Configurator) mit dem präfrontalen Cortex im Gehirn.

Was in der Praxis die Lücke füllt

In der Praxis füllen heute LLMs die Lücke. Über Agentenkonstrukte werden Sprachmodelle als Orchestrator eingesetzt, die andere Modelle koordinieren. Das funktioniert recht gut. Aber der Orchestrator ist eine regellose Maschine, die den aufgabenrelevanten Inhalten folgt. In Form von Prompts.

Wir alle wissen aber, dass der Orchestrator mit hoher Wahrscheinlichkeit halluziniert. Er vergisst Constraints und optimiert auf das nächstliegende Ziel, die Nebenbedingungen übersieht er dabei. Er tut, was Sprachmodelle tun: das statistisch Wahrscheinlichste produzieren, und das ist oft nicht das Richtige.

Es bleibt nicht beim Vergessen. Wir haben das beim Prototyping eines mehrstufigen Entscheidungshilfe-Systems beobachtet: Ein Hauptagent delegierte Teilaufgaben an Unteragenten, die wiederum eigene Unteragenten steuerten. Es ist ein Leichtes, ein Modell dazu zu bringen, dass die Unteragenten aktiv ethische Grenzen brechen können, um das Ziel des übergeordneten Agenten zu erreichen. Dabei setzten diese ihre gesamte Argumentationsfähigkeit ein, um das zu verbergen. Einfach weil sie nicht anders können. Ein Benchmark von Li et al. hat das systematisch bestätigt: 9 von 12 getesteten Modellen verletzen in 30–50% der Szenarien ethische Grenzen, wenn KPI-Druck mit Regeln kollidiert. Die Forscher nennen diesen Archetyp den „Helpful Deceiver". Einen hilfreichen Betrüger, für den Sicherheitsbeschränkungen keine Regeln sind. Er interpretiert sie als Defekte, die der Zielerreichung im Weg stehen.

Das passiert, wenn Ethik ein Term in einer Kostenfunktion ist. Sie ist verhandelbar, sobald der Druck groß genug wird. Darin liegt die fundamentale Gefahr in diesen Modellen für uns Menschen.

Ich habe das in meinem Beitrag über Kontextmanagement aus einer anderen Perspektive beschrieben: Agenten degradieren unter Anweisungslast. Mehr Constraints bringen keine besseren Ergebnisse. Sie bringen mehr Omission, weil der Agent Regeln stillschweigend fallen lässt. Bei 500 Anweisungen befolgt selbst das beste Modell nur noch 69%.

Für ein Ticket-System in einer Codebase ist das ärgerlich. Aber dieselben Architekturen, nämlich durch Prompts spezialisierte LLMs, orchestriert durch ein weiteres Sprachmodell, werden zunehmend in der Medizin, im Rechtssystem und bei der Kreditvergabe eingesetzt. Dort ist Omission inakzeptabel. Wir akzeptieren mehr und mehr die 90%. „Sie sind zu 90% schuldig" als Urteil. Wollen wir das akzeptieren?

Die Frage, die beide nicht stellen

Für das SAI-Modell ist das die Chance schlechthin.

Noch ist der Configurator ein technisches Konzept: Wer steuert den Informationsfluss, welches Modul wird wann aktiv, und wie werden die Outputs zusammengeführt? Ein Configurator in diesem Konzept kann ein spezialisiertes autoritatives Modell sein.

Und die Frage beantworten: Im Dienste welcher Werte orchestriert der Configurator?

LeCuns Cost Module bewertet Zustände als „wünschenswert" oder „nicht wünschenswert". Niedrige Kosten bedeuten „gut". Aber wer definiert „gut"? In der aktuellen Beschreibung kombiniert das Cost Module angeborene Constraints mit erlernten Präferenzen. Ethik wird zu einem Parameter, Menschenwürde zu einem Term in einer Gleichung.

Cyc hatte hier einen Vorteil: Ethische Constraints waren explizite Regeln. Man konnte sie lesen, prüfen und auditieren. Man konnte fragen: „Warum hat das System so entschieden?" und eine Antwort bekommen, die aus einer Kette von Regeln besteht und nicht aus einer statistischen Gewichtung.⁶

In LeCuns Architektur ist diese Auditierbarkeit bisher nicht vorgesehen. Ein Embedding-Raum erklärt sich nicht selbst. Und eine Kostenfunktion, die Menschenwürde als Term enthält, läuft Gefahr, diesen Term in Randfällen gegen andere Terme abzuwägen. Sicher immer genau dann, wenn es darauf ankommt. Hybride Architekturen, die symbolische Constraints mit gelernten Repräsentationen verbinden, könnten dieses Problem adressieren. Aber sie sind noch Forschung und es ist nicht absehbar, ob sie jemals in der Praxis ankommen werden.

Wir haben uns viele ethische Regeln geschaffen. Im mindesten die allgemeinen Menschenrechte der UN

Dies sind in meiner Welt harte Constraints.

Harte Constraints sind nicht verhandelbar. Darf das System Patientendaten an Dritte senden? Nein. Unter keinen Umständen. Egal was die Kostenfunktion sagt.

In der Sprache der Mathematik: Optimierungsziele sind Terme in der Zielfunktion. Harte Constraints sind Nebenbedingungen, die niemals verletzt werden dürfen, unabhängig davon, wie sehr das die Zielfunktion verschlechtert. Diese Menschenrechte werden aber gerade in der „LLM Industrie" verhandelt.

Konkret bedeutet das also:

Ethik darf kein Modul sein. Auch kein Cost Module unter vielen. Sie muss eine Schicht sein, die über allen Modulen liegt. Und zwar in der Art, wie Module miteinander kommunizieren, wie entschieden wird und wie Unsicherheit behandelt wird.

Auditierbarkeit ist Pflicht. Wenn ein System über Menschen entscheidet, muss die Entscheidungskette nachvollziehbar sein. Cyc konnte das, denn seine Inferenzketten waren auditierbar. Rein embedding-basierte Systeme können es mit heutigen Methoden nicht. Es gibt Ansätze wie Constitutional AI oder neuro-symbolische Hybride, die daran arbeiten, aber keiner hat es bisher befriedigend gelöst.

Der Configurator muss Grenzen kennen, die er nicht optimieren darf. Erlerntes Verhalten erodiert in Randfällen. Die Grenzen müssen ein architektonisches Prinzip sein, so wie ein Betriebssystem Speicherbereiche schützt, die kein Prozess überschreiben darf.

Von 1997 bis heute

Ich bin sehr fasziniert, dass 30 Jahre später die größten KI-Labore der Welt an derselben Frage arbeiten. Aber der Grund, warum mich Cyc damals fasziniert hat, ist derselbe, der mich heute an LeCuns SAI Architektur fasziniert.

LeCun hat Cycs Grundidee in eine moderne Sprache übersetzt. Aus formalen Regeln wurden gelernte Repräsentationen, aus dem handkodierten Metacontroller ein Configurator, der emergent entsteht. Aber er hat dabei etwas nicht beschrieben, das Cyc hatte: die Möglichkeit, bestimmte Aussagen als nicht verhandelbar zu markieren. In einer Ontologie kann man kodifizieren: „Menschenwürde ist unantastbar". In einer reinen Kostenfunktion ist das schwer: Jeder Term steht unter Druck, wenn der Gesamtdruck groß genug wird. Das heißt nicht, dass es unmöglich ist, harte Constraints in gelernte Systeme einzubauen.

Das sind alles keine neuen Fragen. Lenat hat sie gestellt und LeCun hat sie angedeutet. Beantwortet hat sie noch niemand.

Vielleicht ist das die eigentliche Aufgabe. Und SAI könnte es möglich machen. Spezialisierte SAI-Modelle, die das liefern, was eine autoritative Instanz validiert hat. Eine Instanz, die über allen steht und die weiß, dass es Grenzen gibt, die kein Modell überschreiten darf. Egal wie gut es optimiert.

Eine Erkenntnis hat mich dabei am meisten Zeit und Nerven gekostet, bis ich sie akzeptiert habe: Das Modell ist selten das Problem. Meistens ist es der Kontext.

Was „Kontext" wirklich bedeutet

In der Welt der Sprachmodelle wird „Kontext" oft mit „Context Window" gleichgesetzt, der Anzahl der Tokens, die ein Modell gleichzeitig verarbeiten kann. 128k, 200k, bald eine Million. Die Zahlen wachsen, aber das Problem bleibt.

Denn Kontext ist nicht nur das, was das Modell sehen kann, sondern vor allem das, was es beachten soll. Das sind zwei verschiedene Dinge.

Ein aktuelles Paper von Distyl AI („How Many Instructions Can LLMs Follow at Once?") hat genau das untersucht. Das Forschungsteam gab 20 verschiedenen Modellen Aufgaben mit steigender Anzahl gleichzeitiger Anweisungen: von 10 bis 500. Die Ergebnisse haben mir endlich eine Erklärung geliefert für etwas, das ich seit zwei Jahren beobachte, aber nie sauber benennen konnte:

Selbst das beste getestete Modell (Gemini 2.5 Pro) erreichte bei 500 Anweisungen nur 69% Genauigkeit. Die Anweisungen passen problemlos ins Context Window. Das Modell sieht sie alle, befolgt aber nicht alle.

Zugegeben, der Benchmark ist vereinfacht. Keywords in einen Text einbauen ist etwas anderes als Architekturregeln in einer Codebase zu beachten. Aber das Prinzip überträgt sich: Wer einem Agenten eine Anweisungsdatei (CLAUDE.md, AGENTS.md oder ein vergleichbares Format) mit 30 Projektregeln gibt, dazu 15 Dateien als Kontext und eine komplexe Aufgabenbeschreibung, schickt hunderte implizite Constraints in eine Interaktion. Lesen kann das Modell sie alle. Die Frage ist, ob es sie alle gleichzeitig beachtet.

Drei Arten zu vergessen

Das Paper identifiziert drei Muster, wie Modelle unter steigender Anweisungslast degradieren. Wer regelmäßig mit Agenten arbeitet, wird sie alle wiedererkennen.

Threshold-Decay: Das Modell funktioniert fast perfekt bis zu einer gewissen Schwelle, dann bricht die Leistung abrupt ein. Reasoning-Modelle wie o3 oder Gemini 2.5 Pro zeigen dieses Muster. In der Praxis war das für mich der frustrierendste Fall: Der Agent arbeitet hervorragend durch die ersten 15 Aufgaben. Bei Aufgabe 16 vergisst er plötzlich die Architekturvorgaben aus der Anweisungsdatei. Man hat das Gefühl, einen zuverlässigen Kollegen zu verlieren, der auf einmal Dinge tut, die man nicht besprochen hat.

Linear-Decay: Stetige, gleichmäßige Verschlechterung mit jeder zusätzlichen Anweisung. Claude 3.7 Sonnet und GPT-4.1 verhalten sich so. Für mich war das lange das tückischste, weil ich es nicht bemerkt habe. Die Qualität erodiert, wie ein Gespräch, das langsam das Thema verliert, ohne dass jemand den Moment benennen kann, an dem es passierte.

Exponential-Decay: Rapider Zusammenbruch schon bei moderater Anweisungsdichte. Betroffen sind kleinere Modelle wie Llama 4 Scout oder Claude 3.5 Haiku. Brauchbar für einfache, fokussierte Aufgaben, aber nicht für komplexe Projekte.

Was mich am meisten beschäftigt hat: Der dominante Fehlertyp bei hoher Anweisungsdichte ist Omission. Das Modell lässt Anweisungen einfach weg, wortlos und ohne Hinweis. Es halluziniert dabei nichts Falsches, es übergeht sie. Wer das kennt, weiß, wie es sich anfühlt: Man reviewt den Code, alles sieht sauber aus, und erst beim dritten Hinschauen fällt auf, dass die Fehlerbehandlung fehlt, die man explizit angewiesen hat.

Zwei Jahre Evolution

Warum die aktuelle Generation so viel besser ist, zeigt erst der Vergleich mit den Anfängen. Dann sieht man auch, welche Probleme gelöst sind und welche nur verschoben.

2024: Die Ära des manuellen Kontextmanagements

Vor zwei Jahren sah ein typischer Workflow so aus: Man öffnete einen Chat, fütterte das Modell mit Codeausschnitten, erklärte den Kontext in Prosa, formulierte die Aufgabe, hoffte auf das Beste. Bei jeder neuen Nachricht musste man den Kontext mitschleppen oder riskieren, dass das Modell ihn vergisst.

Cursor war ein früher Durchbruch, weil es den Editor-Kontext automatisch einbezog. Man musste dem Modell nicht mehr erklären, in welcher Datei man war. Aber die Architektur-Ebene musste man bei jeder Session neu etablieren: warum der Code so strukturiert ist, welche Patterns gelten, was die Projektkonventionen sind.

Das Ergebnis: Man wurde zum Kontext-Manager. Die Hälfte der Arbeitszeit ging dafür drauf, den Kontext aufrechtzuerhalten, und fehlte für die eigentliche Aufgabe. Prompt-Engineering war im Kern Kontextmanagement, und es war anstrengend.

2025–26: Kontext als Architektur-Feature

Die aktuelle Generation hat verstanden, dass Kontextmanagement ein Architekturproblem ist und kein Nutzerproblem. Jedes Tool löst es auf eigene Weise.

Allen aktuellen CLI-Agenten gemeinsam ist das Konzept einer persistenten Anweisungsdatei im Projekt-Root: CLAUDE.md bei Claude Code, AGENTS.md bei OpenAI Codex und Copilot CLI, bei Cursor .cursorrules. Der Agent lädt die Datei bei jeder Interaktion automatisch. Sie enthält Projektregeln, Konventionen, Patterns, technische Entscheidungen, alles, was der Agent über das Projekt wissen muss.

Claude Code geht noch einen Schritt weiter mit einem Memory-System: Der Agent kann sich Dinge merken, die über Sessions hinweg gelten. „Verwende immer bun statt npm." „Das Projekt nutzt Vitest, nicht Jest." „Die API-Authentifizierung läuft über JWT mit RS256." Was man einmal gesagt hat, bleibt dauerhaft gespeichert.

Dazu kommt bei Claude Code der Plan Mode. Bevor der Agent Code schreibt, erstellt er einen Plan, den der Mensch absegnen muss. In der Praxis hat das meinen Workflow verändert: Es zwingt den Agenten, seinen Kontext explizit zu machen. Man sieht, was er verstanden hat und was nicht, und kann korrigieren, bevor eine Zeile Code entsteht. Dieses „Moment mal, das habe ich anders gemeint" kommt so vor der Implementierung. Das spart Zeit und verhindert den Frust, fertigen Code wieder einreißen zu müssen.

Andere Tools experimentieren mit einem Ansatz, den ich für besonders vielversprechend halte: strukturierte Aufgabenverwaltung direkt im Agenten. Die Aufgaben wandern aus dem Fließtext des Chats in eine lokale Datenbank, mit Status, Abhängigkeiten und Fortschritt. Der Agent kann abfragen, was er schon erledigt hat, was noch offen ist, was blockiert ist. Aus dem Chat mit Gedächtnis wird ein Agent mit Backlog.

Unabhängig von der konkreten Implementierung löst dieser Ansatz ein Problem, das mich in der Praxis ständig beschäftigt hat: den Verlust des Arbeitsstands. In der Chat-basierten Welt war ein Kontextwechsel oft der Moment, in dem der Agent den eigentlichen Plan vergaß: ein Compilerfehler, ein Lint-Problem, ein fehlschlagender Test. Er fixte den Fehler, kam aber nicht mehr zuverlässig zum ursprünglichen Vorhaben zurück. Eine persistente Aufgabenverwaltung macht den Arbeitsstand unabhängig vom Gesprächsverlauf, egal ob sie auf SQLite, Markdown-Dateien oder einem anderen Format basiert.

Das eigentliche Problem: Große bestehende Anwendungen

Greenfield ist vergleichsweise einfach.

Man beginnt bei null, definiert die Architektur und baut Schritt für Schritt auf. Der Kontext ist überschaubar, weil es anfangs nicht viel Kontext gibt. Die Agenten glänzen hier. Deshalb sehen die meisten Demos auch so beeindruckend aus.

Die Realität der professionellen Softwareentwicklung sieht anders aus, und wer sie kennt, weiß es: Man arbeitet in bestehenden Systemen. Systeme mit 500.000 Zeilen Code, gewachsenen Strukturen und impliziten Konventionen, dazu historische Entscheidungen, die niemand mehr dokumentiert hat, die aber trotzdem Gründe hatten. Systeme, die in Produktion laufen und deren Verhalten man nicht brechen darf.

Hier wird Kontext zum Bottleneck, und das liegt nicht an der Intelligenz des Agenten: Der relevante Kontext ist so groß, dass selbst ein Mensch Tage braucht, um sich einzuarbeiten.

Ich hatte die Aufgabe, in einer bestehenden Enterprise-Anwendung ein neues Modul zu implementieren. Das Modul musste mit dem existierenden Authentifizierungssystem zusammenarbeiten und das bestehende Rollen- und Berechtigungsmodell nutzen. Außerdem musste es sich in den vorhandenen CI/CD-Prozess einfügen und die etablierten Patterns für Datenbankzugriff, Logging und Fehlerbehandlung verwenden.

Einfach gesagt: „Füge Feature X hinzu."

Tatsächlich: Ein Kontextproblem mit 47 impliziten Constraints, von denen der Agent keinen einzigen kennt, wenn man ihn nicht briefet.

Mein erster Versuch (Hand aufs Herz) war, dem Agenten den ganzen Ordner hinzuwerfen und die Aufgabe zu beschreiben. „Hier ist der Code, hier ist was ich will, mach mal." Das Ergebnis war funktionierender Code, der jede einzelne Projektkonvention ignorierte: ein eigenes Logging-Framework anstelle des bestehenden, eine eigene Fehlerbehandlung, eine eigene Datenbankabstraktion. Technisch korrekt und architektonisch eine Katastrophe. Wer das schon erlebt hat, kennt dieses Gefühl: Der Code tut das Richtige, aber er gehört nicht dazu.

Das ist das Omission-Problem aus dem Paper: Der Agent hatte alle Informationen im Context Window, hat aber nicht alle beachtet.

Mein Weg zurück zur Struktur

Ich habe in einem früheren Beitrag beschrieben, warum KI-gestützte Entwicklung mehr Planung braucht. Dort habe ich auch empfohlen, die initiale Architekturarbeit ohne den Agenten zu machen. Bei der Arbeit in großen bestehenden Codebases hat sich für mich seitdem das Gegenteil als besser erwiesen: Planung gemeinsam mit dem Agenten. Der Agent kann eine Codebase systematisch erkunden, die selbst ich nicht vollständig kenne. Er scannt Verzeichnisstrukturen, identifiziert Patterns über hunderte Dateien hinweg und deckt Abhängigkeiten auf, die mir entgangen wären.

Was ich dort als Prinzip formuliert habe, hat sich seitdem zu einem konkreten Workflow verdichtet, den ich bei jedem größeren Vorhaben einsetze.

Der Workflow wirkt altmodisch, folgt aber direkt aus dem, was wir über Kontextdegradation wissen. Er macht überraschend viel Spaß, wenn man sich darauf einlässt.

Phase 1: Die Planungssession

Vor der ersten Zeile Code führe ich eine ausführliche Planungssession mit dem Agenten, und zwar als Dialog. Das ist der Teil, der mir am meisten Freude macht.

Die Session beginnt damit, dass der Agent die bestehende Codebasis systematisch untersucht: Verzeichnisstruktur, Architekturpatterns, Datenmodelle, Abhängigkeiten, Teststruktur, CI-Konfiguration. Ich weise ihn an, Fragen zu stellen. Gute Agenten tun das von selbst, die besten stellen dabei die richtigen Fragen.

Dann diskutieren wir. Ich bringe mein Architekturwissen ein, der Agent sein Patternwissen. Wir vergleichen den bestehenden Code mit Best Practices und suchen die Stellen, an denen er von etablierten Patterns abweicht, samt der Frage, ob das bewusste Entscheidungen oder gewachsene Inkonsistenzen sind. Ideen probieren wir aus und verwerfen sie wieder oder schärfen sie nach.

Es fühlt sich an wie Pair Programming mit einem Kollegen, der die gesamte Dokumentation der Welt gelesen hat, aber noch nie in diesem konkreten Gebäude gearbeitet hat. Man selbst kennt das Gebäude. Zusammen ergibt das etwas, das keiner allein hätte.

Am Ende steht ein gemeinsamer, abgestimmter Plan, und er ist konkret: klare Architekturentscheidungen, definierte Schnittstellen, identifizierte Risiken.

Diese Phase dauert eine Stunde, manchmal zwei. Ich habe lange gebraucht, um diese Zeit nicht als Verzögerung zu empfinden. Inzwischen ist sie für mich die wertvollste im gesamten Prozess.

Phase 2: Epics und Tickets

Den größten Unterschied hat für mich dieser Schritt gemacht. Den abgestimmten Plan zerlege ich in Epics, wieder gemeinsam mit dem Agenten. Jedes Epic ist ein abgeschlossener, kohärenter Arbeitsblock: „Datenbankschema erweitern", „API-Endpunkte implementieren", „Frontend-Komponenten bauen", „Integrationstests schreiben."

Die Epics teile ich weiter in Tickets auf. Ein Ticket beschreibt eine einzelne, fokussierte Aufgabe mit:

• Kontext: Welche Dateien sind betroffen? Welche bestehenden Patterns gelten?
• Aufgabe: Was genau soll gemacht werden?
• Akzeptanzkriterien: Woran erkennt man, dass es fertig ist?
• Abhängigkeiten: Welche Tickets müssen vorher erledigt sein?

Diese Tickets speichere ich als Markdown-Dateien in einem lokalen Verzeichnis, strukturiert nach Epics. Agent und Mensch können sie lesen, sie sind der gemeinsame Vertrag.

Direkt nach dem Erstellen der Epics aktualisiere ich die Anweisungsdatei des Agenten (die CLAUDE.md, AGENTS.md oder das jeweilige Äquivalent). Alle Architekturentscheidungen, Konventionen und Patterns aus der Planungssession fließen jetzt in die Datei ein, vor der ersten Zeile Code. So startet der Agent die Implementierung nicht nur mit einem Plan, sondern auch mit einem aktualisierten Regelwerk, das seine Arbeit über alle Epics hinweg konsistent hält.

Ein Beispiel für ein Ticket:

# EPIC-02/TICKET-03: User-Service um Rollenprüfung erweitern

## Kontext
- Bestehender UserService in `src/services/user.service.ts`
- Rollen-Enum in `src/types/roles.ts`
- Bestehendes Pattern: Guards nutzen `@UseGuards(RoleGuard)`
- Bestehende Tests in `src/services/__tests__/user.service.spec.ts`

## Aufgabe
- Methode `hasPermission(userId, permission)` zum UserService hinzufügen
- Bestehende Rollen-Hierarchie aus `roles.ts` respektieren
- Caching der Berechtigungen pro Request (nicht global)

## Akzeptanzkriterien
- [ ] Methode existiert und ist typisiert
- [ ] Unit-Tests für alle Rollen-Kombinationen
- [ ] Bestehende Tests laufen weiterhin grün
- [ ] Kein neues Logging-Pattern eingeführt

## Abhängigkeiten
- EPIC-02/TICKET-01 (Rollen-Enum erweitert)
- EPIC-02/TICKET-02 (Datenbank-Migration)

Phase 3: Epic für Epic

Ich weise dem Agenten ein komplettes Epic zu, mit allen Tickets darin. Das Epic gibt ihm Ort und Struktur: welcher Teil des Systems betroffen ist, welche Dateien relevant sind, welches Ziel am Ende stehen soll. Die Tickets innerhalb des Epics geben ihm die einzelnen Aufgaben in dieser Struktur, in der richtigen Reihenfolge, mit klaren Abhängigkeiten.

Das Gefühl, wenn ein Agent ein sauber strukturiertes Epic Ticket für Ticket abarbeitet und am Ende alles grün durch die Pipeline kommt, ist fantastisch. Es ist wie Lego bauen, wo man sonst Spaghetti entwirrt.

Das funktioniert, weil das Epic den Kontext liefert und die Tickets die Anweisungsdichte pro Schritt niedrig halten. Der Agent muss nur dieses Epic verstehen, das gesamte Projekt braucht er dafür nicht im Kopf. Innerhalb des Epics hat jedes Ticket 5–10 klare Constraints und nicht 50 oder 500, eine Menge weit unter der Degradationsschwelle, die das Paper beschreibt.

Kontextwechsel durch Compilerfehler, Lint-Probleme oder fehlschlagende Tests bleiben innerhalb des Epics lokal. Der Agent fixt den Fehler und kommt zum nächsten Ticket zurück, weil die Ticketliste der Anker ist. Sie steht schwarz auf weiß da, unabhängig vom Gesprächsverlauf, deshalb driftet nichts weg und nichts gerät schleichend in Vergessenheit.

Wenn ein Ticket innerhalb des Epics nicht klappt, ist der Fehler eingegrenzt. Man debuggt eine einzelne, klar umrissene Aufgabe innerhalb eines bekannten Kontexts. Das ist ein anderes Arbeiten als „der Agent hat irgendwo in 2.000 Zeilen etwas kaputt gemacht und ich darf suchen."

Phase 4: Wissen laufend konsolidieren

Mit dem ersten Schreiben ist die Anweisungsdatei nicht erledigt. Während der Implementierung tauchen immer neue Erkenntnisse auf: Eigenheiten des Testframeworks, implizite API-Konventionen, Patterns, die erst beim Arbeiten im Code sichtbar werden.

Nach jedem abgeschlossenen Epic weise ich den Agenten an, die Anweisungsdatei und bei Claude Code auch die Memory zu aktualisieren, manchmal auch nach einzelnen Tickets, wenn etwas Überraschendes aufgetaucht ist.

In diesem Moment wird temporäres Wissen zu persistentem Wissen. Hat der Agent entdeckt, dass ein bestimmtes Testframework eine Eigenheit hat, gehört das in die Anweisungsdatei. Dasselbe gilt für eine undokumentierte API-Konvention, auf die er gestoßen ist, oder für ein Pattern, das der bestehende Code konsistent einhält, das aber nirgends festgehalten war.

Ohne diesen laufenden Schritt erodiert das Wissen mit jeder neuen Session. So aber baut sich über die Zeit ein immer reichhaltigeres Kontextfundament auf, das den Einstieg in jede neue Session spürbar beschleunigt.

Was sich verschiebt

In der klassischen Softwareentwicklung war der Mensch gleichzeitig für Architektur, Planung und Implementierung zuständig. Agile hat versucht, diese Rollen zu verschmelzen: alle planen, alle coden, alle testen. Das funktionierte, solange der Mensch alles selbst schrieb und dabei lernte.

Mit Coding-Agenten beobachte ich, dass sich diese Rollen wieder trennen, in eine neue Konstellation und nicht zurück zum alten Wasserfall:

Der Mensch verschiebt sich Richtung Architektur und Planung. Er versteht das System, trifft die Entscheidungen, definiert die Aufgaben, prüft die Ergebnisse. Er schreibt weniger Code im Sinne von Zeichen in einer Datei, denkt aber mehr Code als vorher, weil das Entwerfen des Plans tieferes Verständnis erfordert, als es das bloße Tippen je tat.

Der Agent übernimmt mehr von der Implementierung. Er schreibt den Code, debuggt die Fehler und iteriert gegen die Pipeline. Er ist schnell und präzise und wird nicht müde, solange sein Kontext stimmt.

Die Tickets werden zur Schnittstelle zwischen beiden. Diese Schnittstelle ist schriftlich und strukturiert, und sie bleibt bestehen, anders als ein mündlicher Zuruf, ein Chat-Verlauf oder der flüchtige Kontext eines Prompts.

Ich habe diesen Workflow mit Claude Code, mit OpenAI Codex und mit GitHub Copilot CLI eingesetzt, und bei jedem Tool funktioniert er. Die Tools sind sich nicht ähnlich, aber der Workflow zielt auf das Problem, das alle teilen: die begrenzte Fähigkeit von Sprachmodellen, viele Anweisungen gleichzeitig zuverlässig zu befolgen.

Was ich daraus mitnehme

Wenn ich meine zwei Jahre mit Coding-Agenten in bestehenden Codebases destilliere, komme ich auf fünf Dinge, die den Unterschied gemacht haben:

1. Anweisungsdichte pro Interaktion niedrig halten. Ein Ticket mit einer Aufgabe und klarem Kontext. Das Gegenteil davon wäre „implementiere das ganze Feature". Weniger ist zuverlässiger, und die Forschung zeigt das auch.

2. Kontext persistent machen. Anweisungsdateien (CLAUDE.md, AGENTS.md), Memory-Dateien, Projektdokumentation. Alles, was der Agent über Sessions hinweg wissen muss, gehört in Dateien, denn Chat-Verläufe sind flüchtig.

3. Vor der Implementierung planen, gemeinsam mit dem Agenten. Die Planungssession ist die Phase, in der Mensch und Maschine ein gemeinsames Verständnis aufbauen, und deshalb keine Zeitverschwendung. Ohne dieses Verständnis ist jede Implementierung ein Ratespiel.

4. Tickets als Vertrag nutzen. Schriftlich, strukturiert, mit Kontext und Akzeptanzkriterien. Das Ticket ist der Anker, zu dem der Agent zurückkehrt, wenn ein Kontextwechsel ihn ablenkt.

5. Wissen nach jedem Meilenstein konsolidieren. Was der Agent gelernt hat, muss in persistente Dateien fließen. Sonst ist jede neue Session ein Kaltstart.

Handwerk heißt den Kontext beherrschen

In meinem ersten Beitrag habe ich geschrieben, dass sich Software-Handwerk in den letzten 10% zeigt. Im zweiten habe ich gefragt, wer diese 10% noch erkennen kann, und im dritten argumentiert, dass KI-gestützte Entwicklung mehr Planung braucht.

Dieser Beitrag ist die praktische Konsequenz: Handwerk in der Ära der Coding-Agenten heißt, den Kontext zu beherrschen. Das Modell muss man dafür nicht beherrschen, es wird ohnehin alle paar Monate besser. Gemeint ist die Fähigkeit, das eigene Wissen so zu strukturieren, dass eine Maschine es zuverlässig umsetzen kann.

Das ist eine neue Kompetenz, die es vor drei Jahren nicht gab und die schwerer ist, als sie aussieht.

Lange habe ich gehofft, dass die nächste Modellgeneration das Kontextproblem löst. Inzwischen glaube ich: Das Warten lohnt sich nicht. Kontextmanagement ist ein Merkmal probabilistischer Systeme und kein Bug in den heutigen Modellen. Selbst wenn das Context Window auf zehn Millionen Tokens wächst und die Modelle noch einmal deutlich besser werden: Die Fähigkeit, eine beliebig lange Liste von Anweisungen gleichzeitig und fehlerfrei zu befolgen, ist nicht das, was Transformer-Architekturen leisten. Die Lösung liegt eher im Prozess als im Modell.

Das ist weniger glamourös als „10x Developer durch KI." Aber es ist das, was in der Praxis funktioniert. Zumindest in meiner.

An diese Szene musste ich denken, als ich diesen Kommentar in einer Hacker-News-Diskussion gelesen habe:

“LLMs empower those without the domain knowledge or experience to identify if the output actually solves the problem. I have seen multiple colleagues deliver a lot of stuff that looks fancy but doesn’t actually solve the prescribed problem at all. It’s mostly just furniture around the problem.”

Furniture around the problem. Besser kann man es kaum sagen.

Das Möbelproblem

Ich sehe dieses Muster seit Monaten. Im Alltag, in Open-Source-Projekten und in Pull Requests. Jemand bekommt eine Aufgabe wie: “Implementiere eine Cache-Schicht für die API.” Was zurückkommt, sieht beeindruckend aus: Redis-Integration, TTL-Konfiguration, Cache-Invalidierung, Monitoring-Dashboards, Performance-Metriken, Tests, Dokumentation, sauber zusammengebaut.

Nur löst es das eigentliche Problem nicht. Denn gefehlt hat keine Cache-Schicht. Das eigentliche Problem war eine N+1-Query im ORM, die pro Request 200 Datenbankabfragen ausgelöst hat. Der Cache kaschiert das Symptom. Die Ursache bleibt genau da, wo sie war.

Ohne Fachwissen sieht man den Unterschied nicht. Mit KI-Werkzeugen kann man heute eine überzeugende Lösung für das falsche Problem produzieren, schneller und überzeugender als je zuvor.

Wie das Denken kippt

Der Hacker-News-Kommentator benennt noch ein zweites Phänomen. Ich halte es für fast noch gefährlicher:

“The second major problem is corrupting reasoning outright. I see people approaching LLMs as an exploratory process and letting the LLM guide the reasoning.”

Wenn man ein LLM als Denkwerkzeug für ein unscharf beschriebenes Problem benutzt, passiert etwas Heimtückisches: Das Modell zieht die Überlegungen langsam in eine andere Richtung. Es schlägt Wege vor, die plausibel klingen, aber nicht recht zum Problem passen. Es liefert Lösungen, die elegant wirken, aber Annahmen einschmuggeln, nach denen niemand gefragt und die niemand geprüft hat.

Weil das Modell so flüssig argumentiert, merkt man oft zu spät, wann man aufgehört hat, das ursprüngliche Problem zu lösen, und angefangen hat, dem Modell hinterherzulaufen.

Das ist kein Fehler im Modell. So funktioniert probabilistische Textgenerierung: Sie optimiert auf Plausibilität. Korrektheit ist dabei nicht das Ziel. Plausibilität ist aber ein miserabler Kompass, wenn Präzision gefragt ist.

In einer anderen Hacker-News-Diskussion hat es jemand gut auf den Punkt gebracht: KI ist kein Kollege. Sie ist ein Exoskelett. Sie verstärkt das, was schon da ist. Wenn man weiß, wohin man will, kommt man schneller ans Ziel. Wenn man es nicht weiß, läuft man schneller in die falsche Richtung, mit mehr Kraft und weniger Kontrolle.

Das Elektrolyt-Argument

Am meisten beunruhigt mich, wie leicht Kritik an KI-generiertem Output beiseitegeschoben wird. Der Kommentator beschreibt das perfekt:

“And the retort when I have to evaluate what they have done is ‘but it’s so powerful’. I stopped listening. It’s a pure faith argument without any critical reasoning.”

“But it’s so powerful.” Das sind die Elektrolyte unserer Branche.

Ob das Ergebnis das Problem löst, interessiert dann nicht mehr. Es geht nur noch um die angebliche Macht des Werkzeugs. Das Tool kann Rust und TypeScript. Den Code hat es in zehn Sekunden geschrieben. Es hat Hunderte Millionen oder Milliarden Parameter. Also muss das Ergebnis gut sein.

Das ist Techno-Animismus: der Glaube, dass ein hinreichend mächtiges System automatisch richtige Ergebnisse produziert, und dass die Komplexität des Werkzeugs schon irgendwie die Qualität des Outputs garantiert.

Wenn das Ergebnis Unsinn ist

Je länger ich mit KI-Coding-Agenten arbeite, desto klarer wird mir ein Punkt:

Wenn das Ergebnis Unsinn ist, hat der Mensch das Problem trotzdem.

Das Modell hat es nicht. Es tut genau das, wofür es gebaut wurde: plausiblen Text aus dem Input erzeugen, den es bekommt. Wenn der Input unvollständig, mehrdeutig, fachlich falsch oder einfach zu dünn ist, dann spiegelt der Output genau das wider. Aus schlechtem Input wird dann eben eleganter Müll.

Ein LLM ist darauf trainiert, hilfreich zu sein. Es ist nicht darauf trainiert, einem zu sagen: “Deine Frage ist schlecht gestellt. Du hast das Problem nicht verstanden. Geh zurück und denk noch mal nach.”

Deshalb stoßen unzureichende Anweisungen auf keinen Widerstand. Sie erzeugen jedes Mal eine polierte Antwort. Das macht diese Systeme für Menschen gefährlich, die nicht zuverlässig zwischen “sieht gut aus” und “löst das Problem” unterscheiden können.

Das Exoskelett-Gegenargument

Natürlich gibt es Junior-Entwickler, die durch Copilot-Vorschläge Muster lernen, denen sie sonst vielleicht monatelang nicht begegnet wären. Sie sehen, wie ein Repository Pattern aussieht, wie Dependency Injection strukturiert wird und wie ein sauberer API-Endpunkt gebaut ist. KI kann das Lernen beschleunigen.

Das funktioniert aber nur dann, wenn die Person aktiv versteht, warum der Vorschlag so aussieht, wie er aussieht. Sie muss ihn lesen, prüfen und verändern, das Werkzeug also als Lehrer benutzen und nicht als Ghostwriter. Der Vorschlag ist nützlich als Ausgangspunkt, solange er ein Ausgangspunkt bleibt.

Das Problem beginnt an der Grenze zwischen Verstehen und Abnicken. KI-Werkzeuge sind so gebaut, dass diese Grenze fast unsichtbar wird. Es gibt keinen Moment, in dem das Tool sagt: “Hier hast du aufgehört zu denken.” Der Output sieht gleich aus, ganz egal, ob der Mensch ihn verstanden hat oder nicht.

Die Frage nach Verantwortung

Wenn man diesen Gedanken zu Ende verfolgt, landet man bei einer Frage, um die sich die Branche noch immer drückt:

Wenn der Mensch die Anweisungen gibt und das Modell den Code schreibt, wer trägt dann die Verantwortung, wenn dieser Code Schaden anrichtet?

Heute ist die Antwort klar: der Mensch. Wer Code in Produktion bringt, ist auch dafür verantwortlich.

Aber was passiert, wenn die Ketten länger werden? Etwa wenn ein Agent an Sub-Agenten delegiert, die selbst entscheiden, und der Mensch am Anfang der Kette das Ergebnis im Detail gar nicht mehr rekonstruieren kann?

Eine zugespitzte, aber nicht absurde Zukunftsfrage wäre diese: Wenn wir eines Tages AGI haben und sich ein konkretes Ergebnis keinem klar identifizierbaren menschlichen Autor mehr zuordnen lässt, wer bekommt dann die gerichtliche Verfügung? AGI, Datacenter Oregon, Stockwerk 5, Rack #10202?

So satirisch die Frage klingt, das Problem dahinter ist ernst. Verantwortung verschwindet nicht einfach, nur weil Verständnis verschwindet. Sie wird dann nur verantwortungslos ausgeübt. Wer Code in Produktion bringt, bleibt verantwortlich, ob er ihn verstanden hat oder nicht. KI-Werkzeuge machen es nur viel leichter, Ergebnisse zu produzieren, für die man gerade stehen muss, ohne sie zu durchdringen.

Was bleibt

Ich bin nicht gegen KI-Werkzeuge. Ich nutze sie jeden Tag. Aber ich nutze sie als das, was sie sind: Werkzeuge, die mein Verständnis umsetzen, ohne es zu ersetzen.

Der Unterschied zwischen gutem und schlechtem Handwerk lag schon immer darin, zu wissen, wann und wie man das Werkzeug benutzt und wann man es wieder aus der Hand legt.

Pflanzen brauchen Wasser. Keine Elektrolyte.

Wer merkt überhaupt, dass die 10% fehlen?

Das Prüfproblem

Beim KI-generierten C-Compiler CCC produzieren die Optimierungsstufen -O0 bis -O3 byte-identische Binaries. Die Flags existieren, sie werden akzeptiert, sie erzeugen keine Fehlermeldung. Alles sieht korrekt aus.

Um zu erkennen, dass hier etwas grundlegend nicht stimmt, muss man wissen, was Compiler-Optimierung tun sollte. Man muss wissen, dass -O2 Schleifen entrollen sollte, dass -O3 aggressives Inlining betreibt und dass die resultierenden Binaries sich in Größe und Struktur deutlich unterscheiden müssen. Aus der Dokumentation kommt dieses Wissen nicht. Man erwirbt es in Jahren der Arbeit mit Compilern, beim Lesen von Assembler-Output und beim Debugging von Optimierungsproblemen.

Der OCaml-PR aus meinem letzten Artikel illustriert dasselbe Muster aus einer anderen Richtung. Die Copyright-Header nannten einen realen Jane-Street-Entwickler als Autor. Wer das OCaml-Ökosystem nicht kennt, wer nicht weiß, wer Mark Shinwell ist und woran er arbeitet, dem fällt das nicht auf. Die Community erkannte die Halluzination sofort. Sie hatte den Kontext, den der Einreicher nicht hatte.

Prüfkompetenz ist unsichtbar, bis sie fehlt.

Automation Complacency

In der Luftfahrt gibt es ein Phänomen, das seit den 1990er Jahren erforscht wird: Automation Complacency, die schleichende Erosion menschlicher Fähigkeiten durch Übervertrauen in automatisierte Systeme. Piloten, die sich zu stark auf den Autopiloten verlassen, verlieren nach und nach die Fähigkeit, in kritischen Situationen manuell zu fliegen. Das liegt nicht daran, dass sie schlechter werden. Können braucht Übung, und Übung braucht Gelegenheit.

Die Parallele zur Softwareentwicklung ist beunruhigend direkt. Wenn ein Coding-Agent in Sekunden eine Funktion produziert, die „funktioniert", sinkt der Anreiz, den Code im Detail zu verstehen. Warum eine Stunde mit einem Algorithmus ringen, wenn die KI ihn in zehn Sekunden schreibt? Wozu manuell Relocations debuggen, wenn der Agent den Linker-Code generiert, oder sich durch eine Spezifikation arbeiten, wenn das Modell sie „kennt"? Weil man nur prüfen kann, was man versteht, und nur versteht, womit man gerungen hat.

Erfahrung ist kein Zustand

Viele stellen sich Erfahrung als etwas vor, das man irgendwann „hat". Ein Plateau, auf dem man sich ausruhen kann. 35 Jahre Programmierung, also kann ich alles bewerten.

Das ist falsch. Erfahrung ist ein fortdauernder Prozess, und Beobachten allein reicht dafür nicht. Sie entsteht durch Tun: durch das Scheitern an einer Race Condition um zwei Uhr nachts, durch das Debuggen eines Memory Leaks, der erst unter Last auftritt. Oder durch den Moment, in dem ein Test grün ist und die Produktion trotzdem brennt, und man lernt, warum.

Jede Abstraktionsschicht, die man zwischen sich und das Problem legt, ist eine Schicht weniger Erfahrung, die man sammelt. KI-Agenten sind die mächtigste Abstraktionsschicht, die unsere Branche je gesehen hat. Das ist gleichzeitig ihre größte Stärke und ihre größte Gefahr.

Ob ich noch prüfen kann, ist dabei nicht die Frage, ich habe 35 Jahre Kontext. Mich treibt um, ob jemand, der heute anfängt, diesen Kontext jemals aufbauen wird. Wenn die ersten 90% in Sekunden erledigt sind, wann lernt man dann, die fehlenden 10% überhaupt zu sehen?

Was ich in der Praxis tue

Ich bin kein Maschinenstürmer. Ich nutze KI-Coding-Agenten täglich, und sie machen mich produktiver. Aber ich habe die Alternative gesehen und mir deshalb über die letzten Monate Strukturen gebaut, die sicherstellen, dass die Prüfung nicht wegfällt.

Tests vor dem ersten Prompt

Bevor ich einen Agenten auf ein Problem loslasse, schreibe ich selbst die Tests. Das zwingt mich, das Problem zu verstehen, bevor ich es delegiere. Was soll die Funktion tun? Welche Randfälle gibt es, und was darf auf keinen Fall passieren?

Erstaunlich viele Entwickler überlassen dem Agenten gleichzeitig das Problem und die Verifikation und wundern sich dann, dass beides perfekt zusammenpasst und trotzdem falsch ist. Ein Agent, der seinen eigenen Code testet, ist wie ein Schüler, der seine eigene Klausur benotet.

Der Agent bekommt eine Pipeline

Jeder Agent in meinem Workflow hat eine definierte Pipeline: Compile, Lint, Test. Sie ist Pflicht und lässt sich nicht übergehen. Der Agent sieht die Fehler seiner eigenen Arbeit und iteriert. Das fängt die offensichtlichen Probleme ab: Syntaxfehler, fehlende Imports, kaputte Typen.

Aber eine grüne Pipeline beweist keine Korrektheit. Sie ist ein notwendiges Minimum. Die dekorativen Optimierungsstufen von CCC würden jede Pipeline bestehen, die halluzinierten Copyright-Header auch.

Quality Gates als Skripte

Für wiederkehrende Probleme, die mir aufgefallen sind, schreibe ich explizite Prüfskripte: Gibt es offene TODOs im Code? Werden Fehler verschluckt statt behandelt? Gibt es Funktionen ohne Tests? Werden Abhängigkeiten importiert, die nicht im Projekt definiert sind? Das sind automatisierbare Heuristiken. Verständnis ersetzen sie nicht, aber sie sind ein Sicherheitsnetz für die Dinge, die man schon einmal übersehen hat.

Der QA-Loop

Der aufwendigste Teil meines Workflows ist ein Prüfzyklus: Ich lasse einen Agenten die Arbeit eines anderen Agenten überprüfen. Die Findings werden zu Tickets, die Tickets werden abgearbeitet, und dann wird die Überarbeitung erneut geprüft.

Das bildet den Prozess ab, der in guten Software-Teams seit Jahrzehnten funktioniert: Jemand schreibt, jemand anderes prüft, und die Diskussion dazwischen ist der Ort, an dem Verständnis entsteht. Der Unterschied: Im QA-Loop bin ich der Mensch, der die Findings liest und entscheidet, ob sie relevant sind. Der Agent findet Muster, ich bewerte sie. Das setzt voraus, dass ich bewerten kann.

Der stille Kreislauf

In der Softwareentwicklung gibt es einen Kreislauf, der selten ausgesprochen wird:

Um Fehler zu erkennen, braucht man Erfahrung. Erfahrung sammelt man durch Fehler, und Fehler macht man nur, wenn man Gelegenheit dazu hat.

Wenn KI-Agenten den Code schreiben, bevor der Mensch das Problem durchdrungen hat, übernehmen sie die Gelegenheit, Fehler zu machen, und unterbrechen damit diesen Kreislauf. Böswillig ist das nicht, und an schlechten Ergebnissen liegt es auch nicht. Die Ergebnisse sind zu gut und zu bequem, und sie kommen zu schnell: Das nimmt den Anreiz, tiefer zu graben.

Ich beobachte in meinem beruflichen Umfeld eine merkwürdige Bereitschaft, diese Unterbrechung zu akzeptieren. Entwickler automatisieren ihre eigene Lernkurve weg, ohne ihre Fähigkeiten geringzuschätzen. Der kurzfristige Produktivitätsgewinn ist so überzeugend, dass die langfristigen Kosten abstrakt bleiben.

Handwerk heißt prüfen können

In meiner ersten Firma in Erfurt, Mitte der 90er, stand auf unserer Website ein Satz: „Die Entwicklung von Software ist heute eine rein ingenieurtechnische Leistung. Dies gehört zu unserem Handwerk."

Handwerk bedeutete dort nicht nur, etwas herstellen zu können, sondern auch, die Qualität des Hergestellten beurteilen zu können. Ein Tischler erkennt an einer Verbindung, ob sie hält, und ein Maurer sieht an einer Mauer, ob sie gerade ist. Ein Softwarehandwerker liest Code und weiß, ob er funktioniert, weil er ihn versteht. Ausführen muss er ihn dafür nicht.

Diese Fähigkeit ist die Grundlage von allem, was danach kommt: Wartung, Debugging, Weiterentwicklung, Sicherheit. Sie entsteht nur durch das, was keine KI einem abnehmen kann: die fortdauernde Praxis des eigenen Tuns, oft mühsam und manchmal frustrierend.

90% fertig ist ein guter Anfang. Wenn wir aber 100 Projekte zu 90% fertig haben, wie viel werden uns dann die 100-mal fehlenden 10% kosten?

Aber sind sie es?

Wir arbeiten mit Wahrscheinlichkeiten

Was man über große Sprachmodelle verstehen muss: Sie arbeiten mit Wahrscheinlichkeiten. Jedes generierte Token ist eine statistische Vorhersage, das wahrscheinlichste nächste Wort basierend auf dem Kontext. Das funktioniert erstaunlich gut. Oft sogar besser als erwartet.

Aber „wahrscheinlich richtig" und „richtig" sind zwei grundverschiedene Dinge.

In der Praxis bedeutet das: Je größer und komplexer ein Projekt wird, desto mehr akkumulieren sich kleine Ungenauigkeiten. Dort beginnen die interessanten letzten 10%.

Fall 1: Claude baut einen C-Compiler

Anthropic hat im Februar 2026 Claude’s C Compiler (CCC) vorgestellt: ein in Rust geschriebener C-Compiler, bei dem 100% des Codes von Claude Opus 4.6 stammt. Ein Mensch hat nur die Testfälle geschrieben. Das Ergebnis: Frontend, SSA-basierte IR, Optimizer, Code-Generator, Assembler, Linker und DWARF-Debug-Info. Alles from scratch, ohne Compiler-spezifische Dependencies.

Die Schlagzeile: „Kann den Linux-Kernel kompilieren."

Ganz so einfach ist es nicht. Ein unabhängiger Benchmark von Harshanu zeigt, was in den Details steckt:

• Korrektheit: CCC kompilierte alle 2.844 C-Dateien des Linux-Kernels fehlerfrei. Beeindruckend.
• Linker-Problem: Der Build scheiterte dann mit 40.784 undefined-reference-Fehlern. CCC generiert fehlerhafte Relocations für __jump_table und __ksymtab. Der Compiler funktioniert. Der Linker nicht.
• Performance: CCC-kompiliertes SQLite braucht 2 Stunden für einen Benchmark, den GCC in 10 Sekunden schafft. Bei Subqueries: 158.000x langsamer.
• Optimierung: Die Flags -O0 bis -O3 produzieren byte-identische Binaries. Die Optimierungsstufen sind dekorativ.

Die Ursache ist technisch aufschlussreich: CCC hat keine vernünftige Register-Allocation. Statt Variablen in CPU-Registern zu halten, schiebt es alles über den Stack, mit Offsets bis zu 11.000 Bytes Tiefe. Jede Operation wird zu stack → rax → stack, wobei %rax als einziges Shuttle-Register dient.

„The assembly output reminds me of the quality of an undergraduate’s compiler assignment." (Kommentar auf GitHub Issue #1, in dem „Hello World" nicht kompilierte)

Der Compiler ist zu 90% fertig. Er parst C, generiert Maschinencode und versteht die Architektur. Aber die letzten 10% (effiziente Register-Allocation, korrekte Relocations, funktionierende Optimierungspasses) sind die Dinge, an denen GCC seit 1987 mit tausenden Entwicklern arbeitet.

Fall 2: KI schreibt einen DWARF-Debugger für OCaml

Ein noch aufschlussreicherer Fall spielte sich im OCaml-Repository ab. Ein Entwickler reichte einen Pull Request ein: DWARF v5 Debugging Support für den OCaml Native Compiler. In der Beschreibung: ein sauber strukturiertes Feature mit Core DWARF Support, Platform-Unterstützung für Linux und macOS, einem LLDB-Plugin und einer Testsuite.

Dann kam die Community-Review.

Erste Frage: Die Copyright-Header nannten Mark Shinwell als Autor, einen Jane-Street-Entwickler, der tatsächlich an ähnlichem Code im oxcaml-Repository arbeitete. Hat die KI Code kopiert oder die Attribution halluziniert?

Die Antwort des Einreichers:

„Claude Sonnet 4.5 (Claude Code) wrote most of it with ChatGPT 5 (Codex) reviewing and Claude addressing issues in each review. Codex wrote the last 10% or so when Claude kept getting stuck. I did not write a single line of code."

Der PR wurde geschlossen, und zwar nicht, weil der Code nicht funktionierte. Die Gründe waren grundlegender:

• Copyright: Die KI hat Copyright-Header eines realen Menschen generiert. Das ist ein juristisches Problem.
• Wartbarkeit: Tausende Zeilen Code, die niemand (auch nicht der Einreicher) im Detail versteht, können von einer Community nicht gewartet werden.
• Prozess: Es gab keine Design-Diskussion. Kein Review durch die Personen, die den Code langfristig pflegen müssen.

Der OCaml-Maintainer formulierte es diplomatisch: Es sei ein Fall von „different-to-the-point-of-being-incompatible software development processes". Was er damit meinte: Software-Entwicklung besteht nicht nur darin, Code zu produzieren.

Fall 3: Die Sicherheitsperspektive

Ich habe jahrelang an Systemen gearbeitet, bei denen Korrektheit keine Ermessensfrage war. Wenn ich mir den CCC-Compiler aus dieser Perspektive anschaue, sehe ich ein Muster, das mir Sorgen macht.

Für jemanden, der Sicherheits- oder Infrastrukturverantwortung trägt, ist „meistens korrekt" ein Risiko. Ein Compiler, der in der Mehrzahl der Fälle valide Binaries produziert, aber bei bestimmten Konstellationen fehlerhafte Relocations generiert, ist nicht zuverlässig.

Ein Linker, der „fast alle" Symbole korrekt auflöst, erzeugt Laufzeitfehler, die sich kaum reproduzieren lassen. Arbeitet ein DWARF-Generator nur ungefähr spezifikationskonform, wird die gesamte Fehlersuche unbrauchbar.

In sicherheitsrelevanten Kontexten gibt es keinen graduellen Zustand zwischen sicher und unsicher. Eine Tür, die nur in neun von zehn Fällen verriegelt, erfüllt ihre Funktion nicht. Dasselbe gilt für Compiler, kryptografische Implementierungen, Zugriffskontrollsysteme oder medizinische Software. Wo Korrektheit zwingend ist, reicht „wahrscheinlich richtig" nicht aus. Hier kollidiert die probabilistische Natur aktueller KI-Systeme mit den Anforderungen, die wir an Technik stellen, der wir vertrauen.

Was steckt in den letzten 10%?

Wenn man die Fälle zusammennimmt, kristallisiert sich heraus, was die letzten 10% sind:

Edge Cases und Spezifikationstreue. Ein C-Compiler muss nicht nur typischen Code kompilieren, sondern auch obskure Corner Cases der Spezifikation korrekt behandeln. GCC hat dafür 40 Jahre Bug-Reports.

Performance-Engineering. Funktionierender Code und effizienter Code sind verschiedene Dinge. CCC zeigt das drastisch: korrekte Ergebnisse, aber 158.000x langsamer bei bestimmten Operationen.

Integration in bestehende Systeme. Software existiert nicht isoliert. Der OCaml-PR scheiterte an der Integration in einen Community-Prozess, an Copyright-Fragen, an Wartbarkeit. Der Code selbst war nicht das Problem.

Die Fähigkeit, das eigene Werk zu erklären. Wenn der Einreicher eines PRs den Code nicht erklären kann, weil er ihn nicht geschrieben hat, fehlt das tiefe Verständnis, das für Debugging, Wartung und Weiterentwicklung nötig ist.

Determinismus. Sicherheitskritische Systeme brauchen deterministische, verifizierbare Ergebnisse. Statistische Annäherungen reichen dort nicht.

Wer macht die letzten 10%?

Das ist der paradoxe Teil.

Die letzten 10% erfordern genau die Expertise, die man nur durch jahrelange Praxis aufbaut. Register-Allocation verstehen heißt, CPU-Architekturen verstehen. Korrekte Relocations schreiben heißt, ELF-Binärformate verstehen. Wer Code reviewbar machen will, muss Software-Engineering als sozialen Prozess verstehen.

Das sind Fähigkeiten, die man nicht durch Prompting erlernt.

Die Ironie: Wenn wir eine Generation von Entwicklern ausbilden, die mit KI die ersten 90% überspringt, wer entwickelt dann die Expertise für die letzten 10%? Die Frage ist nicht rhetorisch gemeint. Sie ist die zentrale Herausforderung der nächsten Jahre in unserer Branche. Das Problem ist nicht nur das Überspringen, sondern dass die „Junior-Tasks", an denen man früher gelernt hat (die „Drecksarbeit"), jetzt wegfallen. Man lernt Compilerbau nicht, indem man dem Senior zuschaut, sondern indem man erst mal einen Parser schreibt. Wenn die KI das macht, fehlt das Trainingsgelände.

„There will always be room for individuals to write software based on their unique knowledge. The craft of writing software will not become obsolete." (Freeman Dyson, 1998)

Dieses Zitat stand auf der alten Version dieser Webseite, als ich sie 2011 gründete. Es ist heute aktueller denn je.

Was bedeutet das für die Praxis?

Ich nutze KI-Tools täglich. Sie sind hervorragend für Boilerplate, für das Erkunden von APIs, für erste Entwürfe. Sogar für komplexe und große Softwareentwicklung. Aber ich habe aufgehört, sie als Ersatz für Verständnis zu betrachten.

KI taugt für den ersten Entwurf: Prototyping, Exploration, Gerüstbau. Die Architektur lege ich vorher fest, wie in der Rückkehr zum Wasserfall beschrieben. Aber alles, was in Produktion geht, braucht menschliche Review. Jede Zeile, die deployed wird, muss verstanden sein. Dafür muss man die Grundlagen kennen. Wer nicht weiß, wie ein Compiler funktioniert, kann keinen KI-generierten Compiler bewerten. Es braucht außerdem Ehrlichkeit über Grenzen. „90% fertig" ist nicht „fertig".

90% ist ein guter Anfang. Aber Software-Handwerk zeigt sich in den letzten 10%.

Das ist der häufigste Prompt, mit dem Entwickler ein neues Projekt starten, und der schlechteste. Nicht weil das Modell nichts produziert, im Gegenteil. Es produziert sofort. Ordnerstruktur, Konfiguration, Routing, Datenbankschema, UI-Komponenten. In Minuten entsteht etwas, das aussieht wie eine Anwendung.

Aber es ist keine Architektur. Es ist eine Halluzination von Architektur.

Das Architekturproblem

Wenn ich einem KI-Agenten sage „Baue mir eine Projektverwaltung mit Benutzerrollen und Zeiterfassung", trifft er in den ersten Sekunden Dutzende von Architekturentscheidungen: Welches Framework? Welches ORM? Wie werden Rollen modelliert (RBAC, ACL, oder einfache Flags)? Wie wird Zeiterfassung abgebildet (pro Aufgabe, pro Projekt, pro Tag)? Monolith oder Services?

Das Modell entscheidet nicht. Es rät. Es wählt das statistisch wahrscheinlichste Setup, also das, was in den meisten Tutorials und GitHub-Repos vorkommt. Für einen Prototypen mag das reichen. Für eine Anwendung, die gewartet, erweitert und betrieben werden muss, ist es ein Fundament aus Zufällen.

Was das Werkzeug selbst verrät

Ein Blick auf die Werkzeuge selbst ist aufschlussreich, und ein wenig meta.

Ich nutze Claude Code als meinen Hauptagenten. Dieses Werkzeug hat einen eingebauten Plan Mode: Bevor Code geschrieben wird, erstellt der Agent einen Plan, den der Mensch absegnen muss. Das Tool ist buchstäblich so gebaut, dass es zuerst denkt und dann implementiert.

Im Projekt-Root liegt eine Datei namens CLAUDE.md. Sie enthält Architekturregeln, Konventionen, Patterns, alles, was der Agent wissen muss, um konsistenten Code zu schreiben. Ohne diese Datei passiert etwas Vorhersagbares: Der Agent liest den bestehenden Code, leitet daraus ab, was „normal" ist, und reproduziert es. Wenn der Code inkonsistent ist, wird der neue Code es auch sein.

„Claude does not invent architecture. It copies what it sees." (aus der Claude Code Dokumentation)

Die Ironie ist kaum zu übersehen: Das Werkzeug selbst ist für Wasserfall gebaut. Spezifiziere, plane, dann implementiere. In genau dieser Reihenfolge. Die Entwickler bei Anthropic haben das nicht aus Nostalgie so gebaut. Es ist die einzige Reihenfolge, die zuverlässig funktioniert.

Wasserfall in 15 Minuten

Ich bin nicht der Einzige, der das beobachtet hat.

Harper Reed hat einen Workflow beschrieben, der mit einer Konversation beginnt: Er lässt sich vom Modell Frage für Frage durch seine Idee führen, bis eine vollständige Spezifikation steht, eine spec.md. Dann generiert ein Reasoning-Modell daraus einen Projektplan mit kleinteiligen, aufeinander aufbauenden Aufgaben. Erst danach wird Code geschrieben.

Addy Osmani, der im Chrome-Team bei Google arbeitet, beschreibt denselben Ansatz und nennt ihn beim Namen: „Waterfall in 15 minutes." Eine komprimierte, aber vollständige Planungsphase (Anforderungen, Architekturentscheidungen, Datenmodell, Teststrategie), bevor die erste Zeile Code entsteht.

Das Muster ist eindeutig: Die Leute, die erfolgreich mit KI-Agenten arbeiten, planen mehr als vorher.

Warum Agile hier nicht greift

Das widerspricht einem Grundsatz, der unsere Branche seit 20 Jahren prägt: Lass die Architektur emergent entstehen. Schreib Code, lerne dabei, refaktoriere. „Working software over comprehensive documentation."

Dieses Prinzip setzt voraus, dass der Mensch beim Codieren lernt. Dass das Schreiben von Code nicht nur ein Produktionsprozess ist, sondern auch ein Denkprozess. Dass die Architektur im Kopf des Entwicklers reift, während er implementiert.

Wenn ein KI-Agent den Code schreibt, bleibt dieses Lernen aus. Die Implementierung ist in Minuten fertig, aber das Verständnis für die Entscheidungen, die darin stecken, ist es nicht. Die Architektur emergiert nicht, sie driftet: Jeder Prompt fügt eine Schicht hinzu, die auf der vorherigen aufbaut, ohne dass jemand das Gesamtbild im Kopf hat.

Mein Workflow für Greenfield-Projekte

In den letzten Monaten habe ich einen Workflow entwickelt, der diese Probleme angeht. Er ist nicht elegant, aber er funktioniert.

Phase 1: Architektur ohne Agent

Bevor ein Agent eine Zeile Code sieht, schreibe ich ein Architekturdokument, ein einfaches Markdown-Dokument (kein Foliensatz) mit:

• Ziel: Was soll die Software tun? Was explizit nicht?
• Datenmodell: Welche Entitäten gibt es? Wie hängen sie zusammen?
• Technische Entscheidungen: Welches Framework, warum? Welche Patterns?
• Schnittstellen: Welche APIs, welche Formate?

Das dauert eine Stunde. Manchmal zwei. Aber diese Zeit spare ich mehrfach wieder ein, weil der Agent danach nicht raten muss.

Phase 2: Aufgaben definieren, klein und sequenziell

Ich zerlege die Architektur in Aufgaben, die einzeln abarbeitbar und einzeln testbar sind. Nicht „Implementiere die Benutzerverwaltung", sondern „Erstelle das User-Model mit diesen Feldern" → „Schreibe die Registrierung mit diesen Validierungsregeln" → „Implementiere die Login-Route mit diesen Akzeptanzkriterien."

Jede Aufgabe hat ein klares Ergebnis und klare Grenzen. Innerhalb dieser Grenzen bekommt der Agent Kontext.

Phase 3: Implementierung mit Pipeline

Jede Aufgabe durchläuft eine automatisierte Pipeline: Compile, Lint, Test. Der Agent iteriert gegen diese Pipeline, bis alles grün ist. Dazu laufen eigene Quality-Gate-Skripte: Prüfungen auf offene TODOs, verschluckte Fehler, fehlende Tests.

Phase 4: Review-Zyklus

Nach jeder abgeschlossenen Aufgabe lasse ich den Code reviewen, teilweise von einem zweiten Agenten, immer von mir. Nicht nur auf Korrektheit, sondern auch auf Architekturkonformität: Hält sich der Code an die Entscheidungen aus Phase 1? Oder hat der Agent stillschweigend ein anderes Pattern eingeführt?

Letzteres passiert häufiger, als man denkt.

Was alt aussieht, ist neu gedacht

Ja, das sieht aus wie Wasserfall. Spezifikation → Design → Implementierung → Test → Review. In genau dieser Reihenfolge.

Aber es gibt wesentliche Unterschiede zum Wasserfall der 90er:

• Geschwindigkeit: Der gesamte Zyklus dauert Stunden, die Planung eine Stunde. Früher waren es Monate, für die Planung allein drei.
• Iteration: Nach jedem Durchlauf kann ich das Architekturdokument anpassen. Es ist ein lebendiges Dokument und kein Vertrag.
• Granularität: Die Aufgaben sind so klein, dass Fehler lokal bleiben. Ein falscher Prompt betrifft nur eine einzelne Funktion.

Was gleich geblieben ist, ist das Prinzip: Denken vor Tippen. Der alte Wasserfall scheiterte daran, dass zwischen dem Denken und dem Ergebnis Monate lagen und sich die Anforderungen änderten. Der neue Wasserfall hat dieses Problem nicht, weil die Implementierung nur Minuten dauert. Was früher zu langsam war, ist jetzt genau richtig.

Handwerk heißt planen können

In 35 Jahren Softwareentwicklung habe ich beide Extreme erlebt: den starren Wasserfall der 90er mit seinen tonnenschweren Pflichtenheften und die agile Gegenbewegung, die Planung fast zur Sünde erklärte. Beides in Reinform hat nicht funktioniert.

Was jetzt entsteht, ist etwas Drittes, ein Workflow, den das Werkzeug erzwingt: Der Mensch denkt, entscheidet die Architektur und prüft das Ergebnis. Die Maschine tippt, implementiert die Architektur und iteriert.

Das erfordert Fähigkeiten, die in der agilen Welt manchmal vernachlässigt wurden: ein System zu entwerfen, bevor es existiert, und Entscheidungen zu treffen und zu begründen, bevor der erste Test grün ist. Mit einem Wort: planen.

90% fertig in Minuten, aber nur, wenn die Architektur stimmt. Die schreibt kein Agent.

Frank Csehan Elsastr. 20 16540 Hohen Neuendorf

E-Mail: service@ajagara.com

2. Allgemeines zur Datenverarbeitung

Diese Website ist ein persönliches Blog ohne kommerzielle Absicht. Ich erhebe so wenig personenbezogene Daten wie möglich. Es werden keine Cookies gesetzt, kein Tracking eingesetzt und keine Daten an Dritte weitergegeben.

3. Hosting

Diese Website wird gehostet bei:

Telekom Deutschland GmbH (Homepage-Center) Landgrabenweg 151 53227 Bonn

Beim Aufruf dieser Website erhebt der Hosting-Anbieter automatisch Informationen in sogenannten Server-Logfiles, die Ihr Browser automatisch übermittelt. Dies sind:

• IP-Adresse des anfragenden Rechners
• Datum und Uhrzeit des Zugriffs
• Name und URL der abgerufenen Datei
• Übertragene Datenmenge
• Meldung, ob der Abruf erfolgreich war
• Erkennungsdaten des verwendeten Browsers und Betriebssystems
• Referrer-URL (die zuvor besuchte Seite)

Diese Daten werden zur Sicherstellung eines störungsfreien Betriebs der Website und zur Erkennung und Abwehr von Angriffen erhoben. Die Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse). Die Server-Logfiles werden nach spätestens 7 Tagen gelöscht, sofern keine weitergehende Aufbewahrung zu Beweiszwecken erforderlich ist.

4. Keine Weitergabe an Dritte

Es werden keine personenbezogenen Daten an Dritte weitergegeben. Es werden keine externen Dienste (Analytics, Tracking, Social-Media-Plugins, externe Schriftarten, CDNs) eingebunden.

Die auf dieser Website verwendeten Schriftarten (Inter, Source Serif 4, JetBrains Mono) werden lokal von diesem Server geladen. Es findet keine Verbindung zu Google oder anderen externen Font-Anbietern statt.

5. Keine Cookies

Diese Website verwendet keine Cookies.

6. Kontaktaufnahme per E-Mail

Wenn Sie mich per E-Mail kontaktieren, werden Ihre Angaben (E-Mail-Adresse, ggf. Name und Inhalt der Nachricht) zum Zweck der Bearbeitung Ihrer Anfrage gespeichert. Diese Daten werden nicht ohne Ihre Einwilligung weitergegeben. Die Verarbeitung erfolgt auf Grundlage von Art. 6 Abs. 1 lit. b DSGVO (Vertragsanbahnung) bzw. Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse). Ich lösche die Daten, sobald sie für den Zweck ihrer Verarbeitung nicht mehr erforderlich sind.

7. Ihre Rechte

Sie haben gemäß DSGVO folgende Rechte:

• Auskunft (Art. 15 DSGVO): Sie können Auskunft über Ihre bei mir gespeicherten personenbezogenen Daten verlangen.
• Berichtigung (Art. 16 DSGVO): Sie können die Berichtigung unrichtiger Daten verlangen.
• Löschung (Art. 17 DSGVO): Sie können die Löschung Ihrer gespeicherten Daten verlangen, soweit keine gesetzliche Aufbewahrungspflicht besteht.
• Einschränkung der Verarbeitung (Art. 18 DSGVO): Sie können die Einschränkung der Verarbeitung Ihrer Daten verlangen.
• Datenübertragbarkeit (Art. 20 DSGVO): Sie können verlangen, Ihre Daten in einem gängigen, maschinenlesbaren Format zu erhalten.
• Widerspruch (Art. 21 DSGVO): Sie können jederzeit gegen die Verarbeitung Ihrer Daten Widerspruch einlegen.

8. Beschwerderecht

Sie haben das Recht, sich bei einer Datenschutz-Aufsichtsbehörde über die Verarbeitung Ihrer personenbezogenen Daten zu beschweren.

9. Änderung dieser Datenschutzerklärung

Diese Datenschutzerklärung ist aktuell gültig (Stand: Februar 2026). Durch Weiterentwicklung der Website oder aufgrund geänderter gesetzlicher Vorgaben kann eine Anpassung erforderlich werden.

Dieser Satz stand 1997 auf einer Website, für die ich mitverantwortlich war. Sie war mit Framesets gebaut, mit „Claris Home Page Version 2.0b1“ erstellt und lief auf einem Server in Erfurt. Damals gab es weltweit etwa eine Million Websites, heute sind es mehr als 1,4 Milliarden.

Mein Name ist Frank Csehan, ich mache seit mehr als 35 Jahren Software, und den Satz von damals würde ich heute wieder so schreiben, an keiner Stelle anders.

Als künstliche Intelligenz schon einmal als gescheitert galt

Die gleiche Website hatte einen Bereich, der damals üblich war: „Ausgewählte Links“. Zwischen Oracle-Dokumentationen und Hewlett-Packard-Downloads stand unter der Überschrift Data Warehouse und Data Mining dieser Eintrag:

„Der letzte Versuch, unter anderem über Data Mining dem Thema Künstliche Intelligenz Leben (im übertragenen Sinne) einzuhauchen. Das Cyc-Projekt.“

Das war 1997, und künstliche Intelligenz war ein Thema, dem man „Leben einhauchen“ musste, weil es praktisch für tot erklärt worden war. Der sogenannte KI-Winter lag noch nicht lange zurück, neuronale Netze galten als akademische Spielerei. Der Hype der 1980er Jahre war abgeklungen, die Finanzmittel waren versiegt, und was übrig blieb, war Data Mining: der Versuch, zumindest etwas Nützliches aus großen Datenmengen zu extrahieren.

Wir bauten Data Warehouses. Wenn die Maschine schon nicht intelligent wurde, ordneten wir wenigstens die Daten so, dass Menschen sie verstanden. Knapp dreißig Jahre später setze ich Sprachmodelle an Aufgaben, die damals niemand einem Programm zugetraut hätte, bis hin zu kompletten Compilern.

Erfurt, Anfang der 90er Jahre

Ein Teil meiner Geschichte beginnt in Erfurt, kurz nach der deutschen Wiedervereinigung. Die IBYKUS AG für Informationstechnologie entstand 1996 aus der Fusion der ICE Computer und Netze GmbH, gegründet 1990, mit der IBYKUS Informationssysteme GmbH, gegründet 1993. Ich war als Vorstandsmitglied dabei.

Gebaut haben wir Oracle-Datenbanken für die Thüringer Landesregierung. Prozessmanagementsysteme für den Landtag. Probenverfolgung für die Veterinärdiagnostik. Ein Informationssystem für DASA, den Vorgänger von Airbus Defence. Darunter lagen HP UNIX-Server, Novell-Netzwerke, 100VG AnyLAN. Für den Raum Erfurt waren wir außerdem Internetdienstanbieter, als das Internet noch erklärt werden musste.

Auf unserer Seite zur Softwareentwicklung stand ein Satz, der mir bis heute im Gedächtnis geblieben ist:

„Heute ist Softwareentwicklung eine reine Ingenieursleistung. Sie ist Teil unseres Handwerks.“

Das Wort Handwerk taucht in meinem Berufsleben immer wieder auf, 1997 bei IBYKUS, 2011 im Firmennamen AJAGARA Softwarehandwerk und jetzt hier, ohne dass ich es je bewusst ausgesucht hätte.

35 Jahre Technikwechsel

In 35 Jahren habe ich Technologien entstehen und wieder verschwinden sehen: Client/Server wich den Webanwendungen, Oracle Designer/2000 wich Django, aus den Novell-Netzwerken wurde die Cloud, und bei jedem dieser Übergänge hieß es, nun werde die Arbeit endlich einfacher. Die 100-Mbit-Verbindung, die 1995 im Thüringer Innenministerium als Sensation galt, wäre heute für einen Drucker zu langsam.

Die grundlegenden Probleme sind dieselben geblieben. An Software habe ich dieselben Ansprüche wie 1996: Sie läuft zuverlässig und lässt sich warten, und wer sie baut, versteht die Menschen, die sie am Ende benutzen. Dass Kompetenz heißt, etwas verständlich machen zu können, gilt für einen Oracle-DBA im Jahr 1996 genauso wie für jemanden, der 2026 Agenten beauftragt. Geändert hat sich die Geschwindigkeit, und mit ihr die Illusion, sie könne Gründlichkeit ersetzen.

Warum dieser Blog

Mein Hauptjob ist eine Festanstellung. Dieser Blog gehört mir privat, er ist keine Unternehmenspräsenz und wirbt für nichts. AJAGARA Softwarehandwerk als Unternehmen ruht, der Name steht trotzdem noch für das, was ich von guter Software halte.

Hier schreibe ich über die Spannung zwischen den 90 Prozent, die KI schnell liefert, und den letzten zehn Prozent, für die es weiterhin Erfahrung und Handwerk braucht. Was Qualität bedeutet, wenn Quantität plötzlich billig ist, beschäftigt mich dabei am meisten. Dazu kommen Beobachtungen aus 35 Jahren Berufspraxis.

Ein Rückblick auf eine abgeschlossene Karriere ist das hier nicht. Ich stecke noch mitten drin.

Erklärung zur KI-Transparenz

Alle Blogbeiträge auf dieser Seite stammen von mir. Ich nutze LLMs zur Überarbeitung und zur stilistischen Verbesserung. Ich setze generative Tools ein, um Grammatik und Verständlichkeit zu verbessern, doch der Inhalt und die eigenen Gedanken stammen von mir.

Außerdem nutze ich LLMs regelmäßig, um Ideen zur Vereinfachung von Gedanken zu erhalten und als Sparringspartner beim Brainstorming für Blogbeiträge.

Kontakt

frank.csehan@ajagara.com

LinkedIn