Cara Menghentikan Spam Bot AI di Repositori GitHub dengan Flag `--author` Git

• Repositori Archestra mengalami lonjakan komentar dan PR tak bermakna seiring meningkatnya kontribusi berbasis AI, sehingga diskusi nyata tenggelam dan beban pemeliharaan membesar
• Isu bounty senilai $900 awalnya menjadi ruang diskusi bagi para kontributor nyata, tetapi membengkak menjadi 253 komentar akibat komentar bot AI, bahkan disertai sikap agresif
• Isu dukungan provider x.ai menerima 27 PR yang ditutup dan tidak digabungkan, dan sebagian besar bahkan tidak diuji oleh kontributornya
• Pembatasan prior contributor di GitHub tidak mampu membedakan pengembang baru yang nyata dari bot AI, sehingga pengguna yang disetujui ditambahkan sebagai author commit di main menggunakan Git --author
• Proses onboarding membuat commit whitelist lewat GitHub Action setelah aturan AI yang etis dan CAPTCHA, dengan memprioritaskan kualitas dibanding metrik aktivitas yang dibesar-besarkan

---

Bagaimana spam bot AI menggerogoti repositori open source

• Repositori Archestra, berbeda dari pertumbuhan metrik kontribusi berbasis AI yang ditampilkan GitHub, justru menghadapi penurunan kualitas kontribusi dan meningkatnya beban pemeliharaan di lapangan
• Isu dengan bounty $900 awalnya adalah tempat para kontributor nyata mengusulkan rencana, bertanya, dan mencoba mengerjakan tugas, tetapi setelah bot AI berdatangan jumlahnya membengkak menjadi 253 komentar
• Akun-akun AI meninggalkan rencana implementasi yang tak bermakna dan bahkan menunjukkan sikap agresif terhadap maintainer, sehingga mencemari diskusi
• Anggota tim yang memantau repositori menerima notifikasi untuk setiap komentar AI, sementara percakapan kontributor nyata seperti @ethanwater, @developerfred, dan @Geetk172 tenggelam
• Isu dukungan provider x.ai menerima 27 pull request yang ditutup dan tidak digabungkan, dan sebagian besar bahkan belum diuji oleh kontributornya
• Salah satu anggota tim harus menghabiskan setengah hari setiap minggu untuk membereskan PR yang tidak diuji dan isu halusinatif; jika dibiarkan, repositori cepat berubah menjadi tempat yang tidak ramah bagi kontributor nyata

Metode whitelist yang mengakali pembatasan GitHub

• Keterbatasan respons awal

  • Archestra mula-mula membuat bot kecil bernama London-Cat untuk menghitung reputasi kontributor
  • London-Cat menghitung reputasi berdasarkan PR yang sudah digabungkan dan beberapa sinyal lain, dan membantu mengidentifikasi kontributor seperti pada contoh ini
  • Namun pendekatan ini gagal untuk benar-benar memblokir spam
  • AI sheriff yang dibuat pada tahap berikutnya justru ikut menutup beberapa PR nyata, seperti pada contoh ini

• Memblokir aktivitas tanpa onboarding

  • Karena komentar dan usulan AI yang tak bermakna terus berdatangan, kontributor nyata mulai pergi, sehingga pendekatan mendorong kontribusi lewat bounty maupun memberi tugas tes kepada kandidat rekrutmen pun ikut ditinjau ulang
  • Archestra memperkuat respons untuk menciptakan repositori yang nyaman dan aman bagi kontributor nyata, pengguna AI yang bertanggung jawab, pemula, maupun engineer berpengalaman
  • Pengguna yang belum melalui onboarding kini diblokir agar tidak bisa membuat isu, membuka PR, atau menulis komentar
  • Bagi startup yang mendapat investasi VC, metrik aktivitas GitHub memang sensitif, tetapi Archestra menilai kualitas lebih penting daripada metrik yang dibengkakkan oleh AI slop

