AI टूल उपयोग वाले योगदान में खुलासा अनिवार्य

 (github.com/ghostty-org)
5 पॉइंट द्वारा GN⁺ 2025-08-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ओपन सोर्स प्रोजेक्ट Ghostty की PR चर्चा में यह राय सामने आई कि AI टूल के उपयोग को स्पष्ट रूप से सार्वजनिक करना अनिवार्य होना चाहिए
  • प्रस्ताव रखने वाले ने बताया कि AI अब भी कई बार कम गुणवत्ता वाला कोड बनाता है, और खासकर जब अनुभवहीन उपयोगकर्ता बिना समीक्षा के उसे जमा करते हैं तो समस्या और बढ़ जाती है
  • इस खुलासे का उद्देश्य यह है कि maintainer PR की विश्वसनीयता का आकलन कर सकें, और मानव योगदानकर्ताओं को शैक्षिक feedback दे सकें, जबकि केवल AI-जनित योगदान पर अनावश्यक मेहनत कम की जा सके
  • एक अन्य प्रतिभागी ने सुझाव दिया कि PR template के जरिए AI उपयोग शामिल करने वाली checklist जोड़ी जा सकती है
  • दूसरी ओर, यह विचार भी रखा गया कि AI टूल अपने आप एक विशेष byline को मानकीकृत करें और उसे GitHub commit message में दर्ज करें, ताकि transparency और टूल का खुलासा दोनों साथ में सुनिश्चित हों

AI उपयोग के खुलासे की आवश्यकता

  • Mitchellh को AI टूल पसंद हैं और वे खुद भी उनका उपयोग करते हैं, लेकिन उनका आकलन है कि फिलहाल यह समान या बेहतर गुणवत्ता की गारंटी नहीं देता
    • खासकर जब समीक्षा करने की क्षमता कम रखने वाले शुरुआती उपयोगकर्ता AI कोड को ज्यों का त्यों PR में डाल देते हैं, तो गुणवत्ता बहुत खराब होती है
    • ऐसे में maintainer का अनावश्यक समीक्षा और feedback पर समय लगाना “धोखा देने जैसा व्यवहार” है, ऐसी आलोचना की गई
  • इसलिए यदि AI उपयोग को स्पष्ट रूप से बताया जाए, तो maintainer यह निर्णय कर सकते हैं कि कितनी सावधानी से समीक्षा करनी है

PR template लागू करने का प्रस्ताव

  • Yawaramin ने सुझाव दिया कि GitHub की PR template सुविधा का उपयोग कर AI उपयोग को शामिल किया जाए
    • साथ ही Developer Certificate of Origin(DCO) जैसी checklist भी जोड़ी जा सकती है
  • इससे सभी योगदानकर्ता एक समान तरीके से AI उपयोग की जानकारी दे सकेंगे

GitHub मानकीकरण का विचार

  • Tobi ने GitHub स्तर पर AI-विशेष byline standard बनाने का प्रस्ताव रखा
    • जब भी AI टूल उपयोग हो, यह .git staging file में दर्ज हो और commit message में अपने आप जुड़ जाए
    • GitHub इसे सूचीबद्ध करे और टूल का लिंक दे → maintainer स्रोत की पुष्टि कर सकें
    • साथ ही AI टूल को अब की तरह co-authors का spam-जैसा दुरुपयोग नहीं करना पड़ेगा
  • इस तरीके को transparency, टूल प्रचार, और maintainer efficiency—तीनों को पूरा करने वाले समाधान के रूप में देखा गया

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

