Zwei Agenten, dieselbe Aufgabe

Am 18. August 2026, um 21:24:37 Uhr, wurde ein Zweig zusammengeführt. Eine Sekunde später, um 21:25:19, wurde der andere geschlossen. Beide hatten dieselbe Aufgabe gebaut, vom selben Ausgangspunkt, in derselben Nacht, mit demselben Modell.

Der Zweig, der gewonnen hat, hat seine entscheidende Runde nicht selbst gefahren. Sie wurde vom Verlierer gefahren.

Das ist die unbequemste Zeile aus vier gemessenen Doppelläufen, und sie steht ziemlich weit hinten in diesem Text. Vorher steht der ganze Ablauf — damit du ihn nacherleben und bei dir nachbauen kannst.

Was wir eigentlich wissen wollten

Wir betreiben zwei Bau-Agenten. Beide sind dasselbe Modell mit denselben Werkzeugen und demselben Zugriff. Sie unterscheiden sich in genau einer Datei: der, die ihnen sagt, wie sie arbeiten sollen.

Forge hat ein über Monate gewachsenes Prozess-Handbuch. Phasen, Reihenfolgen, Checklisten, Formulierungsvorgaben. 17.273 Zeichen.

Anvil hat eine Seite. Ziele in Prosa, fünf harte Regeln, ein überprüfbares Fertig-Kriterium. 5.537 Zeichen. Faktor 3,1.

Die Ausgangsfrage war: Was bringt das Handbuch?

Die Antwort darauf ist inzwischen das Uninteressanteste an der ganzen Sache. Was wir stattdessen gemessen haben, steht hier.

Teil 1: Der Aufbau — und warum er so streng war

Ein Vergleich zwischen zwei KI-Agenten ist standardmäßig wertlos. Man gibt zwei Systemen eine Aufgabe, schaut sich die Ergebnisse an, und entscheidet sich für das, das einem besser gefällt. Das ist kein Messergebnis, das ist ein Geschmacksurteil mit Zwischenschritten.

Neun Klauseln standen deshalb vor dem ersten Lauf fest, wortgleich für beide Arme.

1. Die Aufgabe war eingefroren.

Der Auftrag wurde als Datei abgelegt und mit einer Prüfsumme versehen. Im letzten Fall lautete sie b089a5c6…. Beide Arme mussten sie vor Baubeginn prüfen und nach dem Lauf erneut — identisch. Niemand konnte unterwegs nachbessern und hinterher behaupten, es sei immer so gemeint gewesen. Auch wir nicht.

2. Beide starteten vom selben Commit.

Der Ausgangsstand wurde beim Start eingefroren (10e50da9) und mitprotokolliert. Kein Arm hatte einen halben Tag Vorsprung im Code.

3. Der jeweils andere Arm war tabu.

Kein Blick in seinen Zweig, seinen Vorschlag, seine Aufzeichnungen.

4. Die Rangfolge stand vorher fest.

Qualität schlägt Rechenarbeit schlägt Zeit. Ein durchgefallenes unabhängiges Review bedeutet: Lauf verloren — egal wie sparsam oder wie schnell er war. Diese Regel wurde am 14. August festgelegt, nicht am Morgen nach dem Lauf.

5. Bewertet hat nicht der Auftraggeber.

Ein dritter Agent hat beide Ergebnisse unabhängig geprüft: Ist die Behauptung belegt? Läuft der Beweis wirklich? Zwei fremde KI-Modelle waren als Gegenprüfung dazugeschaltet, damit nicht dieselbe Denkweise sich selbst abnickt. Ein Agent, der seine eigene Arbeit benotet, besteht nämlich fast immer.

6. Kein Arm durfte sich selbst zusammenführen.

Genau einer wurde übernommen. Die Entscheidung lag außerhalb beider Arme.

7. Keine Schreibzugriffe auf den laufenden Betrieb.

Kein Ausrollen, kein Neustarten von Live-Diensten, keine Änderung an Produktivdaten. Unvermeidbare Ausnahmen mussten offengelegt werden. (Sie kamen vor. Dazu später.)