• Keterbatasan pengaturan GitHub

  • GitHub tidak menyediakan cara sederhana untuk mengelola whitelist penulis komentar atau pembuat PR secara langsung di repositori open source
  • Pengaturan “Limit to prior contributors” memblokir komentar pada isu dan PR dari pengguna yang belum pernah melakukan commit ke main sebelumnya
  • Pengaturan ini tidak mampu membedakan bot AI dari pengembang nyata yang baru datang untuk mengerjakan bounty, karena keduanya sama-sama dianggap bukan kontributor lama

• Whitelist menggunakan flag --author

  • GitHub menilai akun GitHub yang terhubung sebagai author commit di branch main sebagai prior contributor
  • Dalam commit Git ada dua kolom identitas, yaitu author dan committer, dan keduanya bisa berbeda
  • Dengan menggunakan flag --author di Git, kita bisa membuat commit yang diatribusikan ke orang lain; jika emailnya cocok dengan akun GitHub tersebut, GitHub akan menautkan commit itu ke profilnya dan memberinya status kontributor
  • Setiap akun GitHub memiliki email noreply dengan format <id>+<username>@users.noreply.github.com
  • Setelah mengambil ID pengguna lewat API, author commit ditentukan memakai format email tersebut

  gh api users/their-username --jq '.id'  
  git commit \  
  --author="their-username <[e-mail]>" \  
  -m "chore: add their-username to external contributors"  
  

  • Saat commit ini di-push ke main, pengguna eksternal akan ditampilkan sebagai author, akun Archestra sebagai committer, dan GitHub langsung menganggap pengguna itu sebagai prior contributor sehingga bisa segera berkomentar

• Alur onboarding yang sebenarnya

  • https://archestra.ai/contributor-onboard - onboarding dilakukan di situs web dengan aturan AI yang etis dan CAPTCHA
  • GitHub Action - saat formulir dikirim, sistem mengambil GitHub ID pengguna, menambahkan handle ke file EXTERNAL_CONTRIBUTORS.md, lalu me-push commit ke main dengan akun pengguna tersebut sebagai author
  • Pengguna - masuk ke whitelist dan memperoleh hak akses ke repositori
  • Sementara GitHub melaporkan pertumbuhan metrik skala besar yang mencakup aktivitas buatan AI, tim proyek open source justru harus membersihkan sendiri AI slop di repositori dan bahkan membuat jalan memutar untuk mempertahankan tingkat partisipasi nyata
  • AI slop bukan hanya mendorong orang yang ingin memberi kontribusi baik ke tengah kebisingan dan menurunkan motivasi mereka, tetapi juga membawa risiko keamanan ketika penyerang mencoba memancing percakapan lewat bot AI, seperti pada repo LiteLLM

[GN⁺]

Komentar Hacker News

• Kontributor repositori punya hak lebih tinggi, seperti bisa melewati kebutuhan persetujuan untuk menjalankan PR dari fork, jadi pendekatan ini punya dampak keamanan yang terlewat
  Dokumentasi GitHub juga memperingatkan bahwa pada pengaturan yang “hanya meminta persetujuan untuk kontributor pertama kali”, pengguna yang sekali saja commit atau PR-nya digabungkan ke repositori tidak lagi memerlukan persetujuan, dan penyerang bisa memenuhi syarat ini dengan membuat perubahan yang tampak tidak berbahaya seperti sekadar memperbaiki typo

  • Benar juga. Orang yang bukan anggota organisasi tidak bisa dipercaya, jadi menurut saya wajibkan persetujuan untuk semua kontributor eksternal harus menjadi default
  • Itu bukan dampak keamanan
    Jika repositori menjadi tidak aman hanya karena satu PR yang sepenuhnya tidak berbahaya dari seseorang digabungkan, maka repositori itu memang sejak awal sudah dalam keadaan tidak aman

