RFC 406i — Protokol Standar Penolakan Kontribusi Sampah Buatan AI (RAGS)

• Dokumen yang mendefinisikan protokol standar bergaya RFC yang jenaka untuk secara otomatis menolak kontribusi berkualitas rendah yang dihasilkan AI di repositori open source, komunitas, dan lainnya
• Berfungsi sebagai sarana terstandarisasi untuk menyampaikan sinyal penolakan "deteksi AI slop" hanya dengan maintainer proyek menempelkan URI terkait
• Mencantumkan daftar ciri khas kontribusi buatan AI dan secara langsung menyoroti pemborosan sumber daya pemeliharaan serta risiko keluaran yang tidak tervalidasi
• Menegaskan posisi bahwa meskipun kiriman berbasis LLM lolos pengujian dan tata bahasanya benar, tanpa pemahaman logika dan arsitektur, itu pada dasarnya tidak bernilai
• Walau merupakan dokumen satir yang meminjam format RFC, isinya mencerminkan kelelahan nyata para maintainer terhadap penyalahgunaan kontribusi otomatis berbasis AI di ekosistem open source

---

Abstract - Tujuan dokumen ini

• Protokol standar untuk menangani dan membuang kontribusi minim usaha yang dihasilkan AI yang dikirim ke repositori kode sumber, issue tracker, portal pelaporan kerentanan, dan forum komunitas
• Berlaku untuk proyek open source publik maupun sistem internal perusahaan

1. Introduction - Mengapa Anda diarahkan ke halaman ini

• Anda diarahkan ke halaman ini karena kontribusi Anda memicu sistem deteksi AI slop otomatis atau manual
• Secara spesifik, maintainer atau engineer senior melihat kiriman tersebut, menghela napas eksistensial yang dalam, lalu segera menutup koneksi dan menempelkan URI ini
• Kata kunci "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" yang digunakan dalam dokumen ini harus ditafsirkan sebagai ukuran "seberapa besar kami tidak ingin meninjau kiriman ini"

2. Diagnostic Analysis - Ciri yang terdeteksi pada kiriman Anda

• Hasil analisis kosakata dan struktur materi yang Anda kirim menyimpulkan bahwa prompt engineering Anda keliru, dan oleh karena itu Anda seharusnya merasa malu
• Akibat membiarkan burung beo probabilistik menulis PR, pengungkapan kerentanan, komentar issue, dan posting forum atas nama Anda, ia telah membohongi kita semua
• Ciri-ciri berikut terdeteksi dengan sangat jelas:
  • Penggunaan nada yang terlalu sopan dan robotik
  • API yang sepenuhnya tidak ada tetapi dipaparkan dengan keyakinan tinggi
  • Kode boilerplate bengkak yang sama sekali tidak menyelesaikan masalah nyata
  • Menggunakan "delve" dengan serius dalam deskripsi PR
  • Sisa keluaran LLM seperti "Certainly! Here is the revised output:" yang masih tertinggal di docstring, komentar, atau laporan keamanan
  • Pesan commit 600 kata atau esai teoretis besar untuk sekadar memperbaiki typo sederhana
  • Import library halusinatif yang tidak ada seperti utils.helpers
  • Menambahkan paragraf penutup pada laporan bug sepele yang dimulai dengan "In conclusion, this robust and scalable solution..."
  • Penamaan variabel dan fungsi yang ganjil dan steril, mustahil dicapai programmer manusia yang hidup dengan kafein dan kurang tidur
  • Ketergantungan penuh pada regex atau konsep halusinatif, tanpa pemahaman atas arsitektur sistem nyata atau threat model
  • Jejak menempel buta blok konteks besar yang tidak relevan ke prompt seperti "fix this" atau "find a bug"
  • Meminta maaf kepada compiler dalam riwayat commit
• Menurut teorema dasar sampah otomatis: karena Anda tidak membacanya, kami juga tidak akan membacanya

3. The Asymmetry of Effort - Asimetri usaha

