Debian ने AI-जनित योगदानों पर फैसला टाला

• Debian समुदाय ने AI या LLM-आधारित code contribution की अनुमति दी जाए या नहीं इस पर चर्चा की, लेकिन बिना किसी निष्कर्ष के चर्चा समाप्त कर दी गई
• प्रस्तावित मसौदे में AI tools के उपयोग पर स्पष्ट खुलासा, ज़िम्मेदारी की स्पष्टता, और संवेदनशील जानकारी के उपयोग पर रोक जैसी शर्तों के साथ अनुमति देने की बात थी
• डेवलपर्स के बीच ‘AI’ शब्द की अस्पष्टता, LLM के उपयोग-क्षेत्र, और quality, copyright, और ethics से जुड़े मुद्दों पर मतभेद रहे
• कुछ लोगों ने नए contributors के onboarding में बाधा, अनैतिक corporate व्यवहार, और कानूनी अनिश्चितता जैसे कारणों से विरोध जताया
• Debian फिलहाल मौजूदा नीतियों के तहत case-by-case निर्णय की नीति जारी रखेगा और भविष्य में आगे चर्चा की संभावना खुली रखेगा

---

Debian की AI contribution बहस का सार

• Debian ने AI-जनित code को स्वीकार किया जाए या नहीं इस पर आंतरिक बहस की, लेकिन General Resolution (GR) लाए बिना इसे समाप्त कर दिया गया
  • चर्चा तब शुरू हुई जब Lucas Nussbaum ने AI-सहायित contributions पर रुख स्पष्ट करने के लिए एक मसौदा पेश किया
  • उन्होंने feedback इकट्ठा करने के बाद इसे औपचारिक रूप से जमा करने पर विचार किया, लेकिन चर्चा शांत पड़ने के बाद प्रस्ताव आगे नहीं बढ़ा
• मसौदे में AI tools से बने code के खुलासे की अनिवार्यता, contributor की ज़िम्मेदारी का स्पष्ट उल्लेख, security और license compliance की गारंटी, और गोपनीय जानकारी के उपयोग पर रोक शामिल थी

शब्दावली और तकनीकी भेद पर बहस

• कई डेवलपर्स ने ‘AI’ शब्द की अस्पष्टता की ओर इशारा करते हुए LLM जैसी विशिष्ट तकनीकों का स्पष्ट उल्लेख आवश्यक बताया
  • Russ Allbery ने कहा कि “AI” बहुत व्यापक शब्द है और policy बनाने के लिए उपयुक्त नहीं
  • Sean Whitton ने LLM के उपयोग के उद्देश्य के आधार पर भेद (code review, prototype, production code) करने का सुझाव दिया
  • Andrea Pappacoda ने कहा कि Claude’s C Compiler जैसे प्रोजेक्ट Debian में शामिल नहीं होने चाहिए
• इसके विपरीत, Nussbaum का तर्क था कि tool के प्रकार से अधिक महत्वपूर्ण automated code generation की क्रिया स्वयं है

नए contributors के onboarding और लागत का मुद्दा

• Simon Richter ने चिंता जताई कि AI नए डेवलपर्स के सीखने के अवसरों की जगह ले सकता है
  • उनका कहना था कि AI मार्गदर्शन पाने के बावजूद खुद नहीं सीखता, और project resources लगातार ज्ञान-हस्तांतरण में नहीं बदलते
  • यह भी चिंता जताई गई कि AI का उपयोग paid tools पर निर्भरता बढ़ा सकता है, जिससे contributors की पहुंच घट सकती है
• Nussbaum ने माना कि अभी मुफ़्त access उपलब्ध है, लेकिन भविष्य में लागत समस्या बन सकती है
  • उनका जवाब था कि AI उल्टा जटिल कामों तक पहुंच आसान बना सकता है
• Ted Ts’o ने कहा कि AI उपयोगकर्ताओं को बाहर रखना आत्म-विरोधाभासी होगा और इससे contributors की विविधता सीमित हो सकती है

