- Salah satu proyek bahasa open source utama menerapkan aturan ketat yang melarang penggunaan LLM dalam issue, Pull Request, komentar bug tracker, dan terjemahan
- Penggunaan bahasa Inggris hanya anjuran, bukan kewajiban; kontributor dapat menulis dalam bahasa ibu mereka, dan orang lain bisa menafsirkan isinya dengan alat terjemahan pilihan masing-masing
- Bun menambahkan parallel semantic analysis dan multiple codegen units ke LLVM backend pada fork Zig miliknya sendiri dan meraih peningkatan performa kompilasi Bun sebesar 4x, tetapi saat ini tidak ada rencana upstream karena kontribusi yang ditulis LLM dilarang
- Cara review Zig lebih menekankan membantu kontributor baru mencapai hasil kerja yang bisa di-merge daripada menolak PR yang belum sempurna, serta lebih mementingkan pertumbuhan kontributor dibanding kontribusi individual
- PR yang sebagian besar ditulis LLM membuat waktu review tidak terpakai untuk menambah jumlah kontributor baru yang tepercaya, dan maintainer juga memiliki opsi untuk langsung menjalankan LLM sendiri guna menyelesaikan masalah yang sama
Benturan antara kebijakan dan fork Bun
- Zig secara eksplisit menyatakan larangan penggunaan LLM pada issue, Pull Request, komentar bug tracker, dan terjemahan di Code of Conduct
- Penggunaan bahasa Inggris adalah anjuran, dan kontributor boleh menulis dalam bahasa ibu mereka
- Orang lain dapat menafsirkan isinya dengan alat terjemahan pilihan masing-masing
- Salah satu proyek terkenal yang ditulis dengan Zig adalah runtime JavaScript Bun, dan Bun diakuisisi oleh Anthropic pada Desember 2025
- Bun mengelola fork Zig sendiri, dan menambahkan “parallel semantic analysis and multiple codegen units” ke LLVM backend sehingga menghasilkan peningkatan performa 4x saat mengompilasi Bun
- Kode terkait dipublikasikan melalui tautan perbandingan oven-sh/zig
- Saat ini Bun tidak memiliki rencana untuk upstream karena Zig melarang keras kontribusi yang ditulis LLM
- Menurut kontributor inti Zig, patch tersebut tetap sulit diterima terlepas dari isu LLM
- parallel semantic analysis adalah fitur yang sudah lama direncanakan, tetapi memengaruhi bahasa Zig itu sendiri
Contributor Poker dan review yang berpusat pada kontributor
- contributor poker dalam Contributor Poker and Zig's AI Ban adalah analogi kunci untuk memahami kebijakan larangan ketat Zig
- Proyek open source yang sukses mencapai tahap ketika PR yang masuk lebih banyak daripada yang bisa mereka proses
- Untuk memaksimalkan ROI, Zig memilih membantu kontributor baru agar bisa membawa pekerjaan mereka hingga dapat di-merge, alih-alih menolak PR yang belum sempurna
- Pendekatan ini dipandang bukan hanya sebagai “hal yang benar”, tetapi juga “langkah yang cerdas”
- Zig lebih mementingkan kontributor daripada kontribusi individual
- Tujuan utama review dan penerimaan PR bukan sekadar memasukkan kode baru, melainkan membantu orang yang seiring waktu dapat tumbuh menjadi kontributor yang tepercaya dan produktif
- Setiap kontributor menjadi sasaran investasi bagi tim inti Zig
- Dukungan LLM merusak struktur ini
- Bahkan jika LLM membantu membuat PR yang sempurna, waktu yang dipakai tim Zig untuk me-review tidak berkontribusi pada bertambahnya kontributor baru yang percaya diri dan tepercaya
- “contributor poker” berasal dari analogi bahwa permainan ini dimainkan dengan melihat orangnya, bukan kartunya
- Maknanya lebih dekat pada bertaruh pada kontributornya, bukan pada isi PR pertamanya
- Jika sebuah PR sebagian besar ditulis LLM, maintainer proyek punya opsi untuk langsung menjalankan LLM sendiri guna menyelesaikan masalah yang sama, alih-alih me-review dan mendiskusikan PR tersebut
1 komentar
Opini Hacker News
Menurut https://kristoff.it/blog/contributor-poker-and-ai/, kontribusi berbasis LLM pada umumnya berdampak negatif
PR drive-by yang tidak bernilai menambah kebisingan dengan kode halusinasi, bahkan ada yang tidak bisa dikompilasi atau gagal lolos CI, dan pernah juga kontributor pertama kali mengirim PR 10 ribu baris
Ada juga PR yang sepintas terlihat baik dan secara eksplisit menyatakan tidak memakai LLM, tetapi dalam diskusi lanjutan langsung ketahuan bahwa penulis diam-diam merujuk ke LLM dan terus mengulang jawaban yang penuh kesalahan
hooks memang tidak punya cara rapi untuk memaksa instalasi saat clone, tetapi mungkin ada fitur setara lewat GHA Workflows atau forge lain
Untuk proyek dengan skala dan popularitas tertentu, menurut saya ini syarat dasar
Sebagian besar masalah “AI tidak bisa berkontribusi” tampaknya bisa dikurangi sampai taraf tertentu dengan pemeriksaan otomatis dan mekanisme pengaman yang lebih baik
Selain fakta bahwa AI memungkinkan jenis spam baru ini, inti masalahnya bukan AI
Bahkan tanpa AI pun, efeknya akan sama jika orang mempekerjakan pasukan developer murah dari luar negeri untuk memproduksi PR drive-by kualitas sedang secara massal
Kode bagus juga bisa dibuat dengan AI, tetapi seperti alat lain, harus dipakai dengan hati-hati
Ini spam, bukan kontribusi yang dibuat dengan cermat oleh orang yang paham proyek dan tujuannya serta memanfaatkan alat dengan baik
Kebisingan seputar kebijakan AI tampaknya muncul setelah developer Bun mengatakan mereka tidak bisa meng-upstream PR performa karena kebijakan itu
Tetapi alasan sebenarnya tampaknya karena kode PR tersebut sendiri kurang baik dan memperkenalkan kompleksitas yang tidak sehat https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
Menurut penjelasan yang dikutip, parallel semantic analysis sudah lama menjadi rencana eksplisit compiler Zig dan sangat memengaruhi desain self-hosted Zig compiler, tetapi untuk menerapkannya dengan benar dibutuhkan perubahan bukan hanya pada implementasi compiler, melainkan juga pada bahasa Zig itu sendiri
Karena bertabrakan dengan roadmap Zig sendiri untuk hasil yang lebih baik, dan menghambat arah perbaikan berkelanjutan terhadap keseluruhan bahasa
Kebijakannya secara eksplisit melarang semua kode LLM, jadi kebijakan itu jelas merupakan “alasan sebenarnya”
Pihak Zig tampaknya mengikuti jejak ZeroMQ https://zguide.zeromq.org/docs/chapter6
Arahnya adalah “memaksakan kepemilikan kolektif atas proyek untuk memperkuat insentif ekonomi kontributor dan mengurangi risiko pembajakan oleh pihak yang bermusuhan”
Komunitas kontributor yang sehat lebih penting daripada sekadar performa kode, jumlah fitur, atau jumlah baris kode
Saat ini “komunitas” zeromq tergolong tipis, meski masih ada beberapa orang hebat yang aktif, tetapi proses dan saluran komunikasi setingkat manusia tidak didefinisikan dengan baik dan juga tidak benar-benar dijalankan dengan cukup
libzmq dan sebagian besar binding-nya memang stabil, jadi kurangnya aktivitas dan interaksi manusia ini mungkin sampai batas tertentu bisa diterima atau dibenarkan, tetapi visi hebat Hintjens-lah yang membawa zeromq sejauh ini, dan setelah ia tiada proyeknya terasa seperti mengambang
Agak ironis untuk visi yang berpusat pada komunitas, tetapi tampaknya untuk mendapatkan dan mempertahankan komunitas, Anda butuh pemimpin yang karismatik dan aktif, dan itu lebih banyak berbicara tentang sifat manusia daripada pengembangan perangkat lunak
Kembali ke Zig, Zig tidak kekurangan PR, jadi ada asumsi bahwa mereka bisa menyaring kontribusi no-LLM sejak awal
Itu pilihan yang bagus bagi mereka, dan ide “contributor poker” juga masuk akal
Tetapi jika arus pendatang baru berkurang, permainannya berubah, dan bila saat itu orang-orang Zig tetap menginginkan kontributor baru, mereka mungkin harus melebarkan jaring
Hanya saja, jika titik itu tiba, membuka kontribusi berbantuan LLM mungkin sudah terlambat untuk memulihkan keadaan
Hal yang membuat saya penasaran soal kontribusi OSS buatan AI adalah ini
Jika AI benar-benar sangat meningkatkan produktivitas developer, mengapa maintainer OSS ingin menempatkan kontributor asing yang tidak dikenal di antara dirinya dan LLM?
Maintainer bisa langsung bertanya ke Claude Code
Meminjam ucapan seorang rekan, “kita tidak butuh perantara untuk berbicara dengan model AI, dan coding bukan bottleneck”
Dengan AI, ia membuat versi awal yang buruk, menyesuaikan prompt, memperbaiki secara manual, menyuruhnya memperbaiki bagian lain, menemukan fitur terkait untuk ditambahkan, dan menjalankan benchmark untuk membuang fitur kecil atau memilih salah satu dari dua implementasi serupa
Lalu menambah perbaikan manual di sana-sini, menjalankan pengujian otomatis yang diperluas untuk menemukan bug aneh di konfigurasi yang aneh, dan memperbaikinya dengan AI dan kerja manual
Setelah 20 jam, versi akhirnya mungkin hanya 50 baris, dan tiap barisnya bisa saja sudah ditulis ulang 5 kali
Maintainer cukup meninjau versi final selama kira-kira 1 jam
Ini benar-benar berbeda dari membiarkan AI menulis patch selama 5 menit lalu mengirim 1000 baris yang bahkan tidak bisa dikompilasi ke maintainer tanpa dibaca sama sekali
“Itu terlalu mudah, saya juga bisa melakukannya”
Benar, tetapi kenyataannya Anda tidak melakukannya
Tetapi ini bukan tipe hal di mana Anda bisa sekadar melempar instruksi tingkat tinggi seperti ke manusia
Orang yang mengklaim AI bisa bekerja hanya dengan instruksi tingkat tinggi barangkali mengerjakan proyek yang “tidak perlu banyak dipikirkan”, di mana developer yang masuk ke detail memang tidak perlu terlalu banyak berpikir
Saya juga berharap maksudnya bukan bahwa satu-satunya manfaat LLM hanyalah menghasilkan kode yang malas kita ketik sendiri
Penjelasan bahwa “Zig lebih mementingkan kontributor daripada kontribusi. Tujuan utama meninjau dan menerima PR bukanlah memasukkan kode baru, melainkan membantu seseorang tumbuh menjadi kontributor yang tepercaya dan produktif seiring waktu. Bantuan LLM sepenuhnya merusak ini. Bahkan jika LLM membantu mengirim PR yang sempurna, tetap saja begitu” adalah alasan terbaik yang pernah saya lihat sejauh ini
Saya sepenuhnya mendukung keputusan Zig, dan sangat menghargai visi jangka panjangnya terhadap komunitas maupun proyek nyata itu sendiri
Sejujurnya saya juga tidak merasa LLM terlalu cocok untuk kerja yang lebih kolaboratif
Kita lihat saja nanti akan berubah seperti apa, tetapi ketika menerima PR buatan AI, saya sering akhirnya harus mengerjakannya ulang sendiri, dan ironisnya saya juga jadi memakai LLM untuk mengerjakannya ulang sehingga rasanya makin konflik
Meski begitu, setidaknya untuk sekitar 5 tahun ke depan saya rasa kebijakan Zig adalah ide yang bagus
Saya rasa itu adalah ungkapan paling tidak bermusuhan yang bisa mereka pilih, dan saya menghormatinya sebagai keputusan atas proyek mereka sendiri
Meski begitu, tetap terasa seperti mereka mengekang proyek secara tidak perlu
LLM adalah alat, dan bisa membantu berpikir, meneliti, dan menulis kode
Memang bisa dipakai berlebihan, tetapi seharusnya diterima di tempat yang memang terbantu olehnya
Menolak PR Bun karena alasan lain sepenuhnya masuk akal, tetapi sekadar melarang semua PR yang ditulis LLM terasa membatasi secara tidak perlu
Fokus saja pada kualitas hasil kerjanya
Jika maintainer memakai LLM sendiri untuk melakukan hal yang sama, kemungkinan besar hasilnya akan datang dengan desain yang lebih baik dan pendekatan yang lebih hati-hati
Maintainer tidak hanya perlu melakukan review PR berupaya minim, tetapi juga harus menghabiskan waktu untuk pengembangan
Banjir kode LLM mengubah keseimbangan menjadi merugikan maintainer, dan saya sangat paham kenapa mereka ingin langsung melarangnya
Setelah beberapa lama menjalankan LLM dan coding agent, kesan keseluruhan saya adalah ini adalah alat listrik atau crane, bukan alat pengambil keputusan
Orang dalam organisasi yang punya pemahaman konsep dan pemahaman rekayasa mendalam akan mengalami ledakan produktivitas
Sebaliknya, orang yang pemahamannya kurang, atau yang masih baru, atau junior, membuat kode neraka sambil merasa semuanya beres asal programnya jalan
LLM menciptakan kesenjangan intelektual dalam organisasi, dan semakin banyak dipakai, semakin lebar kesenjangan itu
Nantinya bisa sampai pada titik di mana hasil kerja internal organisasi tidak lagi dipercaya karena begitu banyak kode yang dihasilkan
AI pada dasarnya memperkuat skillset, baik sisi baik maupun buruknya
Kasus penggunaan yang sangat bagus belakangan ini adalah menulis konsep untuk authentication daemon
Saya berdialog dengan Codex, memilih saran-sarannya, melakukan pengecekan silang dengan pencarian web biasa, menyusun draf akhir, lalu mendiskusikannya dengan rekan-rekan
Perencanaan percakapan dengan pencarian web terintegrasi seperti ini sangat berguna, dan menurut saya meninjau kode yang sudah ditulis dengan bantuan AI juga murni memberi manfaat
Hanya saja caveat utama AI pada akhirnya adalah Anda harus lebih pintar daripada alatnya
Jika Codex menyarankan memakai tech stack X, Anda harus meneliti mengapa itu benar-benar baik, memahaminya sepenuhnya, dan membandingkannya dengan solusi lain
Banyak orang melewatkan tahap ini, sehingga menimbulkan banyak masalah, dan itu fatal
Setelah percakapan selesai, Anda seharusnya menjadi lebih pintar daripada AI, dan harus bisa sepenuhnya memahami serta mengkritisi apa yang AI katakan
Setelah arsitekturnya ditetapkan, LLM cukup bagus dalam implementasi
Umumnya Anda memang bisa membuat AI menghasilkan kode yang hebat dan teruji dengan baik, dan kadang jauh lebih baik daripada jika Anda bekerja sendiri dalam waktu yang sama
Tetapi tetap menantang untuk terus mengejar pemahaman atas semua hal yang dibuat AI
Logika “jika PR itu sebagian besar ditulis LLM, bukankah maintainer lebih baik menyalakan LLM-nya sendiri untuk memecahkan masalah yang sama daripada menghabiskan waktu meninjau dan mendiskusikan PR itu?” juga berlaku pada open source itu sendiri
Kalau robot bisa langsung menuliskannya, mengapa memakai proyek orang lain?
Terutama kalau proyek open source itu sendiri dibuat dengan vibe coding
AI dan teknologi secara umum membuat personalisasi menjadi murah dan mudah
Dulu kita harus memakai barang produksi massal yang cukup memuaskan untuk semua orang, tetapi sekarang ada harapan mendapatkan sesuatu yang luar biasa khusus untuk diri kita sendiri
Selain itu, banyak orang di banyak tempat akan memakai LLM untuk membuat ulang proyek open source, yang juga mengguncang ekonomi tenaga kerja
LLM bisa memuntahkan itu dalam hitungan menit
Yang paling saya inginkan adalah riwayat penggunaan
Saya ingin memakai perangkat lunak yang sudah dipakai orang lain sebelum saya, dan berharap mereka sudah menemukan bug serta sudut-sudut tajamnya lalu menghaluskannya
Katanya, kalau Anda bisa mengunduh model di rumah, mencetaknya, dan menyesuaikannya tanpa batas, siapa yang masih mau membeli barang?
Alasan kita punya peradaban adalah agar sebagian besar masalah hidup bisa dialihkan menjadi urusan orang lain, dan kita sendiri bisa fokus menjadi sangat baik pada satu hal
Jika Anda dokter gigi atau menjalankan muffler shop, waktu Anda per hari terbatas, dan kemungkinan besar Anda lebih memilih membayar vendor SaaS daripada belajar vibecoding dan mengawasi bawahan aneh yang merepotkan
Ada pengecualian, tetapi tetap saja itu pengecualian
Jika vendor membuat produk yang masuk akal dan kompeten, saya dengan senang hati akan membayar
Open source juga sama
Bahkan jika LLM bisa membuat sistem operasi yang stabil dari nol, apakah saya benar-benar menginginkannya?
Saya tidak ingin memelihara OS, tidak ingin mengelola orang yang memelihara OS, dan sejak awal pun saya tidak yakin punya visi yang konsisten tentang OS
Setelah melewati tingkat kompleksitas tertentu, sulit berharap robot bisa cukup membaca isi pikiran saya untuk memberikan hasil berkualitas tinggi yang “luar biasa hanya untuk saya”
Proyek Zig jelas jauh di luar jangkauan kemampuan seperti itu
Ada orang yang kesulitan menanggung biayanya, dan bahkan bagi yang punya akses, sering atau terus-menerus ada masalah seperti Claude yang down atau performa umum yang menurun seiring waktu
Beberapa bulan lalu saat baru mulai serius memakai Claude, saya bisa dengan mudah maju di beberapa proyek dalam seminggu, tetapi belakangan rasanya saya cuma melihat spinner dan kualitas kodenya juga anjlok, jadi hampir tidak bisa menyelesaikan apa pun
Saya punya beberapa repo dengan sekitar 100 bintang, tidak istimewa, tetapi sampai tahun lalu kadang masih ada PR masuk, sedangkan tahun ini sejauh ini hampir tidak ada
Hipotesis saya adalah LLM cenderung lebih suka menempel pada proyek yang mainstream
Karena banyak developer sekarang sangat bergantung pada LLM, muncul bias untuk mengabaikan sebagian besar hal yang saya sediakan
Salah satu alasan reinventing the wheel makin sering terjadi dengan LLM adalah biaya untuk membuat ulang jadi murah
Jadi lebih mudah cukup menghasilkan sendiri apa yang dibutuhkan daripada memakai sesuatu yang obscure di GitHub, seperti milik saya
Saya juga melihat fenomena yang sama dalam pilihan dependency saya
Kalau tidak ada alasan yang sangat bagus, orang cenderung langsung memilih apa yang disarankan LLM
Saya agak setuju, tetapi tidak sepenuhnya
Memang benar bahwa membina kontributor adalah prioritas yang tepat
Tetapi saya melihat AI sebagai teknologi bantu
Mirip screen reader atau magnifying glass, meskipun tentu ada banyak perbedaannya
Anda bisa menganggapnya seperti eksoskeleton robot
Ini akan dipakai untuk hal-hal buruk dan bodoh, tetapi juga akan dipakai untuk membantu orang melakukan hal baik yang sebelumnya tidak bisa mereka lakukan, atau menjadi lebih mampu
Bagi sebagian orang, AI memungkinkan mereka menulis kode yang dulu tidak bisa mereka lakukan, bagi banyak orang AI menjadi sarana belajar coding dengan melihat apa yang AI lakukan, dan bagi yang lain AI membuat mereka bisa coding jauh lebih cepat atau lebih baik
Pada sebagian orang, mungkin beberapa keterampilan tertentu menurun tetapi keterampilan lain justru berkembang
Eksoskeleton juga akan punya masalah yang sama jika suatu saat ada produk yang layak di pasar, tetapi secara keseluruhan itu tetap akan menjadi alat yang memberdayakan
Saya tidak paham mengapa membina kontributor yang memakai teknologi bantu harus dianggap lebih buruk daripada membina kontributor yang tidak memakainya
Tentu saja mungkin lebih sulit
LLM tidak sepintar yang diklaim vendor LLM
Kalau benar sepintar itu, mestinya sudah sepenuhnya otonom dan kita tidak akan membicarakan ini
Orang yang membabi buta mengirim kode buatan LLM atau tidak mengungkap bahwa mereka memakainya benar-benar harus berhenti
Masalah yang tersisa tetap bahwa ini hanyalah alat
Jika Anda menyuruh developer sembarang orang “buat Zig lebih cepat dengan one-shot PR”, hasilnya juga tidak akan bagus
Dulu proyek OSS tersaring sendiri karena Anda harus bisa menghasilkan working code, dan saat sudah sampai tingkat itu, biasanya Anda telah belajar bertahun-tahun sehingga cenderung melakukan hal yang benar dan punya reasoning sendiri soal fungsi atau kebutuhannya
Hari ini, sekalipun LLM sempurna dan punya reasoning yang bagus, tetap saja ia menjalankan instruksi dari orang yang mem-prompt
Mekanisme penyaringan dirinya sudah hilang
Developer Zig juga kemungkinan sulit membedakan mana kode buatan LLM dan mana buatan manusia
Bisa jadi sudah ada kode buatan LLM yang masuk, tetapi setidaknya manusia yang mengirimkannya itu masih harus cukup paham untuk menangani kodenya dengan baik
Pada akhirnya saya penasaran apakah kita akan menuju ke “hanya manusia dengan trusted badge of honor yang boleh commit”, atau ke tingkat di mana “LLM punya reasoning yang cukup untuk berkata, ‘tidak, pergi sana. fitur/rencana/ide ini sampah jadi saya tidak akan membuatnya’”
Kalau tidak ada cara memberi konsekuensi yang benar-benar terasa ketika mereka melakukannya, saya tidak tahu apa yang bisa menghentikan mereka