Godot अब AI द्वारा लिखे गए code contributions स्वीकार नहीं करेगा

 (pcgamer.com)
2 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ओपन सोर्स गेम इंजन Godot ने तय किया है कि AI-जनरेटेड Pull Request से review का बोझ बढ़ने पर, वह AI द्वारा लिखे गए code और AI agents द्वारा किए गए submissions को contribution policy में प्रतिबंधित करेगा
  • maintainers का मानना है कि AI-जनरेटेड PR की समीक्षा पहले से ही थकाऊ review काम को और अधिक耗साध्य बना देती है, और नए contributors को भविष्य के maintainers के रूप में विकसित करने का प्रभाव भी कम कर देती है
  • नई policy में AI द्वारा लिखे गए code, AI agents द्वारा submit किए गए Pull Request, और लोगों के बीच communication में शामिल AI-जनरेटेड text को स्पष्ट रूप से अस्वीकार किया जाएगा
  • contributors AI का उपयोग केवल “menial things” के लिए सहायक रूप में कर सकते हैं और उन्हें इसका खुलासा करना होगा, जबकि मनुष्य द्वारा लिखे गए मूल पाठ पर आधारित machine translation की अनुमति होगी
  • Godot Foundation का कहना है कि AI tools बहुत तेज़ी से बदल रहे हैं, इसलिए फिलहाल वह सावधानीपूर्ण रुख अपनाएगा और परिस्थितियों में बदलाव के अनुसार policy का फिर से मूल्यांकन करेगा

Godot की contribution policy में बदलाव

  • Godot Foundation और maintainers ने कई महीनों की चर्चा के बाद contributor guidelines को संशोधित कर AI-संबंधित submissions को सीमित करने का फैसला किया है
  • जिन चीज़ों पर रोक लगेगी उनमें AI द्वारा लिखा गया code, AI agents द्वारा submit किए गए Pull Request, और लोगों के बीच communication में शामिल AI-जनरेटेड text शामिल हैं
  • Godot एक ओपन सोर्स गेम इंजन है, जिसका इस्तेमाल Slay the Spire 2 और The Case of the Golden Idol जैसे गेम्स में होता है

AI Pull Request से बढ़ा maintainer पर बोझ

  • maintainers फरवरी से बढ़ रहे AI slop Pull Request से कैसे निपटना है, इस पर चर्चा कर रहे थे
  • इस तरह के PR का प्रवाह project के code reviewers के लिए “increasingly draining and demoralizing” स्थिति बन गया है
  • Godot Foundation का मानना है कि यह समस्या अस्थायी नहीं है, और वह maintainers का बोझ कम करते हुए नए contributors को भविष्य के maintainers के रूप में विकसित करने का रास्ता भी बनाए रखना चाहता है

जब review mentoring में नहीं बदलता

  • review के इंतज़ार में PR की संख्या बढ़ना अपने आप में Godot के उपयोग और contribution में बढ़ती रुचि का संकेत माना जा सकता है
  • लेकिन AI द्वारा लिखे या submit किए गए contributions बढ़ने के साथ, maintainers की PR review पर समय लगाने की इच्छा कम होती जा रही है
  • अगर PR feedback संभावित भविष्य के maintainers को mentor करने के बजाय “मशीन में समा” जाता है, तो अपने free time को review पर खर्च करना उचित ठहराना मुश्किल हो जाता है

नई policy की ठोस सीमाएँ

  • Godot की contribution policy में जल्द ही AI-authored code को स्पष्ट रूप से अस्वीकार करने वाला प्रावधान शामिल किया जाएगा
  • contributors को AI सहायता का उपयोग केवल “menial things” के लिए करना चाहिए और इसके उपयोग का खुलासा करना चाहिए
  • Foundation ने कहा, “AI जिम्मेदारी नहीं ले सकता, और हम AI का भारी उपयोग करने वालों पर इतना भरोसा नहीं कर सकते कि वे अपने code को ठीक करने लायक उसे पर्याप्त रूप से समझते हों”
  • लोगों के बीच communication में भी AI-जनरेटेड text स्वीकार नहीं किया जाएगा
    • Foundation ने इसे “a basic principle of respect” कहा
    • मनुष्य द्वारा लिखे गए मूल पाठ पर आधारित machine translation की अनुमति जारी रहेगी

