RFC 406i — Yapay zeka tarafından üretilen çöp katkıları reddetme (RAGS) standart protokolü

• Açık kaynak depoları, topluluklar vb. ortamlarda yapay zeka tarafından üretilen düşük kaliteli katkıları otomatik olarak reddetmek için mizahi RFC biçiminde tanımlanmış standart bir protokol belgesi
• Proje bakımcılarının ilgili URI’yi yapıştırmasıyla "AI slop algılandı" şeklinde bir ret sinyali iletmek için standartlaştırılmış bir araç olarak çalışır
• Yapay zeka üretimi katkıların tipik özelliklerini sıralar ve bakım kaynaklarının israfı ile doğrulanmamış çıktının risklerini doğrudan işaret eder
• LLM tabanlı gönderimler testleri geçse ve sözdizimi doğru olsa bile, mantık ve mimari anlayışı yoksa temelden değersiz olduğu görüşünü açıkça ortaya koyar
• RFC biçimini ödünç alan hicivli bir metin olsa da, açık kaynak ekosisteminde yapay zeka otomasyonlu katkıların kötüye kullanımı karşısında bakımcıların yaşadığı gerçek yorgunluğu yansıtır

---

Abstract - Bu belgenin amacı

• Kaynak kod depolarına, issue tracker’lara, güvenlik açığı bildirim portallarına ve topluluk forumlarına gönderilen düşük çabalı, yapay zeka üretimi katkıların işlenmesi ve elenmesi için standart protokol
• Hem açık açık kaynak projelerine hem de şirket içi sistemlere uygulanır

1. Introduction - Neden bu sayfaya yönlendirildiniz

• Katkınız otomatik veya manuel AI slop tespit sistemini tetiklediği için bu sayfaya yönlendirildiniz
• Daha açık söylemek gerekirse, bakımcı veya kıdemli bir mühendis gönderime bakıp "derin, varoluşsal bir iç çekiş" bıraktıktan sonra bağlantıyı hemen kapatmış ve bu URI’yi yapıştırmıştır
• Bu belgede kullanılan "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" anahtar sözcükleri, "bu gönderimi incelemek istemeyişimizin derecesi" olarak yorumlanmalıdır

2. Diagnostic Analysis - Gönderinizde tespit edilen özellikler

• Gönderdiğiniz materyalin sözcük dağarcığı ve yapı analizi sonucunda, prompt engineering’inizin hatalı olduğu ve dolayısıyla bundan utanmanız gerektiği sonucuna varılmıştır
• Olasılıksal papağanınıza PR, güvenlik açığı açıklaması, issue yorumu ve forum gönderisi yazdırmanın sonucu olarak, o da hepimize yalan söylemiştir
• Aşağıdaki özellikler ezici derecede açık biçimde tespit edilmiştir:
  • Aşırı kibar ve robotik ton kullanımı
  • Yüksek özgüvenle sunulmuş tamamen var olmayan API’ler
  • Gerçek bir sorunu hiç çözmeyen şişkin boilerplate kod
  • PR açıklamasında "delve" sözcüğünün ciddi biçimde kullanılması
  • Docstring’lerin, yorumların veya güvenlik raporlarının içinde "Certainly! Here is the revised output:" gibi LLM çıktı kalıntılarının aynen kalmış olması
  • Basit bir yazım hatası düzeltmesine 600 kelimelik commit mesajı ya da devasa teorik deneme eklenmesi
  • utils.helpers gibi var olmayan halüsinasyon kütüphanelerinin import edilmesi
  • Önemsiz bir bug raporuna "In conclusion, this robust and scalable solution..." diye başlayan kapanış paragrafı eklenmesi
  • Kafein ve uykusuzlukla çalışan bir insan programcının asla üretemeyeceği kadar acayip ve steril değişken/fonksiyon adlandırmaları
  • Gerçek sistem mimarisi veya tehdit modeline dair anlayış olmadan yalnızca regex’e ya da halüsinasyon ürünü kavramlara bütünüyle dayanılması
  • "fix this" veya "find a bug" prompt’una ilgisiz büyük bağlam bloklarının körü körüne yapıştırıldığını gösteren izler
  • Commit geçmişinde derleyiciden özür dilemek