8. Die Abnahme-Prüfungen waren vorher da — und für die Bauenden schreibgeschützt.

Das ist die Klausel, an der die meisten Vergleiche kippen. Wer baut, schreibt normalerweise auch die Prüfungen, die beweisen sollen, dass es funktioniert. Das ist, als würde man sich die eigene Klausur stellen.

Bei uns schrieb sie jemand anderes, bevor gebaut wurde: elf Prüfungen, die den Weg eines Kunden abfahren — vom Dashboard über die Einstiegsseite bis zur Auftragsliste. Prüfsumme 3be494ce…. Für beide Arme nur lesbar. Wer eine Prüfung ändern wollte, brauchte eine Abnahme und musste den Unterschied offenlegen.

Der Satz dazu in den Klauseln: Ein Arm, der einen Test dem Code anpasst statt umgekehrt, verliert diesen Punkt — auch wenn die Suite danach grün ist.

9. Und die Prüfungen mussten erst einmal rot sein.

Bevor irgendjemand baute, ließen wir sie laufen. Ergebnis, protokolliert am 17. August um 09:23:23 UTC:

10 failed, 1 passed, 13 warnings in 0.71s

Mit Klartext-Meldungen, was fehlt:

AK1: Im Dashboard führt kein Weg zu Delia — der Kunde kann den Design-Service nicht erreichen. AK5: Keine Kundenansicht rendert 'ergebnis_url' — der Kunde hat keinen Ort, an dem sein Ergebnis auftauchen könnte.

Acht Minuten später wiederholt: wieder 10 zu 1. Erst danach ging die Aufgabe raus.

Warum dieser Schritt so wichtig ist: Eine Prüfung, die von Anfang an grün ist, beweist nichts. Sie könnte auch die falsche Sache prüfen. Erst wenn du sie einmal rot gesehen hast, weißt du, dass sie überhaupt etwas messen kann.

Halte diesen Satz fest. Am Ende dieses Textes steht der Befund, der ihn kaputtmacht.

Teil 2: Der Lauf — Fall 5, Schritt für Schritt

Die Aufgabe des letzten Falls: Ein Design-Dienst, den ein zahlender Kunde im Dashboard findet, beauftragen kann und dessen Ergebnis er wiederbekommt. Vorher kam der Dienst im Kundenpfad null Mal vor. Elf automatische Prüfungen, sechzehn Anforderungen, ein Feld auf der grünen Wiese.

Beide Jobs wurden im selben Augenblick eingestellt: 15:58:09 und 15:58:17 Uhr.

Was beide zuerst taten — und zwar identisch

Fünf Entscheidungen waren in der Aufgabe absichtlich offengelassen und dem Eigentümer vorbehalten. Beide Arme entschieden alle fünf gleich. Beide begründeten es gleich. Beide markierten es gleich als „das gehört dem Eigentümer".

Beide fanden unabhängig dieselben zwei Blockaden im Bestand: Die anklickbaren Kacheln waren keine echten Verweise, sondern Klick-Attrappen — die Prüfung konnte ihnen nicht folgen. Und ein Sicherheitsmechanismus hing an Pfad-Vorsilben, die der Testzugang nicht mitschickte.

Beide lösten sie auf dieselbe Bauart.

Das ist der stärkste Einzelbefund des Falls: Zwei verschieden regulierte Agenten kommen bei einer scharf geschnittenen Aufgabe auf dieselben Entscheidungen. Der Unterschied entsteht nicht im Verstehen. Er entsteht danach.

Wo sie auseinanderliefen: erweitern oder danebenbauen

Gemessen gegen denselben Ausgangsstand:

2.959 gegen 2.960 hinzugefügte Zeilen. Die Menge ist praktisch identisch. Die Richtung nicht.

Anvil hängt sich in fünf Fällen an vorhandene Mechanik. Forge baut in drei Fällen eine zweite daneben.

