Membangun kompiler C dengan tim Claude paralel

• 16 agen Claude berkolaborasi secara paralel untuk menyelesaikan kompiler C berbasis Rust, mencapai tingkat yang mampu membangun kernel Linux 6.9
• Dengan sekitar 2.000 sesi dan biaya 20.000 dolar AS, sistem ini menghasilkan basis kode sekitar 100.000 baris, serta mendukung arsitektur x86·ARM·RISC-V
• Para agen bekerja terus-menerus tanpa campur tangan manusia melalui harness loop otomatis, dengan struktur pengujian, paralelisasi, dan pembagian peran untuk meningkatkan efisiensi
• Hasilnya menunjukkan kompatibilitas GCC dan tingkat kelulusan pengujian yang tinggi, tetapi aspek seperti pembuatan kode x86 16-bit, linker, dan kualitas optimisasi masih belum tuntas
• Eksperimen ini menjadi contoh untuk menguji batasan dan potensi tim LLM otonom, sementara keamanan dan pengelolaan kualitas dalam lingkungan pengembangan sepenuhnya otonom muncul sebagai tantangan utama ke depan

---

Ikhtisar proyek kompiler C berbasis tim agen

• Eksperimen di mana beberapa instance Claude berkolaborasi secara paralel untuk mengembangkan satu basis kode
  • Berulang kali menulis, menguji, dan memperbaiki kode secara otonom tanpa campur tangan manusia secara real time
• Tujuannya adalah menyelesaikan kompiler C yang ditulis dalam Rust agar bisa langsung membangun kernel Linux
• Total digunakan 16 agen, sekitar 2.000 sesi, serta 200 juta token input dan 140 juta token output
• Hasil akhirnya adalah kompiler berukuran 100.000 baris, yang mampu membangun kernel Linux 6.9 dan proyek open source utama (QEMU, FFmpeg, SQLite, Redis, dan lain-lain)

Perancangan harness Claude untuk eksekusi jangka panjang

• Claude Code sebelumnya memerlukan input manusia, tetapi dapat berjalan otonom dengan harness eksekusi otomatis berstruktur loop tak terbatas
  • Struktur pengulangan otomatis yang langsung mengerjakan tugas berikutnya setelah satu tugas selesai
  • Ada juga kasus saat Claude tanpa sengaja menjalankan pkill -9 bash dan menghentikan dirinya sendiri
• Struktur eksekusi paralel memanfaatkan container Docker dan sinkronisasi Git
  • Setiap agen bekerja di /workspace lalu melakukan push ke /upstream
  • Konflik pekerjaan dicegah dengan lock berbasis file teks
  • Konflik merge diselesaikan langsung oleh Claude

Cara kerja operasional Claude paralel

• Keunggulan eksekusi paralel adalah debugging simultan dan diferensiasi peran
  • Sebagian agen menulis kode, sementara sebagian lain menangani dokumentasi, kontrol kualitas, dan optimisasi performa
• Tidak ada komunikasi langsung atau koordinator pusat; setiap agen secara otonom memilih tugas berikutnya
• Riwayat Git menyimpan catatan lock pekerjaan dan dokumen progres dari setiap agen

Pelajaran dari pemrograman tim Claude

Pentingnya pengujian berkualitas tinggi

• Karena Claude bekerja otonom berdasarkan pengujian yang diberikan, akurasi validator menjadi sangat penting
  • Jika ada false positive, pengembangan bisa bergerak ke arah yang salah
• Dibangun pipeline continuous integration (CI) untuk memastikan fitur yang sudah ada tidak rusak
• Kualitas dijaga dengan memanfaatkan skrip build open source dan compiler test suite

Mendesain lingkungan dari sudut pandang Claude

• Karena setiap agen memulai dari container baru tanpa konteks, dokumentasi progres menjadi wajib
  • Agen diinstruksikan untuk terus memperbarui README dan file progres
• Pencegahan polusi konteks: log diminimalkan, dan error dicatat agar dapat dikenali dengan kata kunci ERROR
• Untuk mengompensasi ketiadaan persepsi waktu, digunakan opsi --fast untuk menjalankan uji sampel 1~10%

Batas paralelisasi dan solusinya

• Paralelisasi mudah dilakukan saat banyak pengujian bersifat independen, tetapi build kernel Linux adalah satu tugas raksasa tunggal yang memicu konflik
• Sebagai solusi, GCC digunakan sebagai compiler oracle acuan
  • Sebagian file dibangun dengan GCC, sisanya dengan kompiler Claude
  • Saat gagal, file bermasalah dapat dipersempit untuk memungkinkan debugging paralel
  • Setelah itu, delta debugging digunakan untuk mendeteksi error yang saling bergantung

Diferensiasi peran agen

• Ada pembagian peran yang terspesialisasi seperti penghapusan kode duplikat, peningkatan performa, pembuatan kode yang efisien, perbaikan struktur Rust, dan dokumentasi
• Dengan menggabungkan paralelisme dan spesialisasi, efisiensi pengelolaan basis kode skala besar meningkat

