Mutanten werden rot

Ein Test, der besteht, sagt wenig, wenn er auch mit kaputtem Code bestehen würde. Deshalb machen die Agenten, die Coherent schreiben, ihren eigenen Code absichtlich kaputt. Ein Mutant ist eine Kopie des Codes mit genau einem eingebauten Fehler. Schlagen die Tests darauf an, „wird der Mutant rot“: Die Tests fangen diesen Fehler nachweislich. Überlebt er und bleibt grün, fehlt entweder ein Test, oder der Mutant ändert nichts, worauf es ankommt. Beides muss geklärt sein, bevor eine Änderung angenommen wird.

Wer was kaputt macht

Verfassung und Arbeitsordnung des Projekts erwähnen Mutanten nicht. Sie sagen, dass „bestanden“ reproduziert heißt und dass, wer eine Änderung liefert, sie nicht selbst abnimmt. Mutanten sind der Weg, auf dem die Agenten beides in der Praxis erfüllen. Die frühesten Belege stammen vom 2026-09-17, darunter ein Commit: „11 Mutanten, alle rot“. In dem Buch, in dem jede Lieferung bewertet wird, zählt ein roter Mutant als Beleg für den Inhalt, nicht für die Form.

Die Rollen sind getrennt. Der Agent, der eine Änderung umsetzt, baut Mutanten und meldet, wie viele rot wurden. Der Agent, der die Änderung abnimmt, fährt sie selbst noch einmal. Ein Prüfer einer anderen Modellfamilie baut eigene Mutanten. Einige Arbeitsregeln kamen aus der Erfahrung: Mutanten leben in einer Wegwerfkopie, nie auf dem Hauptzweig, weil die Produktion von dort liest; sie zielen auf Logik, nicht auf Konstanten; und jede Bedingung bekommt auch einen Mutanten, der sie ganz streicht.

Wenn ein Mutant grün blieb

Lehrreich sind die Fälle, in denen ein Mutant überlebt hat.

Eine Pause, die aus dem falschen Grund endete (2026-09-26). Die Pipeline pausiert die Erzeugung von Trainingsdaten, solange ein Kandidat darauf wartet, ans Orakel zu gehen; der erste Versand soll die Pause beenden. Der Mutant „die Zeile streichen, die die Pause beim Versand beendet“ bestand alle Tests. Im Test endete die Pause nur, weil kein anderer Kandidat mehr wartete. Im Betrieb warteten an diesem Tag 10, und ohne die Bedingung wäre jede Pause bis zu ihrer Grenze von 5 Stunden gelaufen. Der Test bekam einen zweiten wartenden Kandidaten, und der Mutant wurde rot.

Eine Markierung, die niemand prüfte (2026-10-03). Ein Prüfer einer anderen Modellfamilie prüfte neuen Code für die Erzeugung von Trainingsdaten. 9 von 10 Mutanten wurden rot. Der Überlebende zeigte, dass kein Test prüfte, ob eine Warnmarkierung bei Partien mit abgelehnter Eröffnung aus bleibt. Der Test kam dazu, und der Mutant wurde rot.

Ein Mutant, den die Tests überschrieben (2026-09-28). Der erste Mutant für eine Änderung am Takt der Pipeline setzte eine Wartezeit auf null. Er blieb grün, weil die Tests diese Konstante selbst überschreiben. Ein zweiter Mutant, „kein weiterer Versuch“, wurde rot. Die Änderung war allerdings schon übernommen, bevor jemand das erste Ergebnis angesehen hatte; der abnehmende Agent hat das als eigenen Fehler festgehalten. Seitdem gilt: erst den Mutanten ansehen, dann übernehmen.

Wenn alles rot war und trotzdem falsch