1 टिप्पणियां

 
GN⁺ 2025-08-22
Hacker News की राय
  • यह बताया गया कि "AI" के इस्तेमाल में भी बौद्धिक संपदा प्रदूषण की समस्या होती है, लेकिन हम इस सच को नज़रअंदाज़ कर रहे हैं; अगर कोई व्यक्ति सभी open source projects का कोड याद करके ज़रूरत पड़ने पर हूबहू लिख दे, तो हमारी कंपनी में ऐसे व्यक्ति को निश्चित रूप से प्रतिबंधित किया जाना चाहिए, लेकिन AI के मामले में लोग तरह-तरह के तर्क और बहाने देकर इस तथ्य से इनकार कर रहे हैं; व्यवहार में यह GPL सहित विभिन्न कोड को ढीले-ढाले तरीके से "धोकर" पेश करने जैसा है, और यह बौद्धिक संपदा (IP) आधारित कंपनियों के लिए घातक जोखिम समेटे हुए है
    • अमेरिकी अदालतें पहले ही यह फैसला दे चुकी हैं कि training data का उपयोग transformational use है; बारीक समायोजन के लिए अभी बहुत कुछ बाकी है, लेकिन अंततः यह एक अपरिवर्तनीय बदलाव है; अगर हम चाहते हैं कि IP निर्माण आर्थिक रूप से टिकाऊ गतिविधि बना रहे, तो संबंधित कानूनी ढांचे को भी बदलना होगा
    • अगर इस तर्क को मानें, तो StackOverflow या लगभग हर क्षेत्र की पाठ्यपुस्तकों को भी प्रतिबंधित करना पड़ेगा; व्यावहारिक रूप से programmers दूसरे लोगों का कोड देखने से बच ही नहीं सकते
    • वास्तव में जिनका सीधा आर्थिक हित जुड़ा है, उनके अलावा शायद ही कोई AI से जुड़े कानूनी मुद्दों को गंभीरता से लेता हो; सौभाग्य से ज़्यादातर मामलों में लोग इस मुद्दे को नज़रअंदाज़ कर रहे हैं, और कानूनी व्यवस्था भी प्रगति को रोके बिना ठीक-ठाक काम कर रही है
  • mitchellh की यह बात बहुत प्रभावशाली लगी कि "नए contributors को अंत तक मदद करो, और PR merge होने तक उनका साथ दो"; feedback देकर नए developers को बढ़ने में मदद करना वास्तव में बहुत मूल्यवान है, लेकिन अगर PR भेजने वाला वह feedback तुरंत AI को दे दे और खुद कुछ भी न सीखे, तो वह समय की बर्बादी है
    • अब नए developers के लिए AI के बिना काम करने वाला माहौल शायद रहेगा ही नहीं
  • आज का HN front page यथार्थवादी अनुभव-आधारित अच्छे content से भरा देखकर बहुत अच्छा लगा; बेकार का डर या बढ़ा-चढ़ाकर कही बातें कम थीं और ईमानदार अनुभव ज़्यादा थे; निजी कंप्यूटर पर AI assist बंद रखता हूँ, और कंपनी में भी केवल सचमुच ज़रूरी स्थितियों में बहुत सीमित रूप से इस्तेमाल करता हूँ; AI assist छोटे-छोटे atomic work में बहुत मजबूत है, लेकिन compound work में बेहद कमजोर है; निष्कर्ष यह है कि AI अंततः उतना ही उपयोगी है जितना इंसान उसे उपयोग में लाता है; मानव बुद्धि ही असली कुंजी है
    • "AI उतना ही बुद्धिमान है जितना इंसान उसे संभालता है" इस बात से मैं धीरे-धीरे सहमत होने लगा हूँ; एक ही AI से बिल्कुल अलग नतीजे कैसे निकलते हैं, यह पहले समझ नहीं आता था, लेकिन अब सचमुच महसूस हो रहा है कि AI कोई जादू नहीं है; जो लोग टीम के साथियों को भी कुछ समझा नहीं सकते, वे AI से मूल्य निकाल लेंगे—यह उम्मीद करना मेरी naïve सोच थी; उल्टा, AI शायद साधारण engineer और उत्कृष्ट engineer के बीच की खाई और बढ़ा देगा; अभी भी मन मिला-जुला है, लेकिन अब समझ आता है कि कुछ लोगों को AI बेकार क्यों लग सकता है
    • Frederik P. Brooks की “No Silver Bullets, Refired” का हवाला दिया गया, जिसमें कहा गया है कि software development मूल रूप से जटिल है, और किसी क्रांतिकारी समाधान का इंतज़ार करने के बजाय धीरे-धीरे productivity सुधारना चाहिए; यह नज़रिया यथार्थवादी भी लगता है और आशावादी भी
    • "AI उतना ही बुद्धिमान है जितना इंसान उसे संभालता है" यह बात दिलचस्प लगी; आखिरकार "मैंने AI से एक दिन में cool library बना दी" जैसी पोस्ट लिखने वाले लोग शुरू से ही काफ़ी सक्षम developers थे
    • मैं भी इससे सहमत हूँ; कंपनी में hacking week चल रहा है और हम AI tools का organization-wide प्रयोग कर रहे हैं, जहाँ analytical approach, guardrails, grounded generation जैसी चीज़ों से ही असल उपयोग में अच्छे नतीजे मिलते हैं; हाल में ऐसा लगता है कि बेकार chatbot craze गुजर चुका है और paradigm फिर से machine learning के मूल स्वभाव की ओर reset हुआ है
    • मेरा मानना है कि मुख्य फैसले इंसान लेता है, और उसके बाद AI बाकी चीज़ों को जोड़ता है; कौन-सी चीज़ "मुख्य फैसला" है और कौन-सी सिर्फ बिंदुओं को जोड़ने वाली साधारण कड़ी, यह domain के हिसाब से बदलता है, लेकिन व्यवहार में ज़्यादातर code (लगभग 80~90%) सिर्फ दोहराव/जोड़ने वाला काम होता है; अगर इस सीमा को ठीक से संभाला जाए तो productivity में बहुत बड़ा बढ़ाव मिलता है; इसके उलट अगर मुख्य फैसले AI को दे दिए जाएँ तो नुकसान और बड़ा होता है; कई बार उसे छोड़कर दोबारा करना ही बेहतर होता है; मुख्य फैसलों के उदाहरण हैं database design, type definitions, dependencies, system/infrastructure/screen design, test cases का चयन, code organization structure आदि; दूसरी ओर AI जिन कामों में अच्छा है, वे हैं CRUD, API handlers, साधारण data structure transformations, deployment scripts, test implementation, UI component code, styling, अस्थायी data cleanup आदि; AI research, idea exploration और alternatives खोजने में भी मदद करता है, लेकिन निष्कर्ष और वास्तविक implementation इंसान को खुद संभालना चाहिए
  • मैं AI का बहुत बड़ा प्रशंसक नहीं हूँ, बस उसे एक tool की तरह देखता हूँ; किसी ने PR कैसे तैयार किया, इससे मुझे फर्क नहीं पड़ता, जब तक परिणाम ठीक हो; हाँ, अगर PR जमा करने से पहले maintainer ने कुछ शर्त रखी हो, तो उसके अनुसार चलना शिष्टाचार है
    • PR कहाँ से आया और कैसे बना, यह महत्वपूर्ण है; reviewers भी गलती करते हैं और उनकी भी सीमाएँ होती हैं, इसलिए भरोसा ज़रूरी है; भरोसा न हो तो उसे review process में शामिल ही नहीं करना चाहिए; Linux kernel team ने University of Minnesota को प्रयोगों की वजह से block किया था, वह भी इसी कारण से
    • ऐसा लगता है कि लेख के मुख्य तर्क—"नए contributors की वृद्धि में मदद करना लक्ष्य है, लेकिन अगर सामने वाला AI है, तो वह सिर्फ समय की बर्बादी है"—का ठीक से जवाब नहीं दिया गया
    • AI से एक दिन में 1,000 PR भी बनाए जा सकते हैं; लोग शायद सिर्फ AI से बने अच्छे PR के बारे में सोचते हैं, लेकिन वास्तविकता में AI से project maintainers को बेहद परेशान भी किया जा सकता है
    • अमेरिकी Copyright Office के अनुसार, AI द्वारा generated outputs copyright protection के दायरे में नहीं आते; इसलिए licensing के उद्देश्य से भी AI उपयोग का खुलासा आवश्यक है; इसका उल्लंघन करने पर पूरे काम पर copyright खोया जा सकता है; विवरण के लिए रिपोर्ट और मुख्य पेज देखें
    • अगर मैंने AI का उपयोग किया और मुझसे इसके बारे में पूछा गया, तो मैं हमेशा बताऊँगा; लेकिन अगर विशेष रूप से नहीं पूछा गया, तो 'सामान्य शिष्टाचार के तहत पहले से' इसका खुलासा नहीं करूँगा; मुझे लगता है कि अधिकांश लोग AI उपयोग को सामान्य मानते हैं या उसकी परवाह ही नहीं करते, और यह उल्टा ध्यान भटकाने वाला एक छोटा-सा संकेत बन सकता है; dependabot जैसी सूचना आने पर भी वास्तव में खास रुचि नहीं बनती
  • "मेरे autocomplete का क्या होगा" यह सवाल कई बार आया, लेकिन policy document में साफ़ अपवाद दिया गया है कि साधारण tab autocomplete जैसे keywords या छोटे phrases हों, तो उनका खुलासा करना ज़रूरी नहीं है; लोगों को दस्तावेज़ (या PR) ठीक से पढ़ने की सलाह दी गई
  • इस policy में अतिरिक्त संदर्भ और वजह दी गई है, इसलिए यह समझ में आती है; पहले जो कई AI policies देखी थीं, वे विचारधारात्मक घोषणाओं जैसी लगती थीं, लेकिन यहाँ यह भी बताया गया है कि यह माँग क्यों है और आगे की दिशा क्या होगी, इसलिए यह कहीं अधिक व्यावहारिक लगता है; काश ऐसी नीतियाँ और हों
  • चिंता यह है कि क्या यह policy अंततः ईमानदार लोगों के लिए AI इस्तेमाल करना मुश्किल नहीं बना देगी; सवाल यह है कि अगर AI इस्तेमाल बताने पर PR पर कम ध्यान मिलेगा, तो क्या लोग सब कुछ छिपाने नहीं लगेंगे
    • मुझे नहीं लगता कि बात इतनी सरल है; policy लिखने वाले व्यक्ति (mitchellh) खुद भी LLM इस्तेमाल करते हैं, इसलिए अगर कोई यह समझा सके कि उसने अपने काम को ठीक से समझते हुए सुविधा के लिए AI का इस्तेमाल किया, तो उससे बहुत ज़्यादा भरोसा नहीं टूटेगा
    • यह चिंता सच भी हो सकती है; AI बड़ी मात्रा में ऐसा code बना सकता है जो "ऊपरी तौर पर ठीक लगे लेकिन वास्तव में गड़बड़ हो", इसलिए अगर AI code पर अविश्वास बढ़ता है, तो वह AI की समस्या है, इंसानों की नहीं; बेहतर AI coding tools की ज़रूरत है
    • "chat-gpt इस्तेमाल किया" कह दो तो बात तुरंत दब जाती है, लेकिन कुछ न कहो और जानकार होने का आभास दो तो प्रशंसा मिलती है; लोग पहले से ही AI उपयोग छिपाने की दिशा में जा रहे हैं
    • मुझे नहीं लगता कि इसे समस्या मानना विशेष रूप से अर्थपूर्ण है
    • बात "AI मत इस्तेमाल करो" की नहीं है, बल्कि यह है कि अगर इस्तेमाल किया है, तो PR में ईमानदारी से बताओ
  • यह जानने की जिज्ञासा है कि "ChatGPT से codebase समझने में मदद ली, लेकिन वास्तविक coding खुद की" जैसी विस्तृत disclosure भी क्यों माँगी जा रही है
    • ऐसी जानकारी छोड़ने से reviewer के नज़रिए से "codebase understanding" वाले हिस्से में गलतफहमी या भूल review point बन सकती है, इसलिए उस पर ध्यान केंद्रित किया जा सकता है
    • मैं developer नहीं हूँ, लेकिन ऐसे AI assistants की वजह से code exploration में लगने वाला समय काफ़ी कम हुआ है; व्यक्तिगत रूप से AI ने वास्तव में बहुत मदद की है
  • मुझे वह pattern अच्छा लगता है जिसमें PR बनाने में इस्तेमाल किए गए हर prompt को शामिल किया जाए; LLM पूरी तरह deterministic tool नहीं है, लेकिन किस चरण और किन prompts के ज़रिए परिणाम तक पहुँचा गया, यह संदर्भ छोड़ना अपने आप में मूल्यवान है
    • व्यवहार में यह बहुत अव्यावहारिक है; AI-आधारित एक PR बनाने में भी 10~20 prompts, tests, manual context adjustments, manual coding जैसी कई प्रक्रियाएँ मिली-जुली होती हैं; ऐसे में screen recording बेहतर लगती है
    • मैं vscode plugin (specsytory) और cursor के संयोजन से सभी LLM interaction logs को md में रखता हूँ और Pull Request के साथ जमा करता हूँ, ताकि code review के समय उन्हें देखा जा सके
  • एक व्यक्तिगत project में editor autocomplete के उपयोग तक का खुलासा करने का नियम बनाया गया है
    • इरादा बताने का तरीका दिलचस्प है, लेकिन आज का AI पारंपरिक autocomplete से पूरी तरह अलग है; उसे autocomplete की तरह इस्तेमाल किया जा सकता है, लेकिन AI जो कर सकता है उसकी चौड़ाई और गहराई कहीं ज़्यादा है; AI को सिर्फ साधारण autocomplete समझना एक व्यक्तिगत दृष्टिकोण हो सकता है, बहुत से लोग उसे इस तरह इस्तेमाल नहीं करते
    • tab autocomplete को policy में स्पष्ट अपवाद माना गया है
    • autocomplete आमतौर पर सिर्फ व्याकरणिक tool होता है, जबकि AI code के अर्थ और संरचना तक को guide करने की कोशिश करता है