🍞 Apa Itu Bun? Di Balik Migrasi 535 Ribu Baris Kode dari Zig ke Rust dengan AI

Bun memindahkan 535.496 baris kode perangkat JavaScript-nya dari Zig ke Rust dalam 11 hari. Pada puncaknya, sekitar 64 Claude bekerja bersamaan. Jika dihitung memakai tarif API, kebutuhan komputasinya diperkirakan setara US$165.000.

Angka-angka itu memang menggoda untuk dijadikan headline. Namun, bagian yang paling berguna justru ada di baliknya. Tim Bun tidak mengetik satu perintah "tolong tulis ulang semuanya", lalu menunggu keajaiban. Mereka menyusun aturan migrasi, memetakan umur data di memori, membagi pekerjaan, memisahkan penulis dan pemeriksa kode, serta tetap menempatkan manusia sebagai pengawas.

Sebelum membahas eksperimen AI tersebut, kita perlu menjawab satu pertanyaan dasar.

Bun adalah paket perangkat lengkap untuk mengembangkan aplikasi JavaScript dan TypeScript. Ia dapat menjalankan aplikasi seperti Node.js, memasang dependensi seperti npm atau pnpm, menjalankan pengujian dengan pola yang mirip Jest, dan mengemas kode aplikasi sebelum dirilis.

Developer dapat memakai bun install, bun run, bun test, dan bun build tanpa merangkai banyak alat terpisah. Semuanya tersedia dalam satu program. Untuk menjalankan JavaScript, Bun memakai JavaScriptCore, mesin yang juga menjadi fondasi Safari.

Menurut Bun, perangkat command line mereka diunduh lebih dari 22 juta kali setiap bulan. Claude Code dan OpenCode memakainya sebagai runtime. Vercel, Railway, dan DigitalOcean juga menyediakan dukungan resmi.

Anthropic mengakuisisi Bun pada Desember 2025. Bun tetap dikembangkan sebagai proyek sumber terbuka, tetapi juga menjadi bagian infrastruktur Claude Code, Claude Agent SDK, dan produk pemrograman berbasis AI berikutnya.

Bun lahir dari Zig. Jarred Sumner, pendirinya, bahkan mengakui bahwa ia tidak mungkin membangun perangkat seluas Bun seorang diri dalam satu tahun tanpa Zig. Jadi, perpindahan ini bukan karena Zig tiba-tiba dianggap lambat atau tidak berguna.

Masalahnya terletak pada cara Bun mengelola memori.

JavaScriptCore membersihkan memori JavaScript secara otomatis. Sementara itu, banyak komponen Bun yang ditulis dengan Zig mengharuskan developer mengatur memori sendiri. Keduanya terus bertukar penunjuk data dan tanggung jawab tentang kapan sebuah data boleh dibuang.

Kerumitan itu melahirkan kesalahan seperti program membaca data yang sudah dihapus, membebaskan bagian memori yang sama dua kali, kebocoran memori, dan crash pada jalur error tertentu. Dalam salah satu pengujian Bun, development server kehilangan sekitar 3 MB memori setiap kali melakukan build ulang. Setelah 2.000 build, konsumsi Bun v1.3.14 mencapai 6.745 MB. Versi berbasis Rust berhenti naik di sekitar 609 MB.

Rust membawa sistem kepemilikan data dan borrow checker. Banyak kesalahan yang sebelumnya baru terlihat saat program berjalan dapat dihentikan sebagai error ketika kode dikompilasi. Rust tidak otomatis membuat semua kode benar, tetapi ia memindahkan banyak masalah ke tahap yang lebih awal dan lebih mudah ditangani.

Catatan resmi Bun menyebut sekitar 50 workflow dinamis di Claude Code yang berjalan selama 11 hari. Pada saat paling sibuk, empat workflow aktif di Git worktree terpisah. Masing-masing memakai 16 Claude. Dari sinilah angka sekitar 64 agen secara bersamaan berasal.

Yang menentukan bukan jumlah agennya, melainkan persiapannya.