• Maintainer proyek, tim security triage, dan moderator komunitas, baik sukarelawan tak dibayar maupun rekan internal yang kelelahan, beroperasi di bawah keterbatasan sumber daya yang ketat
• Jika catatan transaksi kiriman Anda ditinjau:
  • a. Apakah terlihat pintar pada kesan pertama? - Mungkin
  • b. Apakah benar-benar menyelesaikan masalah yang terverifikasi dan dapat direproduksi? - Tidak
  • c. Apakah berusaha membuang waktu terbatas reviewer manusia? - Ya
• Tracker proyek, forum, dan repositori bukanlah tempat sampah bagi keluaran salin-tempel tak tervalidasi untuk mengisi rumput GitHub, mengumpulkan bug bounty tanpa dasar, menggelembungkan kecepatan sprint secara artifisial, atau memenuhi KPI perusahaan secara jahat
• Rekan kerja Anda bukan layanan validasi LLM gratis

4. Resolution Protocol - Prosedur pemulihan

• Untuk memulihkan hak tulis dan mendapatkan kembali kepercayaan rekan kerja, Anda harus menjalankan prosedur berikut secara berurutan:
  • 1. Jalankan rm -rf pada branch lokal, file teks, atau skrip kerentanan halusinatif yang menghasilkan kiriman tersebut
  • 2. Lakukan hard reboot pada otak organisme Anda
  • 3. Baca codebase, dokumentasi proyek, atau threat model yang sebenarnya, lalu verifikasi secara manual status kerja dan logika Anda sendiri
  • 4. Jangan kembali sampai Anda mencapai kesadaran yang dapat diverifikasi dan siap mengetik langsung dengan jari manusia

5. Security Considerations

• Status: Ditolak
• Diagnosis: beroperasi dengan skrip Python yang ditulis buruk dan disembunyikan di dalam trench coat
• Tindakan: koneksi diputus

6. Punitive Actions - Tindakan penghukuman dan penurunan akun

• Sebagai akibat dari pengiriman AI slop, akun Anda otomatis dipindahkan ke Trough of Sorrow™ (Palung Kesedihan), dan selama masa percobaan pembatasan berikut dapat diberlakukan:
  • Izin repositori dipaksa turun dari WRITE menjadi WISHFUL_THINKING
  • Semua PR mendatang dirutekan melalui modem dial-up 14.4k baud yang terhubung ke printer dot matrix dengan pita sian yang habis permanen
  • Git alias dipetakan ulang sehingga mengetik git push -f menjalankan rm -rf / dan memutar suara trombon sedih
  • Font default IDE dikunci permanen ke Comic Sans 7pt
• Tidak dapat menghubungi administrator sistem - administrator saat ini sedang menertawakan Anda di channel Slack pribadi

7. FAQ

