Kebijakan Kode Berbantuan AI untuk Proyek Open Source

Hal yang harus dilakukan sebelum mengirim kode berbantuan AI ke upstream

Proyek open source kini menerbitkan kebijakan tentang kode berbantuan AI, dan kebijakan tersebut tidak selalu sama. Karena itu, biasakan untuk mencari kebijakannya sebelum menulis patch, lalu ungkapkan informasinya secara akurat saat mengirim patch. Ada satu aturan yang mendasari keduanya. Jangan pernah mengirim baris kode yang tidak dapat Anda jelaskan saat review.

Patch yang benar tetap dapat ditutup jika proyek melarang kode yang dihasilkan AI, atau jika Anda menyembunyikan asal kode tersebut. Dampaknya melekat pada nama Anda dan tidak mudah hilang, karena maintainer yang kemudian menemukan penghilangan informasi tersebut tidak memiliki alasan untuk mempercayai riwayat kontribusi Anda yang lain. Berikut beberapa istilah yang perlu diketahui karena digunakan dalam kebijakan tersebut. LLM (large language model) adalah model yang digunakan oleh coding agent Anda. PR (pull request) di GitHub disebut MR (merge request) di GitLab, dan semua penjelasan berikut berlaku untuk keduanya. DCO (developer certificate of origin) adalah baris sign-off di bagian bawah pesan commit, dan ternyata menjadi inti dari seluruh perdebatan ini.

Kebijakan open source tentang kode AI telah menetapkan arahnya

Proyek-proyek kini terbagi ke dalam empat kelompok. Setiap contoh di bawah ini mencantumkan tanggal karena kebijakan ini terus berubah.

Dilarang. Dewan Gentoo memutuskan pada 14 April 2024 bahwa "secara tegas dilarang berkontribusi ke Gentoo dengan konten apa pun yang dibuat dengan bantuan alat kecerdasan buatan Natural Language Processing". Pedoman commit NetBSD menyebut output dari LLM sebagai "kode tercemar" yang "tidak boleh di-commit tanpa persetujuan tertulis sebelumnya dari core". Dokumen asal-usul kode QEMU, per Agustus 2026, masih menyatakan bahwa proyek tersebut akan "MENOLAK kontribusi apa pun yang diyakini menyertakan atau berasal dari konten yang dibuat AI".

Hanya untuk analisis. Sebagian besar larangan lebih sempit daripada yang terlihat dari judulnya. Dokumen QEMU menyatakan bahwa kebijakan tersebut "tidak berlaku untuk penggunaan AI lainnya, seperti meneliti API atau algoritma, analisis statis, atau debugging, selama outputnya tidak disertakan dalam kontribusi". Anda boleh menggunakan agent untuk membaca kode. Anda tidak boleh mengirimkan kode yang ditulisnya. Pembedaan ini merupakan batas yang berlaku di sebagian besar proyek yang restriktif, tetapi sering terlewatkan.

Wajib mengungkapkan penggunaan. Dewan Fedora menyetujui kebijakan tentang kontribusi dengan bantuan AI pada Oktober 2025. Kebijakan tersebut mengizinkan penggunaan alat dan membebankan tanggung jawab kepada kontributor: kontributor adalah penulis, bertanggung jawab penuh atas seluruh kontribusi, dan harus mengungkapkan penggunaan alat jika bagian penting dari kontribusi berasal dari alat tersebut tanpa perubahan. Kernel Linux menambahkan halaman tentang coding assistants ke dokumentasi prosesnya pada Desember 2025, lengkap dengan trailer untuk mencatat alat yang digunakan dan aturan tegas tentang pihak yang boleh memberikan persetujuan.

Belum ada ketentuan tertulis. Ini masih merupakan kondisi yang umum. Sebuah preprint dari Mei 2026 menyurvei 1,000 repositori GitHub populer dan menemukan 118 repositori yang memiliki kebijakan AI tertulis. Tidak adanya aturan bukan berarti penggunaan tersebut diizinkan. Ajukan pertanyaan dalam satu kalimat di issue tracker sebelum menulis patch, sehingga jawabannya menjadi catatan publik yang dapat Anda rujuk nanti.

Mengapa maintainer menetapkan aturan ini

