Language Recursive Self-Improvement: Code Intelligence über ~280 Sprachen hinweg grinden

Die Zahlen in diesem Beitrag spiegeln den Stand des Systems zum Veröffentlichungszeitpunkt (Mai 2026) wider. Aktuelle Zahlen findest du auf unserer Team-Seite.

Maguyva extrahiert Symbole, Referenzen und einen Dependency-Graph aus Quellcode in rund 280 Sprachen. Jede Sprache ist ein maßgeschneiderter tree-sitter-Handler — Queries, Heuristiken, Edge Cases — und jeder Handler kann auf seine eigene, subtile Weise falsch liegen. Ein Methodenaufruf, der als Read ausgegeben wird. Eine Funktion, die dem falschen umschließenden Scope zugeordnet wird. Eine Beziehung, die es schlicht nicht gibt.

Das kannst du nicht von Hand auditieren. Kein Team kann Extraktionsergebnisse über 280 Grammatiken hinweg lesen und die schlechten Kanten erkennen. Die interessante Frage ist also nicht „ist unsere Extraktion korrekt“ — sie lautet „wie findest du in dieser Breite heraus, dass sie falsch ist, ohne einen Menschen in jeder Schleife.“ Unsere Antwort ist Language Recursive Self-Improvement: eine Qualitätsschleife, angetrieben von Sprach-Agenten, einem LLM als Judge, und einer Lektion, die wir immer wieder neu lernen: Grün ist nicht dasselbe wie korrekt.

Grün ist nicht korrekt

Jede Sprache hat eine Fixture-Suite, und ein Release-Gate bewertet sie über fünf Dimensionen — Genauigkeit, strukturelle Integrität, Vollständigkeit, Qualität und Performance. Eine Sprache wird nur GRÜN, wenn auf ihren Fixtures Precision ≥ 0,95, Recall ≥ 0,99 und F1 ≥ 0,97 gilt, bei mindestens 20 erwarteten Kanten für statistische Zuverlässigkeit. Darunter ist sie GELB oder ROT und wird nicht ausgeliefert.

Dieses Gate ist notwendig, aber nicht hinreichend. Fixtures validieren gegen Fixtures, die wir geschrieben haben. Sie kodieren die Fälle, an die wir bereits gedacht haben. Ein Handler kann auf seinen Fixtures makellos sein und trotzdem ein Muster verstümmeln, das nur in echtem Code auftaucht — ein Makro-Idiom, eine generisch gebundene Methode, ein Sprachfeature, für das niemand eine Fixture geschrieben hat. GRÜN bedeutet, dass die Fixtures bestehen. Es bedeutet nicht, dass ein echtes Repository sauber extrahiert wird. Also muss die Schleife die Fixtures hinter sich lassen und in die Wildnis schauen.

Die innere Schleife: Stichprobe, Urteil, Fix, Beweis

Die Kernschleife läuft jeweils für eine Sprache:

        ┌──────────────────────────────────────────────────────────┐
        │                                                          │
        ▼                                                          │
  1. corpus run ── clone real-world repos, extract relationships   │
        │                                                          │
        ▼                                                          │
  2. spot-check 100 edges (seed 42, then seed 123 to cross-check)  │
        │                                                          │
        ▼                                                          │
  3. LLM judge classifies every sampled edge:                      │
        CORRECT · FALSE_POSITIVE · TYPE_ERROR ·                    │
        SCOPE_ERROR · METADATA_ERROR                               │
        │                                                          │
        ▼                                                          │
  4. fix ONE thing — handler .py, .scm query, or config           │
        │                                                          │
        ▼                                                          │
  5. re-validate — F1 + re-classify + manifest diff (no regressions)│
        │                                                          │
   better? ──no──► revert, try a different fix ────────────────────┤
        │ yes                                                       │
        ▼                                                           │
  6. promote the fix into fixtures (a permanent regression guard) ──┘

Einige Dinge sorgen dafür, dass das funktioniert, statt nur im Kreis zu drehen.

Der Richter ist der Agent, kein API-Call. Wenn wir „LLM-as-Judge“ sagen, meinen wir, dass der Sprach-Agent selbst jede gesampelte Kante gegen die echte Quelle liest und sie mit einer festen Fünf-Kategorien-Rubrik klassifiziert: Ist diese Kante korrekt, ein False Positive, die richtige Beziehung mit dem falschen Typ, dem falschen Scope zugeordnet, oder trägt sie falsche Metadaten? Diese Rubrik ist das ganze Spiel — „23 % Fehlerrate“ ist bedeutungslos, solange du nicht weißt, ob das echte Defekte sind oder der Richter falsch zählt.

Eine Sache reparieren, dann beweisen. Jede Iteration ändert genau ein editierbares Asset, läuft dann erneut gegen einen festen Prüfstand und behält die Änderung nur, wenn F1 sich verbessert und die Neuklassifizierung besser aussieht. Wenn nicht, wird zurückgesetzt. Kein Batch spekulativer Edits, kein „müsste besser sein“. Eine Änderung verdient sich ihren Platz, oder sie ist weg. Und wenn ein Fix hält, wird er in die Fixture-Suite aufgenommen — sodass der behobene Bug niemals still zurückkehren kann. Dieser Promotion-Schritt macht die Schleife rekursiv statt nur repetitiv: Jeder Durchlauf härtet das Orakel, gegen das der nächste Durchlauf validiert.