Sumner menghabiskan sekitar tiga jam bersama Claude untuk menyusun panduan pemindahan pola kode Zig ke Rust. Workflow lain menelusuri umur setiap field dalam struktur data, lalu menyimpan hasilnya dalam tabel bersama. Sebelum skala diperbesar, proses tersebut diuji pada tiga file.

Untuk setiap tugas, satu Claude menulis kode. Setidaknya dua Claude lain memeriksanya melalui jendela konteks terpisah. Mereka diminta mencari perbedaan perilaku, pelanggaran terhadap panduan migrasi, dan alasan mengapa kode baru bisa gagal. Putaran berikutnya baru menerapkan koreksi.

Pada puncaknya, Claude menghasilkan sekitar 1.300 baris kode per menit. Hasil awalnya belum bisa dipakai. Setelah basis kode dipecah menjadi banyak crate Rust, muncul sekitar 16.000 error kompilasi. Bun kemudian menjalankan workflow tambahan untuk mengelompokkan dan memperbaikinya.

Kepercayaan terhadap hasil akhir bukan datang dari jumlah baris yang selesai ditulis. Bun memiliki rangkaian pengujian yang tidak bergantung pada bahasa implementasi, dengan lebih dari satu juta pemeriksaan di Linux, macOS, dan Windows. Hasil AI juga melewati pemeriksaan tandingan, audit keamanan, fuzzing, dan pemantauan manusia.

Bun menyatakan versi 1.4.0 memperbaiki 128 masalah yang masih dapat ditemukan pada versi 1.3.14. Daftarnya mencakup kebocoran memori, crash, sampai kesalahan kecil pada tampilan bantuan.

Tahap awal migrasi memangkas ukuran program sebesar 3,8 MB di Windows, 5,5 MB di macOS, dan 6,8 MB di Linux. Angka lanjutan dalam laporan yang sama menunjukkan ukuran Bun di Windows turun dari 94 MB menjadi 76 MB, sedangkan Linux turun dari 88 MB menjadi 70 MB.

Dalam pengujian internal Bun, throughput server HTTP dan beberapa pekerjaan aplikasi meningkat sekitar 2,8% hingga 4,8%. Claude Code diam-diam sudah memakai Bun versi Rust sejak rilis 2.1.181 pada 17 Juni. Telemetri produksinya mencatat waktu mulai median di Linux turun dari 517 milidetik menjadi 464 milidetik, atau sekitar 10% lebih cepat.

Seluruh angka tersebut berasal dari Bun. Datanya layak diperhatikan, tetapi tidak cukup untuk menyimpulkan bahwa setiap proyek Zig akan otomatis lebih cepat atau lebih kecil jika dipindahkan ke Rust.

Andrew Kelley, pencipta Zig, menanggapi pengumuman itu dengan tulisan yang sangat tajam. Sebagian komentarnya masuk ke wilayah personal, tetapi keberatan teknisnya tetap perlu dibaca.

Menurut Kelley, kualitas kode Bun sudah menjadi masalah jauh sebelum AI ikut menulis. Ia menilai Bun terlalu mengejar fitur baru dan kurang memberi waktu untuk membereskan utang teknis. Karena itu, basis kode Bun dianggap tidak mewakili praktik terbaik dalam memakai Zig.

Kelley juga mempertanyakan cara peningkatan performa disajikan. Versi Rust memakai optimasi pada tahap linking yang juga didukung Zig. Ia berpendapat ukuran program mengecil karena Bun sebelumnya terlalu banyak memakai fitur kompilasi Zig, bukan karena Rust selalu menghasilkan program lebih ramping. Menariknya, tulisan Bun sendiri mengakui penyebab tersebut.

Pertanyaan terkerasnya menyentuh proses pemeriksaan: jika rangkaian tes lama gagal menangkap semua bug pada versi Zig, mengapa lolos dari tes yang sama dianggap cukup untuk menjamin lebih dari satu juta baris kode baru?

