निर्भरताओं में LLM कोड नहीं
LLM-जनित कोड का पता लगाना
- कुछ लोग ऐसे टूल चाहते हैं जो हीयुरिस्टिक्स का उपयोग करके LLM-जनित कमिट्स को चिह्नित करें: बड़े ब्लॉब्स जिनमें व्यापक टिप्पणियाँ हों, असामान्य लाइनों-ऑफ-कोड प्रति घंटा, और प्री-LLM-युग के रिपॉज़िटरीज़ पर प्रशिक्षित कमिट शैलियाँ।
- अन्य लोग तर्क देते हैं कि “AI detection” स्वभावतः अविश्वसनीय है, इसकी तुलना पॉलीग्राफ से करते हैं, और उच्च false positives की चेतावनी देते हैं।
- एक नरम रुख: detection को पूर्ण होने की ज़रूरत नहीं—बस इतना अच्छा होना चाहिए कि “स्पष्ट” मामलों को मानव समीक्षा के लिए सामने ला सके।
- कमिट co-author टैग्स की जाँच जैसे सरल heuristics को low-hanging fruit के रूप में प्रस्तावित किया गया है।
बिना-LLM निर्भरताओं की व्यावहारिकता
- एक पक्ष LLM-प्रदूषित निर्भरताओं को अस्वीकार करने को एक सैद्धांतिक लेकिन संभावित रूप से अव्यावहारिक रुख मानता है, खासकर जब यह महत्वपूर्ण टूल्स और भाषाओं के नए संस्करणों को रोक देता है।
- अन्य लोग इसे “AI slop” के खिलाफ एक उचित बचाव मानते हैं, भले ही इसका मतलब अधिक काम, निर्भरताओं को स्थिर करना, या कम निर्भरताओं का उपयोग करना हो।
- यह समझ भी है कि लंबी अवधि में यह अस्थिर हो सकता है और शुद्धता तथा भाषा/टूल सुधारों तक पहुँच के बीच समझौते मजबूर कर सकता है।
OSS शासन और योगदान नीतियाँ
- सुझावों में शामिल हैं: बाहरी योगदानों को बिल्कुल स्वीकार न करना, अतिरिक्त समीक्षा के लिए PRs पर paywall लगाना, या “AI-free” hosting की ओर जाना।
- कुछ लोग तर्क देते हैं कि open source LLM-जनित patches को अस्वीकार कर सकता है और फिर भी खुला रह सकता है; असहमत उपयोगकर्ताओं के लिए fork करना हमेशा एक विकल्प है।
- एक बार-बार उठने वाली चिंता है कम-गुणवत्ता वाले AI PRs से maintainer burnout और यह जोखिम कि volunteer projects review बोझ के नीचे “implode” कर जाएँ।
- कई टिप्पणियाँ युवा मनुष्यों को mentor करने (जो आगे चलकर maintainers बन सकते हैं) और LLM output की समीक्षा करने के बीच गुणात्मक अंतर पर ज़ोर देती हैं, क्योंकि बाद वाले से समुदाय को कोई दीर्घकालिक लाभ नहीं मिलता।
LLM कोड बनाम मानव कोड की गुणवत्ता
- एक धड़ा दावा करता है कि LLMs मध्यम-से-निम्न-स्तर के developers जैसे हैं और जिम्मेदारी से उपयोग करने पर उपयोगी हो सकते हैं; समस्या sloppy users हैं, tool नहीं।
- आलोचक कहते हैं कि LLMs सामान्य devs से भी खराब हैं, समझ की कमी रखते हैं, और सुपरह्यूमन गति से सूक्ष्म, बड़े पैमाने की गड़बड़ियाँ पैदा करते हैं।
- एक ऐसे भविष्य का डर है जो opaque, churn-heavy “slopcode” से भर जाएगा, जहाँ समझ और विश्वसनीयता बिगड़ जाएगी।
सुरक्षा, नैतिकता, और corporate बनाम OSS दृष्टिकोण
- कुछ लोग भविष्य-स्तरीय सुरक्षा ऑडिटिंग के लिए LLMs को आवश्यक मानते हैं; अन्य जवाब देते हैं कि analysis और code generation अलग मुद्दे हैं।
- “job market” द्वारा LLMs का उपयोग करने के लिए “मजबूर” किए जाने और इस विश्वास के बीच तनाव है कि फिर भी यह स्थिति खराब है।
- कई टिप्पणियाँ training data और code reuse से जुड़े unresolved copyright/licensing प्रश्नों को उजागर करती हैं।
- आदर्शवादी, सार्वजनिक रूप से scrutiny झेलने वाली open source परियोजनाओं और internal रूप से कम provenance-चिंता के साथ LLMs का उपयोग करने वाली corporations के बीच अंतर खींचा गया है।