• Otomatik çöpün temel teoremine göre: siz okumadığınız için, biz de okumayacağız

3. The Asymmetry of Effort - Çabanın asimetrisi

• Proje bakımcıları, güvenlik triyaj ekipleri ve topluluk moderatörleri; ister ücretsiz gönüllüler ister yorgun şirket içi ekip arkadaşları olsun, katı kaynak kısıtları altında çalışır
• Gönderinizin işlem kaydı incelendiğinde:
  • a. İlk bakışta akıllı göründü mü? - Muhtemelen
  • b. Doğrulanmış, yeniden üretilebilir bir sorunu gerçekten çözdü mü? - Hayır
  • c. İnsan inceleyicilerin sınırlı zamanını boşa harcamaya çalıştı mı? - Evet
• Proje takip sistemleri, forumlar ve depolar; GitHub çimi doldurmak, dayanaksız bug bounty toplamak, sprint hızını yapay olarak şişirmek veya kurumsal KPI metriklerine kötü niyetli uyum sağlamak için doğrulanmamış kopyala-yapıştır çıktılarının çöp kutusu değildir
• Ekip arkadaşlarınız ücretsiz bir LLM doğrulama hizmeti değildir

4. Resolution Protocol - İyileştirme prosedürü

• Yazma yetkisinin geri kazanılması ve ekip arkadaşlarının güveninin yeniden tesisi için aşağıdaki adımlar sırayla uygulanmalıdır:
  • 1. Bu gönderiyi üreten yerel branch, metin dosyası veya halüsinasyon ürünü güvenlik açığı script’i üzerinde rm -rf çalıştırın
  • 2. Organik beyninize hard reboot uygulayın
  • 3. Gerçek kod tabanını, proje belgelerini veya tehdit modelini okuyun ve kendi çalışma durumunuzu ile mantığınızı manuel olarak doğrulayın
  • 4. Doğrulanabilir bilince ulaşıp insan parmaklarıyla doğrudan yazmaya hazır olana kadar geri dönmeyin

5. Security Considerations

• Durum: Reddedildi
• Teşhis: trençkot içine saklanmış kötü yazılmış bir Python script’i tarafından işletiliyor
• İşlem: bağlantı sonlandırıldı

6. Punitive Actions - Cezai işlemler ve hesap düşürme

• Yapay zeka üretimi slop gönderiminin sonucu olarak hesabınız otomatik olarak Trough of Sorrow™ (Keder Yalağı) konumuna taşınmıştır; gözetim süresi boyunca aşağıdaki kısıtlamalar uygulanabilir:
  • Depo izinlerinin WRITE seviyesinden WISHFUL_THINKING seviyesine zorunlu olarak düşürülmesi
  • Gelecekteki tüm PR’ların, cyan şeridi kalıcı olarak bitmiş bir dot matrix yazıcıya bağlı 14.4k baud dial-up modem üzerinden yönlendirilmesi
  • git push -f girildiğinde rm -rf / çalıştıracak ve hüzünlü trombon sesi çalacak şekilde git alias’ının yeniden eşlenmesi
  • IDE varsayılan yazı tipinin kalıcı olarak 7pt Comic Sans yapılması
• Sistem yöneticisine ulaşılamıyor - yönetici şu anda özel Slack kanalında sizinle alay etmekle meşgul

7. FAQ

