Proyek Bun menyelesaikan migrasi kode besar dari Zig ke Rust pada Mei 2026, dengan lebih dari 1 juta baris kode dan 6.778 commit dalam 11 hari. Migrasi menggunakan 64 Claude yang bekerja secara paralel, menghabiskan biaya API sebesar $165.000. Setelah migrasi, masalah memory leak secara fundamental teratasi; memori turun dari 6,7 GB menjadi stabil di 609 MB setelah 2.000 build, performa meningkat 2% hingga 5%, dan ukuran file biner berkurang sekitar 20%. Namun, kode tersebut mengandung sekitar 13.000 kata kunci unsafe, 178 kali lebih banyak daripada proyek sejenis, dengan 19 masalah regresi yang diketahui, dan perubahan 1 juta baris kode tidak dapat ditinjau secara manual oleh manusia. Saat ini, Bun telah diakuisisi oleh Anthropic.

Penulis artikel, sumber: InfoQ

Pada Mei 2026, proyek Bun menyelesaikan migrasi kode skala besar yang hampir tak lazim dalam sejarah pengembangan perangkat lunak.

Migrasi ini dimulai pada 3 Mei dan secara resmi digabungkan ke cabang utama pada 14 Mei, hanya memakan waktu 11 hari. Penulisan kode hanya memakan waktu 6 hari, dan seluruh prosesnya bersifat terbuka. Namun, Jarred Sumner membutuhkan hampir sebulan untuk menulis blog ringkasannya, jauh lebih lama daripada waktu yang dibutuhkan untuk menulis kode.

Runtime JavaScript ini awalnya memiliki 535.496 baris kode Zig, tidak termasuk komentar; sekitar 20% kode ditulis dalam C++ dan menyertakan beberapa pustaka C/C++. Dalam pembaruan ini, kode tersebut ditulis ulang menjadi Rust dengan bantuan AI, melibatkan lebih dari 1 juta perubahan baris kode, 6.778 commit, dan menjalankan sekitar 50 dynamic workflows di Claude Code.

Berdasarkan data yang diungkapkan oleh Sumner, penulisan ulang ini menghabiskan 5,9 miliar token input tidak tercache, 690 juta token output, dan 72 miliar pembacaan token input tercache, dengan perkiraan biaya sekitar $165.000 berdasarkan harga API.

Sumner mengatakan ini adalah batas terdepan yang dapat dicapai oleh teknologi saat ini. Ia memperkirakan bahwa jika tiga insinyur yang benar-benar familiar dengan kodebase Bun melakukan migrasi ini secara manual, dibutuhkan sekitar satu tahun, dan selama tahun itu, tim hampir tidak dapat melanjutkan pengembangan fitur baru, perbaikan bug, dan perbaikan keamanan.

Setelah penulisan ulang ini, Bun v1.3.14 menjadi versi Zig terakhir, dan Bun v1.4.0 akan menjadi versi Rust pertama.

1. Hasil: Dari kebocoran memori 6,7 GB menjadi stabil di 609 MB

Bun awalnya merupakan proyek Zig dengan cakupan yang sangat luas: ia sekaligus berfungsi sebagai transpiler JavaScript dan TypeScript, bundler, manajer paket, test runner, resolver modul, serta klien HTTP dan WebSocket, dan juga mengimplementasikan lapisan API Node.js. Kekuatan fitur sekaligus inilah yang membuat CLI Bun mencapai lebih dari 22 juta unduhan per bulan dan mendapat dukungan dari proyek atau perusahaan seperti Vercel, Railway, DigitalOcean, Claude Code, dan OpenCode.

Namun, lebar yang sama juga membawa beberapa tantangan bagi Bun.

Terutama di Bun v1.3.14, ada masalah yang telah lama mengganggu: saat melakukan panggilan Bun.build() secara berulang, memori terus terakumulasi dan tidak pernah dilepaskan. Setiap build bocor sekitar 3MB, yang tampaknya tidak banyak, tetapi jika Anda menjalankan server pengembangan yang memicu build setiap permintaan, memori akan perlahan-lahan terkuras hingga proses gagal.

Dalam pengujian nyata, penggunaan memori mencapai 1,9 GB setelah 500 build, 3,5 GB setelah 1.000 build, 5,1 GB setelah 1.500 build, dan melonjak menjadi 6,7 GB setelah 2.000 build.

Ini hanyalah puncak gunung es dari banyak masalah memori. Dalam daftar perbaikan bug v1.3.14, Sumner mencantumkan sejumlah besar masalah:

Saat memanggil .reset() di modul zlib, jika ada .write() asinkron yang sedang dieksekusi di thread pool, proses akan crash karena "use-after-free"; pada modul http2, callback JavaScript bersarang memicu rehashing tabel hash, menyebabkan pointer aliran internal menjadi tidak valid; pada UDPSocket.sendMany(), jika kode pengguna mengubah status koneksi soket melalui callback valueOf atau toString selama iterasi, terjadi penulisan out-of-bounds; pada crypto.scrypt, jika alokasi buffer output gagal, callback dan buffer password yang dilindungi tidak pernah dilepaskan; ......

Kesamaan dari bug-bug ini sangat jelas—hampir semuanya menunjuk pada akar yang sama: menggabungkan GC dengan manajemen memori manual dalam perangkat lunak yang sama.

Mesin modern seperti JavaScriptCore (dan V8) memiliki aturan yang sangat ketat terhadap penanganan pengecualian dan GC, sementara Zig tidak mengelola memori secara otomatis seperti C. Ketika dua paradigma ini berada dalam proses yang sama, setiap alokasi memori harus ditinjau baris demi baris: di mana byte-byte ini dilepaskan? Bagaimana memastikan hanya dilepaskan sekali? Apakah pengecualian JavaScript telah diperiksa dengan benar? Apakah pointer yang dikelola oleh GC terlihat oleh scanner tumpukan konservatif? Apakah ini memori yang dikelola oleh GC atau memori yang dikelola secara manual?

Yang lebih membuat cemas, tim tidaklah tanpa usaha. Mereka telah memodifikasi compiler Zig, menambahkan dukungan Address Sanitizer (ASAN), menjalankan pengujian ASAN di CI untuk setiap commit, membangun dengan ReleaseSafe di Windows, melakukan pengujian fuzzing 24/7 dengan Fuzzilli, serta sejumlah besar pengujian kebocoran memori end-to-end. Meski demikian, laporan crash tetap berdatangan tanpa henti.

“Daftar perbaikan bug kami membuat kita merasa buruk, saya bosan tidur dengan kekhawatiran tentang kegagalan Bun,” tulis Sumner. Ia tidak menyalahkan Zig—pengguna Zig lainnya tidak mengalami masalah seperti Bun, karena menggabungkan GC dengan manajemen memori manual adalah kebutuhan yang sangat jarang, dan hampir tidak ada bahasa yang dirancang untuk itu.

Sedangkan versi Rust menghasilkan hasil: menjalankan 2000 kali Bun.build(), memori stabil di 609MB.

Selain masalah kebocoran memori yang telah diselesaikan secara mendasar, penulisan ulang menggunakan Rust juga membawa perbaikan di beberapa dimensi lainnya.

Dalam hal stabilitas, v1.4.0 memperbaiki 128 bug yang dapat direproduksi di v1.3.14, mulai dari kebocoran memori hingga crash hingga kesalahan tampilan warna pada teks bantuan.

Dari segi ukuran, dengan menggabungkan penulisan ulang menggunakan Rust, perubahan ICU, dan penggabungan kode yang sama, ukuran file biner Bun berkurang sekitar 20% di Linux dan Windows.

Dalam hal kinerja, terjadi peningkatan umum sebesar 2% hingga 5%. Bun.serve meningkat dari 169.600 req/s menjadi 177.700 req/s, sedangkan node:http meningkat dari 103.800 menjadi 108.500. Dalam skenario penggunaan nyata, next build turun dari 13,62 detik menjadi 13,03 detik, dan kompilasi batch tsc turun dari 0,94 detik menjadi 0,89 detik.

Setelah Claude Code dirilis berbasis Rust Bun, waktu boot di Linux turun dari 517ms menjadi 464ms, lebih cepat sekitar 10%.

2 metode: 64 Claude, 11 hari, 50 alur kerja

Bagaimana Sumner melakukannya, ini mungkin bagian yang paling patut diperhatikan—karena metode yang ia gunakan berbeda dari pendekatan tradisional "membuat AI menulis kode".

Sumner memecah seluruh proses menjadi sekitar 50 alur kerja dinamis, masing-masing alur kerja merupakan sebuah siklus. Ia menjelaskan pola ini dengan pseudocode di blognya:

Setiap tugas memiliki konteks (misalnya, tiket Jira atau isu GitHub), Claude menulis kode berdasarkan konteks tersebut, lalu dua reviewer (juga Claude) meninjau kode, dan akhirnya menerapkan umpan balik. Setelah selesai, ambil tugas berikutnya.

Pola ini berlaku sepanjang proses penulisan ulang. Setiap alur kerja bertanggung jawab atas satu tujuan tertentu:

• Buat panduan porting yang memetakan pola dan tipe Zig ke pola dan tipe Rust;
• Mengimpor setiap file .zig secara mekanis menjadi file .rs, dan sesuaikan dengan PORTING.md dan LIFETIMES.tsv;
• Perbaiki kesalahan kompilasi setiap crate;
• Jalankan subcommand seperti bun test atau bun build;
• Buat semua pengujian dalam seluruh suite pengujian Bun lulus; lakukan beberapa putaran重构 dan pembersihan besar.

