Rolle in der Werkstatt
Die Fitness- und Prüfschicht der Werkstatt — sie trennt den Vorschlag eines Agenten von der Entscheidung über seine Übernahme.
— Leitseite · Messen und Verbessern
Eine neue Variante ist erst besser, wenn sie sich im Vergleich bewährt.
Ich trenne Erzeugung, Messung und Entscheidung. evolab prüft messbare Änderungen mit Lighthouse; ein Fresh-Eyes Quorum prüft qualitative Entscheidungen mit mehreren unabhängigen Blickwinkeln. In beiden Fällen gilt: Der Agent, der eine Variante baut, ist nicht zugleich ihr einziger Richter.
evolab für Messwerte · Fresh Eyes für begründete Urteile.
Die Leitidee: Eine plausible Erklärung ist noch kein Fortschritt. Erst Messwerte, Nachweise und vorher festgelegte Regeln machen eine Entscheidung nachvollziehbar.
Codex-MutationLighthouse-FitnessFresh-Eyes ReviewNo-RegressKein Auto-Deploy
Privates Repository. Mechanik und Ergebnisse sind hier öffentlich dokumentiert — der Code bleibt geschlossen, ein Walkthrough ist auf Anfrage möglich.
Zuletzt aktualisiert:
01
Erzeugen
Codex baut eine begrenzte Variante.
02
Messen
Werkzeuge liefern Werte und Nachweise.
03
Entscheiden
Eine feste Regel behält, verwirft oder eskaliert.
Jetzt prüfbar
- Architektur & Fitness-/Selektionslogik — hier dokumentiert
- Lighthouse-Proof & Fitness-Demo auf dieser Seite
- Code: privates Repository — Walkthrough auf Anfrage
— Rollen-Transfer
Was diese Route in der Werkstatt beweist.
Hier zeige ich zwei Wege zur belastbareren Entscheidung: externe Messwerte für objektive Ziele und unabhängige Reviews für qualitative Fragen.
Transfer
Übertragbar sind No-Regress-Regeln, Messungen gegen eine frische Baseline, belegte Reviewer-Stimmen und eine konservative Eskalation.
Öffentlicher Beleg
Ein dokumentierter Lighthouse-Loop mit akzeptierten und verworfenen Mutationen sowie acht geprüfte Quorum-Fälle.
Grenze
Kein Auto-Deploy, keine produktive Verbindung beider Systeme und keine Behauptung, dass mehrere Agenten automatisch unabhängige Urteile liefern.
— Warum gebaut?
Erzeugen, messen und entscheiden sind getrennte Rollen.
Sprachmodelle können ihren eigenen Output erklären und verteidigen. Das bedeutet jedoch nicht, dass die erzeugte Änderung besser ist. Deshalb darf der Erzeuger Vorschläge machen, aber nicht allein über ihren Erfolg urteilen.
Bei messbaren Zielen übernimmt evolab diese Trennung: Codex verändert eine Oberfläche, Lighthouse misst Leistung und Barrierefreiheit, und eine feste Regel vergleicht den Kandidaten mit dem besten bekannten Stand.
Bei Architektur, Sicherheit oder Freigaben reicht eine einzelne Zahl häufig nicht. Dann verlangt das Fresh-Eyes Quorum mehrere eindeutige Reviewer, Nachweise und tatsächlich unterschiedliche Perspektiven. Uneindeutige Fälle werden nicht künstlich entschieden, sondern eskaliert.
— Vom Messpunkt zur Schleife
Erst einordnen, dann gezielt weitergehen.
evolab kann nur den vorhandenen Stand messen, eine einzelne Annahme prüfen oder mehrere Varianten nacheinander vergleichen. Die drei Betriebsarten bauen bewusst aufeinander auf.
Aktive Betriebsart
Baseline
- Zweck
- Den vorhandenen Stand belastbar einordnen.
- Ablauf
- Mehrfach messen, Median und Streuung bestimmen.
- Ergebnis
- Ein frischer Vergleichswert, noch ohne Änderung.
— Evolution als Maschine
Die Maschine verändert, misst und wählt aus.
Der Kern ist eine wiederholte Prüfschleife. Codex erzeugt eine begrenzte Variante, Lighthouse misst sie, und eine vorher festgelegte Regel entscheidet, ob sie bleibt.
Messen statt meinen: Jede Mutation wird mit Lighthouse gemessen — Median aus 3 bis 5 Läufen, um Mess-Jitter zu glätten.
Nur Fortschritt zählt: Die Selektion übernimmt eine Variante nur, wenn sie besser ist und keine Metrik regrediert — sonst wird sie verworfen.
— Die Regel
Eine Verbesserung reicht nicht — sie darf nichts kaputtmachen.
Die Selektion ist hart: Eine Mutation muss mindestens eine Metrik echt verbessern und darf zugleich keine andere unter die Toleranz drücken. Wähle ein Szenario, um zu sehen, wie entschieden wird.
perf85→85
a11y98↓93
Verdiktverworfen
a11y regrediert (98→93) — eine gehaltene Performance rettet das nicht. Genau der reale loop-short-Iter-2.
— In echten Läufen geprüft
Echte Läufe, ungeglättet.
Die Zahlen stammen aus echten Läufen gegen das DCO-Dashboard, nicht aus einer Demo. Inklusive der Schritte, die verworfen wurden — die machen die Disziplin erst sichtbar.
39→90perf · overnight
56→85perf · fresh
21Tests
Stand 06/2026Quelle Lighthouse CI, DCO-DashboardScope Overnight-Lauf; 39→91-Variante verworfen
3 akzeptierte Mutationen über 10 Iterationen — 4 Codex-Timeouts ehrlich mitgezählt. a11y stieg dabei von 98 auf 100. Der Overnight-Lauf erreichte mit 5 konservativen Mutationen 39→90; eine riskantere Minify-Variante (39→91) blieb bewusst außen vor, weil sie ungeprüftes Verhalten löscht. Stand 06/2026.
Im loop-short-Lauf wurden zwei Mutationen verworfen: eine, weil sie Accessibility opferte (98→93), eine, weil sie Performance kostete (85→84). Und im fresh-Lauf scheiterten zwei Kandidaten mit Performance 86 an der Jitter-Toleranz — 86 lag nicht weit genug über dem Bestwert 85, um als echter Fortschritt statt Messrauschen zu zählen.
Stand 06/2026Quelle evolab report.json (loop-short- und fresh-Lauf)
— Wenn eine Zahl nicht reicht
Mehr Stimmen sind erst mit einem neuen Blick hilfreich.
Das Fresh-Eyes Quorum ist eine isolierte Entscheidungsregel: Stimmen werden nach Reviewer dedupliziert, Nachweise geprüft und Perspektiven verglichen. Probiere aus, wann es annimmt, ablehnt oder an einen Menschen weitergibt.
Fresh-Eyes Quorum
Wähle einen Fall. Die Regel zählt nicht nur Stimmen, sondern prüft Herkunft, Nachweise und unterschiedliche Blickwinkel.
Reviewer Aannehmen
Spec
Nachweis vorhanden
Reviewer Bannehmen
Sicherheit
Nachweis vorhanden
Entscheidung
Zwei eindeutige Reviewer stimmen mit Nachweisen aus unterschiedlichen Perspektiven zu.
Reviewer
eindeutig
Nachweise
Pflicht
Unklarheit
eskalieren
Der aktuelle Proof-of-Concept bleibt bewusst klein: reine Python-Logik, keine Datenbank, kein Netzwerk und keine produktiven Schreibrechte. Acht dokumentierte Testfälle prüfen unter anderem doppelte Reviewer, fehlende Nachweise, gleiche Perspektiven und Widersprüche.
— Kontrolle als Design
Autonomie mit harten Grenzen.
Messung und Review lösen nicht jedes Risiko. Sie begrenzen die Entscheidung so, dass Rückschritte, Rauschen und Widersprüche sichtbar bleiben.
Scope-Guard
Codex darf nur Dateien aus einer Allowlist anfassen — ein Diff, der ausschert, wird verworfen, bevor er überhaupt gemessen wird.
Jitter-Toleranz
Die Selektion rechnet mit Messrauschen: tol = max(1, jitter). Eine Mutation muss über das Rauschen hinaus verbessern, nicht nur knapp darüber.
Eskalation statt Scheinsicherheit
Fehlen Nachweise, unterschiedliche Perspektiven oder ein klares Urteil, übernimmt das Quorum die Entscheidung nicht selbst.
Kein Auto-Deploy
Output sind nur Reports und ein best-ref zum menschlichen Review — die Maschine schreibt nichts ins Ziel-Repo.
— Übertragbare Muster
Was sich verallgemeinern lässt.
Die eigentliche Ausbeute ist nicht der Lighthouse-Optimierer, sondern das Prinzip dahinter — übertragbar auf jeden Agenten, der sich selbst verbessern soll.
/01
Externe Messung
Lighthouse misst, nicht der Agent. Der Vorschlag und das Urteil bleiben bewusst getrennt.
/02
Mehrere Ziele schützen
Eine einzelne Kennzahl zu optimieren kann andere Qualitäten beschädigen. Die Regel gegen Rückschritte hält dagegen.
/03
Einen neuen Blick verlangen
Mehrere Stimmen helfen nur, wenn ihre Nachweise und Perspektiven nicht denselben blinden Fleck wiederholen.
— Nächste Iteration
Das Projekt lebt weiter.
- Weitere Fitness-Signale jenseits von Lighthouse erproben
- Funktionale Browser-Tests vor einer Übernahme ergänzen
- Das Quorum zunächst nur als Vorschau an den DCO anbinden
— Austausch
Messwerte und Urteile brauchen unterschiedliche Prüfwege.
Lighthouse ist nur ein mögliches Signal, ein Quorum nur eine mögliche Review-Regel. Wenn du an einem ähnlichen System arbeitest, können wir die Grenze zwischen Messwert, Urteil und menschlicher Übernahme gemeinsam einordnen.