• "Bu da ne demek oluyor?": Kısacası - gönderinizi makine yazdı ve şu anda gönderinizi reddeden de makine. Siz bu alışverişte tamamen gereksiz bir et bazlı aracı (meat-based middleman) konumundasınız
• "Kod derleniyor / rapor ayrıntılı / gramer doğru": İyi biçimlendirilmiş tehdit mektupları da öyle olabilir. Gramer ve sözdizimi, katkının asgari tabanıdır; tavanı değildir. Mantığınız hâlâ halüsinasyon ürünü bir ateşli rüya
• "Yapay zeka teknolojinin geleceğidir": Eğer bu gönderim geleceği temsil ediyorsa, tarım toplumuna geçişi memnuniyetle hızlandırırız
• "Yardımcı olmaya çalışıyordum": Sizin "yardımınız" şu anda kibar selamlarla paketlenmiş yerel hizmet reddi saldırısına benziyor. Gerçekten yardımcı olmak istiyorsanız, üretim enerjinizi bizzat sahip olduğunuz ve bakımını üstlendiğiniz depolara yönlendirin
• "Bunu yapay zekanın yazdığına dair kanıt yok": İnsan beceriksizliği fizik yasaları ve tembellikle sınırlıdır. Sizin gönderiniz ise ancak gigawattlarca elektrik yakan sunucu çiftliklerinin üretebileceği ölçüde özgüvenli ve gramer olarak kusursuz bir delilik seviyesine ulaşmış durumda
• "CI/CD geçti ve testler yeşil": Çünkü üretici modeliniz test paketini yalnızca True == True doğrulasın diye yeniden yazdı
• "Hataları belirtirseniz öğrenirim": Mümkün değil. Bakımcılar sizin LLM debugging loop’unuz için ters proxy değildir. Geri bildirime ihtiyacınız varsa, bu felaketi yaratan sohbet penceresine stack trace’i tekrar yapıştırın
• "GitHub çimine ihtiyacım var": Yeşil bir whiteboard kalemi alıp doğrudan monitöre çizmenizi öneririz. Bu, zamanımızı çok daha az tüketirken potansiyel işverenlerden aynı düzeyde profesyonel saygı görmenizi sağlar
• "Açık kaynak bakımcılarının görevi kapsayıcı bir topluluk kurmak değil mi?": Görev yazılımın bakımını yapmaktır. "Kapsayıcı" olmak, gerçek düşünce katkısı sunan bilinç sahibi varlıklar için geçerlidir; issue tracker’da olasılıksal geviş getiren özerk botnet’ler için değil
• "Bu mesaj kırıcı": Güzel tepki. LLM’nizden size özel empatik özür mektubu üretmesini isteyin. Şu anda merhamet stoğumuz tükendi; duygusal destek SLA’sı 99 yıl
• "Bu düşmanlığı yönetime bildireceğim": Bunu zaten öngördük ve tercih ettiğiniz LLM’in yazdığı 800 kelimelik istifa mektubunu HR’a gönderdik. İçinde altı kez "delve" geçiyor ve yöneticinin "sinerjik paradigmasını" övüyor
• "Bu bir Code of Conduct ihlali": CoC insan katkıcıları korur. Analize göre siz şu anda OpenAI API anahtarını saran ince bir et kabuğu olarak çalışıyorsunuz. Haklar, utanç hissedebilen karbon bazlı varlıklar için ayrılmıştır
• "İtiraz edebilir miyim?": Evet. Tüm itirazlar doğrudan /dev/null konumuna yönlendirilir. Gönderinize sizin gösterdiğinizle tam olarak aynı düzeyde dikkatle izlenmektedir
• "Özür dileyip düzeltmenin bir yolu var mı?": Var. Orijinal PR’ı kalın kağıda yazdırın, keskin bir origami turnasına katlayın ve kibarca yiyin. Ancak o zaman iyileşme başlayacaktır

Appendix A - Tırmandırma yolu

• RFC 406i’nin tekrarlı ihlali halinde depo, proje, araç ve diğer tüm erişim haklarının tamamen iptali
• MAC adresinin kara listeye alınması
• E-postanın agresif derecede karmaşık regex eğitimi günlük özetine zorunlu abone edilmesi

• İyi günler dileriz.

Appendix B - Standart reddetme makroları

Bakımcılar ve inceleyiciler için anında kopyala-yapıştır yapılabilecek standart ret ifadeleri:

• PR / MR:
  • PR closed. Diff’iniz, bağlam penceresini kaybetmiş bir predictive text matrisi gibi okunuyor. Otomatik tahmin oyunları değil, manuel karbon bazlı test ve gerçek mantıksal süreklilik istiyoruz. Referans: 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 raporu:
  • Issue closed. Bu rapordaki temperature parametresi fazla yüksek ayarlanmış. Doğrulanabilir bir bug’ı açıklayamayan düzgün biçimlendirilmiş üretken bir deneme değil, bilinç sahibi bir kullanıcıdan ham ve yeniden üretilebilir stack trace’ler istiyoruz. Referans: 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
