Vibecoded Fuzzer Menemukan Bug Division by Zero di FFmpeg: Pelajaran Testing untuk Developer

Dunia open-source baru saja mendapat cerita menarik: sebuah fuzzer yang dibuat dengan bantuan AI coding — atau yang populer disebut "vibecoding" — berhasil menemukan bug division by zero di FFmpeg, salah satu library pemrosesan media paling penting di dunia. Cerita ini menarik bukan hanya karena bug-nya, tapi karena cara bug itu ditemukan: kombinasi antara automated testing dan kode yang dihasilkan AI.

Artikel ini membahas apa yang sebenarnya terjadi, kenapa fuzzing penting, apa itu vibecoding dalam konteks ini, dan pelajaran apa yang bisa diambil developer untuk praktik testing sendiri.

Apa yang Terjadi

FFmpeg adalah library open-source yang dipakai hampir di semua aplikasi yang memproses audio dan video — dari pemutar media, editor, sampai platform streaming. Karena cakupannya yang luas dan kritis, FFmpeg menjadi target utama para peneliti keamanan dan pengembang yang mencari bug.

Yang menarik dari insiden ini adalah metode penemuannya. Seorang developer membuat fuzzer — program yang secara otomatis menghasilkan input acak atau semi-acak untuk mencari perilaku tidak normal — dengan bantuan AI coding. Fuzzer tersebut kemudian menemukan bug division by zero di dalam kode FFmpeg.

Division by zero adalah jenis bug klasik: program membagi angka dengan nol, yang menyebabkan crash atau perilaku tidak terdefinisi. Di library seperti FFmpeg yang memproses data input yang beragam — termasuk file media yang bisa dimanipulasi dengan sengaja — bug semacam ini bisa dieksploitasi untuk membuat aplikasi crash, atau dalam kasus tertentu, untuk tujuan yang lebih serius.

Yang membuat cerita ini penting: fuzzer yang berhasil menemukan bug tersebut tidak dibuat oleh peneliti keamanan berpengalaman dengan ratusan jam kerja, melainkan sebagian besar dihasilkan dengan bantuan AI. Ini menunjukkan bahwa penghalang untuk masuk ke praktik fuzzing semakin rendah.

Kenapa Fuzzing Penting

Fuzzing adalah salah satu teknik paling efektif untuk menemukan bug yang tidak terlihat oleh code review biasa atau unit test tradisional. Prinsipnya sederhana: masukkan banyak input yang bervariasi — termasuk yang aneh, tidak valid, atau sengaja bermusuhan — ke dalam program, dan lihat apakah program bereaksi dengan benar.

Banyak bug muncul hanya pada input tertentu yang tidak pernah terpikirkan oleh penulis kode. Unit test biasanya menguji skenario yang "normal" — input valid dengan hasil yang diharapkan. Fuzzing melengkapi ini dengan menjelajahi ruang input yang luas, termasuk kasus-kasus tepi yang tidak terduga.

Di library seperti FFmpeg yang menerima format file sangat beragam — MP4, MKV, WebM, dan puluhan format lain dengan varian codec — jumlah kombinasi input yang mungkin tidak terhitung. Code review manual tidak akan pernah bisa menutupi semua kemungkinan. Fuzzing adalah jawaban praktis: biarkan mesin yang menjelajahi ruang input tersebut.

Pentingnya fuzzing juga diakui oleh industri. Google, Microsoft, dan berbagai organisasi keamanan menjalankan program fuzzing berkelanjutan pada software populer. Proyek open-source besar termasuk FFmpeg sendiri sudah memiliki infrastruktur fuzzing — yang artinya bug yang ditemukan fuzzer baru ini lolos dari pengawasan fuzzing yang sudah ada, menunjukkan bahwa pendekatan baru yang berbeda bisa tetap menemukan hal baru.

Apa Itu Vibecoding dalam Konteks Ini

Vibecoding adalah istilah populer untuk praktik menulis kode dengan bantuan AI secara intensif — developer memberikan instruksi ke AI coding assistant, dan AI menghasilkan sebagian besar kode. Istilah ini sering dipakai setengah bercanda, tapi di baliknya ada praktik nyata yang semakin umum: AI sebagai partner coding yang produktif.

Dalam konteks insiden FFmpeg ini, "vibecoded fuzzer" berarti fuzzer tersebut sebagian besar ditulis atau dirancang dengan bantuan AI. Developer mungkin menjelaskan tujuan dan batasan, lalu AI menghasilkan kode fuzzer yang bisa langsung dijalankan — termasuk logika untuk menghasilkan input, memanggil FFmpeg, dan mendeteksi crash.

