Django में token नहीं, समय और पैसा निवेश करें

 (better-simple.com)
5 पॉइंट द्वारा GN⁺ 2026-03-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • LLM का इस्तेमाल करके Django tickets संभालना मददगार नहीं है, और उन resources को सीधे Django Software Foundation को दान करना ज़्यादा उपयोगी है
  • Django एक बहुत ऊँचे quality standards और long-term stability पर ज़ोर देने वाला project है, इसलिए इसमें केवल code generation से आगे की गहरी समझ चाहिए
  • अगर LLM लेखक की जगह code लिखे, PR description बनाए और review responses भी संभाले, तो यह समझना मुश्किल हो जाता है कि contributor वास्तव में समझता भी है या नहीं
  • open source contribution में मानवीय संवाद और community collaboration सबसे अहम हैं, और अगर LLM इन्हें ढक दे तो reviewer के साथ भरोसा कमज़ोर पड़ता है
  • Django में योगदान देने के लिए सीधे सीखने और प्रयोग के ज़रिए समझ विकसित करने की प्रक्रिया अनिवार्य है, और यही एक developer के रूप में growth की ओर ले जाती है

LLM के जरिए Django contribution की सीमाएँ

  • LLM का उपयोग करके Django tickets हल करना community के लिए ठोस रूप से मददगार नहीं है
    • अगर LLM द्वारा बनाए गए code से PR submit किया जाए और feedback भी उसी से संभाला जाए, तो लेखक की समझ का स्तर जानना मुश्किल हो जाता है
    • reviewer के नज़रिए से यह किसी इंसान से नहीं, बल्कि ‘नकली समझ की एक परत’ से बात करने जैसा लगता है
  • Django के पास बड़ा user base, धीमा बदलाव चक्र, और 20 साल से अधिक समय तक चलने वाले project के रूप में quality requirements हैं
    • इन विशेषताओं के कारण, साधारण automated code generation से अधिक गहरी समझ और ज़िम्मेदार contribution महत्वपूर्ण है

LLM का सही उपयोग कैसे करें

  • LLM का इस्तेमाल समझ को बेहतर बनाने वाले सहायक tool के रूप में होना चाहिए
    • पहले अपनी भाषा में explanation लिखें, फिर LLM की मदद से उसकी अभिव्यक्ति को बेहतर बनाना उचित है
    • अगर communication में कठिनाई हो, तो LLM का सक्रिय रूप से उपयोग किया जा सकता है, लेकिन इसके उपयोग की बात स्पष्ट रूप से बतानी चाहिए
  • Django में योगदान देते समय contributor को problem, solution और review feedback को खुद समझना चाहिए
    • बिना समझ के बनाया गया code पूरे project की quality को नुकसान पहुँचा सकता है

मानव-केंद्रित open source collaboration

  • Django contribution एक community-based experience है, जिसमें मानवीय transparency और vulnerability शामिल होती है
    • अगर LLM इस मानवीय पहलू को ढक दे, तो collaboration मुश्किल हो जाती है
    • reviewer को ‘इंसान की असली समझ’ के आधार पर संवाद करने से प्रेरणा मिलती है
  • LLM का उपयोग केवल सहायक साधन के रूप में होना चाहिए, और इसे contributor की मूल भूमिका का स्थानापन्न नहीं बनना चाहिए

Django contribution का सार और मूल्य

  • Django एक 20 साल के इतिहास और long-term vision वाला project है, इसलिए इसमें जो भी code जोड़ा जाए उसे गहराई से समझा जाना चाहिए
    • इस समझ के लिए समय, प्रयोग और सीखना अनिवार्य हैं
  • Django contribution केवल नाम दर्ज कराने से बढ़कर developer के रूप में विकास देने वाला अनुभव है
    • contribution process से मिलने वाली learning किसी सूची में नाम आने से कहीं अधिक मूल्यवान है

community के लिए प्रस्ताव

  • LLM का अत्यधिक उपयोग करके खुद को और अपनी समझ को छिपाना नहीं चाहिए
    • Django community असल लोगों के साथ सहयोग करना चाहती है
  • अगर आप Django को support करना चाहते हैं, तो समय और पैसा निवेश करना या Django Software Foundation को दान देना सबसे प्रभावी है

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