policy का संचालन कैसे होगा

  • Godot Foundation का फोकस कम मेहनत वाले “slop” contributions पर अतिरिक्त बाधाएँ लगाने पर है
  • policy के लक्ष्यों में यह भी शामिल है कि maintainers code review जारी रख सकें और नए contributors भविष्य के maintainers के रूप में विकसित हों
  • सभी contributions ऐसे मनुष्य से आने चाहिए जो अपने code की जिम्मेदारी ले और असफल होने पर उसे खुद ठीक कर सके
  • Foundation ने कहा कि फिलहाल AI tools रोज़ बदल रहे हैं, इसलिए वह सतर्क policy बनाए रखेगा, लेकिन बदलाव के अनुसार इसका फिर से मूल्यांकन करेगा

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की राय

  • यह नीति वाजिब है। लंबी-चौड़ी AI द्वारा लिखी टेक्स्ट की दीवारें ध्यान से review करने के लिए मिलना सच में झुंझलाने वाला है, और इंसानी दिमाग पर denial-of-service attack जैसा लगता है
    हालांकि, यह AI-आधारित coding को खुद नहीं रोक पाएगी। नकारात्मक तौर पर, submitter इसे इंसान जैसा दिखाने के लिए शैलीगत निशान जोड़ सकते हैं, जिससे मुख्य सामग्री और योगदान का आकार वही रहेगा लेकिन style अजीब हो सकता है
    सकारात्मक तौर पर, इससे “यह code है, इसे बदलने की वजह यह है, और असर यह होगा” जैसे बिना फालतू बातों वाले commits और comments आ सकते हैं। AI ने बनाया हो तब भी ऐसे छोटे योगदान verify करना कहीं आसान हो जाता है, और उचित contribution size या ज्यादा सख्त review की जरूरत वाले बदलावों के लिए standards भी बन सकते हैं
    व्यक्तिगत रूप से, अगर content दूसरी स्थिति में fit बैठता है तो उसके AI-generated होने या न होने से मुझे ज्यादा फर्क नहीं पड़ता

    • review करने के अनुभव से कहूं तो ज्यादातर contributors policy पढ़ते ही नहीं, और खासकर तेज AI PR बनाने वाले तो और भी नहीं। नई policy इससे बहुत बड़ा बदलाव ला पाएगी, ऐसा नहीं लगता
      “बिना फालतू बातों वाले commits और comments” सच में आ जाएं तो सपने जैसा होगा
    • समस्या यह है कि कई AI contributions आलस में बनाए जाते हैं और उन्हें ठीक से review नहीं किया जाता। अगर कोई contribution correctness check, असल में चलाकर testing, side effects की जांच, readability tuning और project guidelines के पालन से होकर आया हो, तो उसे पूरी तरह इंसान द्वारा बनाए contribution से अलग करना मुश्किल होगा, लेकिन बहुत लोग इतनी मेहनत नहीं करते, इसलिए ज्यादातर उस स्तर तक नहीं पहुंचते
    • “इंसानी दिमाग पर denial-of-service attack” वाला वाक्य शायद जानबूझकर की गई adversarial design का उदाहरण भी हो सकता है। भारी-भरकम output को summarize करने के लिए अंततः user को LLM-आधारित tools इस्तेमाल करने पर मजबूर करने का तरीका
      इस संदर्भ में AI contributions को दूर रखना उचित है, और Godot जैसे software के लिए तो और भी, जिसने पहले ही बड़ी value साबित की है
    • Linux kernel में भी मूल रूप से ऐसा ही rule था, और यह प्रति patch 200 lines या कम था। git commits और pull request descriptions में भी प्रति commit 400 characters/10 lines, शुरुआती pull request में 3 commits या कम, pull request description 20 lines, और एक साथ open pull requests 3 या कम जैसी सीमाएं लाई जा सकती हैं
    • अगर AI द्वारा लिखा commit इंसान द्वारा लिखा हुआ लगे, तो developer ने अपना काम कर दिया है, और दिखाने के लिए कुछ नहीं होगा
      अगर AI द्वारा लिखा commit मूल रूप से अलग नहीं है, तो उसे reject करने की वजह भी नहीं है; इसलिए मुझे नहीं लगता कि लक्ष्य AI-आधारित coding को रोकना है

  • दिलचस्प है कि एक तरफ AI कंपनियों की valuation इस धारणा पर टिकी है कि निकट भविष्य में सारा code और digital output AI द्वारा लिखा जाएगा, और दूसरी तरफ लगभग सभी लोकप्रिय open source projects AI contributions को रोकना चाहते हैं। दोनों को साथ बैठाना मुश्किल है
    व्यक्तिगत रूप से, अपने open source projects में काफी इस्तेमाल करने के बाद मैं भी किसी AI hangover जैसा अनुभव कर रहा हूं। इस्तेमाल करते वक्त लगता है कि कई हफ्ते लगने वाला feature कुछ घंटों में बनाकर जबरदस्त ताकत मिल गई, लेकिन समय बीतने पर code देखते हैं तो tool द्वारा छोड़ी गई subtle दरारें और inconsistencies दिखती हैं, जिससे परेशानी होती है
    अब मैं बड़े feature development के बजाय planning, debugging, और सीमित scope वाले refactoring जैसी जगहों पर, जहां सख्त guardrails लगाए जा सकते हैं, इसका कम इस्तेमाल करने की कोशिश करता हूं। फिर भी काम तेज होता है, लेकिन 10x नहीं, बल्कि करीब 1.5–3x
    coding के लिए जरूरी mental focus तो घटता है, लेकिन machine से लगातार chat करते हुए यह न जानने की नई थकान पैदा होती है कि natural language instructions कैसे interpret होंगे। यह ऐसे machine को button combinations से चलाने जैसा लगता है जिसकी internal wiring लगातार बदल रही हो, इसलिए संतोषजनक नहीं है

    • परंपरागत रूप से open source contributions self-selecting रहे हैं। PR बनाने के लिए project में कुछ हद तक interest होना जरूरी था, और मूल्यवान contribution देने के लिए codebase और conventions को समझना और project से थोड़ा interaction करना पड़ता था
      AI ने जो संभव किया है, वह उन लोगों के contributions हैं जिनका project से कोई जुड़ाव नहीं है। अब केवल PR बनाने के fact से यह नहीं माना जा सकता कि “इस व्यक्ति को project की success में कुछ interest है” वाली threshold पार हो गई है
      AI सही तरह से इस्तेमाल हो तो amplifier है, लेकिन open source maintainers के लिए project में interest न रखने वाले लोगों द्वारा डाले गए बड़ी मात्रा के कम-value “contributions” में डूब जाना आसान है
    • नशे वाली analogy काफी सही है। पहले “अलौकिक क्षमता मिल गई” जैसा एहसास आता है, और बाद में “ओह, मैंने तो गड़बड़ कर दी” वाला hangover आता है
      खासकर AI की चापलूसी प्रवृत्ति के कारण यह लगातार “बहुत अच्छा idea है!” कहता रहता है, जबकि मुझे अच्छी तरह पता है कि मेरे अधिकतर ideas महान नहीं होते
      बच्चों के साथ रहते हुए फोन पर vibe coding करने जैसी बातें सुनकर यह लगभग compulsive लगने लगता है
    • लंबे समय तक तेजी से आगे बढ़ना एक बड़ा moat था, लेकिन अब तेजी से आगे बढ़ना आसान हो गया है। नया moat quality हो सकता है
      वैसे भी open source में तेजी का बहुत बड़ा मतलब कभी नहीं था, और इसकी वजहें थीं
    • मैं भी काफी हद तक इसी नजरिए पर वापस आ गया हूं। मौजूदा पीढ़ी के AI tools के outputs को वास्तव में इस्तेमाल करने की कोशिश करें तो वे अभी काफी कमतर लगते हैं
      काम करते समय या नया project शुरू करते समय बहुत आसानी से AI की ओर हाथ बढ़ जाने वाला dopamine structure भी समस्या है
      अभी मैं अपने दिमाग को फिर से इस तरफ train करने की कोशिश कर रहा हूं कि Claude से शुरू करने के बजाय ज्यादातर code हाथ से लिखना पसंद करूं। यह अस्थायी phase है या फिर LLM anonymous जैसी meetings की जरूरत पड़ेगी, यह समय बताएगा
    • यह धारणा कि जल्द ही सारा code और digital output AI द्वारा लिखा जाएगा, वह कहानी है जिसे AI कंपनियां अपने shovel बेचने के लिए लोगों से मनवाना चाहती थीं। एक बार समझ आ जाए कि यह धारणा भ्रम है, तो दोनों बातों को साथ बैठाने में मुश्किल नहीं रहती

  • AI-रहित software की curated lists मौजूद हैं। समय के साथ वे कैसे बदलती हैं, इसे index या graph में देखना अच्छा होगा
    https://codeberg.org/brib/slopfree-software-index
    https://noai.starlightnet.work/list.html

    • मैंने एक filter बनाया है जो Hacker News पर आए GitHub repositories में से सिर्फ वे दिखाता है जिनमें AI द्वारा लिखे होने के निशान नहीं हैं
      https://hcker.news/?ai=exclude&include_domains=github.com
    • दिलचस्प कोशिश है। जानना चाहूंगा कि ऐसी list का criteria क्या है
      functional reasons के हिसाब से no-AI policy आसानी से समझ नहीं आती। जिसने भी बनाया हो या जिस चीज ने भी बनाया हो, अगर वह चलता है तो चलता है
      AI-generated garbage से बच भी जाएं तो filter से pass होने वाले human-generated या human+AI-generated garbage से नहीं बच सकते
      फिर भी provenance, accountability, proof of work, लोगों को खुद code लिखने के लिए encourage करना, और इंसान codebase को कैसे evolve करते हैं इसे empirically track करना जैसे non-functional reasons जरूर सोचे जा सकते हैं

  • Foundation की यह बात बिल्कुल मुद्दे पर है: “अगर PR पर दिया गया feedback किसी ऐसे व्यक्ति को mentor करने में नहीं लग रहा जो भविष्य में maintainer बन सकता है, बल्कि बस मशीन में absorb हो रहा है, तो अपने खाली समय को PR review में लगाने को justify करना कहीं ज़्यादा मुश्किल हो जाता है।”

    • Zig का contributor poker अब और भी दूरदर्शी लगता है
    • इससे भी बुरा यह है कि वह feedback शायद अगले LLM training में चला जाएगा। आखिर में यह AI कंपनियों के लिए एक और तरह का मुफ्त श्रम बन जाता है

  • अगर समझ नहीं आ रहा, तो इन्हें देख लें
    https://github.com/godotengine/godot/pull/115280
    https://github.com/godotengine/godot/pull/116410
    जिस project में AI युग से पहले भी review करने के लिए PR बहुत ज़्यादा थे, वहाँ maintainers से ऐसी चीज़ें भी लगातार संभालने को कहना fair नहीं है
    इसलिए policy में सचमुच बड़ा बदलाव यह है कि नए contributors अब बड़े features या refactoring नहीं ले सकते

    • पहले उदाहरण में बात सिर्फ यह नहीं थी कि वह AI-driven था, बल्कि यह भी कि वह व्यक्ति कम उम्र का था
      repository में बची जानकारी से उसका alias और social accounts मिल गए, और वह अभी शुरुआती teen उम्र तक भी नहीं पहुँचा बच्चा था। लगता था कि समस्या या उससे जुड़े social structures समझने के लिए उसके पास अभी बुनियादी knowledge भी नहीं थी
    • “यह contribution उस university class project का हिस्सा है जिसमें असली open source contribution करना होता है” — वह university सच में मूर्ख है। क्या यह पता लगाने का कोई तरीका है कि कौन-सी university students से open source projects को spam करवाती है
    • बहुत अजीब है। उस contributor की असली motivation क्या होगी

  • यह Brandolini's law के काम करने का बिल्कुल वैसा ही उदाहरण है
    बकवास का खंडन करने में उसे पैदा करने से 10 गुना ज़्यादा मेहनत लगती है। code review खंडन ही है, और किसी proposition की correctness verify करना भी ऐसा ही है
    proposition generate करना आसान है, लेकिन खंडन करने के लिए true/false साबित करना या contradiction ढूँढना पड़ता है। समय की कमी से जूझ रहे open source maintainers की energy बेवजह बर्बाद होती है, इसलिए energy बचाकर उसे productive तरीके से इस्तेमाल करने की बात से मैं पूरी तरह सहमत हूँ

  • AI ने गलती से industry के सबसे महँगे resources में से एक खोज लिया है: अपने day job के बाद शाम को open source maintain करने वाले लोगों का खाली समय

  • Foundation ने उस बात को पकड़ा जो हमेशा सच थी, लेकिन AI ने उसे सामने ला दिया: AI सहित कोई भी contributor आगे चलकर उस patch को maintain न कर पाए, ऐसा हो सकता है
    मुख्य बात AI का use अपने-आप में नहीं है, बल्कि यह है कि submitter को खुद नहीं समझ कि वह क्या submit कर रहा है—AI use इसका एक संकेत हो सकता है। variable naming conventions तोड़ना, ऐसी API बदलना जिन्हें नहीं छेड़ना चाहिए, या भाषा की अपरिपक्व गलतियाँ करना—ये सब वजहें patch काम करने के बावजूद उसे reject करने के लिए काफी हो सकती हैं
    workaround के तौर पर, PR को AI की वजह से reject बताया जा सकता है और author से कहा जा सकता है कि वह किसी एक हिस्से को चुने जिस पर उसे खास गर्व है, और AI वाली text wall के बजाय अपने शब्दों में बताए कि वह क्या कर रहा है और क्यों अच्छा है। author को ऐसा taste और opinions दिखाने चाहिए जो AI में नहीं होते

    • 2026 का AI opinions जैसे दिखने वाले text काफी हद तक बना सकता है। इस तरीके से AI और इंसानी author में फर्क करने में मदद नहीं मिलेगी

  • यहाँ कई लोग असली policy पढ़ने के बजाय title पर react करते लगते हैं। policy में कहा गया है कि PR review को नए contributors की training और संभावित future maintainers खोजने में इस्तेमाल करना एक अहम वजह है
    AI contributions की quality से अलग, इस हिस्से का खंडन करना मुश्किल लगता है
    अपवाद तब है जब आप मानते हों कि AI open source contribution या maintenance की पूरी अवधारणा को ही unnecessary बना देगा; लेकिन तब Godot को PR भेजने के बजाय engine को fork करके agents से काम करवाना ज़्यादा सही लगेगा

  • क्या AI contributors सचमुच सोचते हैं कि वे मदद कर रहे हैं? क्या उन्हें नहीं पता कि ऐसे “काम” से वे project को नुकसान पहुँचा रहे हैं
    जो चीज़ कोई नहीं चाहता और reject होनी है, उस पर पैसे क्यों खर्च किए जाते हैं, समझ नहीं आता। क्या इनके पास कोई hobby नहीं है, या फिर creator भूल गया है और आज़ाद घूमती हुई OpenClaw instances अपनी मर्ज़ी से चल रही हैं

    • वह दौर चला गया जब FOSS contribution सिर्फ अपनी problem solve करने, altruism या curiosity से चलता था। कंपनियों को hiring के समय applicant का GitHub page देखना शुरू किए हुए 10 साल से ज़्यादा हो चुके हैं
      ऐसे लोग बड़े FOSS projects में contribution को resume padding की तरह harvest कर रहे हैं। vulnerability reports में भी यही हो रहा है
      bulk generators सच में सोच सकते हैं कि वे मदद कर रहे हैं, या उन्हें पता भी हो सकता है कि उनका “contribution” project के लिए net negative है। लेकिन जब direct economic incentive हो और हालात अस्थिर हों, तो externalities priority से बाहर हो जाती हैं
    • “AI contributor” में भी degrees होते हैं। हाल ही में Rust में लिखे एक open source tool में मुझे एक rare edge case मिला; जिस language से मैं परिचित नहीं हूँ, उसमें छोटा, clean और Rust-idiomatic change करने में मुझे एक हफ्ते से ज़्यादा लग जाता
      Claude ने 1 घंटे में कर दिया, और मैंने 3–4 बार polish करके text wall घटाई और original project style से match किया। विकल्प था बस छोड़ देना या केवल issue खोलकर burden maintainer पर डाल देना
      इसलिए मुझे लगता है कि मैंने मदद की। यह edge case भी मुझे अपनी hobby, homelab से छेड़छाड़ करते समय मिला था
    • मैंने AI का इस्तेमाल करके contribute किया है। Brew और far2 ने मेरा काम accept किया, और KDE spectacle maintainer ने जवाब नहीं दिया
      दोनों PR छोटे थे और human PR से अलग नहीं थे। मुझे अब भी भरोसा है कि वे valuable additions थे, और कुछ maintainers ने भी साफ तौर पर ऐसा ही माना
    • यह art में AI use जैसा कुछ-कुछ है। लोग असल में use करना नहीं चाहते, बल्कि “मैंने इस्तेमाल किया” वाली स्थिति और उससे मिलने वाला समझा जाने वाला social status चाहते हैं
      वे coding करना या product को बेहतर बनाना नहीं चाहते; वे details समझे बिना “lines of code”, “commits”, और सुंदर GitHub green profile चाहते हैं