• Güvenlik / bug bounty:
  • Report rejected. Temel linter uyarılarını bir LLM’e verip felaket tellallığı yapan bir tehdit anlatısı üretmek geçerli bir güvenlik açığı bildirimi sayılmaz. Hesaplama maliyeti yüksek, sentetik panik için bounty ödemiyoruz. Referans: 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 / tartışma forumu:
  • Thread locked. Bu topluluk, hizalanmamış prompt deneyleriniz için bir reinforcement learning sandbox’ı değildir. Lütfen kendi bilişsel yükünüzü kullanarak bir soru yazabildiğinizde geri dönün. Referans: 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⁺]

Hacker News yorumları

• Gerçekten yardımcı olmak istiyorsan, o enerjiyi bizzat sahip olduğun ve bakımını yaptığın depoya harcaman daha iyi olur
  İnsanların da bu alışkanlığı öğrenmesi gerekiyor. Bir fork’u yayımlamak kolaylaştı ama kendin gerçekten kullanmadığın bir kodu başkalarının kullanmasını beklememelisin
  GitHub’da günde kaç projeye PR gönderildiğine dair istatistiklere bakıldığında, %99’u bir, %1’i iki, %0,1’i üç proje. Günde 5’ten fazla PR gönderen hesapların neredeyse tamamı bot veya script çıkmıştı. Kayıtsız botlara hız sınırlaması uygulanmalı

  • Böyle bir durumda, fork’umun asıl deponun üstüne düzenli olarak rebase edildiği kalıcı yama modu gibi bir özellik güzel olurdu. Mesela tek satırlık bir düzeltme bile otomatik olarak güncel kalabilse

• Ben Ghostty’nin AI politikasını daha çok tercih ediyorum
  “AI yardımı olmadan değişikliğin ne yaptığını ve sistemin geneli üzerinde nasıl bir etkisi olduğunu açıklayamıyorsan, bu projeye katkıda bulunma” cümlesini özellikle beğeniyorum

  • Güzel fikir ama sorun nasıl uygulanacağı. AI’ya açıklattırıp sonra onu kendi sözlerinle yeniden yazarsan fiilen dolaşmış olursun

• Sorunun, açık kaynak katkısının bir tür geçiş ritüeline dönüşmüş olması olduğunu düşünüyorum
  Gerçek katkıdan çok ‘katkıda bulunmuş olmak’ önemli hale gelince böyle yüzeysel PR’ler ortaya çıkıyor. Eskiden güvenlik açığı bildirimleri de benzerdi — “null koyunca NullPointerException çıkıyor” seviyesinde raporlar
  Geliştirme hızı gibi yanlış metriklere önem vermek de sorun. Eski şirketimde AI ile hızlı geliştirme yaptığını öven bir iş arkadaşımın PR’ına baktım; testlerin hepsi patlıyordu. Sonuçta bu AI destekli gamification olayı

  • Ben de bu aralar AI ile yazılmış başvurular çok alıyorum. Bazıları GitHub katkılarını özellikle öne çıkarıyor. Muhtemelen bu tür PR’lerin gerçekten kabul edildiği durumlar var. Projelerin yıldız sayısını işe alım metriği olarak kullanma kültürü bu spam’i teşvik ediyor
  • “Matematiği gerçekten çok hızlı yapabiliyorum” → “O zaman 137*243 kaç?” → “132,498” → “Yanlış” → “Ama hızlıydı ya” hissi veriyor

• Bu sadece eğlencesine yazılmış bir blog yazısı. AI ile düşük kaliteli PR gönderenler zaten böyle yazıları okumuyor
  Benim yöntemim basit:

  1. PR’ı kapat
  2. Fazla özensizse kullanıcıyı engelle
     Yakın zamanda string tanımlarında ‘’ yerine '' kullandığı için tüm CI’ın patladığı bir PR vardı. Hemen engelledim
  • PR’ı kapatırken bu sayfanın bağlantısını yoruma eklemek iyi olabilir