• "Sebenarnya ini maksudnya apa?": Singkatnya - mesin menulis kiriman Anda, dan mesin kini menolak kiriman Anda. Dalam pertukaran ini Anda sepenuhnya hanyalah perantara berbasis daging (meat-based middleman) yang tidak diperlukan
• "Kodenya berhasil dikompilasi / laporannya detail / tata bahasanya benar": Surat ancaman yang diformat rapi juga bisa begitu. Tata bahasa dan sintaks hanyalah standar minimum kontribusi, bukan batas tertinggi. Logika Anda tetaplah mimpi demam halusinatif
• "AI adalah masa depan teknologi": Jika kiriman ini mewakili masa depan, kami dengan senang hati akan mempercepat transisi kembali ke masyarakat agraris
• "Saya cuma ingin membantu": "Bantuan" Anda saat ini menyerupai serangan denial-of-service lokal yang dibungkus salam sopan. Jika benar-benar ingin membantu, arahkan energi generatif itu ke repositori yang benar-benar Anda miliki dan rawat sendiri
• "Tidak ada bukti bahwa ini ditulis AI": Ketidakmampuan manusia dibatasi oleh hukum fisika dan kemalasan. Kiriman Anda telah mencapai tingkat kegilaan percaya diri dengan tata bahasa sempurna yang hanya dapat diproduksi server farm pembakar listrik skala gigawatt
• "CI/CD lolos dan test semuanya hijau": Karena model generatif Anda telah menulis ulang test suite agar hanya menegaskan True == True
• "Kalau tunjukkan kesalahannya saya akan belajar": Tidak bisa. Maintainer bukan reverse proxy untuk loop debugging LLM Anda. Jika butuh umpan balik, tempelkan kembali stack trace ke jendela chat yang menciptakan kekacauan ini
• "Saya butuh rumput GitHub": Kami sarankan membeli marker whiteboard hijau dan menggambarnya langsung di monitor. Hasilnya memberi tingkat penghormatan profesional yang sama dari calon pemberi kerja sambil jauh lebih sedikit membuang waktu kami
• "Bukankah peran maintainer open source adalah membangun komunitas yang ramah?": Perannya adalah memelihara software. "Ramah" berlaku bagi makhluk sadar yang menyumbang pemikiran nyata, bukan botnet otonom yang melakukan regurgitasi probabilistik di issue tracker
• "Pesan ini menyinggung saya": Respons yang bagus. Silakan minta LLM menulis surat permintaan maaf empatik khusus untuk Anda. Stok simpati saat ini habis, SLA dukungan emosional adalah 99 tahun
• "Saya akan melaporkan permusuhan ini ke administrator": Sudah diprediksi; kami telah mengirim surat pengunduran diri 800 kata ke HR yang dibuat oleh LLM pilihan Anda. Kata "delve" dipakai enam kali dan memuji "paradigma sinergis" administrator
• "Ini melanggar Code of Conduct": CoC melindungi kontributor manusia. Berdasarkan analisis, Anda saat ini beroperasi sebagai selubung daging tipis yang membungkus API key OpenAI. Hak disediakan untuk entitas berbasis karbon yang mampu merasakan malu
• "Bisa ajukan banding?": Bisa. Semua banding dirutekan langsung ke /dev/null. Kami memantaunya dengan tingkat perhatian yang persis sama seperti yang Anda berikan pada kiriman Anda sendiri
• "Apakah ada cara untuk minta maaf dan memperbaikinya?": Ada. Cetak PR asli di kertas tebal, lipat menjadi bangau kertas tajam, lalu silakan makan dengan sopan. Baru setelah itu penyembuhan akan dimulai

Appendix A - Jalur eskalasi

• Pelanggaran berulang terhadap RFC 406i akan menyebabkan pencabutan total akses ke repositori, proyek, alat, dan akses lainnya
• Masuk daftar hitam alamat MAC
• Email Anda akan didaftarkan paksa ke digest harian tutorial regex yang agresif dan rumit

• Semoga hari Anda menyenangkan.

Appendix B - Makro penolakan terstandarisasi

Frasa penolakan standar yang dapat langsung disalin-tempel oleh maintainer dan reviewer:

• PR / MR:
  • PR closed. Diff Anda terbaca seperti matriks teks prediktif yang kehilangan context window-nya. Kami membutuhkan pengujian manual berbasis karbon dan kesinambungan logika yang nyata, bukan permainan tebak-tebakan otomatis. Lihat: https://406.fail
  • PR closed. Your diff reads like a predictive text matrix that lost its context window. We require manual, carbon-based testing and actual logical continuity, not automated guessing games. See: https://406.fail
• Issue / bug report:
  • Issue closed. Parameter temperature pada laporan ini disetel terlalu tinggi. Kami membutuhkan stack trace mentah yang dapat direproduksi dari pengguna yang sadar, bukan esai generatif rapi yang gagal menjelaskan bug yang dapat diverifikasi. Lihat: https://406.fail
  • Issue closed. The temperature parameter on this report is set too high. We require raw, reproducible stack traces from a sentient user, not a neatly formatted generative essay that fails to describe a verifiable bug. Protocol at: https://406.fail
• Security / bug bounty:
  • Report rejected. Memasukkan peringatan linter dasar ke LLM untuk menghasilkan narasi ancaman katastrofik bukanlah pengungkapan kerentanan yang valid. Kami tidak membayar bounty untuk kepanikan sintetis yang mahal secara komputasi. Lihat: https://406.fail
  • Report rejected. Feeding basic linter warnings into an LLM to generate a catastrophic threat narrative does not constitute a valid vulnerability disclosure. We do not pay bounties for computationally expensive, synthetic panic. Refer to: https://406.fail
