Recursive na Pagpapahusay sa Wika: Pag-grind ng Code Intelligence sa Humigit-Kumulang 280 Wika

Ang mga numero sa post na ito ay sumasalamin sa system noong publication (Mayo 2026). Tingnan ang aming team page para sa kasalukuyang mga figure.

Kinukuha ng Maguyva ang mga symbol, reference, at dependency graph mula sa source code sa halos 280 wika. Bawat wika ay may sariling custom na tree-sitter handler — mga query, heuristic, edge case — at bawat handler ay puwedeng mali sa sarili nitong subtle na paraan. Isang method call na naitala bilang read. Isang function na na-attribute sa maling enclosing scope. Isang relationship na wala talaga.

Hindi mo iyan kayang hand-audit. Walang team na kayang basahin ang extraction output sa 280 grammar at makita ang masasamang gilid. Kaya ang interesting na tanong, hindi “tama ba ang extraction namin” — kundi “paano mo malalaman na mali ito, sa ganitong lawak, nang walang tao sa bawat loop.” Ang sagot namin: recursive na pagpapahusay sa wika — isang quality loop na pinapatakbo ng mga language agent, isang LLM na kumikilos bilang judge, at isang tuntunin na paulit-ulit naming natututunan ulit: hindi pareho ang green at tama.

Hindi Pareho ang Green at Tama

Bawat wika ay may fixture suite, at may release gate na nagsu-score nito sa limang dimensyon — accuracy, structural integrity, completeness, quality, at performance. Nagiging GREEN lang ang isang wika kapag, sa mga fixture nito, ang precision ≥ 0.95, recall ≥ 0.99, at F1 ≥ 0.97, na may kahit 20 expected edges para sa statistical confidence. Kung mas mababa diyan, YELLOW o RED ito, at hindi ito nagshi-ship.

Kailangan ang gate na iyon pero hindi ito sapat. Ang mga fixture, sinusubukan laban sa mga fixture na sinulat namin. In-encode nila ang mga kaso na naisip na namin dati. Puwedeng flawless ang isang handler sa mga fixture nito pero puwede pa ring sirain nito ang isang pattern na lumalabas lang sa totoong code — isang macro idiom, isang generic-bound method, isang language feature na walang gumawang fixture. Ang ibig sabihin ng GREEN, pumasa ang mga fixture. Hindi ito nangangahulugang malinis na naeextract ang isang totoong repository. Kaya kailangan ng loop na iwan ang mga fixture at tumingin sa ligaw.

Ang panloob na loop: suriin, husgahan, ayusin, patunayan

Isang wika lang ang tinatrabaho ng core loop sa isang pagkakataon:

        ┌──────────────────────────────────────────────────────────┐
        │                                                          │
        ▼                                                          │
  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) ──┘

May ilang bagay na nagpapagana nito sa halip na magkagulo lang.

Ang judge ay ang agent, hindi isang API call. Kapag sinabi naming “LLM-as-judge,” ang ibig naming sabihin, binabasa mismo ng language agent ang bawat sampled edge kasama ng totoong source at inuuri ito gamit ang fixed na limang-kategoryang rubric: tama ba ang edge na ito, isang false positive, ang tamang relationship pero may maling type, naka-attach sa maling scope, o may maling metadata? Ang rubric na iyon ang buong laro — walang kahulugan ang “23% error rate” hangga’t hindi mo alam kung totoong depekto ba ang mga iyon o mali lang ang bilang ng judge.

Ayusin ang isang bagay, tapos patunayan ito. Bawat iteration, isang editable asset lang ang binabago, tapos tinatakbo ulit laban sa isang fixed harness at itinatago lang ang pagbabago kung umangat ang F1 at mas maganda ang re-classification. Kung hindi, ire-revert ito. Walang batch ng speculative edits, walang “dapat mas maganda.” Kikitain ng isang pagbabago ang lugar nito o mawawala ito. At kapag kumapit ang isang fix, ipo-promote ito papunta sa fixture suite — para hindi na tahimik na makabalik ang bug na na-fix nito. Ang promotion step na iyon ang gumagawa sa loop na recursive sa halip na pag-uulit lang: pinapatigas ng bawat pass ang oracle na sinusuri ng susunod na pass.

Ang Aral na Paulit-ulit Naming Natututunan: Nag-o-over-report ang Metrics