Jawaban Bun bukan bahwa tes mereka sempurna. Proses barunya menambahkan pemeriksaan tandingan, aturan compiler Rust, audit keamanan, Miri, LeakSanitizer, serta fuzzing terus-menerus. Meski begitu, implementasi Rust Bun masih memiliki cukup banyak kode unsafe yang akan dikurangi secara bertahap.

Bagian paling mengesankan bukan kecepatan AI mengetik kode. Bun membangun sistem yang mampu menolak hasil AI ketika salah.

Migrasi sebesar ini membutuhkan setidaknya empat fondasi:

• Kontrak perilaku. Pengujian harus menjelaskan apa yang dilakukan sistem tanpa bergantung pada bahasa yang dipakai untuk membangunnya.
• Aturan migrasi tertulis. Semua agen perlu memakai keputusan yang sama tentang kepemilikan data, penamaan, arsitektur, dan pengecualian yang diizinkan.
• Peran yang dipisahkan. Model yang menulis perubahan tidak boleh menjadi satu-satunya pihak yang menilai kebenarannya.
• Proses yang dapat diperbaiki. Jika kesalahan yang sama terus muncul, perbaiki instruksi dan workflow-nya. Jangan hanya menambal ribuan gejala satu per satu.

Angka US$165.000 juga perlu konteks. Nilai itu adalah perkiraan biaya berdasarkan 5,9 miliar token input tanpa cache, 690 juta token output, dan 72 miliar pembacaan token cache. Bun sudah menjadi bagian Anthropic, sehingga angka tersebut tidak otomatis berarti ada tagihan tunai US$165.000 yang dibayar seperti pelanggan API biasa.

Sebelas hari juga bukan berarti proyek berangkat dari nol lalu selesai permanen pada hari kesebelas. Tim Bun menyiapkan workflow, memantaunya terus-menerus, melanjutkan audit keamanan setelah kode digabungkan, dan masih mempunyai pekerjaan refactoring.

Bun adalah infrastruktur JavaScript yang dipakai secara nyata, bukan sekadar framework baru dengan nama lucu. Migrasinya ke Rust menunjukkan bahwa AI mampu memangkas waktu untuk pekerjaan besar yang sebelumnya terlalu mahal untuk dikerjakan.

Namun, kasus ini tidak membuktikan bahwa sekumpulan agen dapat menggantikan tim engineering. Bun memiliki pengujian yang dibangun selama bertahun-tahun, pengetahuan mendalam tentang basis kode, dokumen migrasi yang rinci, pemeriksa yang sengaja mencari kesalahan, dan manusia yang tetap mengambil keputusan.

Tanpa semua itu, kemampuan menghasilkan 1.300 baris per menit bukan produktivitas. Itu hanya cara lebih cepat untuk memperbesar antrean code review.

Apakah Bun bisa menggantikan Node.js?

Bun dapat menggantikan Node.js untuk banyak aplikasi JavaScript dan TypeScript. Ia juga menyediakan package manager, test runner, dan bundler. Namun, kompatibilitasnya belum tentu mencakup setiap API dan dependensi, sehingga aplikasi produksi tetap perlu diuji.

Apakah pengguna Bun harus menulis Rust?

Tidak. Developer aplikasi tetap menulis JavaScript atau TypeScript. Rust digunakan untuk membangun mesin internal Bun.

Apakah 64 agen AI menulis ulang Bun tanpa bantuan manusia?

Tidak. Sekitar 64 Claude aktif bersamaan pada puncaknya, tetapi Jarred Sumner merancang workflow, memantau hasil, membaca kode, memperbaiki proses, dan memakai infrastruktur pengujian Bun yang sudah ada. Sepanjang 11 hari, laporan resmi menyebut sekitar 50 workflow dinamis.

Apakah migrasi ini membuktikan Rust lebih baik daripada Zig?

Tidak. Kasus ini menunjukkan sistem kepemilikan Rust cocok untuk masalah pengelolaan memori yang dihadapi Bun. Sebagian pengurangan ukuran dan peningkatan performa juga berasal dari perubahan implementasi serta konfigurasi build yang tidak hanya tersedia di Rust.