• Mailing list / discussion forum:
  • Thread locked. Komunitas ini bukan sandbox reinforcement learning untuk eksperimen prompt Anda yang tidak selaras. Silakan kembali saat Anda mampu menulis pertanyaan dengan beban kognitif Anda sendiri. Lihat: https://406.fail
  • Thread locked. This community is not a reinforcement learning sandbox for your unaligned prompt experiments. Please return when you can author a question using your own cognitive load. Diagnostics: https://406.fail

[GN⁺]

Komentar Hacker News

• Jika benar-benar ingin membantu, sebaiknya curahkan energi itu ke repositori yang Anda miliki dan pelihara sendiri
  Orang-orang juga perlu belajar kebiasaan ini. Mempublikasikan fork kini makin mudah, tetapi jangan berharap orang lain akan memakai kode yang bahkan tidak Anda gunakan sendiri
  Jika melihat statistik berapa banyak proyek yang dikirimi PR per hari di GitHub, 99% mengirim ke satu proyek, 1% ke dua proyek, dan 0,1% ke tiga proyek. Akun yang mengirim PR ke 5 proyek atau lebih hampir semuanya adalah bot atau skrip. Bot yang tidak terdaftar perlu diberi rate limit

  • Dalam situasi seperti ini, akan bagus jika ada fitur semacam mode patch permanen di mana fork saya direbase secara berkala di atas repositori asal. Misalnya, bahkan perbaikan satu baris pun bisa terus diperbarui otomatis ke versi terbaru

• Saya lebih menyukai kebijakan AI Ghostty
  Saya sangat suka kalimat, “Jika Anda tidak bisa menjelaskan apa yang dilakukan perubahan tersebut dan apa dampaknya terhadap keseluruhan sistem tanpa bantuan AI, jangan berkontribusi ke proyek ini”

  • Ini ide yang bagus, tetapi masalahnya ada pada cara penerapannya. Seseorang bisa saja meminta AI membuat penjelasan lalu menuliskannya ulang dengan kata-katanya sendiri, yang pada praktiknya menjadi bentuk pengelakan

• Masalahnya, kontribusi open source sudah menjadi semacam ritus peralihan
  Ketika yang penting bukan kontribusi nyata melainkan sekadar fakta bahwa seseorang “pernah berkontribusi”, muncullah PR dangkal seperti ini. Dulu laporan kerentanan juga mirip — laporan setingkat “kalau memasukkan null, akan muncul NullPointerException”
  Terlalu menekankan metrik yang keliru seperti kecepatan pengembangan juga jadi masalah. Saya pernah melihat PR rekan kerja yang membanggakan pengembangan cepat dengan AI di perusahaan lama, ternyata semua test gagal. Pada akhirnya ini adalah fenomena gamifikasi bantuan AI

  • Saya juga belakangan menerima banyak lamaran kerja yang ditulis AI. Sebagian menonjolkan kontribusi GitHub. Mungkin PR seperti ini memang kadang lolos. Budaya menjadikan jumlah bintang proyek sebagai metrik rekrutmen ikut mendorong spam semacam ini
  • Rasanya seperti, “Saya bisa berhitung sangat cepat” → “Kalau begitu 137*243 berapa?” → “132,498” → “Salah” → “Tapi cepat, kan?”

• Ini cuma tulisan blog iseng. Orang-orang yang mengirim PR buruk dengan AI bahkan tidak akan membaca tulisan seperti ini
  Cara saya sederhana:

  1. Tutup PR
  2. Jika terlalu asal-asalan, blokir penggunanya
     Baru-baru ini bahkan ada PR yang membuat seluruh CI gagal hanya karena memakai ‘’ alih-alih ''. Langsung saya blokir
  • Saat menutup PR, sepertinya bagus jika menambahkan tautan halaman ini di komentar