Narito ang bitag, at diretso kaming pumasok dito. Ang mga secondary corpus metric — kung gaano kadalas walang resolvable symbol ang isang extracted target, ilang symbol ang mukhang “orphaned,” at iba pa — nag-o-over-report nang malaki sa mga problema. Karamihan sa mga ito, paradigm artifact lang, hindi bugs.

Ang pinakamalinaw na halimbawa: dati, nagpakita ang llvm ng 73% na “source-without-symbol” rate at na-brand na catastrophic. Sinuri namin ito. Ang tunay na accuracy, 98.5%. Ang “nawawalang symbols” ay halos lahat legitimate external reference — mga tawag papunta sa standard library, papunta sa frameworks, papunta sa code na nasa labas ng repo. Sinusukat ng metric ang isang katangian ng wika, hindi isang depekto sa handler. May mga wika tulad ng Zig, COBOL, at Odin na nagpapakita ng 65–70% na “orphan” rate at ganap namang tama; walang tunay na error ang COBOL.

Kung hinayaan naming pamunuan ng mga numerong iyon ang trabaho, gumugol sana kami ng linggo sa “pag-aayos” ng mga handler na tama na pala at hindi na binigyan ng pansin ang mga wikang may tahimik, tunay na bugs. Diretso ang konklusyon: ang aggregate metrics, isang magaspang na triage signal lang sa pinakamaganda. Ang tunay na quality signal ay ang spot-check na may edge classification — pagtingin sa aktwal na mga edge sa aktwal na mga repository at pagsuri sa mga ito isa-isa. Data higit sa intuition, pero saka mo lang malalaman kung aling data ang totoo.

Ang Outer Loop: Isang Fleet, Hindi Isang Marathon

Isang wika lang sa isang pagkakataon, aabutin ito ng napakatagal kung 280 lahat, kaya ang panloob na loop ay nakabalot sa panlabas na loop na nagpapatakbo ng marami nang sabay.

   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

Ang bawat agent ay nagtatrabaho sa isang throwaway worktree para hindi sila magkakatapakan. Ini-integrate ng orchestrator ang mga fix nila isa-isa, bawat isa naka-gate sa likod ng isang full-manifest regression check: hindi papasok ang isang pagbabago na tumutulong sa sariling wika nito pero tahimik namang sumisira sa tatlo pa. Naka-gate at kumpirmado muna ang integration bago may itulak — ang regression gate ang nagdedesisyon kung ano ang safe, isang tao pa rin ang nagdedesisyon kung ano ang nagshi-ship. Tapos umiikot ang pool papunta sa susunod na set ng mga wika at umuulit ang buong bagay.

Ano ang Hindi Pa Perpekto

Puwedeng magkamali ang judge, at may direksyon ang pagkakamali: ang isang agent na tumatakbo nang may kaunting context lang, nag-o-over-report. Sa isang batch, walong wika ang na-flag sa 5–20% na error; sa inspeksyon, isa lang ang totoong per-language bug — ang natitira, mga pagkakamali ng judge mula sa pagkaligta sa sariling semantics ng wika (isang source line na legitimately nagla-labas ng maraming edge, parameter bindings na na-model bilang assignments, mga wikang reference-per-identifier). Kaya naman kami nag-sample gamit ang dalawang seed at nagcross-check, at kaya naman ang hindi pagkakasundo sa pagitan ng judge at ng mga fixture, tinuturing na pinaka-interesting na signal, hindi tapos nang desisyon — minsan, ang fixture ang mismong mali.

Tapat din kami tungkol sa target. Ang layunin, zero real errors, tapos. Pero direksyon ang “zero” na patuloy naming ginigiling, wika kada wika, hindi isang kahong nachecheck lang. Palaging may isa pang repo na may isa pang idiom.

Kinita, Hindi Basta Sinabi

Lahat ng ginagawa ng Maguyva para sa isang agent — paghahanap ng symbol, pagsubaybay ng dependency, pagsagot ng tanong na may cited code — nakasalalay sa katumpakan ng extraction sa ilalim nito. Sa 280 wika, hindi puwedeng basta sabihin na “tama” ito; kailangan itong patuloy na kitain laban sa totoong code. Ang loop ang paraan namin para kitain ito: isang autonomous na siklo ng mabilisang pagsusuri at pag-aayos na pinaghihinalaan ang sarili nitong metrics, pinapatunayan ang bawat pagbabago, at ginagawang guard ang bawat fix laban sa susunod na regression. Hindi ito kaakit-akit. Ito ang trabaho na nagbibigay-daan sa aming sabihing “sinusuportahan namin ang wika mo” at seryosohin ito. Madali ang green. Kinita ang tama.