Alasan pertama adalah beban peninjauan, dan perhitungannya hanya berjalan ke satu arah. Sebuah agen dapat menghasilkan merge request sepanjang 400 baris yang tampak masuk akal dalam satu menit. Meninjau merge request tersebut dengan benar menghabiskan waktu satu sore bagi seorang maintainer, dan sebagian besar maintainer adalah sukarelawan. Biaya pengiriman turun hampir menjadi nol. Biaya peninjauan sama sekali tidak berubah.

curl menunjukkan ujung lain dari kurva tersebut. Daniel Stenberg melaporkan pada pertengahan 2025 bahwa sekitar seperlima laporan keamanan yang masuk melalui program bug bounty proyek tersebut merupakan hal yang ia sebut AI slop: laporan yang menyebut fungsi nyata dan jalur kode nyata, menjelaskan serangan yang masuk akal, tetapi tidak berisi apa pun. Proyek tersebut mengakhiri program bounty pada awal 2026 daripada terus membiayai banjir laporan itu. Laporan tersebut bukan patch, tetapi mekanismenya sama: maintainer membuka PR Anda dalam keadaan sudah lelah.

GNOME Calendar mencatat masalah ini dalam bentuk label. Pada Juni 2026, proyek tersebut memperkenalkan label "Probabilistically Automated" untuk merge request yang menunjukkan "ketergantungan besar atau total pada 'kecerdasan' buatan untuk menghasilkan kode", serta menyebut gejalanya secara tepat: "biasanya disertai kurangnya pengujian yang semestinya, dan penyelesaian patch berdasarkan perilaku yang diharapkan secara teoretis, bukan kebenaran kode". Baca frasa terakhir itu dua kali. Kode tersebut tampak seolah-olah akan berfungsi. Tidak ada yang memeriksa apakah kode itu benar-benar berfungsi.

Alasan kedua adalah provenance, yaitu asal kode dan lisensi yang berlaku atasnya. QEMU menyatakan konfliknya secara jelas: sign-off menegaskan bahwa Anda "sepenuhnya memahami status hak cipta dan lisensi konten" yang Anda kontribusikan, sedangkan status hak cipta keluaran model masih belum pasti. Council Gentoo memberikan alasan yang sama, disertai pertimbangan kualitas dan etika. Anda tidak harus menyetujui penafsiran hukum tersebut. Namun, Anda harus memahami bahwa keputusan itu merupakan wewenang maintainer, bukan Anda.

Bagaimana cara menemukan kebijakan AI suatu proyek?

Cari di tempat-tempat berikut, sesuai urutan ini.

• CONTRIBUTING.md di root repositori, lalu .github/CONTRIBUTING.md, kemudian file DCO apa pun yang berada di sebelahnya.
• Dokumentasi pengembang. QEMU menyimpan aturannya di docs/devel/code-provenance.rst. Kernel menyimpannya di Documentation/process/coding-assistants.rst.
• Situs web atau wiki proyek. Kebijakan Gentoo terdapat di halaman wiki council, sedangkan kebijakan NetBSD terdapat di panduan commit.
• Pelacak issue dan arsip mailing list. Kebijakan biasanya sudah ada di sana selama berbulan-bulan sebelum seseorang menuliskannya ke dalam repositori.

Dari dalam checkout, satu perintah grep mencakup sebagian besar lokasi tersebut:

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

Kemudian baca riwayat proyek itu sendiri karena konvensi yang sudah di-commit lebih kuat daripada ringkasan tentangnya:

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

Angka di samping nilai trailer menunjukkan bentuk yang benar-benar digunakan proyek tersebut. Hasil kosong berarti belum ada yang mengungkapkannya dalam bentuk tersebut di sini. Itu juga merupakan informasi. Jika proyek berada di GitHub dan alur kerja ini masih baru bagi Anda, cara kerja pull request dan fork di GitHub menjelaskan mekanisme yang diasumsikan dalam bagian ini.

Ungkapkan melalui trailer commit, bukan dalam komentar

Trailer adalah baris Key: value pada paragraf terakhir pesan commit. Git sudah menggunakan format ini untuk Signed-off-by: dan Co-authored-by:, dan berbagai alat dapat menguraikannya. Karena itu, format ini adalah satu-satunya pengungkapan yang ikut terbawa bersama kode ke dalam tree.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

Kernel mendokumentasikan format tersebut sebagai Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] dan menjelaskan batasannya secara tegas: "AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)." Nama agen dicantumkan pada Assisted-by. Nama Anda dicantumkan pada Signed-off-by. Jangan pernah membiarkan alat menulis yang kedua, dan jangan pernah membiarkannya mengarang alamat Co-authored-by yang tidak dimiliki siapa pun.