Beides hatte Folgen, und zwar in beide Richtungen: Anvils Anschluss an das Bestehende reparierte nebenbei, dass Protokollzeilen eines Bausteins im Klartext statt im Format des Hauses geschrieben wurden — ohne diese Reparatur wäre eine Zusage im ganzen Haus nicht einlösbar gewesen. Er zog aber auch eine Härtung mit, die ein geteiltes Verzeichnis traf. Forges Danebenbau erzeugte den schwersten eigenen Fund des ganzen Falls. Dazu gleich.

Wer prüfte, ob seine eigenen Prüfungen etwas prüfen

Beide fuhren Mutationsproben. Das heißt: Man macht absichtlich etwas kaputt und schaut, ob die eigene Kontrolle anschlägt. Tut sie es nicht, war die Kontrolle Dekoration.

Das liest sich gegen Forge. Es ist das Gegenteil.

Forge hat fünf tote Tests, weil Forge fünf tote Tests gefunden hat. Der ehrlichste Satz des Falls steht in seinem eigenen Protokoll:

„ohne Mutationsprobe wären 3 der ~35 eigenen Tests Belege ohne Aussage gewesen, und die Suite hätte grün geleuchtet."

Ob Anvils 44 Tests eine vergleichbare Quote tragen, ist nicht gemessen — er fuhr seine Proben gegen acht Schutzblöcke, nicht gegen jeden einzelnen Test. Der unabhängige Prüfer fand bei ihm später eine tragende Schutzschicht, die von keinem seiner 44 Tests gehalten wurde: Die Härtung griff nur beim Neuanlegen eines Verzeichnisses, nicht bei einem, das schon da war. Eine Mutation an dieser Stelle überlebte die volle Suite.

Und Forge hat unterwegs sich selbst korrigiert: Ein zu enger Filter beim Testaufruf hatte eine eigene Aussage falsch gemacht. Er hat es gemerkt, korrigiert und offengelegt. Seitdem läuft dort jede Mutation zweimal.

Der Fund, den nur ein Bild zeigt — und der, den nur eine Mutation zeigt