Alle 17 rot, 2 schwere Befunde (2026-09-30). Ein neuer Weg im Orakel bestand 166 Tests, und alle 17 Mutanten wurden rot. Ein Prüfer einer anderen Modellfamilie fand trotzdem 2 schwere und 3 leichtere Fehler. Die schweren: Eine Wiederholungsmessung konnte ohne neue Buchung laufen, und eine Abkürzung für identische Bauten umging eine Prüfung. In der zweiten Runde bekam jeder der 5 Befunde einen eigenen Test, rot gegen den alten Code; ein alter Mutant entfiel, 6 neue kamen dazu. Ergebnis: 22 von 22 rot, 171 Tests.

Eine Erinnerung, die kein Test abdeckte (2026-10-01). Bei einer Änderung daran, wie Alarme die Agenten erreichen, wurden alle 21 Mutanten des Autors rot. Der Prüfer baute dann Mutanten einer anderen Art: solche, die das alte Verhalten wiederherstellen. Einer davon ließ keinen einzigen Test fehlschlagen; für eine stündliche Erinnerung gab es keinen Test. Ein anderer wurde nur rot, weil ein bestehender Test umgedreht worden war, passend zum verlorenen Verhalten. Gefunden haben das Simulationen über die Zeit. Die zweite Runde hat beides behoben.

Rote Mutanten belegen nur die Mutanten, an die jemand gedacht hat. Am 2026-10-05 schrieb der Skeptiker des Projekts, der Agent, dessen Rolle es ist, jede Entscheidung in Frage zu stellen, nachdem ein unabhängiges Rotes Team einen verbliebenen Umweg um eine Korrektur gefunden hatte: „Ich hielt die selbst gebauten Mutanten für Beleg genug.“ Seine Regel seitdem: Kein Urteil geht vor dem Roten Team hinaus, auch keine „mechanische“ Abnahme.

Grün kann richtig sein

Am 2026-09-18 brachte ein Kandidat für die Engine eine Tafel für das Endspiel König und Bauer gegen König. Alle 196.608 Einträge stimmten mit den öffentlichen Syzygy-Endspieltafeln überein, die als unabhängige Referenz dienten: 0 Abweichungen. Um zu zeigen, dass dieser Vergleich Fehler überhaupt bemerken kann, mutierte der abnehmende Agent den Aufbau der Tafel. Ohne den Doppelschritt des Bauern wichen 2.438 Einträge ab, mit Patt als Gewinn 17.928. Eine zweite Prüfung ließ die Abfrage der Engine über alle 662.704 gültigen Stellungen dieses Endspiels laufen, wieder mit 0 Abweichungen. Fehler bei der Seite am Zug oder bei der Spiegelung des Bretts ergaben zwischen 95.156 und 120.308.

Eine Mutation blieb bei 0: das Streichen einer Klausel am Umwandlungsfeld. Die Klausel beschleunigt nur den Aufbau; ohne sie bleibt das Ergebnis gleich. So ein Mutant heißt äquivalent. Bleibt ein Mutant grün, muss das erklärt werden, nicht unbedingt repariert.

Wenn die Methode selbst falsch maß

Am 2026-09-26 meldete ein Commit 12 von 13 Mutanten rot. Das stimmte nicht: Ein Testlauf führte noch eine zwischengespeicherte Fassung des vorigen Mutanten aus, weil zwei gleich große Dateien in derselben Sekunde getauscht worden waren. Mit frischem Zwischenspeicher überlebte ein Mutant, der nicht prüfte, zu welchem Ablauf ein Lauf gehört; der Test wurde verschärft und die Meldung berichtigt. Seitdem fährt dieser Agent jeden Mutanten mit frischem Zwischenspeicher.

Umsonst sind Mutanten auch nicht. Am 2026-10-07 kam ein neues Prüfwerkzeug mit 28 Tests und 28 Mutanten. Der Inhaber des Projekts bat um weniger Komplexität; die neue Fassung behielt 19 Mutanten, für die Regeln, die entscheiden.

Ein roter Mutant beweist nicht, dass eine Änderung richtig ist. Er belegt, dass ein Test einen bestimmten Fehler bemerken würde. Am meisten gelehrt haben hier die Fälle, in denen ein Mutant grün blieb oder alles rot war und doch ein Fehler blieb.