ethics, copyright, और quality पर चर्चा

• Matthew Vernon ने तर्क दिया कि AI कंपनियों की अनैतिक data collection और पर्यावरणीय नुकसान के कारण Debian को स्पष्ट विरोध करना चाहिए
  • उन्होंने copyright उल्लंघन, बिना सहमति image generation, और झूठी security reports जैसी समस्याओं की ओर ध्यान दिलाया
• Jonathan Dowland ने सुझाव दिया कि कानूनी अनिश्चितता दूर होने तक AI-जनित सामग्री की स्वीकृति सीमित रखी जाए
• Thorsten Glaser ने कहा कि LLM-आधारित code वाले प्रोजेक्ट्स को ‘non-free’ सेक्शन में ले जाना चाहिए, लेकिन Linux kernel, Python जैसे प्रमुख प्रोजेक्ट्स के बाहर हो जाने के जोखिम के कारण इस विचार को समर्थन नहीं मिला
• Allbery ने कहा कि AI code की quality पर बहस बहुत मायने नहीं रखती, क्योंकि इंसान भी खराब code लिख सकते हैं
• Bdale Garbee ने AI को एक विकास-चरण के रूप में देखते हुए इसके दीर्घकालिक प्रभावों को देखने की ज़रूरत पर ज़ोर दिया

‘Preferred form of modification’ पर बहस

• Nussbaum ने जवाब दिया कि LLM input (prompt) ही modification का preferred form है, लेकिन non-determinism की समस्या पर बहस जारी रही
  • कुछ लोगों का कहना था कि LLM non-deterministic हैं, इसलिए वे reproducible build के लिए उपयुक्त नहीं
  • अन्य लोगों ने जवाब दिया कि एक ही PRNG seed और समान environment बनाए रखने पर पुनरुत्पादन संभव है
  • चर्चा आगे बढ़कर determinism, reproducibility, और GPU computation की asynchronous प्रकृति जैसे तकनीकी विवरणों तक पहुंची

निष्कर्ष: Debian ने फैसला टाला

• Debian के भीतर AI-जनित contributions की परिभाषा पर भी सहमति नहीं बन पाई है
• बहुमत का मानना था कि अभी resolution पर मतदान का समय नहीं है, और mailing list स्तर पर चर्चा जारी रहना बेहतर होगा
• Nussbaum ने कहा कि “AI की अनुमति दी जाए, लेकिन safeguards के साथ” जैसा समझौता व्यावहारिक हो सकता है
• फिलहाल मौजूदा नीतियों के तहत case-by-case निर्णय जारी रहेगा, और AI models, LLM code, और AI-जनित contributions को कैसे संभाला जाए यह अब भी तय नहीं है
• जटिल तकनीकी बदलावों और विविध मतों के बीच, status quo को फिलहाल सबसे व्यावहारिक विकल्प माना गया

[GN⁺]

Hacker News की राय

