Agent-Selbstoptimierung mit Lighthouse als Fitness

Ein Agent, der seinen eigenen Output bewertet, ist ein schwacher Richter. Er neigt dazu, sich selbst recht zu geben — dieselbe Instanz, die den Code schreibt, urteilt auch darüber, ob er gut ist. Die Frage hinter evolab war deshalb einfach: Was passiert, wenn die Bewertung von außen kommt, messbar und unbestechlich?

Der Loop: mutieren, messen, selektieren

Codex bekommt die Aufgabe, eine Oberfläche zu verbessern. Nicht das Urteil — nur den Vorschlag. Das Urteil liegt komplett bei Lighthouse, Googles Web-Qualitätsmessung: Performance und Accessibility werden gemessen, nicht behauptet.

Der Loop selbst ist ein genetischer Algorithmus mit einem ungewöhnlichen Mutations-Operator: einem Sprachmodell statt eines Zufallsgenerators. Codex erzeugt eine Variante, Lighthouse misst sie gegen den aktuellen Bestwert, und eine harte Selektionsregel entscheidet, ob sie bleibt.

Die Regel ist absichtlich streng: eine Mutation muss mindestens eine Metrik echt verbessern — UND darf keine andere Metrik unter die Toleranz drücken. Eine einzelne Zahl zu optimieren wäre einfacher gewesen, hätte aber Kollateralschaden erzeugt: eine Performance-Verbesserung, die Accessibility killt, ist auf dieser Site kein Fortschritt.

Mit dem Messrauschen rechnen

Reale Lighthouse-Läufe schwanken — dieselbe Seite liefert bei zwei aufeinanderfolgenden Messungen nicht exakt denselben Score. Wer das ignoriert, akzeptiert Zufall als Fortschritt. Die Selektionsregel rechnet deshalb mit einer Jitter-Toleranz: tol = max(1, jitter). Eine Mutation muss über das Rauschen hinaus besser sein, nicht nur knapp darüber.

Im fresh-Lauf zeigte sich das konkret: zwei Kandidaten erreichten Performance 86 — und wurden trotzdem verworfen, weil 86 nicht weit genug über dem bisherigen Bestwert 85 lag, um als echter Fortschritt statt Messrauschen zu zählen. Das fühlt sich beim ersten Hinschauen unnötig konservativ an. Ist es aber nicht: ohne diese Schwelle hätte der Loop irgendwann eine Kette von Zufallsschwankungen als "Verbesserung" verbucht.

Was verworfen wurde

Die interessanteren Zahlen sind nicht die Erfolge, sondern die Ablehnungen — die machen die Disziplin des Systems erst sichtbar.

Im loop-short-Lauf wurden zwei Mutationen verworfen: eine, weil sie Accessibility von 98 auf 93 gedrückt hätte — ein klarer Performance-für-Accessibility-Tausch, den die No-Regress-Regel nicht zulässt. Eine zweite, weil sie Performance von 85 auf 84 gekostet hätte.

Im fresh-Lauf: 3 akzeptierte Mutationen über 10 Iterationen, Performance stieg von 56 auf 85 — bei 4 Codex-Timeouts, die ehrlich mitgezählt wurden statt stillschweigend übersprungen. Accessibility stieg im selben Lauf von 98 auf 100.

Der overnight-Lauf erreichte mit 5 konservativen Mutationen einen Sprung von Performance 39 auf 90. Eine riskantere Minify-Variante hätte theoretisch 39→91 erreicht — blieb aber bewusst außen vor, weil sie ungeprüftes Verhalten löscht statt es zu verifizieren. Ein Prozentpunkt mehr Score war den Kontrollverlust nicht wert.

Leitplanken, nicht Vertrauen

Ein Agent, der selbst Code schreibt und sich selbst bewertet, braucht harte Grenzen — sonst optimiert er ins Leere oder ins Unsichere. Vier davon tragen den Loop:

Scope-Guard: Codex darf nur Dateien aus einer Allowlist anfassen. Ein Diff, der ausschert, wird verworfen, bevor er überhaupt gemessen wird.
Jitter-Toleranz: siehe oben — Messrauschen darf nicht als Fortschritt zählen.
Gehärteter Subprocess: der Codex-Aufruf läuft kontrolliert in einem abgegrenzten Arbeitsverzeichnis, nicht frei auf dem Zielsystem.
Kein Auto-Deploy: der Loop produziert nur Reports und eine best-ref-Empfehlung für menschlichen Review. Die Maschine schreibt nichts direkt ins Ziel-Repo.

Der letzte Punkt ist der wichtigste. Ein evolutionärer Loop, der autonom deployt, ist ein anderes Risikoprofil als einer, der nur einen geprüften Kandidaten vorschlägt. Die Selektionsregel entscheidet, was gemessen als Fortschritt zählt — nicht, was live geht.

Was sich verallgemeinern lässt

Der eigentliche Ertrag ist nicht der Lighthouse-Optimierer selbst, sondern das Prinzip dahinter: ein unbestechliches externes Mess-Signal statt Selbstbewertung, eine Multi-Metrik-Regel statt Single-Score-Tunnelblick, und eine Toleranz, die Messrauschen respektiert statt zu ignorieren. Das trägt auf jeden Agenten, der sich selbst verbessern soll — Lighthouse ist nur ein Signal von vielen, das sich dafür eignet.

Wo würdest du die Fitness-Funktion ansetzen, wenn du einen Agenten gegen ein externes Signal optimieren lässt? Wenn dich interessiert, wie sich das Prinzip auf andere messbare Ziele übertragen lässt, schreib mir.