• Masalahnya adalah GitHub membiarkan hal seperti ini mungkin terjadi. Kalau sejak awal mereka memasang syarat yang sangat dasar untuk menulis komentar dan membuat PR, situasinya mungkin tidak akan sampai begini
  Dan seperti issue bisa dihapus, saya juga ingin PR bisa dihapus

  • Saat ini admin sedang dikerjakan fiturnya untuk mengarsipkan PR
    Tujuannya agar maintainer bisa lebih mengontrol cara mereka mengelola kontribusi repositori. PR yang diarsipkan hanya akan terlihat oleh admin, dan maintainer tetap bisa mengakses catatan kontribusi untuk audit atau kebutuhan organisasi dan kepatuhan. Penasaran apakah fitur seperti ini akan membantu
  • Penilaian itu tepat. Sama seperti mencegah email spam bukan sesuatu yang harus “diselesaikan sendiri” oleh tiap orang, ini juga bukan masalah yang seharusnya dibebankan ke komunitas open source atau proyek individual
  • Saya tidak paham keuntungan apa yang didapat dari menghapus PR alih-alih menutupnya. Dengan menutupnya, ada sinyal PR seperti apa yang tidak diterima; kalau dihapus, keuntungan itu hilang

• Spam PR adalah masalah besar untuk repositori yang menawarkan bounty. Mungkin GitHub perlu memblokir sementara pembuatan PR untuk akun yang lebih dari 95% PR-nya ditolak

  • Akan bagus jika GitHub punya sistem untuk menerbitkan semacam token 1-PR
    Jika seseorang ikut dalam diskusi yang bermakna dan menunjukkan ide bagus untuk menyelesaikan issue atau fitur, awalnya mereka diberi satu token PR, lalu jika kualitas PR-nya bagus diberi beberapa lagi, dan pada akhirnya dipromosikan menjadi kontributor yang bebas membuat PR. Akan bagus juga kalau ada sistem serupa untuk issue, meski saya tidak yakin bentuknya seperti apa ketika issue menjadi titik awal kontribusi PR. Hanya saja, GitHub/MS tampaknya ingin menjual langganan Copilot dan token, dan PR buatan LLM juga bagian dari model bisnis itu, jadi rasanya kecil kemungkinan ini benar-benar terjadi
  • GitHub tidak punya insentif untuk memblokir AI. Itu mirip seperti meminta perusahaan iklan memasang ad blocker di browser mereka sendiri
  • Masalahnya, bot bisa terus membuat akun GitHub baru dan mengirim spam tanpa batas. Meski begitu, sebagai langkah awal ini tetap bisa menjadi pertahanan sederhana yang lumayan
  • GitHub dan Microsoft sendiri aktif berkontribusi pada masalah ini, jadi mengapa mereka mau mengakui kesalahan mereka sendiri?

