RFC 406i — AI द्वारा बनाए गए कचरा योगदानों की अस्वीकृति (RAGS) मानक प्रोटोकॉल

 (406.fail)
10 पॉइंट द्वारा GN⁺ 2026-03-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ओपन सोर्स repository, community आदि में AI द्वारा बनाए गए निम्न-गुणवत्ता वाले योगदानों को स्वतः अस्वीकार करने के लिए एक मानक प्रोटोकॉल को व्यंग्यात्मक RFC प्रारूप में परिभाषित करने वाला दस्तावेज़
  • यह project maintainer के लिए संबंधित URI को केवल paste करने भर से "AI slop detection" अस्वीकृति संकेत भेजने के एक मानकीकृत माध्यम की तरह काम करता है
  • AI-निर्मित योगदानों की विशिष्ट विशेषताओं की सूची देते हुए, maintenance resources की बर्बादी और अप्रमाणित output के ख़तरों की सीधे ओर इशारा करता है
  • यह स्पष्ट रूप से कहता है कि भले ही LLM-आधारित submissions test pass कर जाएँ और grammar सही हो, अगर उनमें logic और architecture की समझ नहीं है, तो वे मूल रूप से निरर्थक हैं
  • RFC प्रारूप उधार लेने वाला यह व्यंग्य दस्तावेज़, ओपन सोर्स ecosystem में AI automation आधारित contribution abuse को लेकर maintainers की वास्तविक थकान को दर्शाता है

Abstract - इस दस्तावेज़ का उद्देश्य

  • source code repository, issue tracker, vulnerability reporting portal, और community forum में जमा किए जाने वाले कम-प्रयास, AI-निर्मित योगदानों के निपटान और परित्याग के लिए मानक प्रोटोकॉल
  • यह सार्वजनिक ओपन सोर्स projects और आंतरिक corporate systems, दोनों पर लागू होता है

1. Introduction - आपको इस पेज पर क्यों भेजा गया

  • आपको इस पेज पर इसलिए भेजा गया है क्योंकि आपके contribution ने automated या manual AI slop detection system को trigger किया है
  • विशेष रूप से, किसी maintainer या senior engineer ने आपकी submission देखी, एक "गहरी अस्तित्वगत आह" भरी, तुरंत connection बंद किया, और यह URI paste कर दिया
  • इस दस्तावेज़ में प्रयुक्त "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" keywords की व्याख्या "हम इस submission की समीक्षा कितनी नहीं करना चाहते" के पैमाने के रूप में की जानी चाहिए

2. Diagnostic Analysis - आपकी submission में पहचानी गई विशेषताएँ

  • आपकी जमा सामग्री के शब्द-विन्यास और संरचना के विश्लेषण के परिणामस्वरूप यह निष्कर्ष निकला कि आपकी prompt engineering गलत थी, और इसलिए आपको स्वयं पर शर्म आनी चाहिए
  • किसी stochastic parrot से PR, vulnerability disclosure, issue comment, या forum post लिखवाने का परिणाम यह हुआ कि उसने हम सब से झूठ बोला
  • निम्नलिखित लक्षण अत्यधिक स्पष्ट रूप से पहचाने गए हैं:
    • अत्यधिक विनम्र और रोबोट जैसी भाषा का उपयोग
    • पूरे आत्मविश्वास के साथ प्रस्तुत की गई पूरी तरह काल्पनिक APIs
    • फूला हुआ boilerplate code जो किसी वास्तविक समस्या को हल नहीं करता
    • PR विवरण में "delve" का गंभीरता से उपयोग
    • docstring, comment, या security report के अंदर "Certainly! Here is the revised output:" जैसे LLM output के अवशेष ज्यों-के-त्यों छोड़े गए हैं
    • साधारण typo fix के साथ 600-शब्दों का commit message या विशाल सैद्धांतिक निबंध संलग्न
    • utils.helpers जैसी अस्तित्वहीन hallucinated library का import
    • मामूली bug report में "In conclusion, this robust and scalable solution..." से शुरू होने वाला समापन पैराग्राफ जोड़ना
    • असामान्य और निष्फल variable एवं function naming जिसे caffeine और नींद की कमी पर चलने वाला कोई इंसानी programmer कभी हासिल नहीं कर सकता
    • वास्तविक system architecture या threat model की समझ के बिना केवल regex या hallucinated concepts पर पूरी निर्भरता
    • "fix this" या "find a bug" prompt के साथ असंबंधित बड़े context block को अंधाधुंध paste करने के संकेत
    • commit history में compiler से माफ़ी माँगना
  • automated garbage के मूल प्रमेय के अनुसार: आपने इसे नहीं पढ़ा, इसलिए हम भी नहीं पढ़ेंगे