1 टिप्पणियां

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

  • मेरा मानना है कि LLM किसी भी ऐसे codebase में समस्या पैदा कर सकता है जहाँ human reviewer हों
    अगर टिकट, solution, या PR feedback को समझे बिना LLM का इस्तेमाल किया जाए, तो यह पूरे project के लिए हानिकारक है
    open source योगदान एक सामुदायिक काम है, लेकिन LLM इंसानी पारदर्शिता और असुरक्षा को छिपा देता है
    reviewer के नज़रिए से यह किसी इंसानी ‘मुखौटे’ से बात करने जैसा लगता है, इसलिए यह उत्साह तोड़ने वाला अनुभव है
    इसलिए LLM को एक tool की तरह सहायक रूप में इस्तेमाल करना चाहिए, उसका विकल्प नहीं बनाना चाहिए
    आजकल टीमों में भी AI द्वारा लिखे गए PR तेज़ी से बढ़ रहे हैं, और Claude या Codex को review feedback का जवाब देते भी देख रहा हूँ
    अगर यह संस्कृति जम गई, तो इससे पूरे industry में विश्वास का पतन और मनोबल में गिरावट आ सकती है

    • Jira का AI autocomplete feature ticket system को spam का स्वर्ग बना देता है
      productivity बढ़ने से ज़्यादा बस “तेज़ होने का एहसास” ही बचता है
      असल में organizations productivity को ठीक से मापती ही नहीं हैं, इसलिए इन features का net effect किसी को नहीं पता
    • पहले PR को good faith में भेजा गया मानते थे, लेकिन अब ज़्यादातर AI द्वारा लिखे हुए लगते हैं
      AI का व्यापक उपयोग विश्वास को क्षीण कर रहा है
    • open source contribution में LLM का असर Photoshop का Tinder पर असर जैसा है
      ऊपर से सब अच्छा दिखता है, लेकिन प्रामाणिकता गायब हो जाती है
    • ऐसे AI-आधारित PR वास्तव में review पास करके code merge भी हो जाते हैं
      आखिरकार code पास हो ही रहा है, तो यह भी सोचता हूँ कि क्या लोगों को वास्तव में शिकायत नहीं है

  • जिन सबसे बेहतरीन साथियों के साथ मैंने काम किया, वे हमेशा reviewer के लिए आलोचना करना आसान बनाते थे
    वे assumptions, जो नहीं जानते थे, और trial and error को साफ़-साफ़ लिखते थे, ताकि reviewer आसानी से प्रतिवाद कर सके
    अगर किसी PR में ऐसी विनम्रता और आत्मचिंतन दिखे, तो LLM के शामिल होने पर भी मुझे चिंता नहीं होती
    समस्या यह है कि जो लोग पहले भी basic build तक न होने वाला code भेजते थे, अब वे LLM से और ज़्यादा बेकार PR बना रहे हैं
    इसलिए “code चल रहा है तो किसने लिखा, इससे फ़र्क नहीं पड़ता” वाली बात से मैं सहमत नहीं हूँ

  • अभी स्थिति नियंत्रण से बाहर है
    खासकर hiring process में GitHub activity को evaluation factor मानने के बाद, लोग LLM से contribution history में हेरफेर करने की कोशिश कर रहे हैं
    असल में project को समझे बिना PR पास हो जाए, बस वही काफ़ी है

    • लेकिन मुझे नहीं लगता कि लेख ने पर्याप्त रूप से समझाया कि यह समस्या ‘क्यों’ है
      अच्छे developer का LLM इस्तेमाल करना समस्या नहीं है
      समस्या यह है कि जो लोग पहले से कमज़ोर थे, वे अब LLM की वजह से और ज़्यादा low-quality code जमा कर रहे हैं
    • सच कहें तो यह AI की नहीं, इंसानों की समस्या है
      पहले भी ऐसे लोग थे जो StackOverflow से copy-paste करके बिना समझे code जमा कर देते थे
      AI ने बस उसे बढ़ा दिया है
    • अगर मैं hiring manager होता, तो PR के accepted vs rejected ratio को देखता
      अगर कोई कई repositories में मिलते-जुलते PR बेतहाशा भेज रहा हो और ज़्यादातर reject हो रहे हों, तो वह एक साफ़ संकेत है
      अंततः हमें मात्रा नहीं, गुणवत्ता-केंद्रित contribution culture की ओर लौटना होगा
    • लोगों को दोष देने से बेहतर है कि system की incentive structure बदली जाए
      समस्या को पहचानना आसान है, लेकिन सहमति और व्यावहारिक समाधान बनाना कठिन है, और engineers उस हिस्से में अक्सर कमज़ोर होते हैं
    • मज़ाक में कहूँ तो अब शायद AI reviewer startup की बाढ़ आ जाएगी

  • मुझे पैसे दान करने का विचार पसंद है
    Django के core contributors शायद token से ज़्यादा funding का बेहतर उपयोग कर सकें
    दूसरे projects AI usage disclosure, external contributions को अस्थायी रूप से रोकने, या issue filing restrictions जैसे कदम उठा रहे हैं
    low-quality PR इतनी आसानी से बन रहे हैं कि community का समय और focus प्रभावित हो रहा है
    इसलिए शायद हमें ज़्यादा बंद collaboration model की ओर बढ़ने की ज़रूरत हो
    Debian का इस समस्या को सावधानी से संभालने का फ़ैसला भी प्रभावशाली लगा

    • मैंने इस विषय पर एक essay भी लिखा है
      मेरा मानना है कि token खरीदने के बजाय सीधे core contributors को पैसे दान करना बेहतर है, और वे उन्हें जैसे चाहें वैसे इस्तेमाल करें

  • “reviewer के लिए किसी इंसानी मुखौटे से बात करना मानसिक रूप से थका देने वाला है” — इस बात से मैं गहराई से सहमत हूँ
    open source के rewards में से एक लोगों से जुड़ाव है, और अगर वह चला जाए, तो यह सिर्फ़ मज़दूरी जैसा लगने लगता है
    अंत में सबकी धैर्य-सीमा घटती है, और collaboration का आनंद गायब हो जाता है

    • पहले Reddit पर “let me google that for you” जैसी प्रतिक्रियाएँ भी होती थीं, लेकिन लोग फिर भी मानवीय संवाद चाहते हैं
      जैसे कोई अपने पसंदीदा कसाई से बातचीत करता है, वैसे ही लोग संबंध बनाना चाहते हैं
    • academia में भी ऐसी ही चर्चा है
      paper लिखना LLM से आसान हो गया है, लेकिन validation और review अब भी कठिन और समय लेने वाले हैं
      इसलिए AI के उपयोग का खुलासा करना, या AI detection algorithm से PR को mark करने जैसे तरीक़े ज़रूरी हो सकते हैं
      अंततः इसका असर यह होगा कि लोगों को LLM के जवाबों को अपनी भाषा में अनुवाद करना पड़ेगा
    • शायद अब देर हो चुकी है, लेकिन अच्छा होता अगर GitHub में “AI PR allow करना है या नहीं” जैसी setting होती
      लेकिन व्यवहारिक रूप से नियमों को नज़रअंदाज़ करने वाले लोग हमेशा रहेंगे

  • आजकल सारी innovation लोगों को सिर्फ़ अल्पकालिक इनाम के पीछे भागने की दिशा में धकेल रही है
    incentive structure दीर्घकालिक दृष्टि रखने वालों का समर्थन नहीं करती
    game theory को एक बार देख लें, तो यह मानने से इंकार करना मुश्किल है कि दुनिया को ऐसा ही बनाया गया है

    • सरकारों की मुद्रा विस्तार नीति ने लोगों को survival के लिए short-term profit पर अटकने के लिए मजबूर किया है
    • लेकिन game theory, जीवन की तरह होने वाली लगातार पारस्परिक क्रियाओं को पूरी तरह समझा नहीं पाती
      इसलिए long-term strategy का मूल्यांकन करने में उसकी सीमाएँ हैं

  • संदेश अच्छा है, लेकिन जो लोग हर चीज़ LLM से करते हैं, वे शायद ऐसे लेख पढ़ते ही नहीं होंगे
    open source maintainer के रूप में मेरे लिए भी AI-लिखे code को पहचानना मुश्किल है

    • “हर चीज़ LLM से करने वाले लोग” कहना अतिशयोक्ति है
      वास्तव में ऐसे professional developer बहुत कम हैं
    • गलत जानकारी या hallucination को पकड़ना शायद पूरी तरह LLM-generated चीज़ों को पहचानने का पहला कदम हो सकता है

  • कभी-कभी सोचता हूँ कि क्यों न सिर्फ़ LLM के लिए open source project बनाया जाए
    जिसमें सिर्फ़ LLM द्वारा बनाया गया code इकट्ठा हो, और contribution protocol साफ़-साफ़ तय हो
    लेकिन संभव है कि बहुत से LLM contribution सिर्फ़ portfolio के लिए हों

    • वास्तव में OpenClaw ऐसा ही एक प्रयोगात्मक project है
      इसमें हज़ारों contributors और दसियों हज़ार commits हैं
    • ऐसे projects low-quality LLM code के honeypot की भूमिका निभा सकते हैं
    • मज़ाक में कहें तो, “Moltbook meets GitHub” एक unicorn company बन सकती है

  • AI अक्सर productivity नहीं बढ़ाता, बल्कि verification का बोझ किसी और पर डाल देता है
    अंततः maintainers पर ज़्यादा काम आ जाता है, और contributor सिर्फ़ श्रेय ले जाने वाली संरचना बन जाती है

  • मैंने भी Django जैसे project में LLM का इस्तेमाल करके patch बनाए हैं
    LLM न होता तो शायद मैं कोशिश भी नहीं करता
    लेकिन नतीजे को मैंने ख़ुद review किया और tests भी लिखे

    • समस्या यह नहीं है कि LLM इस्तेमाल हुआ या नहीं, बल्कि यह है कि contributor सामग्री को समझता है या नहीं
      आजकल code, PR description, और review response तक सब कुछ LLM ही कर रहा है
      reviewer के नज़रिए से तो कभी-कभी लगता है, “तो फिर मैं ही LLM से review क्यों न करवा लूँ?”
      इसलिए LLM को सहायक tool की तरह इस्तेमाल करना चाहिए, विकल्प की तरह नहीं