• मैंने पूरी ज़िंदगी coding की है, लेकिन कलाई की चोट के बाद typing लगभग असंभव हो गई थी; LLM, AI autocomplete और agent-based development की वजह से मैं फिर से high-quality code लिख पा रहा हूँ
  AI के hallucination भी उल्टा prompt को refine करने और intent को साफ़ करने में मदद करते हैं
  accessibility के नज़रिए से AI मेरे लिए एक ज़रूरी tool है, और “अच्छाई बुराई पर भारी पड़ती है या नहीं” से ज़्यादा ecosystem में इसे समग्र रूप से अपनाने का रवैया महत्वपूर्ण है

  • जैसा तुमने कहा, कुछ लोग AI का समझदारी से इस्तेमाल करते हैं, लेकिन यह मान लेना कि सभी user ऐसे ही होंगे, ख़तरनाक है
    कुछ projects में low-quality PR की बाढ़ आ रही है, और कई contributors सिर्फ़ अपना GitHub profile भरना चाहते हैं
    आख़िरकार असली सवाल यह है कि क्या योगदान good faith में किया गया है, और project को उसकी स्वीकार्य सीमा साफ़ करनी चाहिए
  • मैं भी कुछ ऐसा ही करता हूँ। AI को मुश्किल problem देने के बजाय, मैं उसे वही technical solution देता हूँ जिसे मैं पहले से implement करना चाहता था, और उससे code generate करवाता हूँ
    इससे review fatigue कम होती है, और मैं सिर्फ़ उन हिस्सों पर ध्यान देता हूँ जो उम्मीद से अलग हैं
  • मेरी भी कलाई में दर्द है, इसलिए मैं Whisper + LLM combination से voice input और summarization करता हूँ। email, document writing, यहाँ तक कि receipt sorting भी automate हो गया है, जिससे सेहत पर भी अच्छा असर पड़ा है
    अब तो हालत यह है कि ऐसी सुविधाएँ रोकने वाली company में काम नहीं करना चाहूँगा
  • मुझे भी RSI है, और AI autocomplete से काफ़ी मदद मिली है। लेकिन agent-type AI real-time C++/Rust environment में ज़्यादा उपयोगी नहीं है
    accessibility वाला पहलू बहुत महत्वपूर्ण है, लेकिन copyright और liability के सवाल अब भी जटिल हैं
  • अगर कोई code पर sign करके अपनी expertise और reputation दाँव पर लगाने को तैयार है, तो AI बस एक उन्नत autocomplete tool है, और इसे “no AI” rule के exception की तरह देखना चाहिए

• मेरा मानना है कि PR (pull request) review आख़िरकार trust का सवाल है। यानी यह भरोसा कि submit करने वाले ने अपनी तरफ़ से पूरी कोशिश की है
  AI इस्तेमाल हुआ या नहीं, उससे ज़्यादा अहम यह है कि उसका ज़िम्मेदारी के साथ इस्तेमाल हुआ या नहीं

  • बेशक, malicious actor भी होते हैं। XZ attack की तरह persistent threat (APT) open source में भी एक हक़ीक़त है
    कई fake accounts मिलकर भी एक ही attacker का हिस्सा हो सकते हैं, और LLM से बना code LLM को देखने में ठीक लग सकता है, इसलिए verification और कठिन हो जाती है
    नतीजतन, अब PR को evaluate करना उसे बनाने से भी कठिन हो गया है
  • फिर भी, मैं अब भी मानता हूँ कि हर code को संभावित trojan horse मानकर verify करना चाहिए
  • review process इतनी robust होनी चाहिए कि वह इंसान हो या AI, दोनों की errors पकड़ सके

• AI contributions की quality पर बहस अजीब लगती है। quality की ज़िम्मेदारी हमेशा submit करने वाले की होती है
  AI इस्तेमाल करने से कोई liability से मुक्त नहीं हो जाता, बल्कि AI usage restriction policy अच्छे इरादे वाले contributors को ही नुक़सान पहुँचा सकती है

  • समस्या यह है कि LLM code ऊपर से अच्छा दिख सकता है, लेकिन असल में वह बिना समझे implement किया गया code हो सकता है
  • अहम बात tool नहीं, बल्कि यह है कि contributor review में अपने code को समझा और defend कर सकता है या नहीं
    मैं AI की मदद से 300 commits वाला fork maintain करता हूँ, लेकिन हर line को review करके समझा सकता हूँ
    आख़िरकार मुद्दा भागीदारी की quality है, tool के प्रकार का नहीं
  • असली invariant है ज़िम्मेदारी। अगर आपने patch submit किया है, तो उसके design और maintenance तक की ज़िम्मेदारी लेनी चाहिए
  • लेकिन AI लोगों को उस ज़िम्मेदारी से बच निकलने की आदत भी डाल सकता है