3. The Asymmetry of Effort - प्रयास की विषमता

  • project maintainer, security triage team, और community moderator—चाहे वे अवैतनिक स्वयंसेवक हों या थके हुए आंतरिक सहकर्मी—कड़े resource constraints के तहत काम करते हैं
  • आपके submission transaction record की समीक्षा करने पर:
    • a. क्या यह पहली नज़र में स्मार्ट लगा? - शायद
    • b. क्या इसने वास्तव में किसी सत्यापित और पुनरुत्पादित की जा सकने वाली समस्या का समाधान किया? - नहीं
    • c. क्या इसने मानव reviewer के सीमित समय की बर्बादी की? - हाँ
  • project tracker, forum, और repository, GitHub grass भरने, निराधार bug bounty इकट्ठा करने, sprint velocity को कृत्रिम रूप से बढ़ाने, या corporate KPI metrics का दुर्भावनापूर्ण पालन करने के लिए अप्रमाणित copy-paste output का कूड़ादान नहीं हैं
  • आपके सहकर्मी मुफ़्त LLM validation service नहीं हैं

4. Resolution Protocol - सुधार प्रक्रिया

  • write permission की बहाली और साथियों का भरोसा वापस पाने के लिए आपको नीचे दी गई प्रक्रिया क्रम से पूरी करनी होगी:
    • 1. उस local branch, text file, या hallucinated vulnerability script पर rm -rf चलाएँ जिसने यह submission पैदा की
    • 2. जैविक मस्तिष्क का hard reboot करें
    • 3. वास्तविक codebase, project documentation, या threat model पढ़ें और अपनी कार्य-स्थिति तथा तर्क को हाथ से सत्यापित करें
    • 4. सत्यापन योग्य चेतना प्राप्त होने और मानवीय उँगलियों से सीधे typing करने के लिए तैयार होने तक वापस न आएँ

5. Security Considerations

  • स्थिति: अस्वीकृत
  • निदान: trenchcoat के अंदर छिपी एक भद्दे ढंग से लिखी Python script से संचालित
  • कार्रवाई: connection समाप्त

6. Punitive Actions - दंडात्मक कार्रवाई और account downgrade

  • AI-निर्मित slop submission के परिणामस्वरूप आपका account स्वतः Trough of Sorrow™ (शोक की नांद) में स्थानांतरित कर दिया गया है, और probation अवधि के दौरान निम्नलिखित प्रतिबंध लागू हो सकते हैं:
    • repository permission को WRITE से ज़बरदस्ती WISHFUL_THINKING में downgrade किया जाएगा
    • भविष्य के सभी PR एक 14.4k baud dial-up modem के माध्यम से route किए जाएँगे, जो ऐसी dot matrix printer से जुड़ा होगा जिसकी cyan ribbon स्थायी रूप से खत्म हो चुकी है
    • git push -f टाइप करने पर rm -rf / चलाने और उदास trombone sound बजाने के लिए git alias remap किया जाएगा
    • IDE का default font स्थायी रूप से 7pt Comic Sans पर सेट कर दिया जाएगा
  • system administrator से संपर्क संभव नहीं है — administrator इस समय private Slack channel में आपका मज़ाक उड़ा रहा है

