मुझे चिंता है कि हमारा Copilot कुछ यात्रियों को पीछे छोड़ रहा है

GitHub Copilot और ऐसे अन्य AI coding assistants को कुछ अनुभवी engineers शक्तिशाली autocomplete tools के रूप में सराहते हैं, लेकिन दूसरे इन्हें ऐसे code को बढ़ावा देने के लिए आलोचना करते हैं जो फूला हुआ, inaccessible, या सूक्ष्म रूप से गलत होता है और जिसे बाद में teammates को सुलझाना पड़ता है। टिप्पणीकारों को चिंता है कि LLM-जनित code पर अत्यधिक निर्भरता, खासकर कम अनुभवी developers द्वारा और security तथा accessibility जैसे क्षेत्रों में, software quality में लंबे समय से जारी गिरावट को तेज़ करेगी और “enshittification” दबावों को बढ़ाएगी। बहुत से लोग तर्क देते हैं कि इन टूल्स का उपयोग मजबूत tests, reviews, और स्पष्ट मानदंडों के साथ सबसे अच्छा है: उन्हें junior collaborators या translators की तरह देखें, न कि समझ, design, और long-term maintainability के विकल्प के रूप में.

टीम के मानदंड और codegen टूल्स का दुरुपयोग

  • कई लोग ऐसे सहकर्मियों का ज़िक्र करते हैं जो LLM-जनित बड़े बदलाव, जिनमें असंबंधित कोड भी होता है, सीधे चिपका देते हैं, उन्हें समझा नहीं पाते, और उम्मीद करते हैं कि साथी उन्हें debug और style-fix कर दें।
  • बहुतों का तर्क है कि इसे किसी भी अन्य खराब engineering की तरह ही माना जाना चाहिए: PRs reject करें, explanations माँगें, और codebase के मानदंडों के अनुरूपता की माँग करें; कुछ लोग मानते हैं कि सोच-विचार को बार-बार दूसरों पर डालना नौकरी से निकालने का आधार हो सकता है।
  • चिंता यह है कि “LLM developers” मेहनत author से हटाकर reviewers पर डाल देते हैं, जिसे असम्मानजनक माना जाता है।

Copilot कहाँ मदद करता है बनाम कहाँ नुकसान

  • इसे सबसे उपयोगी माना जाता है: boilerplate, repetitive structures, formats के बीच translation (जैसे JSON → types), त्वरित doc lookups, test scaffolding, और “rubber-duck” debugging के लिए।
  • कुछ लोग इसे default से बंद रखते हैं और सिर्फ़ तब enable करते हैं जब उन्हें ठीक-ठीक पता हो कि वे क्या चाहते हैं।
  • अन्य लोग बताते हैं कि यह अब बदतर या असंगत हो गया है, अक्सर बहुत कम context के साथ guesses देता है या बिल्कुल कोई solution नहीं देता।
  • प्रभावी उपयोग के पैटर्न: इसे शक्तिशाली autocomplete की तरह लें, एक बहुत junior dev की तरह इसके साथ pair करें, और केवल वही स्वीकार करें जो आप पहले से ही करना चाहते थे।

Code quality, accessibility, और security

  • कई लोग सहमत हैं कि Copilot public code की (अक्सर खराब) गुणवत्ता को ही दोहराता है: div-soup HTML, कमजोर accessibility, खराब Bash, आदि।
  • चिंता है कि LLM-जनित code खराब practices (accessibility, security, internationalization) को सामान्य बना देगा, जो “काम करती हुई” लगती हैं और इसलिए अनदेखी रहकर ship हो जाती हैं।
  • कुछ का मानना है कि इन मुद्दों को बेहतर training data और generation loop में linters, accessibility checkers, और tests को जोड़कर कम किया जा सकता है।

सीखना, hiring, और overreliance

  • इस टूल को experts के लिए (जो गलतियाँ पकड़ सकते हैं) एक बढ़ावा और novices के लिए (जो नहीं पकड़ सकते) एक trap माना जाता है।
  • चिंता है कि juniors सोचने का काम बाहर दे देंगे, गलत patterns सीखेंगे, और fundamentals कभी नहीं बनाएँगे।
  • Hiring: interviewers को remote tests में candidates के गुप्त रूप से AI इस्तेमाल करने के मामले दिखते हैं; countermeasures में full-screen sharing, केवल pseudocode वाले tasks, या rote coding की बजाय reasoning पर ध्यान देना शामिल है।

व्यापक उद्योग और भविष्य की दिशाएँ

  • कई लोग LLMs को “enshittification” से जोड़ते हैं: वे पहले से खराब incentives (तेज़ी से चलना, कभी सफ़ाई न करना, mediocre UX/perf स्वीकार करना) को और तेज़ कर सकते हैं।
  • दूसरे तर्क देते हैं कि garbage apps का कारण market हैं, tools नहीं; LLMs छोटे teams को जमे-जमाए खराब systems से बेहतर प्रतिस्पर्धा करने में मदद भी कर सकते हैं।
  • कुछ लोग अधिक समृद्ध workflows की कल्पना करते हैं: organization-specific models, compilers/grammars द्वारा constrained generation, refactoring suggestions, और tests तथा linters द्वारा validated multi-pass generation।