Language Recursive Self-Improvement: Menggrind Kecerdasan Kode di ~280 Bahasa
> Kami mendukung kecerdasan kode untuk ~280 bahasa. Tidak ada manusia yang bisa mengaudit itu secara manual. Jadi kami membangun loop language recursive self-improvement — spot-check, LLM-as-judge, perbaiki satu hal, validasi ulang — dan menjalankannya dengan sepasukan agen terisolasi sampai ekstraksinya benar-benar tepat, bukan sekadar hijau.
Angka dalam tulisan ini mencerminkan sistem pada saat publikasi (Mei 2026). Lihat halaman tim kami untuk angka terkini.
Maguyva mengekstraksi simbol, referensi, dan graf dependensi dari kode sumber di sekitar 280 bahasa. Setiap bahasa punya handler tree-sitter khusus — query, heuristik, edge case — dan setiap handler bisa salah dengan caranya masing-masing yang halus. Sebuah panggilan method yang teremisikan sebagai pembacaan. Sebuah fungsi yang teratribusi ke scope pembungkus yang salah. Sebuah relasi yang sebenarnya tidak ada.
Anda tidak bisa mengaudit itu secara manual. Tidak ada tim yang bisa membaca output ekstraksi lintas 280 grammar dan menemukan edge yang salah. Jadi pertanyaan yang menarik bukan “apakah ekstraksi kami benar” — melainkan “bagaimana Anda menemukan bahwa itu salah, pada skala seluas ini, tanpa manusia di setiap loop.” Jawaban kami adalah language recursive self-improvement: sebuah loop kualitas yang digerakkan oleh agen bahasa, sebuah LLM yang bertindak sebagai judge, dan satu aturan yang terus kami pelajari ulang: hijau tidak sama dengan benar.
Hijau bukan berarti benar
Setiap bahasa punya suite fixture, dan sebuah release gate menilainya di lima dimensi — akurasi, integritas struktural, kelengkapan, kualitas, dan performa. Sebuah bahasa baru menjadi GREEN hanya ketika, pada fixture-nya, presisi ≥ 0,95, recall ≥ 0,99, dan F1 ≥ 0,97, dengan minimal 20 edge yang diharapkan untuk keyakinan statistik. Di bawah itu, statusnya YELLOW atau RED, dan tidak akan dirilis.
Gate itu perlu tetapi tidak cukup. Fixture divalidasi terhadap fixture yang kami tulis sendiri. Fixture mengenkode kasus-kasus yang sudah kami pikirkan sebelumnya. Sebuah handler bisa sempurna pada fixture-nya tetapi tetap mengacaukan sebuah pola yang hanya muncul di kode dunia nyata — sebuah idiom macro, sebuah method dengan generic-bound, sebuah fitur bahasa yang tidak pernah ditulis fixture-nya oleh siapa pun. GREEN berarti fixture-nya lulus. Itu tidak berarti sebuah repositori sungguhan terekstraksi dengan bersih. Jadi loop ini harus meninggalkan fixture dan melihat ke alam liar.
Loop dalam: spot-check, judge, perbaiki, buktikan
Loop inti berjalan satu bahasa dalam satu waktu:
┌──────────────────────────────────────────────────────────┐
│ │
▼ │
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) ──┘
Beberapa hal membuat ini berjalan alih-alih hanya berputar-putar tanpa hasil.
Judge-nya adalah agen itu sendiri, bukan sekadar panggilan API. Ketika kami bilang “LLM-as-judge,” maksud kami agen bahasa itu sendiri membaca setiap edge yang disampel terhadap kode sumber sungguhan dan mengklasifikasikannya dengan rubrik lima kategori yang tetap: apakah edge ini benar, sebuah false positive, relasi yang tepat dengan tipe yang salah, terpasang pada scope yang salah, atau membawa metadata yang salah? Rubrik itulah keseluruhan permainannya — “tingkat kesalahan 23%” tidak berarti apa-apa sampai Anda tahu apakah itu cacat sungguhan atau judge yang salah hitung.
Perbaiki satu hal, lalu buktikan. Setiap iterasi mengubah tepat satu aset yang bisa diedit, lalu dijalankan ulang terhadap harness yang tetap dan mempertahankan perubahan itu hanya jika F1 membaik dan reklasifikasinya terlihat lebih baik. Jika tidak, perubahan itu dibatalkan. Tidak ada batch edit spekulatif, tidak ada “seharusnya lebih baik.” Sebuah perubahan mendapatkan tempatnya, atau hilang. Dan ketika sebuah perbaikan bertahan, perbaikan itu dipromosikan ke dalam suite fixture — sehingga bug yang diperbaikinya tidak akan pernah diam-diam kembali. Langkah promosi itulah yang membuat loop ini rekursif, bukan sekadar berulang: setiap putaran memperkuat oracle yang divalidasi oleh putaran berikutnya.
Pelajaran yang terus kami pelajari ulang: metrik terlalu banyak melaporkan
Inilah jebakannya, dan kami langsung terjerumus ke dalamnya. Metrik korpus sekunder — seberapa sering sebuah target hasil ekstraksi tidak punya simbol yang bisa diresolusi, berapa banyak simbol yang terlihat “yatim,” dan seterusnya — secara masif melaporkan masalah yang terlalu banyak. Kebanyakan itu adalah artefak paradigma, bukan bug.
Contoh paling jelas: llvm pernah menunjukkan tingkat “source-without-symbol” sebesar 73% dan langsung dicap bencana. Kami menggalinya lebih dalam. Akurasi sesungguhnya adalah 98,5%. “Simbol yang hilang” itu hampir semuanya adalah referensi eksternal yang sah — panggilan ke pustaka standar, ke framework, ke kode yang hidup di luar repositori. Metrik itu mengukur properti dari bahasanya, bukan cacat pada handler-nya. Bahasa seperti Zig, COBOL, dan Odin menunjukkan tingkat “yatim” sebesar 65–70% dan sepenuhnya benar; COBOL bahkan tidak punya satu pun kesalahan sungguhan.
Jika kami membiarkan angka-angka itu mengendalikan pekerjaan, kami akan menghabiskan berminggu-minggu “memperbaiki” handler yang sebenarnya sudah benar dan mengabaikan bahasa-bahasa dengan bug sungguhan yang diam-diam bersembunyi. Kesimpulannya blak-blakan: metrik agregat paling banter hanya sinyal triase kasar. Sinyal kualitas sesungguhnya adalah spot-check dengan klasifikasi edge — melihat edge sungguhan di repositori sungguhan dan menilainya satu per satu. Data mengalahkan intuisi, tapi hanya setelah Anda tahu data mana yang berkata jujur.
Loop luar: sepasukan, bukan maraton
Satu bahasa dalam satu waktu akan memakan waktu selamanya di seluruh 280 bahasa, jadi loop dalam dibungkus dalam loop luar yang menjalankan banyak bahasa secara paralel.
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
Setiap agen bekerja di worktree sekali pakai sehingga mereka tidak bisa saling menabrak. Orchestrator mengintegrasikan perbaikan mereka satu per satu, masing-masing di balik pemeriksaan regresi full-manifest: sebuah perubahan yang membantu bahasanya sendiri tetapi diam-diam merusak tiga bahasa lain tidak akan mendarat. Integrasi digerbangi dan dikonfirmasi sebelum apa pun didorong keluar — gate regresi memutuskan apa yang aman, manusia tetap yang memutuskan apa yang dirilis. Lalu pool berputar ke set bahasa berikutnya dan seluruh proses berjalan lagi.
Apa yang masih belum sempurna
Judge-nya bisa saja salah, dan kesalahan itu punya arah: sebuah agen yang berjalan dengan konteks terlalu sedikit melaporkan berlebihan. Dalam satu batch, delapan bahasa ditandai dengan tingkat kesalahan 5–20%; setelah diperiksa, hanya satu yang merupakan bug sungguhan per bahasa — sisanya adalah kesalahan judge karena melewatkan semantik bahasa itu sendiri (satu baris sumber yang secara sah mengemisikan beberapa edge, binding parameter yang dimodelkan sebagai assignment, bahasa dengan reference-per-identifier). Itulah sebabnya kami menyampel dengan dua seed dan melakukan cross-check, dan mengapa ketidaksepakatan antara judge dan fixture diperlakukan sebagai sinyal paling menarik, bukan verdict final — kadang fixture-lah yang justru salah.
Kami juga jujur soal targetnya. Tujuannya adalah nol kesalahan sungguhan, titik — tetapi “nol” adalah arah yang terus kami grind, bahasa demi bahasa, bukan kotak centang yang sudah selesai. Selalu ada repo lain dengan idiom lain.
Didapatkan, Bukan Diasumsikan
Semua yang dilakukan Maguyva untuk seorang agen — menemukan sebuah simbol, menelusuri sebuah dependensi, menjawab sebuah pertanyaan dengan kode yang dikutip — bertumpu pada ekstraksi di baliknya yang benar. Di 280 bahasa, “benar” tidak bisa diasumsikan; itu harus terus-menerus didapatkan dari kode sungguhan. Loop inilah cara kami mendapatkannya: sebuah siklus otonom spot-check-dan-perbaiki yang memperlakukan metriknya sendiri dengan curiga, membuktikan setiap perubahan, dan mengubah setiap perbaikan menjadi penjaga terhadap regresi berikutnya. Ini tidak glamor. Inilah kerja yang memungkinkan kami berkata “kami mendukung bahasa Anda” dan sungguh-sungguh memaksudkannya. Hijau itu mudah. Benar itu didapatkan.
Bacaan terkait
Lebih banyak dari build log Maguyva
Mengapa Kami Meningkatkan Pencarian Kode ke voyage-4-large_
Kami memindahkan embedding kode kami ke voyage-4-large — saat ini teratas di papan peringkat retrieval kode RTEB publik. Versi jujurnya: trade-off yang kami ambil, apa yang sebenarnya kami indeks, dan mengapa kami membayar untuk embedding premium.
Multi-Modal Fusion Search: Memilih Retriever yang Tepat untuk Setiap Kueri_
Kueri seperti 'di mana parseConfig didefinisikan' menginginkan pencarian yang berbeda dari 'bagaimana auth bekerja'. Maguyva mengklasifikasikan intent, memberi bobot pada empat modalitas retrieval sesuai kebutuhannya, lalu menggabungkan hasilnya dengan weighted Reciprocal Rank Fusion.
Observabilitas Agen: Hooks, Alloy, dan Grafana_
Kami menghubungkan Claude Code dan Codex ke satu stack Grafana yang sama dengan OpenTelemetry dan Alloy, lalu menggunakan trace dan log untuk menemukan dan memperbaiki masalah perilaku agen langsung di sumbernya.