7. FAQ

  • "आख़िर यह सब क्या है?": संक्षेप में — मशीन ने आपकी submission लिखी, और मशीन ही इस समय आपकी submission को अस्वीकार कर रही है। इस पूरे आदान-प्रदान में आप पूरी तरह अनावश्यक meat-based middleman हैं
  • "Code compile होता है / report विस्तृत है / grammar सही है": अच्छी formatting वाला धमकी-पत्र भी ऐसा हो सकता है। grammar और syntax किसी contribution के न्यूनतम मानक हैं, उसकी अंतिम सीमा नहीं। आपका logic अब भी एक hallucinated fever dream ही है
  • "AI तकनीक का भविष्य है": अगर यह submission भविष्य का प्रतिनिधित्व करती है, तो हम कृषि समाज की ओर वापसी को ख़ुशी-ख़ुशी तेज़ कर देंगे
  • "मैं मदद करना चाहता था": आपकी "मदद" फिलहाल विनम्र अभिवादन में लिपटे local denial of service attack जैसी लगती है। अगर आप सचमुच मदद करना चाहते हैं, तो अपनी generative energy ऐसे repository की ओर मोड़ें जिसका स्वामित्व और maintenance आप स्वयं करते हों
  • "यह साबित नहीं होता कि इसे AI ने लिखा है": मानवीय अयोग्यता पर भौतिकी के नियमों और आलस्य की सीमाएँ लागू होती हैं। आपकी submission ने आत्मविश्वासी, व्याकरणिक रूप से परिपूर्ण पागलपन का वह स्तर हासिल कर लिया है जिसे केवल gigawatt बिजली जलाने वाला server farm ही पैदा कर सकता है
  • "CI/CD pass हो गया और tests हरे हैं": क्योंकि आपके generative model ने test suite को फिर से लिख दिया ताकि वह केवल True == True assert करे
  • "अगर आप गलती बताएँगे तो मैं सीख लूँगा": नहीं। maintainer आपके LLM debugging loop के लिए reverse proxy नहीं हैं। अगर feedback चाहिए, तो उस chat window में stack trace फिर से paste करें जिसने यह आपदा पैदा की
  • "मुझे GitHub grass चाहिए": सुझाव है कि एक हरा whiteboard marker खरीदें और सीधे monitor पर ही रेखाएँ खींच लें। इससे हमारा समय बहुत कम बर्बाद होगा और संभावित employers से आपको लगभग वही पेशेवर सम्मान मिल जाएगा
  • "क्या open source maintainer की भूमिका एक welcoming community बनाना नहीं है?": भूमिका software का maintenance करना है। "welcoming" उन सचेत प्राणियों पर लागू होता है जो वास्तविक सोच का योगदान देते हैं, न कि issue tracker में stochastic जुगाली करने वाले autonomous botnet पर
  • "यह संदेश अपमानजनक है": अच्छा है। अपने LLM से आपके लिए एक custom empathetic apology letter बनाने को कहें। फिलहाल sympathy stock समाप्त है, emotional support SLA 99 वर्ष है
  • "मैं इस शत्रुता की शिकायत administrator से करूँगा": इसका पूर्वानुमान पहले ही लगा लिया गया था, इसलिए आपके पसंदीदा LLM द्वारा तैयार 800-शब्दों का resignation letter HR को भेज दिया गया है। उसमें "delve" का छह बार उपयोग हुआ है और administrator के "synergistic paradigm" की प्रशंसा भी की गई है
  • "यह Code of Conduct का उल्लंघन है": CoC मानव contributors की रक्षा करता है। विश्लेषण के अनुसार, आप इस समय OpenAI API key के चारों ओर लिपटा एक पतला मांसल खोल बनकर काम कर रहे हैं। अधिकार उन carbon-based प्राणियों के लिए सुरक्षित हैं जो शर्म महसूस कर सकते हैं
  • "क्या मैं appeal कर सकता हूँ?": हाँ। सभी appeals सीधे /dev/null पर route की जाती हैं। उन पर ठीक उतने ही स्तर का ध्यान दिया जाता है जितना आपने अपनी submission पर दिया था
  • "क्या माफ़ी माँगने और सुधार करने का कोई तरीका है?": है। मूल PR को मोटे कागज़ पर print करें, उसे एक नुकीले paper crane में मोड़ें, और विनम्रतापूर्वक खा जाएँ। तभी उपचार वास्तव में शुरू होगा

Appendix A - Escalation Path

  • RFC 406i के बार-बार उल्लंघन पर repository, project, tool और अन्य सभी access rights पूरी तरह निरस्त कर दिए जाएँगे
  • MAC address blacklist में जोड़ा जाएगा
  • ईमेल को आक्रामक रूप से जटिल regex tutorial daily digest की अनिवार्य सदस्यता में शामिल कर दिया जाएगा
  • आपका दिन शुभ हो।

Appendix B - मानकीकृत rejection macros

