Kode dari AI Boleh, Tapi Manusia Tetap Bertanggung Jawab Penuh: Aturan Baru Linux dan Rust

Para maintainer sub-sistem juga memiliki wewenang untuk menerapkan aturan yang lebih ketat. Pada Agustus 2026, Johannes Berg, maintainer sub-sistem jaringan nirkabel kernel (802.11, mac80211, WWAN, rfkill), mengumumkan sikap yang sangat tegas terhadap patch buatan AI/LLM :

• Aturan "tinjauan tiga detik": Patch apa pun yang tidak terlihat jelas benar dalam waktu tiga detik saat ditinjau akan langsung diabaikan .
• Tidak ada proses bolak-balik: Ia menolak untuk terlibat dalam siklus review untuk memperbaiki patch buatan AI .
• Penolakan terhadap "slop" berkualitas rendah: Patch yang tidak benar secara sepele akan ditolak tanpa diskusi lebih lanjut .

Kebijakan ini mengikuti aturan Greg Kroah-Hartman bahwa sub-sistem drivers/staging/ menolak semua patch buatan LLM, kecuali untuk perbaikan keamanan yang asli .

Mengapa Linux Kernel Mengambil Pendekatan Ini?

Komunitas kernel mengidentifikasi tiga masalah inti yang mendorong kebijakan ini:

1. Krisis bandwidth review: Para maintainer kewalahan dengan banjir patch buatan AI. Banyak di antaranya yang terlihat rapi di permukaan, tetapi secara semantik salah atau berbahaya .
2. Degradasi sinyal: Patch yang tampak rapi tidak lagi menjadi indikator yang dapat diandalkan untuk menunjukkan upaya tulus, pemahaman, atau minat jangka panjang dari kontributor .
3. Akuntabilitas: Komunitas menyimpulkan bahwa akuntabilitas manusia adalah harga mati—AI tidak dapat mensertifikasi asal-usul hukum atau bertanggung jawab atas bug .

Rust Project: Kebijakan LLM dari Lima Tim (5 Agustus 2026)

Pada 5 Agustus 2026, lima tim di Rust project mengadopsi kebijakan LLM formal untuk repositori inti rust-lang/rust . Kebijakan ini secara eksplisit bukan merupakan sikap resmi di seluruh proyek dan hanya berlaku untuk repositori inti serta tim-tim yang mengadopsinya .

Apa yang Diizinkan (dengan pengungkapan)

• Menggunakan LLM untuk menjawab pertanyaan, menganalisis kode, atau mempelajari basis kode untuk pemahaman pribadi .
• Review kode atau teks secara pribadi oleh kontributor .
• Penemuan bug yang kemudian diverifikasi sendiri oleh kontributor .
• Penerjemahan mesin untuk konten .

Apa yang Dilarang

• Mengirimkan dokumentasi buatan LLM, termasuk komentar dokumen dan komentar keamanan .
• Memposting komentar GitHub, body issue, deskripsi pull-request, diagnosa kompiler, atau komentar kode sumber yang substansial yang dihasilkan oleh LLM .
• Mempublikasikan kode buatan LLM kecuali telah mendapatkan persetujuan reviewer sebelumnya dan penggunaan LLM diungkapkan secara eksplisit .
• Mengirimkan konten buatan AI tanpa pemahaman atau review .

Inti dari kebijakan ini dirangkum dalam satu kalimat: "Tidak masalah menggunakan LLM untuk menjawab pertanyaan, menganalisis, menyaring, memeriksa, menyarankan, dan meninjau. Tetapi jangan untuk menciptakan (create)."

Mengapa Rust Mengambil Pendekatan Ini?

Jynn Nelson, penulis kebijakan ini, memaparkan tiga masalah inti dalam blog pengumuman resmi :

1. Produk teknis yang rapi tidak lagi menunjukkan usaha dan pemahaman: LLM dapat menghasilkan patch yang terlihat bersih, tetapi pengirimnya sendiri mungkin tidak memahaminya. Ini merusak sinyal sosial bahwa sebuah PR yang cermat mewakili investasi manusia yang tulus.
2. Bandwidth review sudah kewalahan: Ada 1.281 PR terbuka di rust-lang/rust. Membuat kode lebih mudah ditulis tanpa menambah kapasitas reviewer hanya akan memperburuk kemacetan yang sudah ada.
3. Copy-paste mekanis membuang waktu semua orang: Kontributor yang menempelkan komentar review ke LLM dan kemudian menempelkan balasan LLM tersebut kembali ke GitHub mengikis kepercayaan dan mengesampingkan musyawarah manusia.

Kebijakan ini juga dimotivasi oleh keinginan untuk beralih dari moderasi informal yang tidak konsisten ke aturan yang jelas dan tertulis, yang dapat dirujuk oleh reviewer dan ditemukan oleh kontributor baru .

Implikasi Lebih Luas bagi Tata Kelola Open-Source

Kedua kebijakan ini mengungkapkan pola yang sama dan serangkaian tantangan tata kelola yang serupa:

Apa yang Diisyaratkan oleh Hal Ini?

• "Krisis review" adalah ketegangan sentral. Kedua proyek menyadari bahwa LLM secara dramatis meningkatkan volume kontribusi tanpa menambah jumlah reviewer yang berkualifikasi. Ini adalah pemicu stres tata kelola terbesar .
• Keruntuhan sinyal itu nyata. Kedua komunitas mencatat bahwa PR yang rapi dulunya menandakan usaha dan pemahaman; LLM telah menghancurkan sinyal itu .
• Formalisasi menggantikan moderasi ad-hoc. Kedua proyek beralih dari aturan informal ke kebijakan yang dikodifikasi justru karena penegakan yang tidak konsisten membingungkan kontributor dan melelahkan maintainer .
• Otonomi sub-sistem itu penting. Pendekatan Linux kernel memungkinkan maintainer individu untuk menetapkan aturan yang lebih ketat, seperti yang dilakukan Johannes Berg untuk wireless. Pendekatan Rust adalah adopsi tim-per-tim .
• Tidak ada konsensus tentang AI itu sendiri. Kebijakan Rust secara eksplisit mengakui bahwa tidak akan pernah ada konsensus di seluruh proyek tentang AI, sehingga kebijakan hanya berfokus pada mekanisme kontribusi, bukan pada penilaian moral tentang LLM .