Nama dapat berbeda-beda. Karena itu, salin nama lokal yang tersedia, bukan mengarang nama sendiri. Patch yang dikirim ke milis QEMU pada May 2026 mengusulkan pelonggaran larangan pada proyek tersebut untuk perubahan mekanis, pengujian, dokumentasi, dan perbaikan bug yang terdiri dari dua puluh baris atau kurang, dengan pencatatan melalui trailer seperti AI-used-for: tests, docs. Per August 2026, hal tersebut masih merupakan proposal di milis, dan dokumen yang telah disetujui masih menolak konten yang dibuat secara otomatis. Satu proyek mengubah posisinya dua kali antara 2023 dan 2026. Perubahan berikutnya tidak akan menunggu Anda. Karena itu, metodenya lebih penting daripada daftarnya.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer memerlukan Git 2.32 atau yang lebih baru. Perintah kedua seharusnya langsung menampilkan kembali nilainya. Baris kosong berarti git tidak menguraikan trailer tersebut. Penyebabnya hampir selalu adalah baris kosong atau kalimat biasa yang berada di dalam blok trailer pada bagian paling bawah pesan. Untuk rangkaian commit yang sudah Anda tulis, git rebase --signoff origin/main menambahkan sign-off ke setiap commit, sedangkan git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt mengedit file pesan.

Ada dua kondisi kegagalan yang perlu direncanakan. Squash merge menulis ulang pesan commit. Jadi, pada proyek yang menggunakan squash, ulangi pengungkapan tersebut dalam deskripsi PR agar maintainer dapat membacanya. Selain itu, komentar review bukanlah catatan resmi karena komentar dapat diedit dan tidak pernah masuk ke riwayat git.

Akurasi berlaku dalam dua arah. Assisted-by pada commit yang Anda ketik sendiri hanyalah gangguan dan mengurangi nilai pengungkapan Anda yang sebenarnya. Tidak mencantumkannya pada commit yang ditulis agen adalah tindakan yang mengakhiri hubungan tersebut.

Apa yang sebenarnya ditegaskan oleh Signed-off-by?

DCO adalah satu teks singkat, versi 1.1, yang diterbitkan di developercertificate.org dan digunakan oleh kernel, QEMU, serta banyak proyek lain. Menambahkan Signed-off-by: Your Name <you@example.com> berarti Anda menyatakan bahwa Anda memenuhi ketentuan tersebut. Baca hal yang Anda nyatakan, karena banyak orang menandatanganinya tanpa pernah membacanya.

Klausul (a) menyatakan bahwa kontribusi tersebut "dibuat seluruhnya atau sebagian oleh saya dan saya berhak menyerahkannya berdasarkan lisensi open source yang tercantum dalam file". Klausul (b) mencakup pekerjaan yang didasarkan pada kode open source sebelumnya yang boleh Anda teruskan dengan modifikasi. Klausul (c) mencakup kode yang diberikan kepada Anda oleh seseorang yang menyatakan hal yang sama. Klausul (d) menyatakan bahwa Anda memahami kontribusi tersebut dan informasi pribadi dalam sign-off Anda bersifat publik dan disimpan tanpa batas waktu.

Perhatikan hal yang tidak dicantumkan. DCO tidak pernah menyatakan bahwa Anda mengetik setiap karakter. DCO menyatakan bahwa Anda berhak menyerahkan kode tersebut berdasarkan lisensi ini. Karena itu, kode yang dihasilkan secara otomatis berada dalam posisi yang tidak sepenuhnya jelas: pertanyaannya bukan tentang kepengarangan, melainkan apakah Anda dapat menjelaskan asal-usulnya. Sebagian besar proyek yang mewajibkan sign-off juga mewajibkan nama asli, sehingga pseudonim tidak lolos pemeriksaan. Tambahkan baris dengan git commit -s, yang membaca user.name dan user.email dari konfigurasi git Anda. Ketika bot DCO menolak PR Anda dan menyebut commit yang tidak memiliki baris tersebut, git rebase --signoff origin/main dan force push ke branch Anda akan memperbaikinya.

Menandatangani commit tidak sama dengan memberikan sign-off