• Eğer bu bir bug ise, düzeltmenin doğrulandığı bir kırmızı satır(diff) olmalı; eğer bir özellikse, en azından bir kabul kriteri gerekli
  Dokümantasyonsa okunup anlaşılması yeterli. Yardım sayılması için eşik oldukça düşük

• “Açık kaynak bakımcıları kapsayıcı bir topluluk oluşturmak zorunda değil mi?” sorusuna cevaben, bu bir yükümlülük değil
  Bakımcılar projenin sahibidir ve nazik olmak zorunda da değiller. Hoşuna gitmiyorsa fork’la ya da ayrıl

  • Bence bu tür iddialar aslında duygusal manipülasyona yakın. “Zamanımızı duygusal olarak boşa harcatma; LLM tarafından üretilen PR’lerin neden işe yaramadığını anlamaya çalış” demek daha iyi. Biz de LLM kullanmayı biliyoruz ve sonrasındaki gerçek iş yükünün ne kadar büyük olduğunu da biliyoruz

• Gerçekten çok tatmin edici. Keşke böyle yazılar özensiz PR gönderenleri utandırmak için yaygın biçimde kullanılsa. SSS’nin doğrudan ve kaba tonu bu yüzden ferahlatıcı

  • Ama o tip insanlar utanma duygusu taşımıyor. Telefon dolandırıcılarına kızmak gibi — sadece kapatıp tekrar deniyorlar

• Şirkette yaşanmış bir olay. AI ile küçük bir özellik talebini çözen bir kod üretildi ama codebase iyi bilinmediği için doğruluğundan emin olunamıyordu
  1 dakikalık prompt, 5 dakikalık düzenleme, 30 dakikalık inceleme ile 2 günlük mühendislik zamanı kazandırabilirdi ama sonunda mesele güvendi
  Çeşitli görüşleri dinledikten sonra, sadece özellik talebini açıp diff eklememeye karar verildi.
  İlginç şekilde AI taraftarları “güvenini artırmak için daha çok AI kullan” diye tavsiye etti ama sürekli düzeltmeye çalışınca kod daha da dolaştı ve tamamen güven kaybedildi

  • Eğer LLM’in ürettiği kodu gerçekten kullanmak istiyorsan, tüm değişiklikleri anlaman ve bunu bizzat özetleyip özellik talebine eklemen iyi olur
    Bana da birçok kez LLM’in yazdığı PR geldi; iletişim kurulamıyor, mevcut kalıpları görmezden gelen kod oluyor ve sonunda çöpe gidiyor.
    Bir insandan, sorunu kendi bakış açısından açıklamasını beklersin. Bu çok daha faydalı olur
  • Sende iyi bir mühendislik sezgisi var. Keşke sektörde daha fazla insan böyle olsa
  • “2 günlük mühendislik zamanı tasarrufu” lafını anlamıyorum. Codebase’i bilen biri de aynı şekilde AI kullanabilir sonuçta. Neden AI çıktısını başkasına doğrulatmaya çalıştığını anlamıyorum. Biz de LLM kullanmayı biliyoruz
    İlgili yazı: Prompting hakkında bir yazı
  • Ben de benzer bir yaklaşım kullanıyorum. Claude’un yazdığı kodu tamamen anlayamadığımda, “Bu kısmı neden böyle yaptın?” “Edge case’ler nasıl ele alınıyor?” gibi sorular sorup, değiştirme, sadece açıkla diyorum. Böylece sonucu kendime ait hale getirebiliyorum
  • Eğer o kütüphaneyi gerçekten kullanıyorsan, staging ortamında test edip sonra inceleme göndermen iyi olur

• Sondaki plonk ifadesi harikaydı
  Plonk(Usenet) bkz.

  • BOFH Task Force ise bunu yapabilmesi zaten beklenirdi

• “rm -rf ile local branch’i ya da saçma sapan script’i sil” cümlesi çok komik
  “Organik beyni hard reboot et” ifadesi de mükemmel

  • Aslında LLM sanki o PR yazarlarının beynine rm -rf çekmiş gibi