Pelajaran dari penulisan ulang Bun dari Zig ke Rust yang selesai dalam 11 hari dengan AI

• Saat kebocoran dan crash terus terjadi di Zig yang tidak memiliki keamanan memori, Bun memindahkan 535.496 baris kode ke Rust dengan 64 agen AI, memangkas pekerjaan yang akan memakan 1–2 tahun menjadi 11 hari
• Titik awal keberhasilan adalah PORTING.md sepanjang 600 baris, lalu proses dilanjutkan secara berurutan dengan konversi paralel per file, dua kali review adversarial, perbaikan error kompilasi, pengujian lokal, dan lolos CI
• Untuk membuat 6.500 commit, digunakan US$165.000 berdasarkan harga API, serta 5,9 miliar token input non-cache, 690 juta token output, dan 72 miliar token pembacaan input cache
• Jika dikerjakan manual, diperkirakan 3 engineer yang sangat memahami codebase harus menghentikan peningkatan produk, perbaikan bug dan keamanan, serta pengembangan fitur baru selama sekitar 1 tahun, sehingga penulisan ulang itu sendiri kemungkinan sulit dilakukan
• Untuk mengulangi pendekatan yang sama, dibutuhkan engineer yang sangat memahami codebase, test suite yang kuat sehingga hasilnya bisa dipercaya, serta kemauan menanggung biaya token meski keberhasilannya belum pasti

---

Mengapa Bun memilih penulisan ulang ke Rust

• Bun adalah proyek production yang kompleks yang menyediakan banyak fitur di luar JavaScript runtime
  • Transformasi JavaScript·TypeScript·CSS, bundling, minifikasi
  • Test runner dan package manager kompatibel npm
  • Resolusi modul, klien WebSocket, implementasi Node.js, dan berbagai modul
• Unduhan bulanannya mencapai 22 juta, dan digunakan oleh Claude Code serta OpenCode, sementara Vercel·Railway·DigitalOcean mendukungnya secara langsung
• Zig bukan bahasa yang aman terhadap memori, sehingga bahkan di Bun versi terbaru masih terus terjadi kebocoran memori, crash akibat masalah memori, penulisan di luar batas heap, dan sebagainya
  • Tim Bun menambal compiler Zig dan memperkenalkan pengujian kebocoran memori end-to-end, tetapi tidak berhasil menghilangkan masalah tersebut
  • Kebocoran kecil dan crash sesekali muncul saat menangani masa hidup nilai garbage-collected dan nilai yang dikelola manual secara bersamaan
  • Untuk setiap alokasi memori, mereka harus meninjau lokasi pembebasan, kemungkinan double-free, penanganan exception JavaScript, hingga visibilitas pointer pada conservative stack scanner
• Di Rust yang aman, use-after-free dan double-free menjadi error kompilasi, sementara masalah lupa membebaskan resource di jalur error bisa ditangani lewat pembersihan otomatis berbasis Drop
• Metode memperkenalkan smart pointer ala Rust langsung ke kode Bun juga sempat dipertimbangkan, tetapi kegunaannya lebih buruk daripada Rust dan tidak memberikan jaminan yang sama

Mengapa proyek penulisan ulang yang ada biasanya memakan waktu lama

• Selama penulisan ulang berlangsung, fitur terus ditambahkan ke codebase asli, sehingga waktu penyelesaian cenderung terus mundur
  • Pekerjaan yang diperkirakan 9 bulan bisa jadi masih memerlukan sekitar 6 bulan lagi setelah 9 bulan berlalu
  • Bahkan setelah 15 bulan, masih bisa tersisa beberapa bulan pekerjaan karena harus mengejar fitur baru
  • Bahkan jika beruntung, proyek baru selesai dalam sekitar 18 bulan setelah pembekuan fitur selama 2 bulan, sehingga estimasi awal 9 bulan bisa membengkak menjadi lebih dari 2 tahun
• Kode Zig Bun di luar komentar berjumlah 535.496 baris, sehingga diperkirakan tim engineer kecil akan membutuhkan sekitar 1 tahun untuk memindahkannya ke bahasa lain
• Karena tidak realistis menghabiskan 1 tahun tanpa perbaikan yang terlihat oleh pengguna, mereka memutuskan menguji dengan Fable apakah kemungkinan porting ke Rust bisa diverifikasi dalam waktu seminggu

Perancangan dan validasi awal untuk porting

• Pada tahap pertama, selama sekitar 3 jam mereka berdiskusi dengan Claude tentang cara memetakan pola Zig ke Rust sedekat mungkin, lalu merangkumnya dalam PORTING.md sepanjang 600 baris
• Panduan porting itu memuat batasan spesifik untuk mempertahankan struktur eksekusi Bun yang ada
  • Tidak menggunakan tokio, rayon, hyper, async-trait, futures
  • Melarang modul yang mengakses I/O seperti std::fs, std::net, std::process
  • Karena Bun memiliki event loop dan system call sendiri, mereka memakai callback dan state machine seperti di Zig alih-alih async fn
  • Jika terjadi konflik dengan borrow checker, simpan nilai skalar yang diperlukan ke variabel lokal, akhiri borrow, lalu borrow lagi
  • Penggunaan raw pointer untuk menghindari borrow checker dilarang, dan lokasi yang strukturnya diubah harus diberi catatan porting