• Jika itu bug, seharusnya ada baris merah (diff) yang menunjukkan perbaikannya, dan jika itu fitur, setidaknya perlu ada kriteria penerimaan
  Untuk dokumentasi, cukup jika bisa dibaca dan dipahami. Ambang untuk dianggap membantu sebenarnya cukup rendah

• Menanggapi pertanyaan “Bukankah maintainer open source harus membangun komunitas yang ramah?”, itu bukan kewajiban
  Maintainer adalah pemilik proyek, dan tidak harus bersikap ramah. Jika tidak suka, fork saja atau pergi

  • Menurut saya klaim seperti itu sebenarnya lebih mirip manipulasi emosional. Lebih baik bilang, “Jangan buang waktu kami secara emosional, pahami kenapa PR buatan LLM tidak berguna.” Kami juga tahu cara memakai LLM, dan kami tahu betapa besarnya beban kerja nyata setelah itu

• Sangat melegakan. Saya berharap tulisan seperti ini dipakai luas untuk membuat pengirim PR yang asal-asalan merasa malu. Nada FAQ yang lugas dan kasar justru terasa menyegarkan

  • Tapi orang-orang seperti itu tidak merasa malu. Sama seperti memarahi penipu lewat telepon — mereka tinggal menutup sambungan dan mencoba lagi

• Ini kejadian di kantor. Saya membuat kode dengan AI untuk menangani permintaan fitur kecil, tetapi karena tidak terlalu paham codebase-nya, saya tidak yakin dengan keakuratannya
  Prompt 1 menit, perapian 5 menit, dan review 30 menit mungkin bisa menghemat 2 hari waktu engineering, tetapi pada akhirnya masalahnya adalah kepercayaan
  Setelah mendengar berbagai pendapat, saya memutuskan untuk hanya mengajukan permintaan fitur tanpa menyertakan diff.
  Menariknya, pihak yang pro-AI menyarankan agar saya “lebih banyak memakai AI untuk meningkatkan kepercayaan diri”, tetapi justru setelah terus diperbaiki, kodenya makin kusut dan saya kehilangan kepercayaan sepenuhnya

  • Jika benar-benar ingin memakai kode buatan LLM, sebaiknya pahami semua perubahannya, lalu rangkum sendiri dan lampirkan pada permintaan fitur
    Saya juga sudah beberapa kali menerima PR buatan LLM, tetapi tidak bisa diajak berdiskusi, dan kodenya mengabaikan pola yang sudah ada sehingga akhirnya harus dibuang.
    Kalau itu manusia, saya ingin dia menjelaskan masalahnya dari sudut pandangnya sendiri. Itu jauh lebih membantu
  • Anda punya insting engineering yang bagus. Andai lebih banyak orang di industri ini seperti itu
  • Saya tidak paham dengan ungkapan “menghemat 2 hari waktu engineering”. Orang yang paham codebase juga bisa memakai AI yang sama. Saya tidak mengerti kenapa output AI ingin divalidasi oleh orang lain. Kami juga tahu cara memakai LLM
    Tulisan terkait: artikel tentang Prompting
  • Saya juga memakai pendekatan serupa. Saat saya tidak sepenuhnya memahami kode yang dibuat Claude, saya mengajukan pertanyaan seperti, “Kenapa bagian ini dibuat begini?” “Bagaimana edge case ditangani?” lalu meminta agar jangan mengubah apa pun, cukup jelaskan saja. Dengan begitu, hasilnya bisa benar-benar menjadi milik saya
  • Jika Anda benar-benar menggunakan library itu, sebaiknya uji di lingkungan staging lalu kirimkan review

• Saya sangat suka ungkapan plonk di bagian akhir
  Lihat Plonk(Usenet)

  • Kalau itu BOFH Task Force, saya kira mereka tentu bisa melakukan setidaknya sebanyak itu

• Kalimat “hapus local branch atau skrip omong kosong dengan rm -rf” sangat lucu
  Ungkapan “hard reboot otak organik” juga sempurna

  • Sebenarnya rasanya LLM sudah lebih dulu me-rm -rf otak para penulis PR seperti itu