Die Lektion, die wir immer wieder neu lernen: Metriken übertreiben

Hier ist die Falle, in die wir direkt hineingelaufen sind. Die sekundären Corpus-Metriken — wie oft ein extrahiertes Ziel kein auflösbares Symbol hat, wie viele Symbole „verwaist“ aussehen, und so weiter — übertreiben Probleme massiv. Sie sind größtenteils Paradigma-Artefakte, keine Bugs.

Das klarste Beispiel: llvm zeigte einmal eine 73%ige „Quelle-ohne-Symbol“-Rate und wurde als katastrophal gebrandmarkt. Wir haben nachgegraben. Die echte Genauigkeit lag bei 98,5 %. Die „fehlenden Symbole“ waren fast alle legitime externe Referenzen — Aufrufe in die Standardbibliothek, in Frameworks, in Code, der außerhalb des Repos lebt. Die Metrik hat eine Eigenschaft der Sprache gemessen, keinen Defekt im Handler. Sprachen wie Zig, COBOL und Odin zeigen 65–70 % „Waisen“-Raten und sind vollkommen korrekt; COBOL hatte null echte Fehler.

Hätten wir diese Zahlen die Arbeit steuern lassen, hätten wir Wochen damit verbracht, Handler zu „reparieren“, die bereits richtig waren, und die Sprachen mit stillen, echten Bugs ignoriert. Die Schlussfolgerung ist unverblümt: Die Aggregatmetriken sind bestenfalls ein grobes Triage-Signal. Das echte Qualitätssignal ist die Stichprobe mit Kantenklassifizierung — echte Kanten in echten Repositories anschauen und sie einzeln beurteilen. Daten vor Intuition, aber erst, wenn du weißt, welche Daten die Wahrheit sagen.

Die äußere Schleife: eine Flotte, kein Marathon

Eine Sprache nach der anderen würde bei 280 von ihnen ewig dauern, also ist die innere Schleife in eine äußere eingebettet, die viele parallel laufen lässt.

   pick a wave of near-GREEN / high-error languages
        │
        ▼
   fan out 10–15 agents, each ISOLATED in its own git worktree,
   each grinding ONE language, committing to its own branch
        │
        ▼
   orchestrator integrates serially: file-scoped apply, then
   `manifest diff` — any cross-language regression blocks the batch
        │
        ▼
   gated push (reviewed and confirmed) ──► rotate to the next wave

Jeder Agent arbeitet in einem Wegwerf-Worktree, damit sie sich nicht gegenseitig ins Gehege kommen. Der Orchestrator integriert ihre Fixes einen nach dem anderen, jeweils hinter einem Full-Manifest-Regressionscheck: Eine Änderung, die ihrer eigenen Sprache hilft, aber still drei andere kaputt macht, wird nicht gelandet. Integration wird gated und bestätigt, bevor irgendetwas gepusht wird — das Regressions-Gate entscheidet, was sicher ist, ein Mensch entscheidet weiterhin, was ausgeliefert wird. Dann rotiert der Pool zur nächsten Menge an Sprachen, und das Ganze läuft erneut.

Was noch unperfekt ist

Der Richter kann sich irren, und der Irrtum hat eine Richtung: Ein Agent, der mit zu wenig Kontext läuft, übertreibt. In einem Batch wurden acht Sprachen mit 5–20 % Fehlerrate markiert; bei genauerer Prüfung war nur eine ein echter sprachspezifischer Bug — der Rest waren Richterfehler, weil die eigene Semantik der Sprache übersehen wurde (eine Quellzeile, die legitim mehrere Kanten erzeugt, Parameterbindungen, die als Zuweisungen modelliert werden, Reference-per-Identifier-Sprachen). Deshalb samplen wir mit zwei Seeds und gleichen ab, und deshalb wird eine Abweichung zwischen Richter und Fixtures als das interessanteste Signal behandelt, nicht als endgültiges Urteil — manchmal ist die Fixture das, was falsch ist.

Wir sind auch ehrlich, was das Ziel angeht. Das Ziel ist null echte Fehler, Punkt — aber „null“ ist eine Richtung, auf die wir Sprache für Sprache hingrinden, keine abgehakte Checkbox. Es gibt immer noch ein weiteres Repo mit einem weiteren Idiom.

Verdient, nicht behauptet

Alles, was Maguyva für einen Agent tut — ein Symbol finden, eine Abhängigkeit verfolgen, eine Frage mit zitiertem Code beantworten — beruht darauf, dass die Extraktion darunter stimmt. Über 280 Sprachen hinweg lässt sich „richtig“ nicht behaupten; es muss gegen echten Code kontinuierlich verdient werden. Die Schleife ist, wie wir es verdienen: ein autonomer Stichproben-und-Fix-Zyklus, der seinen eigenen Metriken misstraut, jede Änderung beweist und jeden Fix in eine Schutzmaßnahme gegen die nächste Regression verwandelt. Es ist nicht glamourös. Es ist die Arbeit, die uns erlaubt zu sagen „wir unterstützen deine Sprache“ — und das auch so zu meinen. Grün ist einfach. Korrekt ist verdient.