Ini menarik karena menunjukkan dua hal. Pertama, AI coding bisa menghasilkan kode yang berfungsi untuk tugas teknis spesifik seperti fuzzing — bukan cuma boilerplate atau contoh sederhana. Kedua, keahlian domain developer tetap penting: AI mungkin menghasilkan kode fuzzer, tapi butuh developer yang paham FFmpeg, paham cara kerja fuzzing, dan bisa menafsirkan hasilnya untuk menemukan serta melaporkan bug yang valid.

Kombinasi ini — kecepatan AI dalam menghasilkan kode dan keahlian manusia dalam mengarahkan serta memverifikasi — adalah pola kerja yang semakin umum di 2026 dan seterusnya.

Pelajaran untuk Developer

Ada beberapa pelajaran yang bisa diambil dari insiden ini. Pelajaran pertama: jangan remehkan automated testing. Fuzzer yang "sekadar" menghasilkan input acak berhasil menemukan bug di salah satu library paling banyak diuji di dunia. Automatisasi adalah kekuatan: mesin bisa menjelajahi ruang yang tidak pernah bisa dijelajahi manusia secara manual.

Pelajaran kedua: mulai fuzzing di proyek sendiri. Banyak developer menganggap fuzzing sebagai domain peneliti keamanan, padahal tooling modern membuatnya mudah dimulai. Library seperti libFuzzer, AFL++, dan integrasi fuzzing di bahasa pemrograman modern memungkinkan developer biasa menambahkan fuzzing ke test suite dengan usaha yang masuk akal.

Pelajaran ketiga: AI coding adalah alat yang sah untuk tugas teknis. Fuzzer yang dibuat dengan bantuan AI menemukan bug nyata. Ini bukan bukti bahwa AI menggantikan developer — tapi bukti bahwa AI mempercepat pekerjaan teknis ketika diarahkan dengan benar. Developer yang bisa memanfaatkan AI untuk tugas seperti ini mendapat keunggulan produktivitas.

Pelajaran keempat: verifikasi tetap tanggung jawab manusia. Fuzzer menemukan bug, tapi butuh manusia untuk memahami laporan crash, mengonfirmasi bahwa ini bug nyata (bukan false positive), memperbaiki root cause, dan mengirim laporan yang berguna ke maintainer. AI menghasilkan alat; manusia tetap memegang penilaian.

Praktik Fuzzing yang Bisa Dimulai Sekarang

Bagi developer yang ingin mulai menerapkan fuzzing, langkah awalnya cukup sederhana. Pertama, identifikasi fungsi yang memproses input eksternal — parser, decoder, fungsi yang menerima input dari pengguna atau jaringan. Itu adalah kandidat utama untuk fuzzing.

Kedua, gunakan tooling yang sudah ada. Jangan membangun dari nol. libFuzzer untuk C/C++, cargo-fuzz untuk Rust, dan berbagai integrasi untuk bahasa lain menyediakan kerangka yang sudah matang. Dokumentasi dan contoh yang lengkap membuat onboarding lebih cepat.

Ketiga, mulai dengan corpus kecil. Fuzzing bekerja lebih baik jika dimulai dari input valid yang nyata, lalu memutasi dari sana. Kumpulkan beberapa contoh input valid untuk fungsi yang diuji dan gunakan sebagai seed.

Keempat, integrasikan ke CI. Fuzzing paling efektif jika berjalan terus-menerus — setiap perubahan kode baru diuji dengan fuzzing singkat, dan fuzzing panjang dijadwalkan berkala. Regresi yang ditemukan fuzzer akan segera muncul di pipeline, bukan di produksi.

Kelima, belajar membaca output crash. Stack trace, sanitizer report, dan artifact input yang menyebabkan crash adalah informasi penting. Meluangkan waktu untuk memahami format laporan akan membuat proses perbaikan jauh lebih cepat.

Kesimpulan

Cerita fuzzer yang dibuat dengan vibecoding menemukan bug division by zero di FFmpeg adalah pengingat kuat tentang kekuatan automated testing dan perubahan cara developer bekerja. Fuzzing, yang dulu terasa sebagai keahlian khusus peneliti keamanan, kini bisa diakses oleh developer biasa — dan dengan bantuan AI, hambatannya semakin rendah. Pelajaran utamanya bukan soal FFmpeg atau vibecoding semata, tapi soal sikap: kode yang diuji secara otomatis lebih kuat, dan developer yang memanfaatkan alat modern — termasuk AI — bisa menemukan dan memperbaiki masalah yang tidak pernah terlihat oleh review manual. Mulai dari fuzzing kecil di fungsi yang menerima input eksternal, integrasikan ke CI, dan biarkan mesin yang bekerja keras mencari bug untuk lo.