Pada puncaknya, Sumner menjalankan 4 alur kerja sekaligus, masing-masing dengan 16 Claude, sehingga total 64 Claude bekerja secara paralel di 4 pohon kerja, masing-masing mengirimkan dan mendorong file. Pada puncaknya, Claude menulis sekitar 1.300 baris kode per menit.

Pemisahan desain "implementer / reviewer" ini adalah kunci. Claude yang menulis kode ingin kode tersebut diterima, sehingga memiliki bias yang sama seperti insinyur manusia. Oleh karena itu, reviewer dan implementer benar-benar dipisahkan—reviewer hanya melihat perbedaan kode, tidak melihat proses penalaran implementer, dan secara eksplisit diberi tahu "asumsikan kode itu salah". Setiap implementer memiliki lebih dari dua reviewer adversarial, dan satu-satunya tugas reviewer adalah mencari bug.

Menulis kode hanyalah langkah pertama. Kode Zig adalah satu unit kompilasi, sementara Rust harus dibagi menjadi sekitar 100 crate untuk mempercepat kompilasi, dan ketergantungan siklik menyebabkan cargo check menghasilkan sekitar 16.000 kesalahan kompilasi sekaligus. Bagi seseorang, ini adalah bencana, tetapi bagi 64 Claude yang bekerja secara paralel, ini adalah antrian tugas yang dapat ditangani. Alur kerja mengelompokkan kesalahan berdasarkan crate, menjalankan cargo check untuk setiap crate, satu Claude memperbaiki, dua orang meninjau, dan satu orang menerapkan perubahan.

Selanjutnya adalah menjalankan bun --version, lalu bun test. Alur pengujian menjalankan 100 file uji secara acak setiap kali, dibagi ke dalam 4 worktree. Suite pengujian juga mencakup beberapa jenis: beberapa uji mencapai lebih dari satu menit, beberapa menghabiskan jumlah koneksi TCP sistem, dan beberapa melakukan fork sekitar 10.000 proses. Sumner menggunakan systemd-run untuk membuat cgroup guna membatasi sumber daya, tetapi mesin tetap gagal beberapa kali karena kekurangan ruang disk.

Dua hari kemudian, jumlah tes gagal di platform Linux turun dari 972 menjadi 23. Satu setengah hari setelah itu, Linux seluruhnya berwarna hijau. Lima hari kemudian, keenam platform—Linux x64, Linux arm64, macOS x64, macOS arm64, Windows x64, Windows arm64—semuanya lulus.

Pada 14 Mei, PR #30412 secara resmi digabungkan, seluruh rangkaian pengujian berhasil dilewati tanpa melewati atau menghapus pengujian apa pun.

3 Kekhawatiran: 13.000 kode unsafe dan tidak dapat ditinjau baris demi baris

Namun, Sumner juga mengakui bahwa pekerjaan ini belum benar-benar selesai.

Sampai saat ini, sekitar 4% kode Rust Bun berada di dalam blok unsafe, sekitar 13.000 kata kunci unsafe, tersebar di sekitar 27.000 baris kode, sementara total kode Rust sekitar 780.000 baris. Sebanyak 78% blok unsafe hanya terdiri dari satu baris, biasanya berupa pointer dari C++ atau satu panggilan ke pustaka C.

Dia memperkirakan rekonstruksi selanjutnya akan menurunkan rasio ini. Namun, ada yang menghitung: uv memiliki sekitar 350.000 baris kode, dengan hanya 73 panggilan unsafe. Jumlah unsafe Bun adalah 178 kali lipat dari uv. Kesenjangan ini sulit dijelaskan hanya dengan "perlu memanggil pustaka C".

Dan kemudian juga mengekspos perilaku tak terdefinisi dalam kode Rust yang aman. Ini lebih sulit untuk di-debug daripada C++, karena Anda akan menganggap kode aman tidak mungkin mengalami masalah.

Tim Bun kemudian mengubah PathString::init dalam masalah ini menjadi unsafe fn.

Sumner sendiri mengakui bahwa penulisan ulang ini memperkenalkan 19 masalah regresi yang diketahui, dan menyatakan bahwa sebagian besar masalah regresi berasal dari kode yang memiliki sintaksis sama tetapi semantik berbeda.

Misalnya, dua potongan kode ini terlihat sangat mirip, tetapi perilakunya sangat berbeda. Assert Zig adalah sebuah fungsi, sehingga parameternya dijalankan pada setiap build. Debug_assert! Rust adalah makro, sehingga dalam versi rilis, seluruh ekspresi (termasuk pemanggilan fungsi) akan dihapus insert_stale.