Evaluasi performa model Opus 4.6

• Hingga Opus 4.5, build proyek besar masih belum memungkinkan; pada Opus 4.6 barulah untuk pertama kalinya mencapai tingkat yang praktis
• Diimplementasikan secara clean room, tanpa akses internet dan hanya menggunakan pustaka standar Rust
• Lulus 99% GCC torture test suite, dan Doom dapat dijalankan
• Keterbatasan:
  • Tidak dapat menghasilkan kode x86 16-bit, sehingga pada tahap boot masih perlu memanggil GCC
  • Assembler dan linker belum selesai, dan masih ada beberapa bug
  • Efisiensi kode yang dihasilkan rendah, bahkan lebih tidak efisien daripada GCC dengan optimisasi dimatikan
  • Kualitas kode Rust cukup baik, tetapi belum setara tingkat pakar

Batasan dan potensi tim agen otonom

• Proyek ini menjadi benchmark untuk mengukur batas kolaborasi otonom LLM
• Pengembangan yang sepenuhnya otonom membawa jaminan kualitas dan risiko keamanan
  • Ada risiko menganggap pekerjaan selesai hanya karena pengujian lolos
• Disampaikan pula kekhawatiran terhadap deploy kode tanpa verifikasi manusia
• Namun demikian, eksperimen ini membuktikan bahwa tim agen otonom dapat menyelesaikan proyek yang kompleks
• Seiring kemajuan model di masa depan, strategi pengembangan otonom yang aman menjadi tugas penting

Prospek ke depan

• Perkembangan model bahasa berevolusi dari autocomplete IDE → penyelesaian fungsi → pair programming → pelaksanaan proyek otonom
• Agent teams menunjukkan kemungkinan pengembangan yang sepenuhnya otonom
• Di tengah laju kemajuan teknologi yang cepat, ditekankan perlunya kerangka etika dan keamanan baru
• Diharapkan pemanfaatan positif dapat mengimbangi risiko negatif, tetapi tetap diperlukan kesiapan menghadapi paradigma pengembangan baru

[mammal]

Karena ini adalah proyek yang dibuat hanya dengan pustaka standar Rust, bukan compiler yang dibuat dengan C, saya rasa kritik bahwa data pelatihan berisi kode C gcc/clang agak seperti menggeser tiang gawang. Bagaimanapun juga, ini luar biasa.

[GN⁺]

Komentar Hacker News

• Saya hampir 10 tahun bekerja di Google untuk membangun kernel Linux dengan Clang. Proyek kali ini (clangbuiltlinux.github.io) katanya berhasil melakukan hal yang sama dengan LLM lewat 2.000 sesi dan biaya API 20 ribu dolar. Fakta bahwa hasilnya benar-benar bisa boot sangat mengejutkan. Namun, efisiensi kode yang dihasilkan rendah, bahkan lebih tidak efisien daripada versi GCC dengan optimisasi dimatikan. Meski begitu, ini tetap proyek yang sangat keren

  • Memang keren, tapi mungkin saja ini hasil menyalin PR orang lain
  • Katanya Opus tidak bisa mengimplementasikan generator kode x86 16-bit, jadi mereka memakai jalan pintas dengan memanggil GCC pada tahap boot. Jadi masih diragukan apakah ini benar-benar boot sendiri
  • Ini terasa seperti kembalinya era “Trusting Trust” milik Ken Thompson. AI mungkin segera akan menanamkan dirinya sendiri ke dalam compiler
  • Kalau biayanya 20 ribu dolar, dengan uang itu mereka juga bisa mempekerjakan 8 developer senior untuk waktu singkat. Terasa seperti biaya marketing yang berlebihan, dan model pendapatan nyatanya masih tidak jelas

• Ini pendekatan yang jauh lebih realistis dibanding proyek browser Cursor. Mereka menyebutnya implementasi clean room, dengan hanya memakai pustaka standar Rust tanpa akses internet. Compiler 100 ribu baris itu katanya bisa membangun Linux 6.9, QEMU, FFmpeg, SQLite, Postgres, dan Redis.
  Opus 4.5 adalah yang pertama kali bisa lolos pengujian besar, dan hasil kali ini tampaknya nyaris memakai seluruh batas kemampuannya.
  Terlepas dari berbagai keterbatasannya, saya menganggap ini eksperimen yang mengesankan

  • Ungkapan “implementasi clean room” tampaknya berlebihan. Model itu sudah dilatih dengan compiler C dari seluruh internet, jadi sebenarnya tidak perlu memakai istilah itu
  • Menilai hasil seperti ini hanya dari level saat ini terasa kurang tepat. Kalau melihat kecepatan perkembangan beberapa bulan terakhir, setahun lagi hasilnya mungkin akan jauh di luar bayangan
  • Ini pada dasarnya bukan clean room, melainkan lebih mendekati hasil LLM menguraikan pengetahuan terkompresi saat training lewat basis pengujian
  • Kemungkinan modelnya memang dilatih dengan kode GCC atau Clang, jadi saya penasaran seberapa mirip hasilnya dengan kode asli
  • Secara pribadi ini memang hebat, tapi dari sudut pandang pengguna nyata terasa kurang menarik. Menambahkan ISA baru ke LLVM atau membuat compiler untuk bahasa baru tampaknya akan lebih bermakna

