Matt Anderson Photography melalui Moment / Getty Images
Ikuti ZDNET: Tambahkan kami sebagai sumber pilihan di Google.
Kesimpulan utama ZDNET
Digunakan dengan benar, seperti oleh Anthropic dan Mozilla, AI dapat membantu sumber terbuka.
Digunakan dengan buruk, seperti oleh Google dan FFmpeg, AI merugikan sumber terbuka.
Linux memanfaatkan AI untuk menangani banyak tugas membosankan namun penting.
Belum lama ini, ada kabar menggembirakan tentang AI dan sumber terbuka: AI Claude Opus 4.6 dari Anthropic membantu membersihkan kode sumber terbuka Firefox. Menurut Mozilla, perusahaan induk Firefox, Tim Merah Frontier Anthropic menemukan lebih banyak bug berbahaya tinggi di Firefox hanya dalam dua minggu dibandingkan laporan manual dalam dua bulan. Mozilla menyatakan: “Ini adalah bukti jelas bahwa analisis berbantuan AI berskala besar adalah alat baru yang ampuh dalam kotak peralatan para insinyur keamanan.”
Bagus, kan? Benar!? Tunggu dulu. Ada sisi lain yang lebih kelam dari penggunaan AI dalam perangkat lunak sumber terbuka. Daniel Stenberg, pencipta program transfer data sumber terbuka populer cURL, menunjukkan bahwa proyeknya kebanjiran laporan keamanan palsu yang ditulis AI yang menyita waktu pengelola dengan pekerjaan sia-sia.
Juga: 7 Teknik coding AI yang saya gunakan untuk menghasilkan produk nyata dan andal – dengan cepat
Mozilla paham masalah ini. Brian Grinstead, insinyur ternama Mozilla, dan Christian Holler, insinyur perangkat lunak utama Mozilla, menulis, “Laporan bug berbantuan AI memiliki catatan yang beragam, dan skeptisisme wajar. Terlalu banyak kiriman berarti positif palsu dan beban tambahan bagi proyek sumber terbuka.”
Bisa diulangi. Di FOSDEM 2026 di Brussel, Belgia, Stenberg mengatakan bahwa hingga awal 2025, sekitar satu dari enam laporan keamanan ke cURL yang valid. Itu karena, “dulu, seseorang benar-benar meluangkan banyak waktu untuk laporan keamanan. Ada gesekan bawaan di sini, tetapi sekarang sama sekali tidak butuh usaha. Pintu air terbuka. Kirim saja.”
Stenberg berkata: “Angkanya kini meningkat; lebih seperti satu dari 20 atau 30 yang akurat.” Kenaikan ini mengubah proses triase laporan bug keamanan menjadi “pelaporan teror”, menguras waktu, perhatian — dan “semangat hidup” — dari tim keamanan proyek yang beranggotakan tujuh orang. Dia memperingatkan bahwa kebisingan yang diperbesar AI ini tidak hanya menyia-nyiakan upaya sukarelawan tetapi juga membahayakan rantai pasok perangkat lunak: jika pengelola menjadi kebal terhadap laporan sampah ini, kerentanan nyata dalam kode akan terlewat.”
Juga: Apakah Computer baru Perplexity versi OpenClaw yang lebih aman? Begini cara kerjanya
Memang, musim panas lalu, Stenberg menulis, “Kita perlu mengurangi pasir dalam mesin. Kita harus melakukan sesuatu untuk secara drastis mengurangi godaan pengguna mengirimkan laporan berkualitas rendah.” Hasilnya? Lebih banyak sampah yang masuk, sehingga dia memutuskan untuk menutup bounty cURL untuk laporan bug keamanan: “Ambang batas telah tercapai. Kami secara efektif di-DDoS. Jika bisa, kami akan menagih mereka untuk pemborosan waktu kami.”
Tren ini tak boleh berlanjut. Sebagian besar proyek sumber terbuka, bahkan yang kritis, dijalankan oleh sukarelawan dengan dana terbatas. Mereka tidak punya waktu atau sumber daya untuk menyisir ratusan laporan bug sampah AI.
Syukurlah, Anthropic mengambil pendekatan berbeda, lapor Mozilla: “Tim Anthropic menghubungi insinyur Firefox setelah menggunakan Claude untuk mengidentifikasi bug keamanan di mesin JavaScript kami. Yang penting, laporan bug mereka menyertakan kasus uji minimal yang memungkinkan tim keamanan kami dengan cepat memverifikasi dan mereproduksi setiap masalah. Dalam beberapa jam, insinyur platform kami mulai menerapkan perbaikan, dan kami memulai kolaborasi erat dengan Anthropic untuk menerapkan teknik yang sama di seluruh basis kode peramban.”
Begitulah seharusnya AI dan sumber terbuka bersinergi. Namun, kekhawatiran saya adalah pendekatan ini akan menjadi pengecualian bukan aturan di masa depan. Soalnya, pendekatan kolaboratif ini membutuhkan kerja nyata dari pengguna AI. Terlalu sering, perbaikan sumber terbuka dihasilkan oleh pengembang yang tidak berpengalaman atau malas yang mencoba asal-asalan masuk ke proyek sumber terbuka. Maaf, tidak semudah itu.
Lebih buruk, beberapa perusahaan menggunakan AI untuk membuang laporan bug yang akurat tetapi tidak penting ke proyek kecil. Misalnya, Google baru-baru ini menemukan banyak masalah keamanan minor di FFmpeg. Proyek ini digunakan semua orang, dari TV hingga web, untuk memutar file dan aliran media video dan audio.
Juga: Saya menyelesaikan pengembangan produk 4 tahun dalam 4 hari dengan $200, dan saya masih terpukau
Lantas, seberapa kecil bug-bug ini? Salah satunya adalah bug pemutaran di 10 hingga 20 frame pertama Rebel Assault 2, sebuah game tahun 1995. Tim FFmpeg mengandalkan upaya sukarelawan dan tidak punya sumber daya untuk menangani omong kosong semacam ini. Dan yang terpenting, Google juga tidak memperbaiki masalah atau membayar perbaikan bug.
AI dan Linux
Nah, bukan berarti di tangan yang tepat, AI tidak bisa menjadi bantuan besar bagi sumber terbuka. Seperti kata Linus Torvalds, pencipta Linux dan Git, di Open Source Summit Korea 2025 Yayasan Linux: “Ada orang-orang yang banyak berkarya dalam penggunaan AI, untuk membantu pengelola menangani aliran patch dan membackboard patch ke versi stabil dan semacamnya.”
Beberapa minggu kemudian, Torvalds mengatakan bahwa meski benci gembar-gembor AI, dia “percaya besar pada AI sebagai alat.” Secara khusus, dia “jauh kurang tertarik pada AI untuk menulis kode” dan jauh lebih antusias pada “AI sebagai alat untuk membantu memelihara kode, termasuk pemeriksaan patch otomatis dan tinjauan kode sebelum perubahan sampai kepadanya.”
Bukan berarti Torvalds tidak akan menggunakan AI untuk menulis kode. **Matt Anderson Photography via Moment / Getty Images**
Faktanya, ia telah menggunakan [Google’s Antigravity LLM untuk melakukan *vibecode* pada program mainannya, AudioNoise](https://www.theregister.com/2026/01/16/linus_torvalds_vibe_coding/), yang dipakainya untuk menciptakan “efek audio digital acak” menggunakan “desain papan pedal gitarnya yang acak.”
Baca juga: [10 rahasia ChatGPT Codex yang baru saya ketahui setelah 60 jam *pair programming* dengannya](https://www.zdnet.com/article/10-chatgpt-codex-secrets-i-only-learned-after-60-hours-of-pair-programming-with-it/)
Dalam komunitas Linux secara keseluruhan, telah ada kesepakatan mengenai beberapa cara AI seharusnya digunakan. Sasha Levin, seorang *distinguished engineer* di Nvidia dan *maintainer kernel* stabil, menegaskan bahwa [akuntabilitas manusia adalah hal yang mutlak](https://www.zdnet.com/article/ai-is-part-of-linux-plumbing-developers/). Suatu bentuk pengungkapan diperlukan ketika AI digunakan, dan para *maintainer* akan menentukan sendiri cara menggunakan alat-alat AI.
Selain itu, Levin mengungkapkan bahwa ia telah mengintegrasikan [LLM ke dalam dua tugas paling tidak mengenakkan dalam proyek: mengidentifikasi *backport* dan perbaikan keamanan](https://lwn.net/Articles/1026558/). AI kini digunakan dalam [AUTOSEL](https://git.sr.ht/~sashal/autosel), sistem yang mengidentifikasi *patch kernel* untuk di-*backport* ke rilis stabil, serta [alur kerja CVE internal Linux](https://opensourcewatch.beehiiv.com/p/linux-gets-cve-security-business). Keterhubungan ini menghilangkan banyak pekerjaan rutin yang membosankan.
Torvalds juga menyatakan bahwa ia percaya LLM harus diperlakukan sebagai langkah evolusi berikutnya dari kompiler, bukan sebagai pengganti manusia. Ia membandingkan adopsi AI dengan pergeseran dari bahasa *assembly* ke bahasa tingkat yang lebih tinggi. Pergeseran ini awalnya kontroversial, tetapi akhirnya diterima sebagai cara untuk membebaskan pengembang dari pekerjaan kasar, seperti menulis kode *boilerplate* atau dengan cermat menyusun pesan *commit* dalam bahasa kedua.
## *Coding* dengan Bertanggung Jawab
Dan Williams, seorang *senior principal engineer* di Intel dan *maintainer kernel*, sepakat bahwa AI telah terbukti berguna untuk meninjau kode dan meningkatkan produktivitas. Namun, ia memperingatkan, “Saya sering memberi *career talk* di sekolah menengah, dan saya katakan kepada mereka hal terpenting yang bisa dipelajari di sekolah, dan akan kalian gunakan, adalah ‘tunjukkan pekerjaanmu.’ Saya merasa AI adalah puncak dari, ‘Saya tak perlu menunjukkan pekerjaan saya karena AI bilang ini benar.'”
Williams benar, dan kurangnya tanggung jawab itu tidak membantu. Seperti yang diamati baru-baru ini oleh *distinguished engineer* IBM Phaedra Boinodiris dan Rachel Levy, *executive director* Data Science and AI Academy di North Carolina State University, [literasi AI adalah suatu keharusan ke depan](https://www.thedeepview.com/articles/ibm-warns-ai-spend-fails-without-ai-literacy), dan itu berarti jauh lebih dari sekadar tahu cara menulis *prompt* LLM. Siswa harus mempelajari dasar-dasarnya, dan semua orang harus diterima di meja diskusi ketika menentukan bagaimana menggunakan AI dengan sukses dalam *open source* atau di tempat lain.
Satu referensi penting datang dari Stormy Peters, kepala strategi *open source* di AWS, yang dalam pidatonya di [*Linux Foundation Members Summit*](https://events.linuxfoundation.org/lf-member-summit/) baru-baru ini berkata, “Saya pernah khawatir [AI akan membunuh perangkat lunak *open source*](https://thenewstack.io/is-ai-killing-open-source-software/) karena saya akan menghasilkan kode atau *pull request* ini dengan sangat cepat sehingga saya tidak melihat nilainya. Mengapa saya menghabiskan waktu mendorongnya *upstream* ketika siapa pun bisa menghasilkannya sesuai permintaan?”
Baca juga: [10 hal yang saya harap saya ketahui sebelum mempercayai Claude Code untuk membangun aplikasi iPhone saya](https://www.zdnet.com/article/claude-code-vibe-coding-iphone-app-lessons/)
Situasi itu ternyata tidak terbukti dalam kenyataannya. Seperti yang dijelaskan Peters, “Yang sebenarnya terjadi adalah orang-orang mengirimkan semua sampah yang mereka hasilkan dari AI.”
Sementara para *coder* yang dibantu AI mungkin bermaksud baik—”ini sangat cepat, jadi saya seharusnya, dan ini berguna, jadi saya harus menyumbangkannya”—tidak ada kelanjutan karena orang-orang ini tidak memahami apa yang dihasilkan AI: “Yang terjadi adalah, ini bukan milikku, dan aku tidak tahu cara memeliharanya. Jadi, jika ada yang meminta saya untuk menyederhanakannya atau membelanya, saya tidak bisa, dan mungkin *maintainer* proyek juga tidak bisa mudah memahami apa yang terjadi.”
Keadaan ini tidak baik. Lebih buruk lagi, bukti menunjukkan pengembang [19% lebih lambat dengan *coding* berbantuan AI karena waktu yang dihabiskan untuk meninjau dan menganalisis kode ulang](https://thenewstack.io/how-ai-coding-makes-developers-56-faster-and-19-slower/). Sementara itu, penelitian lain menyebutkan bahwa [kode yang dihasilkan AI cenderung memiliki masalah 1,7 kali lebih banyak](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report).
Baca juga: [*AI agents* itu cepat, sembrono, dan di luar kendali, temuan studi MIT](https://www.zdnet.com/article/ai-agents-are-fast-loose-and-out-of-control-mit-study-find/)
Meskipun demikian, Peters dan para pemimpin *open source* lainnya yang saya ajak bicara, ya, bahkan Stenberg, berpikir AI bisa sangat berguna untuk *open source*.
Kita harus menggunakan AI dengan hati-hati dan mempertimbangkan bagaimana ia mengubah teknologi *open source*. Digunakan dengan cerdas dan upaya nyata, seperti yang dilakukan Anthropic dan Mozilla, AI dan *open source* dapat membentuk persahabatan yang indah. Tetapi jika kita tidak memberi perhatian sedemikian rupa, kita akan menghadapi kekacauan yang nyata. **Matt Anderson Photography** melalui *Moment* / Getty Images