git commit -s menambahkan satu baris teks. git commit -S membuat tanda tangan kriptografis pada objek commit menggunakan kunci GPG atau SSH Anda. Keduanya menjawab pertanyaan yang berbeda. Tanda tangan membuktikan bahwa commit ini berasal dari pemegang kunci tersebut dan belum diubah sejak saat itu. Tanda tangan tidak menjelaskan asal kode di dalamnya. Karena itu, commit yang ditandatangani dan berisi kode hasil pembuatan otomatis yang tidak diungkapkan tetap merupakan pelanggaran kebijakan. Sign-off adalah pernyataan tentang asal kode. Tanda tangan adalah pernyataan tentang identitas. Proyek yang memerlukan keduanya akan meminta keduanya.

Jangan pernah mengirimkan kode yang tidak dapat Anda jelaskan saat review

Berikut pengujiannya, dan ini sebenarnya bukan tentang kejujuran. Untuk setiap baris, apa kegunaannya dan apa yang rusak tanpanya? Jika salah satu jawaban tidak ada, patch belum siap, karena komentar review akan muncul dan jawaban Anda akan menjadi putaran generasi berikutnya. Reviewer dapat mengetahuinya. Pada saat itulah kontributor berubah menjadi beban biaya. Ajukan pertanyaan yang sama tentang kondisi batas, input kosong, jalur kegagalan, dan pemanggil kedua.

Jalankan kodenya. Build kode tersebut, jalankan rangkaian pengujian proyek, dan tulis reproducer untuk bug yang ingin Anda perbaiki. Dokumentasi kernel memberikan fallback yang jujur dengan kata-kata sederhana: "Jika perbaikan tidak dapat di-build atau diuji, atau jika reproducer tidak dapat dibuat, nyatakan hal itu secara eksplisit: maintainer saat ini membuang terlalu banyak waktu untuk menganalisis laporan yang tidak terverifikasi dan perbaikan yang tidak diuji." Menulis "Saya tidak dapat mengujinya pada hardware nyata" tidak merugikan Anda. Menyiratkan bahwa Anda telah mengujinya akan merugikan proyek.

Jawab komentar review sendiri, dengan kata-kata Anda sendiri dan sesuai waktu yang Anda miliki. Balasan yang muncul tiga puluh detik setelah komentar dan mengulanginya dalam lima paragraf memberi tahu maintainer apa yang sebenarnya terjadi. Jaga diff tetap kecil. Empat puluh baris yang Anda pahami sepenuhnya lebih bernilai bagi proyek daripada refactor empat ratus baris yang hanya Anda awasi. Jika agent Anda terus mengembalikan perubahan yang melebihi permintaan, keterampilan yang membatasinya pada perubahan terkecil yang berfungsi adalah salah satu cara untuk menjaga patch tetap cukup kecil sehingga masih dapat Anda pertanggungjawabkan baris demi baris.

Simpan instruksi agent di repositori

Instruksi yang Anda berikan kepada agent merupakan bagian dari toolchain, jadi perlakukan instruksi tersebut seperti kode. File di root repositori, biasanya AGENTS.md, memuat perintah build, perintah pengujian, format pesan commit, persyaratan sign-off, serta aturan gaya yang sudah didokumentasikan oleh proyek. File tersebut memiliki versioning dan dapat ditinjau, serta isinya tetap sama dari hari ini hingga esok. Instruksi yang diketik ulang berdasarkan ingatan pada setiap sesi akan menghasilkan patch yang berbeda pada setiap sesi. Anda juga tidak akan mengetahui sesi mana yang menghasilkan patch yang ditolak. Cara menulis AGENTS.md yang dapat dibaca oleh agent dan manusia membahas file tersebut.

Perhatikan repositori milik orang lain. Jangan menjadikan kontribusi pertama Anda sebagai PR yang menambahkan file instruksi agent ke proyek yang tidak Anda kelola. Tindakan tersebut dapat dianggap sebagai upaya menetapkan kebijakan tooling proyek dari luar, dan merupakan cara cepat agar akun Anda dikaitkan dengan hal yang sudah membuat para maintainer jenuh. Simpan file tersebut di fork Anda hingga seseorang memintanya.

Tempat Anda menjalankan agent juga penting karena alasan yang sama. Agent yang dapat melakukan build proyek dan menjalankan pengujiannya di dalam sandbox yang Anda kendalikan akan menghasilkan patch yang benar-benar telah Anda verifikasi. Inilah perbedaan antara mengungkapkan penggunaan bantuan dan mengungkapkan tebakan. Menjalankan coding agent di VPS milik Anda sendiri membahas penyiapan tersebut, sedangkan perbedaan praktis antara Claude Code, Cursor, Codex, dan Copilot membahas perbedaan tools tersebut dalam penggunaan sehari-hari.