• Dari total 1.448 file, mereka menulis ulang 3 file terlebih dahulu, lalu Claude melakukan review adversarial dua kali dalam sesi terpisah dari pekerjaan perubahan

Pekerjaan paralel dari 64 agen AI

• Pekerjaan dipecah agar file dapat diproses secara independen, lalu 64 agen AI dijalankan secara paralel
• Pada awalnya, beberapa agen bentrok karena menyentuh status repositori yang sama
  • Satu agen menjalankan git stash, lalu agen lain menjalankan git stash pop dan git reset HEAD --hard
  • Memberikan worktree terpisah untuk tiap agen menyebabkan kekurangan ruang disk karena ukuran repositori Bun, dan perubahan tetap harus dikompilasi bersama pada akhirnya
• Workflow kemudian diperbaiki dengan melarang perintah Git seperti git stash, git reset, kecuali perintah untuk langsung melakukan commit pada file tertentu, serta melarang cargo dan perintah yang membutuhkan waktu eksekusi lama
• Pada akhirnya, pekerjaan dibagi ke 4 worktree, dan di tiap worktree ada 16 Claude yang melakukan commit dan push file
• Selama dua hari, agen-agen itu memindahkan 535.496 baris kode Zig, dan setiap commit melewati dua kali review adversarial sebelum diterapkan

Error kompilasi dan perbaikan pengujian

• Konversi awal memang selesai, tetapi kodenya belum bisa dikompilasi, sehingga Claude memperbaiki error berdasarkan crate sebagai unit kompilasi tingkat atas di Rust
• Judul tahap menyebut sekitar 1.600 error kompilasi, tetapi kutipan di dalamnya menyatakan bahwa sekitar 16.000 error terungkap saat menyelesaikan cyclic dependency
• Proses perbaikan error juga diparalelkan
  • Menjalankan cargo check di setiap crate
  • Mengelompokkan output per file dan menyimpan file error
  • Memperbaiki semua error kompilasi di crate tersebut
  • Dua reviewer adversarial memeriksa perubahan
  • Satu agen perbaikan menerapkan hasil review
• Para agen memperbaiki error kompilasi dari tengah malam hingga pukul 11:30 pagi tanpa campur tangan manusia
• Setelah itu, selama sekitar dua hari lagi mereka membuat test suite besar bisa dijalankan secara lokal tanpa error kompilasi, lalu menghabiskan beberapa hari tambahan untuk memperbaiki test yang gagal agar lolos CI
• Setelah semua test lolos dan perilakunya terverifikasi, perubahan digabungkan, dan total waktu dari perencanaan hingga selesai adalah 11 hari
  • Porting sekitar 550 ribu baris kode
  • 6.500 commit
  • Menggunakan 64 agen

Biaya dan hasil dibandingkan pengerjaan manual

• Berdasarkan harga API Fable, total biaya penulisan ulang adalah US$165.000
  • 5,9 miliar token input non-cache
  • 690 juta token output
  • 72 miliar token pembacaan input cache
• Anthropic menjual token API dengan margin, sehingga biaya internal sebenarnya lebih rendah dari itu
• Biaya API ini setara dengan gaji pokok tahunan software engineer tingkat menengah di perusahaan AS, tetapi dinilai mustahil bagi satu engineer dengan gaji setara untuk menghasilkan capaian yang sama dalam 11 hari
• Ini juga sejalan dengan penilaian Mitchell Hashimoto bahwa Fable sangat unggul terutama pada tugas sulit dan terfokus yang memiliki fungsi reward yang jelas
• Jika dikerjakan manual, diperkirakan dibutuhkan 3 engineer yang sepenuhnya memahami codebase selama sekitar 1 tahun
  • Selama itu, akan sulit melanjutkan peningkatan kompatibilitas Node.js, perbaikan bug dan masalah keamanan, serta implementasi fitur baru
  • Alternatif yang realistis adalah tidak melakukan penulisan ulang dan terus memperbaiki bug memori yang ada

Syarat untuk diterapkan ke proyek lain

• Jika AI bisa memangkas penulisan ulang atau migrasi yang memakan 1 tahun menjadi setingkat seminggu, maka proyek yang sebelumnya sulit dipertimbangkan pun menjadi layak dijalankan
• Untuk menggunakan ulang alur kerja Bun, ada tiga syarat
  • Engineer yang sangat memahami codebase dan punya kemauan kuat untuk mengerjakannya
  • Test suite yang cukup kuat sehingga kelulusan test bisa dipercaya sebagai bukti perilaku sebenarnya
  • Kemauan menginvestasikan biaya token yang cukup besar bahkan saat keberhasilan belum bisa diketahui sebelumnya
• Pekerjaan berulang seperti migrasi kode relatif ditangani dengan baik oleh LLM, jadi jika ada test yang baik dan engineer yang bisa merapikan masalahnya, peluang keberhasilannya tinggi
• Tidak semua proyek membutuhkan US$165.000
  • Untuk proyek yang lebih sederhana, biayanya bisa lebih rendah
  • Untuk perencanaan tingkat tinggi bisa digunakan model paling mahal, sementara untuk coding dan review dapat dipakai model yang lebih murah
• Migrasi berbasis AI semakin cepat, tetapi kecepatan seperti Bun hanya bisa dicapai pada proyek yang direkayasa dengan baik