• Saya penasaran apakah sistem skor berbasis Elo bisa membantu mengurangi masalah seperti ini
  Misalnya menilai orang yang berhasil menggabungkan PR ke proyek tertentu, yang issue nyatanya diakui, yang kualitas responsnya bisa diukur dari reaksi pengguna lain, lalu dikalikan lagi dengan tingkat pentingnya proyek tempat aktivitas itu terjadi. Ini bisa menjadi tolok ukur untuk membedakan kontribusi yang benar-benar efektif dan membantu dari kontribusi berusaha minim atau spam, bukan semata manusia versus AI. Issue dan PR kemudian bisa diurutkan atau difilter berdasarkan skor Elo. Elo di sini hanya metafora untuk skor berbasis konteks, bukan berarti sistem Elo asli dipindahkan 1:1
  Skor negatif bisa berasal dari laporan pengguna lain terhadap konten spam atau issue yang tidak diakui, dan tampaknya perlu ada wilayah tengah berupa skor netral atau sedikit positif untuk kasus seperti niat baik yang jelas tetapi tidak sampai menjadi PR yang digabung, issue yang ternyata bukan untuk repositori yang tepat, atau PR bagus yang butuh implementasi pendahuluan lebih dulu

  • Elo sangat mudah dimanipulasi
    Misalnya, dulu benar-benar ada pemain catur yang lumayan bagus di penjara, dan dia membentuk kumpulan pemain yang mendapatkan Elo tinggi dengan mengalahkannya, lalu menggunakan mereka untuk menaikkan skornya sendiri lebih jauh. Tinggal ulangi proses itu
    Sistem apa pun yang bisa dimanipulasi akan ditemukan cara manipulasinya oleh AI. Dalam pendekatan artikel aslinya pun, begitu satu AI mendapat status kontributor, AI itu bisa mengangkat AI lain menjadi kontributor, lalu masalah yang sama mulai lagi. Bahkan tidak perlu ada tujuan tertentu. Troll akan tetap trolling, dan troll yang punya bot AI bisa mencurahkan energi tanpa habis. Semakin kita berusaha menghentikannya, semakin menyenangkan bagi mereka. Saya harap ada jawaban untuk masalah ini, tapi saya tidak tahu
  • Tambahan bagi yang penasaran dengan Elo: Elo bukan akronim, melainkan nama keluarga seseorang. Detailnya ada di sini: https://en.wikipedia.org/wiki/Elo_rating_system
  • Itu Elo, bukan ELO. Elo bukan singkatan
    https://en.wikipedia.org/wiki/Elo_rating_system
  • Saya sedang membuat sesuatu yang mirip dan saat ini mengumpulkan datanya
    Frontier users: 527,865
    Light indexed: 527,865
    Ready to queue: 9,083
    Fast scores ready: 0
    Activity events 24h: 30,266
    Fast scores completed 24h: 19,123
    Deep jobs completed 24h: 3,043
    Fast-score ETA: n/a
    Deep-hydrate ETA: 69h
    Stale running jobs: 0
    GitHub backpressure jobs: 19,113
    High automation signals: 4,608
    Medium automation signals: 1,327
    Completed jobs: 74,714
    Kendala terbesar adalah rate limit GitHub. Dengan kecepatan ini, butuh dua bulan lagi untuk mencapai cakupan 98%, tetapi setelah itu pemeliharaannya tampaknya akan cukup sederhana
  • Terdengar agak mirip dengan Vouch milik Mitchell Hashimoto: https://github.com/mitchellh/vouch

• Inilah akibatnya ketika semua orang diberi tahu betapa hebatnya AI menulis kode
  Orang-orang yang menjual AI yang memulainya, dan anehnya banyak developer independen, termasuk yang cukup dihormati di industri, ikut naik ke kereta itu. Facebook yang sekarang memecat orang sambil berkata bahwa AI begitu hebat juga menyiram bensin ke api. Sekarang ada orang-orang yang yakin teman AI mereka menghasilkan kode luar biasa dalam jumlah besar, lalu mengirimkan kode itu ke proyek-proyek yang sudah sepenuhnya kewalahan

  • Mungkin cowboy coder sekarang mendapatkan koboi perempuan virtual dan menjualnya ke semua orang
    Terlepas dari dihormati atau tidak, developer solo tidak selalu memiliki kompetensi minimum yang dibutuhkan agar tidak menjadi cowboy. Bisa karena kurang pengalaman, bisa juga karena memang kurang bakat alami. Namun saya sendiri tidak sepenuhnya percaya pada narasi itu. Sejak “awal” sudah ada dorongan kuat dari atas ke bawah

• Ironis juga bahwa ini ada di domain .ai

  • Saya tidak terlalu melihatnya sebagai ironi. Maksudnya bukan AI itu buruk, tetapi AI bisa disalahgunakan
  • Semoga situs webnya memperbaiki sedikit kode scrolling-nya. Menjengkelkan sekali sampai saya tidak bisa membaca artikelnya
  • Ini seperti perusahaan yang berbasis pada sampah AI berkata, “Saya tidak menyangka AI akan membuat proyek saya jadi sampah!”
  • Bukan cuma domainnya. Ini adalah agentic stack. Dengan kata lain, produk perusahaan ini sendiri bisa dipakai untuk membuat PR seperti yang sedang mereka keluhkan di sini