Metode setelah kebijakan berubah

1. Cari kebijakan yang berlaku sebelum menulis apa pun: repositori, dokumentasi pengembang, situs web, atau pelacak isu.
2. Jika tidak ada kebijakan, ajukan pertanyaan dalam isu dengan satu kalimat, lalu simpan jawabannya.
3. Ungkapkan dalam format yang digunakan proyek tersebut, di trailer commit, dan ulangi dalam isi PR jika proyek melakukan squash.
4. Bubuhkan sign-off dengan nama asli Anda. Baris ini menyatakan bahwa Anda berhak mengirimkan kode tersebut.
5. Tinjau patch Anda sendiri seolah-olah patch itu ditulis oleh orang lain, karena memang pernah ditulis oleh orang lain.

Setiap proyek yang disebut di halaman ini akan berubah saat Anda membacanya. Kelima langkah tersebut tidak berubah.

FAQ

Apakah saya harus mengungkapkan bahwa saya menggunakan agen coding AI?

Periksa proyek tersebut karena jawabannya ditetapkan secara lokal. Fedora mewajibkan pengungkapan jika bagian penting dari kontribusi berasal dari sebuah tool tanpa perubahan. Linux kernel meminta trailer Assisted-by. Gentoo dan QEMU, per Agustus 2026, tidak menginginkan kontribusi tersebut sama sekali. Jika tidak ada ketentuan tertulis, tetap ungkapkan dalam trailer commit. Maintainer yang mengetahuinya kemudian akan bereaksi terhadap kelalaian tersebut, bukan terhadap tool-nya, dan reaksi itu akan melekat pada semua hal lain yang telah Anda kirimkan.

Proyek open source mana yang melarang kode yang dihasilkan AI?

Sebagai gambaran per Agustus 2026: Gentoo sejak April 2024, NetBSD yang menganggap output LLM sebagai kode tercemar yang memerlukan persetujuan inti, QEMU yang menolak kontribusi yang berasal dari konten hasil generasi, serta beberapa aplikasi GNOME termasuk Loupe dan Calendar. Baca ketentuan masing-masing proyek, bukan hanya daftar ini, karena ketentuannya dapat berubah. Perhatikan pengecualian yang dimiliki sebagian besar proyek tersebut: menggunakan model untuk meneliti API, menjalankan analisis statis, atau membantu proses debugging biasanya diperbolehkan selama output-nya tidak masuk ke patch.

Apa perbedaan antara Signed-off-by dan commit yang ditandatangani?

Signed-off-by adalah baris teks biasa yang ditambahkan oleh git commit -s. Baris ini menyatakan sertifikat asal pengembang, yang berarti Anda berhak mengirimkan kode tersebut berdasarkan lisensi proyek. Commit yang ditandatangani, dibuat dengan git commit -S, adalah tanda tangan kriptografis atas objek commit menggunakan key GPG atau SSH Anda. Tanda tangan ini membuktikan bahwa commit berasal dari key Anda dan tidak diubah. Asal dan identitas adalah dua klaim yang terpisah, sehingga commit yang ditandatangani tetap dapat melanggar kebijakan AI.

Apakah saya dapat mencantumkan pengungkapan dalam deskripsi pull request, bukan dalam pesan commit?

Cantumkan dalam pesan commit karena pesan tersebut menjadi rekaman yang masuk ke riwayat git dan ikut bersama kode saat siapa pun melakukan clone repository di kemudian hari. Deskripsi pull request dapat diedit setelahnya dan berada di platform hosting. Tambahkan juga ke isi PR jika proyek menggunakan squash merge karena squash akan menulis ulang pesan commit dan dapat menghapus trailer tersebut.

Pull request saya ditutup karena dibuat oleh AI. Apa yang harus saya lakukan?

Jangan memperdebatkan kebijakan tersebut di thread karena orang yang menutupnya tidak menetapkan aturan itu sendirian, dan thread bukan tempat untuk mengubahnya. Baca teks kebijakannya, lalu tentukan apakah Anda dapat mematuhinya. Jika proyek melarang patch yang dihasilkan, laporan bug yang jelas dengan reproducer tanpa patch tetap diterima, dan sering kali menjadi kontribusi yang lebih bermanfaat. Jika Anda kembali dengan kode, kirimkan perubahan kecil yang dapat Anda pertanggungjawabkan baris demi baris.