• लंबी अवधि में, AI इतना आगे बढ़ सकता है कि मानव और AI के output में फ़र्क करना मुश्किल हो जाएगा
  आख़िर जब वह “काफ़ी अच्छा” स्तर पा लेगा, तो वह इंसान द्वारा बनाए गए जैसा लगेगा; तब क्या होगा, यह सोचने वाली बात है

  • इसे पूरी तरह रोका नहीं जा सकता, लेकिन policy बनाकर रखना कुछ न करने से बेहतर है
    अभी ज़्यादातर AI PR low-quality हैं, लेकिन quality बढ़ जाने पर भी उन्हें कानूनी या वैचारिक कारणों से ठुकराया जा सकता है
  • AI contribution को आख़िरकार व्यक्ति के विस्तार की तरह देखना चाहिए। account किसी वास्तविक इंसान का हो, और उसकी reputation दाँव पर होनी चाहिए
  • अगर अचानक बहुत सारा code आ जाए, तो AI usage पर शक हो सकता है। महत्वपूर्ण सवाल AI का इस्तेमाल नहीं, बल्कि यह है कि क्या वह व्यक्ति समस्या को समझता है
  • AI अब भी token-level prediction तक सीमित है, इसलिए वह इंसानों द्वारा designed code से अलग पहचाना जा सकता है
    बहुत ज़्यादा बारीक abstractions या अनावश्यक refactoring आम हैं
    इंसान AI को tool की तरह इस्तेमाल करे तो ठीक है, लेकिन AI द्वारा इंसान को replace करने का स्तर अभी बहुत दूर है
    हालाँकि vibecoding का दुरुपयोग review और maintenance cost को तेज़ी से बढ़ा रहा है
  • आख़िरकार सही तरीके से इस्तेमाल किया गया code मानव code से अलग पहचाना नहीं जाता। समस्या tool नहीं, उसका इस्तेमाल है

• मेरा रुख यह है कि “अगर काम करता है, तो वही काफ़ी है”
  अगर code functionality, documentation, tests और correctness के मानदंड पूरे करता है, तो वह AI ने लिखा हो या इंसान ने, फ़र्क नहीं पड़ता
  अहम बात “काम करने” की परिभाषा साफ़ करना और कुशल review system बनाना है

• AI एक बार में हज़ारों lines का code generate करके PR खोल सकता है, लेकिन आख़िरकार उसे reviewable size तक सीमित करना चाहिए
  AI के tests pass कर जाने पर भी, अगर author खुद उसकी contents नहीं समझता, तो वह ख़तरनाक है
  काम की सीमा तय करना और पहले के manual contributions का रिकॉर्ड ज़रूरी है

• Debian की policy सीधी है — “किसी को चोट न पहुँचे”। यह एक अच्छा सिद्धांत है

• एक सवाल उठा था कि क्या Debian में किसी और का code अपना बताकर submit करने पर रोक लगाने वाला कोई rule है
  व्यवहार में यह copyright infringement के कारण ग़ैरकानूनी है, इसलिए चाहे साफ़ लिखा न हो, पर यह नियम निहित रूप से मौजूद है
  LLM इंसान नहीं है, लेकिन उसके बनाए code का copyright अब भी अस्पष्ट है

• web app या mobile app की vibecoding से फ़र्क नहीं पड़ता, लेकिन kernel, compiler, operating system जैसे core infrastructure software में AI का इस्तेमाल ख़तरनाक है
  ऐसे क्षेत्रों में Ada/SPARK जैसी formal verification languages की ज़रूरत होती है
  यह सोचकर डर लगता है कि कहीं कभी AI द्वारा बनाया गया braking system लगी हुई car में बैठना न पड़े

  • सहमत। core systems में बहुत सावधानी चाहिए, और LLM में सावधानी और copyright risk, दोनों की कमी है
  • सुना है कि automobile industry में तो AI से पहले से ही auto-generated code काफ़ी रहा है

• “YOLO-style code submission” की तुलना में “AI का इस्तेमाल किया गया लेकिन जितना हो सके verify किया गया code” कहीं ज़्यादा स्वीकार्य है