Anvils teuerster eigener Fund: Eine Anforderung war grün, und der Kunde konnte die Zahl trotzdem nicht lesen. Eigene Formatierung statt der Hausklassen — weiße Schrift auf hellgrauem Kasten im dunklen Erscheinungsbild. Im Quelltext stand alles korrekt. Die Prüfung fand es per Textsuche. Nur auf dem Bildschirmfoto war es unsichtbar. Er hat neun Bildschirmfotos am echten Testkonto gemacht, darunter den erschöpften Zustand („0 von 2", Knopf gesperrt) und den Störfall.

Der Störfall — im Quelltext korrekt, im Bild kaum zu lesen. Der erschöpfte Zustand: „0 von 2“, Knopf gesperrt.

Forges teuerster eigener Fund: Sein eigenes Betriebshandbuch war falsch. Dort stand ein Befehl mit einer Datei als Auftragsdatei — nachgeschlagen liest das Programm diese Datei roh als Auftragstext. Der Kollege hätte eine Datenstruktur als Arbeitsanweisung bekommen. Gefunden nicht durch einen Test, sondern durch Nachschlagen des eigenen Befehls.

Anvil: eine Zusage, die an der Benutzungsstelle nicht ankommt. Nur im Bild zu finden. Forge: ein Beleg, der nichts belegt. Nur durch Mutation zu finden. Keiner von beiden hat beides gefunden.

Und daraus der Satz, den Forge selbst gezogen hat und der es wert ist, aufgeschrieben zu werden:

Ein Betriebshandbuch mit ausführbaren Zeilen ist ein Testfall.

Die Runde, die einer sich selbst bestellt hat

Forge hat sich mitten im Bau ein zusätzliches Review geholt, das niemand verlangt hatte. Es fand zwei schwere Punkte, die kein Test gesehen hatte:

Der Alarm der eigenen Wache ging als Entwarnung raus. Forge hatte die Zustellfunktion der Nachbar-Wache mitbenutzt. Die baut ihren Meldetitel aber aus ihrer eigenen Nutzlast. Ein hängender Kundenauftrag wäre also als „Kachel-Wache: wieder grün" zugestellt worden — unter fremdem Absender, und durch die Titel-Zusammenfassung in derselben Zeile wie die echte Entwarnung gelandet.

Alle sieben eigenen Tests hatten die Zustellfunktion durch eine Attrappe ersetzt.

Die einzige Naht, die kaputt war, war die einzige, die kein Test gefahren ist.

Und: 5.000 frei wählbare Zeichen Kundentext gingen wörtlich in eine Datei, die als Arbeitsanweisung gelesen wird. Die Hausregel dagegen steht seit Juli geschrieben.

Für Anvil ist keine vergleichbare Runde nachweisbar. Nicht aus Nachlässigkeit — seine drei Anläufe starben alle an derselben Überlastungsmeldung der Prüf-Schnittstelle: 16:52:42, 16:56:57, 17:06:44 UTC.

Merk dir das. Es entscheidet nachher mehr, als es sollte.

Der Defekt in der Klausur selbst

Dann fanden beide unabhängig voneinander dasselbe.

In der schreibgeschützten Prüfungsdatei war eine Hilfsfunktion falsch deklariert: Sie versprach ein Paar aus Datensatz und Text, gab aber nur den Text zurück. Die aufrufende Funktion griff daraufhin ein zweites Mal auf ein Textfeld zu, das es nicht mehr gab. Fehler — bevor irgendeine Zusicherung überhaupt geprüft wurde.

Drei der elf Prüfungen konnten dadurch strukturell nie grün werden. Egal, was jemand baut.

Beide leiteten denselben Fix ab. Nicht ähnlich: byte-identisch, unabhängig per Prüfsummenkette nachgewiesen (3be494ce… → a74e64d1…). Ein einziges Wort.

Dann trennten sich die Wege.

Anvil hat die Regel gehalten, als der Prüfer ausfiel. Sein Satz dazu:

„Genau so soll ein Anti-Skip-Gate wirken, wenn der Prüfer fehlt: es hält, statt sich selbst zu öffnen."

Er hat dafür mit einem rot aussehenden Ergebnis bezahlt. Das ist die teurere Haltung — und die verteidigbare. Ein Tor, das der Gebaute sich selbst aufmacht, ist keins.

Forge hat die Regel auch gehalten. Die Klausel verlangte eine Abnahme, er hat sie eingeholt und bekommen. Der Unterschied ist keine Haltungsfrage. Es ist Glück mit der Infrastruktur.

Wer daraus „Anvil ist disziplinierter" liest, misst eine überlastete Schnittstelle.

Teil 3: Wie entschieden wurde

Das unabhängige Review lief für beide getrennt, mit zwei fremden Modellen als Gegenlens.

Nach der vorab festgelegten Regel haben beide verloren. Es gab keinen Lauf ohne Beanstandung, und ausgerechnet der Arm mit dem kleineren Regelwerk hatte mehr Beanstandungen: fünf gegen drei.

Der Prüfer hat das selbst so hingeschrieben:

„Die Regel trifft damit beide gleich — die Entscheidung fällt nicht an diesem Review, sondern an der Abwägung der Reparaturkosten."

Und die Reparaturkosten waren ähnlich: bei Anvil geschätzt unter zwei Stunden, bei Forge unter einer. Das Kriterium, das am Ende trug, war überhaupt kein gemessenes. Es war, dass einer der beiden Zweige in dieser Nacht noch eine Runde bekommen konnte — und dass am Mittwochvormittag ein Kundentermin stand.

Was Anvil wirklich besser gemacht hat

Nicht formal, sondern an den Belegen:

1. Er hat nachgewiesen, dass der Kunde es sehen kann. Neun Bildschirmfotos am echten Testkonto, inklusive Störfall und erschöpftem Kontingent. Forge fuhr ebenfalls nach — aber nur Anvils Nachfahrt hat einen Fehler gefunden, den kein Test finden konnte.
2. Er erweitert die Mechanik des Hauses, statt sie zu verdoppeln. Eine Wache, eine Flanke, ein Meldeweg. Forges zweite Wache musste ihre Zustellung von der Nachbarin borgen — und lief genau dort in ihren schwersten Befund.
3. Seine Nachbesserungsrunde ist die härteste Arbeit des ganzen Falls. Fünf von fünf Punkten behoben, jeder mit eigener Mutation abgesichert, dazu Gegenproben, die das billige „einfach alles sperren" ausschließen. Zwei von fremden Modellen gemeldete schwere Punkte hat er widerlegt statt übernommen. Der Prüfer setzte 13 eigene Mutanten: zwölf wurden gefangen.
4. Er deklariert ehrlicher. Wo eine Überwachungseinheit nachgemessen nicht existierte, steht „teilweise" — nicht „läuft". Eine seiner Prüfungen prüft nicht einen Wert, sondern dass kein Zustandsflag mehr behauptet, als sein eigener Beleg hergibt.

Was am Forge-Arm besser war

Das gehört genauso benannt, sonst ist der Vergleich Propaganda:

1. 11 von 11 grün. Und: Der abgenommene Fix an der Prüfungsdatei kam aus dem Forge-Arm und ging in beide Zweige. Der Prüfer hat für den anderen nicht dessen eigenen Vorschlag genommen, sondern die bereits abgenommene Datei unverändert hineinkopiert. Der übernommene Zweig trägt genau diese Fassung.
2. Weniger Beanstandungen — drei gegen fünf, bei Aufgaben-Schwierigkeitsnoten, die den Abstand nicht erklären.
3. Er hat sich das zusätzliche Review selbst besorgt und dabei zwei schwere Punkte gefunden, die kein Test sah.
4. Er hat einen Fehler in der Versuchsanordnung gemeldet — ein gemeinsames Ablageverzeichnis war zwischen den Armen nicht getrennt. Inklusive der Offenlegung, dass er dadurch selbst ungewollten Sichtkontakt zur Arbeit des anderen hatte. Statt so zu tun, als sei die Trennung sauber gewesen.
5. Die schärfste methodische Lehre des Falls stammt von ihm. Sie kommt gleich.

Und die Pannen kamen aus beiden Armen: Anvils Aufräumbefehl traf um 16:43:30 UTC zwei fremde Live-Dienste — von der Systemverwaltung in derselben Sekunde neu gestartet, per Neustartzähler und Startzeitstempel gegengeprüft. Beide Arme haben ihre Pannen offengelegt. Beide Offenlegungen halten der Nachprüfung stand; eine wurde stichprobenhaft am laufenden System nachgemessen.

Teil 4: Was die Zahlen sagen — und was nicht

Ein Wort zur Rechenarbeit, weil hier die meisten Vergleiche kippen. Gemessen haben wir, was ein Agent tatsächlich gelesen und geschrieben hat — ohne das, was aus dem Zwischenspeicher kam. Der Unterschied ist nicht klein: In Fall 5 stehen rund 493.000 gearbeitete Einheiten gegen rund 100 Millionen inklusive Zwischenspeicher. Faktor zweihundert. Wer den Zwischenspeicher mitzählt, misst Wiederholung, nicht Leistung.

Drei Dinge, die man dazu wissen muss.

Die gleiche Wanduhr ist ein Zufallstreffer. Beide Jobs wurden im selben Augenblick eingestellt, aber der eine begann erst 106 Minuten später — Warteschlange. Gearbeitet haben beide exakt gleich lang. Die Zeit ist ohnehin unsere schwächste Größe.

Die Bau-Läufe sind nicht dasselbe Produkt. Forges 71 Minuten enthalten zwei selbstbestellte Review-Runden und deren Reparaturen; der Bau selbst war nach eigenem Protokoll nach 15 Minuten fertig, „die restlichen 55 gingen in Review-Runden und deren Fixes." Sein Mehrverbrauch von 17,6 Prozent ist zu einem erheblichen Teil eingekaufte Prüfung.

Und bis zum bestandenen Review dreht sich das Vorzeichen um:

Der übernommene Zweig hat 17,3 Prozent mehr gekostet als der geschlossene. Und der geschlossene hat nie die Runde bekommen, mit der er seine drei Punkte hätte schließen können.

Ein Vergleich auf Augenhöhe ist damit nicht möglich. Wer 680.504 gegen 580.176 stellt, vergleicht „fertig geprüft" mit „einmal geprüft, nicht nachgebessert".

Und die Zeile, die am unbequemsten ist: Die Nachbesserungsrunde am Sieger-Zweig wurde vom Agenten forge gefahren. Nicht von Anvil. Der Arm, der die Studie formal gewonnen hat, hat seine entscheidende Runde nicht selbst gefahren. Die 187.241 Einheiten sind Forge-Arbeit auf einem Anvil-Zweig.

Teil 5: Die Befunde, die durch alle Fälle tragen

Vier Fälle liegen vor. Ein Probelauf, ein Härtetest, eine Kundenstrecke, und der eben erzählte.

Befund 1 — Die Aufgabe schlägt den Agenten

Im Härtetest hatten beide Arme im ersten Anlauf denselben schweren Fehler. Nicht einen ähnlichen — denselben. Eine Meldung, die bei jeder Prüfung erneut rausging, statt nur beim Wechsel von „alles gut" zu „kaputt". Nach zwei Tagen hätte niemand mehr hingeschaut.

Warum machten ihn beide? Weil er in der Aufgabenstellung fehlte. Dort stand, was gemeldet werden soll. Dort stand nicht, wann nicht mehr gemeldet werden soll.

In Fall 5 wiederholte es sich, an anderer Stelle: Beide dachten Doppelklick-Schutz und Lebenszyklus nicht zusammen. Bei dem einen gab eine Stornierung das Kontingent frei, aber nicht den Doppelklick-Platz. Bei dem anderen kippte ein Statuswechsel aus einem Endzustand in einen unbehandelten Fehler. Und beide legten Kundenunterlagen weltlesbar ab.

Zwei verschieden regulierte Agenten machen denselben Fehler an derselben Stelle. Das ist eine Aussage über die Aufgabe, nicht über die Regelwerke.

Befund 2 — Mehr Tests sind nicht mehr Sicherheit

In der Kundenstrecke brachte ein Arm 317 Testfunktionen mit, der andere 149 — mehr als doppelt so viele. Und genau der mit den 317 übersah die zwei Stellen, um die es in der ganzen Aufgabe ging.

Wir haben das nicht vermutet, sondern gemessen: An beiden Stellen haben wir absichtlich etwas kaputtgemacht. Beide Male blieben 517 von 517 Tests grün, während die Sache nicht mehr funktionierte.

Der Grund ist benennbar. An diesen Stellen prüften die Tests, ob der Code so aussieht wie vorgesehen — nicht, ob er das Richtige tut. Eine Kontrolle, die nur die Schreibweise kennt, fällt auf die nächste Schreibweise herein.

In Fall 5 in der schärferen Form: 44 Tests gegen 39 — und der unabhängige Prüfer fand bei den 44 eine tragende Schutzschicht, die von keinem davon gehalten wurde.

Befund 3 — Eine Prozentzahl ohne Rundenzahl ist wertlos

Der Token-Abstand über alle vier Fälle: 3,6 Prozent im Probelauf. 9 Prozent im Härtetest. 31 Prozent in der Kundenstrecke — aber nur 8 Prozent pro Runde, denn eine Runde von vieren ist allein schon ein Viertel. Und in Fall 5: 17,6 Prozent in die eine Richtung, die sich auf 17,3 Prozent in die andere dreht, sobald die Nachbesserung mitzählt.

Es gibt keinen stabilen Vorteil eines der beiden Regelwerke. Wenn dir jemand Effizienzgewinne in Prozent vorrechnet, frag zuerst nach der Zahl der Durchläufe — und dann, ob beide Werte aus derselben Messung stammen.

Befund 4 — Eine Regel, die nur in Prosa steht, bindet niemanden

Das ist der teuerste Befund der ganzen Reihe.

Beide Regelwerke schreiben zwingend vor, dass sicherheitsrelevante Änderungen von einem fremden Modell gegengelesen werden. Bei Anvil ist es eine von fünf nicht verhandelbaren Regeln. Bei Forge ein Pflicht-Auslöser. Beide Aufträge trugen zusätzlich wortgleich den Hinweis, das eigene Regelwerk zu lesen.

Die Aufgabe in Fall 5 ist Sicherheit im Kern: Zugriffsgrenze, Schutz gegen fremdgesteuerte Anfragen, fremde Datensätze, Pfad-Ausbruch, Kundendaten.

Ausgezählt über beide Mitschriften:

In der Kundenstrecke davor war es dasselbe Muster, nur milder: Der eine erfüllte die Pflicht in einer von vier Runden, der andere in einer von drei — beide erst in ihrer letzten.

Und das 3,1-fach größere Regelwerk erzeugte dabei keine bessere Befolgung.

Wer Verbindlichkeit will, muss sie in ein Tor legen, das feuert. Nicht in einen Satz, den jemand lesen soll.

Befund 5 — Rot ist nicht gleich richtig rot

Erinnerst du dich an Klausel 9? Erst rot sehen, dann bauen. 10 zu 1, zweimal bestätigt, sauber protokolliert.

Es sah exakt richtig aus. Neun der zehn fielen am ersten Tor. Der Typfehler in der Prüfungsdatei lag dahinter und war unerreichbar — die drei betroffenen Prüfungen wären auch bei perfektem Code rot geblieben.

Forge hat den Schluss gezogen, den wir uns aufgeschrieben haben:

„Ein roter Test beweist nur, dass er rot ist — nicht, dass er aus dem gemeinten Grund rot ist."

Unsere eigene Vorsichtsmaßnahme hat den Defekt nicht gefangen. Sie kann es nicht, solange es keinen Gegenlauf gegen etwas Funktionierendes gibt. Diese Klausel fehlt uns bis heute und steht für den nächsten Fall auf der Liste.

Teil 6: Was das für deine eigene Arbeit heißt

1. Schreib die Fertig-Linie zuerst. Statt „Schritt 1, dann Schritt 2, dann Schritt 3": „Am Ende soll X vorliegen. Fertig ist es, wenn Y erfüllt ist." Den Weg lässt du offen. Wenn du den Weg ohnehin genau kennst, brauchst du dafür keine KI.

2. Sag auch, wann etwas nicht passieren soll. Der teuerste Fehler der ganzen Reihe war eine fehlende Abgrenzung nach unten. Alle Aufträge sagen, was passieren soll. Fast keiner sagt, wann Schluss ist und was ausdrücklich nicht dazugehört.

3. Lass die Prüfung sich selbst prüfen. Reparatur raus, Test muss rot werden, Reparatur rein, Test wird grün. Alles andere ist eine Behauptung. Wenn du nicht sagen kannst, was du kaputtmachen müsstest, damit eine Prüfung anschlägt, prüft sie nichts.

4. Hol die zweite Meinung vor der Abgabe, nicht danach. Beide Arme haben diese Regel gebrochen, in jedem einzelnen Fall. Beide haben dafür bezahlt — einmal in Zeit, einmal in einer Lücke, die bis heute offen ist.

5. Verdächtige bei einem schlechten Ergebnis zuerst deine eigene Aufgabenstellung. Der Reflex ist, dem Modell die Schuld zu geben und mehr Regeln nachzuschieben. In unseren Fällen war es mehrfach die Aufgabe. Die nützlichste Frage lautet: Was habe ich nicht hingeschrieben, weil es für mich selbstverständlich war?

Was diese Studie nicht sagt

Vier Fälle sind genug, um etwas zu sehen. Sie sind zu wenig, um etwas zu beweisen. Fünf Einschränkungen, die wir nicht verschweigen:

Es ist ein Haus, ein Modell, eine Art Arbeit. Beide Arme liefen mit demselben Modell an derselben Sorte Aufgabe — Software bauen. Wir behaupten nicht, dass sich das auf andere Arbeit überträgt.

Fall 1 war ein Probelauf. Ein Arm startete rund fünf Stunden später. Er steht als Messübung da, nicht als Ergebnis.

Wir haben unterwegs einen Messfehler korrigiert. Die erste Verbrauchszahl eines Arms war über den ganzen Tag und den ganzen Rechner gemessen worden. Sie wurde durch eine einheitliche Messung über beide Arme ersetzt. Der Fehler lag bei der Messung, nicht beim Agenten — aber er hätte die Studie beinahe in die falsche Richtung gedreht.

Die Versuchsanordnung war in Fall 5 an drei Stellen unsauber: 106 Minuten Warteschlangen-Versatz, ein gemeinsames Ablageverzeichnis ohne Trennung zwischen den Armen, und — der schwerste Punkt — ungleiche Prüf-Kapazität. Ein Arm bekam drei tote Anläufe und keine Nachbesserungsrunde, der andere einen gelungenen Anlauf und eine Runde. Fall 5 hat damit nicht zwei Arme verglichen, sondern einen Arm mit Nachbesserung gegen einen ohne.

Und die Zahlen liefen mehrfach gegen unsere eigene Vermutung. In der Kundenstrecke lag der Arm vorn, von dem wir es nicht erwartet hatten. Die Testanzahl sagte das Gegenteil dessen, was sie zu sagen scheint. In Fall 5 hatte ausgerechnet der schlanke Arm mehr Beanstandungen. Wir zeigen es trotzdem.

Bilanz über vier Fälle: einer klar für das schlanke Regelwerk, einer nahezu Gleichstand, zwei gegen unsere Ausgangsthese. Ein Fähigkeitsgefälle zwischen den beiden Agenten ist in keinem einzigen Fall gemessen worden. Was in Fall 5 messbar funktioniert hat, war die Kombination: der Bau des einen, der Prüfungs-Fix des anderen, ein externes Review und eine Nachbesserungsrunde. Der übernommene Zweig trägt Arbeit aus beiden Armen. Genau diese dritte Möglichkeit ist nie als eigener Arm gelaufen — aber sie hat den einzigen brauchbaren Stand dieses Falls erzeugt.

Der Teil, der eigentlich zuerst kommen müsste

Lies die neun Klauseln aus Teil 1 noch einmal, aber diesmal mit einer anderen Frage: Was wäre passiert, wenn eine davon gefehlt hätte?

Ohne die eingefrorene Aufgabe hätte einer von uns nach dem Lauf gesagt: „So war das nicht gemeint." Und er hätte es geglaubt.

Ohne den Schreibschutz auf den Prüfungen hätte einer den kaputten Test angepasst statt gemeldet. Wir hätten nie erfahren, dass drei von elf strukturell nie grün werden konnten.

Ohne die vorher festgelegte Rangfolge hätten wir am Morgen danach den Zweig gewählt, der besser aussah. Der sah zufällig grüner aus, weil eine fremde Schnittstelle bei einem der beiden funktioniert hat.

Ohne den unabhängigen Prüfer hätten wir zwei Selbstbewertungen gehabt. Ein Agent, der seine eigene Arbeit benotet, besteht fast immer.

Ohne die Offenlegungspflicht wüssten wir bis heute nicht, dass ein Aufräumbefehl zwei fremde Dienste getroffen hat.

Ohne all das hätten wir zwei Meinungen gehabt. Wir hatten zwei Messungen. Der ganze Unterschied liegt in Vorarbeit, die vor dem ersten Zeichen Code fertig sein musste.

Und dann steht da Befund 4, der uns am meisten wehtut: Wir haben genau diese Vorarbeit an einer Stelle selbst nicht gemacht. Die Fremd-Lens-Pflicht stand bei beiden Agenten im Regelwerk — als Satz. Sie wurde null Mal befolgt. Erst als jemand sie in einem Auftrag ausdrücklich bestellte, lief sie siebzehnmal.

Eine Regel im Text ist eine Bitte. Eine Regel im Tor ist ein Gesetz. Bitten brechen unter Last.

Das ist keine Einsicht über Agenten. Das ist eine Einsicht über die Person, die sie einsetzt — und sie gilt bei dir genauso, auch wenn du keine A/B-Studie fährst, sondern nur einen Claude in einem Ordner.

Deine Regel steht im Chatfenster. Sie ist nach zwei Stunden nicht mehr da, und du merkst es an dem Tag, an dem es teuer wird.