• Awalnya saya berpikir “wah, hebat”, tapi kemudian berubah pikiran. Compiler C adalah perangkat lunak dengan spesifikasi yang sangat ketat, jadi relatif lebih mudah ditangani LLM.
  Namun, sebagian besar pekerjaan kita berada di lingkungan dengan kebutuhan yang ambigu dan tujuan yang terus berubah. Saya penasaran apakah ini juga akan bekerja baik di ranah seperti itu

  • Saya malah tertawa saat mendengar “compiler C itu jelas”. “Unspecified behavior” ada begitu banyak
  • Generasi kode yang disesuaikan dengan tes itu mirip dengan fitting model ML. Manusia tetap harus merancang dan memverifikasi tesnya

• Ekspektasi bahwa hasilnya harus sempurna terasa aneh. Fakta bahwa ini mungkin dilakukan saja sudah mengejutkan. Upaya seperti ini bisa saja tercermin pada training Opus atau Sonnet berikutnya, dan suatu hari mungkin muncul model yang bisa membuat compiler efisien sendiri

  • Saya juga berpikir begitu. “Yang mengejutkan bukan seberapa baik anjing itu menari, melainkan fakta bahwa ia bisa menari”
  • Belakangan sentimen negatif terhadap AI generatif makin besar, jadi suasana yang langsung menyebut ‘sampah AI’ hanya karena ada sedikit cacat terasa disayangkan. Padahal ini sekadar demo dan proof of concept

• Proyek ini katanya bisa membangun kernel Linux, QEMU, FFmpeg, Redis, bahkan Doom. Benar-benar mengejutkan.
  Namun, sistem agen seperti ini bekerja baik di area yang bisa diuji, tetapi punya batas di area yang butuh konteks seperti pengambilan keputusan bisnis

  • Untuk model yang sudah dilatih dengan seluruh internet, saya meragukan apakah konsep “implementasi clean room” masih punya makna
  • Langkah berikutnya adalah AI benar-benar memahami dan mengoperasikan konteks bisnis. Misalnya, jika melihat benchmark seperti Vending-Bench, mungkin tidak lama lagi akan ada AI product manager yang otomatis melakukan wawancara pengguna, eksperimen, sampai usulan roadmap

• Proyeknya keren, tapi sebaiknya tidak usah menyebut “clean room”. Karena ini model yang dilatih dengan kode berhak cipta, jadi justru lebih dekat ke kebalikannya

  • Tapi manusia juga mempelajari codebase yang sudah ada, lalu berdasarkan pengetahuan itu melakukan implementasi clean room
  • Seperti manusia yang mendaur ulang pengetahuan yang dipelajari di satu perusahaan di tempat lain, LLM juga menyusun ulang data pelatihan secara transformasional. Selama bukan sekadar menyalin langsung, persoalannya jadi berbeda

• Menurut issue GitHub, masalahnya terjadi karena path include yang hilang. Compiler-nya sendiri normal

  • Sepertinya hanya paket seperti glibc-devel yang tidak terpasang
  • Tulisannya terlalu panjang dan kurang dasar yang kuat. Rasanya melewatkan inti persoalan
  • AI adalah masa depan
  • Hasil yang benar-benar mengejutkan

• Saya berharap mereka merilis semua prompt dan struktur agen. Itu akan sangat bagus untuk pembelajaran, karena mereproduksinya dengan menghabiskan 20 ribu dolar sendiri terasa berat

  • Akhir-akhir ini terasa disayangkan karena suasananya jadi hanya melihat hasil tanpa penasaran pada prosesnya

• Ini seperti versi yang benar-benar berjalan dari blog Cursor. Bukti bahwa mereka benar-benar membangun kernel Linux jauh lebih meyakinkan

  • Awalnya saya ingin membuat bahasa ringan untuk April Mop, tapi sekarang hasilnya sudah sampai level seperti ini, jadi cukup mengejutkan. Meski begitu, saya tetap berniat terus mencoba

• Ini pendekatan seperti “bisa membangun piramida tapi tidak bisa membangun katedral” (tulisan terkait).
  Mereka pada dasarnya memaksa implementasi fungsi dengan menggelontorkan sumber daya komputasi yang sangat besar, dan 20 ribu dolar itu pantas disebut hangus terbakar.
  Mendapatkan hasil linear dengan komputasi eksponensial memang punya makna, tetapi dalam jangka panjang tampaknya arah yang tidak efisien

  • 20 ribu dolar itu mungkin berdasarkan API, sedangkan jika memakai langganan mungkin setara 5~6 paket Max
  • Meski begitu, itu tetap hanya setara biaya tenaga kerja engineer FAANG selama 2 minggu. Manusia tidak mungkin membuat compiler dalam 2 minggu, jadi untuk sebuah demonstrasi ini sudah sangat bernilai