# Peningkatan Mandiri Rekursif untuk Dukungan Bahasa: Menyempurnakan Kecerdasan Kode di ~280 Bahasa

Canonical source: https://maguyva.ai/id/blog/autonomous-quality-loops-language-grind

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-05-26 · Author: Maguyva Team

> Kami mendukung kecerdasan kode untuk ~280 bahasa. Tidak ada manusia yang bisa mengaudit itu secara manual. Jadi kami membangun loop peningkatan mandiri rekursif untuk dukungan bahasa — 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](/id/team) 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 tercatat 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 peningkatan mandiri rekursif untuk dukungan bahasa: 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 batasan tipe generic, 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 memeriksa kode dunia nyata.

## Loop dalam: spot-check, judge, perbaiki, buktikan

Loop inti berjalan satu bahasa dalam satu waktu:

```text
        ┌──────────────────────────────────────────────────────────┐
        │                                                          │
        ▼                                                          │
  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 mencocokkan setiap edge yang disampel dengan 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 menjadi acuan validasi 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.

```text
   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 melewati pemeriksaan dan konfirmasi sebelum perubahan apa pun di-push — 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, bug sungguhan hanya ditemukan pada satu bahasa — sisanya adalah kesalahan judge karena melewatkan semantik bahasa itu sendiri (satu baris sumber yang secara valid menghasilkan 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 upayakan, bahasa demi bahasa, bukan kotak centang yang sudah selesai. Selalu ada repo lain dengan idiom lain.

## Dibuktikan Lewat Kerja, Bukan Sekadar Diklaim

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 sekadar diklaim; itu harus terus-menerus *dibuktikan* dengan kode sungguhan. Loop inilah cara kami membuktikannya: 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. Kebenaran harus dibuktikan lewat kerja.