• Jadi solusi untuk semua hal pada akhirnya adalah lebih banyak catgirl? [1] Proof of work awalnya dimaksudkan untuk melawan spam email, dan spam PR hanyalah contoh terbaru dalam tradisi panjang itu
  1- https://anubis.techaro.lol

  • Proof of work tidak berhasil di sini, sama seperti dulu tidak berhasil untuk email
    Upaya yang dibutuhkan untuk membuat proof of work yang valid, dalam implementasi apa pun, selalu berakhir lebih merugikan pengguna normal. Orang yang punya insentif mengirim spam akan selalu bisa melakukannya lebih cepat dan lebih efisien
    Kalau laptop Anda terlalu lambat untuk mengirim PR? Tinggal menyewa hash power dari orang lain, dan itu berarti kita baru saja menciptakan sistem di mana Anda membayar pemilik botnet agar bisa mengirim perbaikan typo ke repositori GitHub. Ada alasan mengapa HashCash tidak dipakai di dunia nyata. Kedengarannya lucu, tetapi itu hanya bisa bekerja jika mengasumsikan ruang hampa tempat semua orang jujur, karena insentifnya benar-benar tidak masuk akal
  • Anubis sebenarnya bukan kucing. Dalam mitologi Mesir asli, Anubis adalah dewa kematian dan memiliki kepala canid. Catgirl anime dan dog girl mungkin terlihat mirip pada pandangan pertama
  • Menurut saya Anubis ditujukan untuk memblokir crawler, bukan agen pembuat PR. Di sini proof of work tidak akan berhasil. Agennya tinggal melakukan komputasinya saja

• Gaya bahasa dokumentasi onboarding itu punya ciri AI yang umum. Bahkan di kutipannya terlihat em dash dan kalimat model “bukan A melainkan B”
  Saya paham ini bisa jadi semacam melawan api dengan api, atau seperti sudah disebutkan, mungkin karena tidak ada waktu. Tetap saja, secara keseluruhan ini terasa seperti respons setengah-setengah yang kurang memadai

  • Seluruh tulisan itu terlihat jelas dihasilkan LLM
    Saya paham ada manusia yang menyusun gagasannya, tetapi menyuruh LLM “ubah ini jadi tulisan blog” menurut saya adalah konten usaha rendah yang tidak cocok untuk HN. Meski begitu, setidaknya ini memunculkan diskusi bahwa pendekatan dasarnya, yaitu “batasi ke kontributor”, bisa jadi ide buruk dari sisi keamanan
  • Menggunakan AI di proyek sendiri dan kewalahan oleh kontribusi AI yang dikirim orang atau bot lain adalah dua masalah yang berbeda

• Bagian yang mengatakan “jika email cocok dengan akun GitHub, GitHub akan mengaitkan commit itu ke profil dan memberi status kontributor” membuat saya khawatir apakah ini akan rusak kalau alamat email kontributor berubah
  Karena selama bertahun-tahun saya pernah berkontribusi ke beberapa proyek dengan alamat email yang sudah tidak ada lagi
  Tetapi tampaknya sebenarnya mereka tidak memakai alamat email yang tercatat di commit git asli penulis, melainkan alamat buatan GitHub yang bagian uniknya berisi ID pengguna dan username GitHub. Kalau begitu, ini bisa tetap bertahan meskipun penulis mengganti alamat emailnya. Namun ini bisa rusak jika kontributor kehilangan akses ke akun dan harus membuat akun baru, meski itu mungkin lebih jarang terjadi

• Jawaban untuk “haruskah kita berhenti memberi pelamar tugas tes yang menyenangkan?” adalah ya

  • Tampaknya perusahaan ini memang membayar biaya jika tugas itu diselesaikan, jadi mungkin tidak seburuk itu
  • Para developer: hentikan wawancara whiteboard karena itu tidak mengukur hal yang relevan dengan pekerjaan nyata
    Juga para developer: jangan suruh kami memecahkan masalah yang nyata
  • Sejak awal saya juga tidak tahu menyenangkannya itu buat siapa