Meskipun semua masalah telah diperbaiki, ini tidak berarti bahwa ratusan ribu baris kode AI tidak memiliki masalah lain.

Siapa orang waras yang akan langsung memigrasi aplikasi produksinya ke sistem yang baru saja ditulis ulang sepenuhnya? Jika menganggap versi 1.4 tidak memperkenalkan bug baru atau perubahan perilaku, itu terlalu naif.

Hal lain yang tidak bisa diabaikan adalah tinjauan kode. Perubahan sebanyak satu juta baris tidak mungkin diperiksa secara manual baris per baris—bahkan jika hanya satu menit per baris, akan memakan waktu terus-menerus selama 11,7 hari; dengan kecepatan tinjauan kode yang realistis (200 baris per jam), dibutuhkan lebih dari dua tahun untuk menyelesaikannya.

Reviewer untuk PR ini terutama adalah claude[bot] dan coderabbitai[bot]. Sumner sendiri mengakui bahwa pendekatan review-nya adalah "memeriksa apakah agent review adversarial berhasil menangkap perbedaan, memastikan panduan konversi diikuti, sekaligus secara manual membaca cukup banyak kode". Namun, ia tidak menyebutkan berapa banyak "cukup banyak" itu.

Masih ada satu masalah yang tak bisa dihindari: Bun diakuisisi oleh Anthropic pada Desember 2025, dan alat yang benar-benar mampu memelihara repositori kode ini pada dasarnya hanyalah Claude itu sendiri. Beberapa orang di komunitas mengatakan, ini sudah tidak lagi bisa disebut proyek open source dalam arti tradisional—jika Anda ingin mengirimkan PR ke Bun, Anda harus berlangganan Anthropic, atau mengandalkan beberapa anggota inti yang sudah memahami kode yang dihasilkan AI.

Apakah 165.000 dolar AS setara dengan satu tahun kerja?

Sumner juga mengungkapkan dalam blognya bahwa biaya penulisan ulang API ini sekitar $165.000, setara dengan volume kerja tiga insinyur selama satu tahun. Angka ini memicu diskusi sengit di Hacker News.

Beberapa orang berpendapat bahwa biaya ini sebenarnya sangat menguntungkan. Dengan 165.000 dolar AS, Anda tidak bisa merekrut banyak insinyur penuh waktu di Silicon Valley, apalagi insinyur dari perusahaan sekelas Anthropic. Berdasarkan data gaji di levels.fyi, total kompensasi insinyur Anthropic kemungkinan mencapai 500.000 dolar AS atau lebih. Bahkan jika dihitung kasar dengan rata-rata gaji tahunan 336.000 dolar AS untuk 50 insinyur, biaya harian setara sekitar 1.292 dolar AS. Untuk 50 orang yang bekerja terus-menerus selama 11 hari, biaya tenaga kerja saja sudah mendekati 710.000 dolar AS, belum termasuk tunjangan, tempat kerja, peralatan, dan biaya administrasi lainnya.

Namun, Sumner menggunakan versi pra-rilis dari Claude Fable 5, sebuah model tingkat lanjut yang belum tersedia untuk publik dan kemungkinan tunduk pada pembatasan ekspor. Jadi, harga API hanyalah angka yang dilihat oleh pengguna akhir, sementara di belakangnya terdapat biaya R&D besar yang dikeluarkan oleh Anthropic. Ada juga yang menunjukkan bahwa menyederhanakan biaya menjadi harga API adalah upaya sengaja untuk meredam realitas investasi yang sebenarnya. Jika mempertimbangkan biaya pengembangan model, biaya pelatihan, investasi komputasi, tenaga teknik, dan lainnya, diyakini bahwa total biaya akhir pasti sangat tinggi, kemungkinan besar melebihi 1,5 juta dolar AS.

Dan sepertinya saat ini, meskipun $165.000 untuk satu tahun kerja terlihat sangat menguntungkan secara akuntansi.

Namun, biaya sebenarnya tidak tercantum dalam tagihan ini. Repositori ini memiliki 6.778 commit, dan tidak ada seorang pun yang membacanya secara lengkap dari awal hingga akhir. Meskipun semuanya berjalan lancar saat ini, bagaimana dengan enam bulan mendatang? Ketika masalah konkurensi aneh tiba-tiba muncul pada pukul 03.00 pagi, insinyur yang bertugas menghadapi sistem yang bahkan dirinya sendiri tidak bisa menjelaskan logika internalnya. Hingga ke depannya, sistem ini harus dipelihara oleh AI—bagaimana menghitung biaya pemeliharaannya, sebenarnya cukup sulit.