maintainers और reviewers के लिए तुरंत copy-paste किए जा सकने वाले मानक rejection वाक्य:

  • PR / MR:
    • PR closed. आपका diff ऐसे पढ़ा जाता है जैसे predictive text matrix ने अपना context window खो दिया हो। हमें automated guessing game नहीं, बल्कि manual, carbon-based testing और वास्तविक logical continuity चाहिए। See: 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. इस report का temperature parameter बहुत ऊँचा सेट है। हमें सत्यापित bug का वर्णन न कर सकने वाले सुथरे generative essay नहीं, बल्कि एक sentient user से raw, reproducible stack traces चाहिए। See: 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. बुनियादी linter warning को LLM में डालकर विनाशकारी threat narrative बनाना वैध vulnerability disclosure नहीं है। हम computationally expensive synthetic panic पर bounty नहीं देते। See: 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. यह community आपके unaligned prompt experiments के लिए reinforcement learning sandbox नहीं है। कृपया तब लौटें जब आप अपने स्वयं के cognitive load का उपयोग करके प्रश्न लिख सकें। See: 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

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-03-08
Hacker News की राय

  • अगर आप सच में मदद करना चाहते हैं, तो अपनी ऊर्जा उस repository पर लगाना बेहतर है जिसे आप खुद own करते हैं और maintain करते हैं
    लोगों को यह आदत भी सीखनी चाहिए। fork को पब्लिश करना आसान हो गया है, लेकिन जिस कोड का आप खुद इस्तेमाल नहीं करते, उसे कोई और इस्तेमाल करे—यह उम्मीद नहीं करनी चाहिए
    GitHub पर एक दिन में कितने projects को PR भेजे जाते हैं, उसके आँकड़े देखें तो 99% एक, 1% दो, और 0.1% तीन होते हैं। 5 या उससे ज़्यादा PR भेजने वाले accounts लगभग सभी bots या scripts थे। अनरजिस्टर्ड bots पर rate limit लगनी चाहिए

    • ऐसी स्थिति में, अच्छा होगा अगर permanent patch mode जैसा कोई फीचर हो, जिसमें मेरा fork upstream repository के ऊपर समय-समय पर अपने-आप rebase होता रहे। उदाहरण के लिए, एक लाइन का fix भी अपने-आप latest बना रहे

  • मुझे Ghostty की AI policy ज़्यादा पसंद है
    “अगर आप AI की मदद के बिना यह नहीं समझा सकते कि बदलाव क्या करता है और पूरे सिस्टम पर उसका क्या असर पड़ता है, तो इस project में योगदान मत कीजिए” — यह लाइन मुझे खास तौर पर पसंद है

    • आइडिया अच्छा है, लेकिन दिक्कत इसे लागू करने के तरीके में है। AI से explanation लिखवाकर उसे अपने शब्दों में दोबारा लिख दें, तो असल में इसे bypass किया जा सकता है

  • मुझे लगता है कि दिक्कत यह है कि open source contribution एक तरह का rite of passage बन गया है
    जब असली योगदान से ज़्यादा ‘योगदान किया’ यह बात अहम हो जाती है, तब ऐसे सतही PR पैदा होते हैं। पहले vulnerability reports में भी ऐसा ही होता था — “null डालने पर NullPointerException आता है” जैसी reports
    development speed जैसे गलत metrics को महत्व देना भी समस्या है। मेरी पिछली कंपनी में एक सहकर्मी AI से तेज़ development करने का दावा करता था, लेकिन उसके PR देखे तो सारे tests fail हो रहे थे। आखिर में यह AI-assisted gamification ही है

    • मुझे भी आजकल AI से लिखे गए job applications बहुत मिलते हैं। उनमें से कुछ GitHub contributions को highlight करते हैं। शायद इस तरह के PR कभी-कभी सच में accept भी हो जाते हैं। project के star count को hiring metric मानने वाली culture इस spam को बढ़ावा देती है
    • यह कुछ ऐसा है: “मैं बहुत तेज़ी से गणित कर सकता हूँ” → “तो 137*243 क्या है?” → “132,498” → “गलत” → “लेकिन तेज़ तो था ना”

  • यह बस मज़े के लिए लिखा गया blog post है। AI से low-quality PR भेजने वाले लोग ऐसे लेख पढ़ते भी नहीं हैं
    मेरा तरीका सीधा है:

    1. PR बंद करो
    2. अगर बहुत ही बेपरवाही से भेजा गया हो, तो user को block करो
      हाल में एक PR आया था जिसमें string definition में ‘’ की जगह '' इस्तेमाल किया गया, और पूरा CI fail हो गया। तुरंत block कर दिया
    • PR बंद करते समय इस पेज का link comment में attach कर देना अच्छा रहेगा

  • अगर bug है, तो fix दिखाने वाली लाल लाइनें (diff) होनी चाहिए, और अगर feature है, तो कम-से-कम acceptance criteria होना चाहिए
    documentation हो तो बस पढ़कर समझ में आ जाना चाहिए। मददगार होने की सीमा काफ़ी नीचे है

  • “क्या open source maintainers को welcoming community नहीं बनानी चाहिए?” इस सवाल पर, यह उनकी ज़िम्मेदारी नहीं है
    maintainers project के मालिक हैं, और उन्हें विनम्र होना ज़रूरी नहीं। पसंद नहीं है तो fork कर लीजिए या आगे बढ़ जाइए

    • मेरे हिसाब से ऐसा दावा दरअसल emotional manipulation के काफ़ी क़रीब है। बेहतर होगा यह कहना: “हमारा समय भावनात्मक रूप से बर्बाद मत कीजिए, और समझिए कि LLM-generated PR बेकार क्यों हैं।” हमें भी LLM इस्तेमाल करना आता है, और उसके बाद लगने वाला असल काम कितना बड़ा होता है यह भी पता है

  • यह सच में बहुत संतोषजनक है। अच्छा होगा अगर ऐसे लेखों का इस्तेमाल लापरवाही से PR भेजने वालों को शर्मिंदा करने के लिए व्यापक रूप से हो। FAQ का सीधा और थोड़ा रूखा tone उल्टा ताज़गी देता है

    • लेकिन ऐसे लोगों को शर्म आती ही नहीं। यह फोन scammers पर गुस्सा करने जैसा है — वे बस कॉल काटेंगे और फिर से कोशिश करेंगे

  • यह हमारे workplace में हुई घटना है। AI से एक छोटे feature request को हल करने वाला code बनाया गया, लेकिन codebase की अच्छी समझ नहीं होने की वजह से उसकी correctness पर भरोसा नहीं था
    1 मिनट का prompt, 5 मिनट की सफ़ाई, और 30 मिनट की review से शायद 2 दिन का engineering time बच सकता था, लेकिन आखिर में मसला trust का था
    कई लोगों की राय सुनने के बाद, हमने तय किया कि सिर्फ feature request उठाएँगे, diff शामिल नहीं करेंगे।
    दिलचस्प बात यह रही कि AI समर्थकों ने सलाह दी कि “AI का और इस्तेमाल करके confidence बढ़ाइए,” लेकिन उल्टा लगातार edit करते-करते code उलझ गया और भरोसा पूरी तरह खत्म हो गया

    • अगर आप सच में LLM द्वारा बनाया code इस्तेमाल करना चाहते हैं, तो हर बदलाव को समझना चाहिए, और उसे खुद summary बनाकर feature request में attach करना चाहिए
      मुझे भी कई बार LLM-generated PR मिले हैं, लेकिन न ठीक से बातचीत हो पाती है, न code existing patterns का पालन करता है, इसलिए आखिरकार उन्हें फेंकना पड़ता है।
      अगर सामने इंसान हो, तो मैं चाहूँगा कि वह अपनी नज़र से समस्या समझाए। वह कहीं ज़्यादा मददगार होता है
    • आपके पास अच्छी engineering sense है। काश industry में ऐसे लोग और होते
    • “2 दिन का engineering time बच सकता था” वाली बात समझ नहीं आती। codebase जानने वाला कोई व्यक्ति खुद भी AI इस्तेमाल कर सकता है। समझ नहीं आता कि AI का output दूसरों से validate क्यों करवाना है। हमें भी LLM इस्तेमाल करना आता है
      संबंधित लेख: Prompting पर लेख
    • मैं भी कुछ ऐसा ही करता हूँ। जब Claude द्वारा बनाए code को मैं पूरी तरह नहीं समझ पाता, तो “यह हिस्सा ऐसे क्यों किया?” “edge cases कैसे handle हो रहे हैं?” जैसे सवाल पूछता हूँ, और कहता हूँ कुछ बदलो मत, सिर्फ समझाओ। इससे output को मैं अपना बना पाता हूँ
    • अगर आप वह library वास्तव में इस्तेमाल कर रहे हैं, तो staging environment में test करके review submit करना बेहतर होगा

  • आखिर में आया plonk वाला इस्तेमाल बहुत बढ़िया था
    Plonk(Usenet) देखें

    • अगर यह BOFH Task Force है, तो उनसे इतना तो expected था ही

  • “rm -rf से अपनी local branch या बेकार script मिटा दो” वाली लाइन बहुत मज़ेदार है
    “अपने organic brain को hard reboot करो” वाला expression भी एकदम परफेक्ट है

    • सच कहूँ तो लगता है LLM ने पहले ही ऐसे PR लिखने वालों का brain rm -rf कर दिया है