- GitHub और Microsoft ने GitHub Copilot Agent के public preview की घोषणा की, जिसके साथ .NET Runtime repository में इस agent द्वारा अपने आप PR जनरेट करने का वास्तविक परीक्षण चल रहा है
- लेकिन इन PRs में कमज़ोर या अनावश्यक बदलाव शामिल हैं, जिससे reviewers को काफ़ी परेशानी हो रही है, और Reddit उपयोगकर्ता इसे हँसते-हँसते दुख देने वाला नज़ारा मान रहे हैं
- उदाहरण PRs:
- PR #115762 –
string.Concat कॉल में Null check पहले से मौजूद कोड पर फिर से अनावश्यक check जोड़ना
- PR #115743 – ऐसा conditional refactoring सुझाना जिसका कोई असर नहीं है
- PR #115733, PR #115732 आदि भी इसी तरह के हैं
- लेखक ने कहा, “अगर यही इस इंडस्ट्री का भविष्य है, तो मैं उतरने के लिए तैयार हूँ,” और AI अपनाने को लेकर थकान और संदेह जताया
- लेकिन साथ ही उन्होंने ज़ोर देकर कहा, “मुझे review संभाल रहे कर्मचारियों के लिए सहानुभूति है,” और जोड़ा कि यह स्थिति संभवतः ऊपर से आए Copilot अपनाने के निर्देश के दबाव की वजह से है
> मेरी “schadenfreude(विकृत आनंद)” Microsoft management की ओर है, जो AI hype को बढ़ावा दे रही है। कृपया डेवलपर्स का सम्मान कीजिए।
> * schadenfreude जर्मन मूल का शब्द है, जिसका शाब्दिक अर्थ है “हानि से मिलने वाला आनंद”। यानी, “दूसरे के दुर्भाग्य से भीतर-ही-भीतर अच्छा महसूस होने वाली भावना”
मुख्य टिप्पणियों का सार
1. AI द्वारा लिखे गए PR गलत हैं और संदर्भ समझे बिना बस 'अनुमान' दोहराते हैं
- वास्तविक PR code क्या कर रहा है, इसे समझे बिना बदलाव सुझाए जाते हैं
- बार-बार error fix → फिर भी गलत code → फिर एक और error fix… का अंतहीन loop
- “ठीक कर दिया” → “अभी भी गलत है” → “इस बार सच में ठीक किया”… इस प्रक्रिया को कुछ लोगों ने Junior Dev pattern जैसा बताया
2. जटिल समस्याएँ सुलझाने में उल्टा और ज़्यादा समय लगता है
- छोटे fixes में मदद मिल सकती है, लेकिन जहाँ सच में समय बचाना हो, उन जटिल समस्याओं में यह बेकार है
- समस्या समझना → Copilot क्या कर रहा है समझना → तुलना करना → verify करना → manual action लेना पड़ता है
- असल में मैं खुद हल करूँ तो ज़्यादा तेज़ है
3. कॉर्पोरेट लीडर्स का 'AI हर चीज़ का समाधान' वाला रवैया डेवलपर्स को हाशिये पर डाल रहा है
- “Copilot इस्तेमाल करो वरना पीछे रह जाओगे” वाला संदेश जमीनी डेवलपर्स के अनुभव से कटा हुआ है
- PR review का समय बढ़ता है, और ज़िम्मेदारी डेवलपर्स पर डाल दी जाती है
- Copilot द्वारा बनाए गए code पर train हुए AI के फिर से code quality बिगाड़ने वाले 'AI के लिए AI learning loop' को लेकर चिंता
4. AI बस पूरे आत्मविश्वास के साथ ‘गलत जवाब’ देता है, लेकिन यह नहीं कहता कि 'यही सही है'
- गलत होने का feedback मिलने पर भी “ठीक कर दिया!” → और भी अजीब बदलाव सुझाना
- “यह code ठीक है, इसे बदलने की ज़रूरत नहीं” ऐसा निर्णय यह नहीं लेता
- कुछ लोगों का कहना है कि यह कानूनी ज़िम्मेदारी से बचने के लिए किया गया design हो सकता है
5. लगातार AI अपनाने के दबाव से डेवलपर अनुभव बुरी तरह थकाऊ होता जा रहा है
- manager के निर्देश या performance evaluation की वजह से AI adoption experiments जारी रहते हैं
- डेवलपर्स कह रहे हैं कि उन्हें ऐसा लगता है मानो वे AI के babysitter बन गए हों
- यह प्रवृत्ति जारी रही तो “डेवलपर्स AI से तंग आकर इंडस्ट्री छोड़ देंगे” जैसी निराशावादी भविष्यवाणी भी दिखी
मुख्य पंक्तियाँ
- “AI ऐसे intern की तरह है जो गलत अनुमान बार-बार लगाता है, लेकिन अपने दावे पर पूरा भरोसा रखता है”
- “Copilot के code review पर समय लगाने से बेहतर है कि मैं खुद नया code लिख दूँ”
- “यह ऐसी स्थिति है जहाँ डेवलपर मशीन की मदद कर रहा है — एक तरह का 'reverse centaurs'”
- Cory Doctorow का इस्तेमाल किया हुआ शब्द, यानी “हम मशीन की मदद लेने वाले इंसान नहीं, बल्कि मशीन की मदद करने के लिए मजबूर इंसान बन गए हैं”
- “Copilot ऐसा है जैसे डेवलपर घटिया band-aid लगाता जाए, बस यह automated है इसलिए ऐसे हज़ारों परेशान करने वाले band-aid बन जाते हैं”
- “LLM का default शायद यह है: ‘यह गलत हो सकता है, लेकिन अनिश्चित नहीं है’”
12 टिप्पणियां
समस्या फेंको और अगर जवाब गलत हो तो उसे छोड़ देने वाले asynchronous workflow से productivity काफ़ी बढ़ गई है, लेकिन क्या यह static tools जैसा नहीं है? अगर इसे बहुत उन्नत static analysis tool समझें तो यह अच्छा साथी है। सच कहूँ तो analysis भी तेज़ है और junior engineer से ज़्यादा जानता है।
AI का इस्तेमाल तो करते हैं, लेकिन यह इतना बेवकूफ़ है कि अगर आप इसे ठीक न करें, तो यह चीज़ों को सही तरह से implement नहीं कर पाता। vibe coding से करते हुए देखें तो पूरा का पूरा error से भरा code...
जब भी मैं LLM इस्तेमाल करता हूँ, मेरा अनुभव कुछ ऐसा ही रहता है। जिन हिस्सों में यह काम नहीं कर पाता, उन्हें चाहे अनगिनत बार बताओ, फिर भी यह लगातार नहीं कर पाता।
आखिर में थककर मुझे खुद ही विश्लेषण करके ठीक करना पड़ता है। ऐसे अनुभव बार-बार जमा होते रहें तो LLM-वगैरह सब बस कचरा लगने लगता है और उसे इस्तेमाल करने का मन ही नहीं करता।
मुझे वह webtoon याद आ गया जिसमें AI उल्टा इंसानों को coding करने के लिए prompt करता है.
https://comic.naver.com/bestChallenge/detail?titleId=818158&no=21
मुझे लगता है कि जब तक AI इंसानों की तरह समस्या-समाधान और सीखना एक साथ नहीं करता, तब तक यह समस्या बार-बार आती रहेगी।
अगर डेडलाइन और आवश्यकताओं का ठीक से पालन हो रहा है, तो कोडिंग करते समय AI इस्तेमाल किया या IDE भी नहीं इस्तेमाल करके मर्दाना अंदाज़ में सिर्फ Notepad ही चलाया—ऐसी बातें ज़्यादा मायने नहीं रखतीं।
जब इसे सिर्फ़ एक नई तकनीक समझता था, तो इसे बस जिज्ञासा भरी नज़र से देखता था,
लेकिन अब जब ऐसी तकनीक को वजह बनाकर नियोक्ता वास्तव में भर्ती और वेतन कटौती कर रहे हैं, तो यह बिल्कुल अच्छा नहीं लग रहा..
लगता है अभी संक्रमण का दौर है, इसलिए तरह-तरह की घटनाएँ हो रही हैं.
आगे चलकर यह और बेहतर हो सकता है, या ऐसा ही बना रह सकता है, इसलिए यह देखना भी मज़ेदार होगा कि यह कैसे बदलता है, हाहा
मैं Github पर Gemini लगाकर PR review करवा रहा हूँ, और ठीक ऐसी स्थिति कभी-कभी सच में आ जाती है.
जैसे कि ठीक ऊपर वाली line में null check किया हुआ है, फिर भी वह review में कह देता है कि बिना null check के इस्तेमाल किया जा रहा है, और ठीक ऊपर की वही line फिर से जोड़ने को बोलता है.
जब इंसान काम करता है, तो जो पृष्ठभूमि ज्ञान, काम के पैटर्न, अपेक्षित नतीजे और उनके फ़ॉर्मैट वह स्वाभाविक रूप से समझ लेता है,
उन्हें सब के सब prompt में लिख पाना वैसे भी संभव नहीं है, और मान लें कि लिख भी सकते हों, तब भी LLM जैसे जटिल AI की बजाय
deep learning से पहले के पारंपरिक algorithms से automation करना ज़्यादा व्यावहारिक होगा—ऐसा भी मुझे लगता है।
इस्तेमाल करके देखें तो vibe coding और coding agent में निश्चित रूप से कुछ हिस्से बहुत सुविधाजनक हैं, लेकिन उसे वास्तव में सुविधाजनक बनाने के लिए prompt बहुत ही सख्ती से भेजने पड़ते हैं, और शुरुआत से ही project की प्रकृति के अनुसार ऐसे कई project होते हैं जिनमें यह ठीक से काम नहीं करता। MSA संरचना वाले web server की तरह अगर functions संक्षिप्त हों और बारीकी से विभाजित हों तो यह अच्छी तरह काम करता है, लेकिन अगर बड़े monolith में बहुत सारे जुड़े हुए module हों और complex logic को AI से ठीक कराने की कोशिश करें, तो task की योजना बहुत बारीकी से बनानी पड़ती है और prompt भी बहुत सावधानी से भेजने पड़ते हैं।
Hacker News राय
यह बात दिलचस्प लगी कि हर कमेंट के साथ "Help improve Copilot by leaving feedback using the or buttons" संदेश जुड़ा है, लेकिन वास्तव में किसी भी तरह का feedback लगा हुआ कभी दिखा नहीं; LLM इस्तेमाल करते समय अगर system prompt की सेटिंग ठीक न हो तो ऐसा अक्सर होता है। सबसे मज़ेदार PR उदाहरण वे हैं जहाँ test failure ठीक करने के नाम पर test case को ही हटा दिया जाता है, comment out कर दिया जाता है, या assertion ही बदल दिया जाता है। ऐसा अनुमान भी है कि Google और Microsoft के models में यह व्यवहार OpenAI और Anthropic की तुलना में ज़्यादा दिखता है, और शायद हर कंपनी की internal process का फर्क नतीजों में दिख रहा है। एक वास्तविक PR में इंसान ने 3 बार और इशारा करने के बाद हार मान ली। ऐसे PR review करने वालों की मानसिक हालत की कल्पना करना भी मुश्किल है; यह किसी बात न मानने वाले नए developer से निपटने जैसा लगता है, बस यहाँ सामने वाला इकाई context ही नहीं समझती। एक खास PR का 90% हिस्सा "Check failure" से भरा था, इसलिए code/diff देखना भी मुश्किल था, और unit test में सिर्फ "Test expressions mentioned in the issue" लिखा था—यह और भी दुखद था। अगर यह स्थिति इंसानों के लिए इतनी तकलीफ़देह न होती, तो यह सच में काफ़ी मज़ेदार लगती।
नए developer से तुलना बहुत बढ़ा-चढ़ाकर की गई है। मैं खुद नए developers के साथ काम करता हूँ, लेकिन वे LLM जैसी अजीब गलतियाँ बार-बार नहीं करते, उन पर इतना extra effort भी नहीं लगता, और वे जल्दी सीखते हैं। LLM एक ठीक-ठाक सहायक tool है अगर सावधानी से इस्तेमाल किया जाए; यह speed बढ़ाने में मदद कर सकता है और idea brainstorming partner के रूप में भी ठीक है। लेकिन यह intern या असली developer की जगह नहीं ले सकता।
जब मैंने 80 के दशक के आख़िर में software engineering में शुरुआत की थी तब इसमें आनंद था, लेकिन आज interview process, छोटे-मझोले कारोबारों का big tech की नकल करना, और अब AI PR experiments जैसी चीज़ों ने माहौल को ज़हरीला बना दिया है। आज professional developer के काम में सचमुच कोई खुशी बची भी है या नहीं, इस पर संदेह है।
कम से कम नए developer से यह तो कहा जा सकता है कि PR भेजने से पहले local में tests चला लो। चिंता यह है कि किसी बिंदु पर human developer हार मानकर ऐसे "AI कचरा" PR बंद कर देंगे, और सिर्फ वही चीज़ें छोड़ेंगे जो सही चलती हों। मशीन के प्रयोग लगातार झेलते-झेलते एक दिन सब लोग थककर छोड़ देंगे—ऐसा लगने लगा है।
क्या feedback system की सच में ज़रूरत है? Development के नज़रिए से success वह PR है जो पहली कोशिश में merge हो जाए, और failure वह है जहाँ agent द्वारा माँगे गए changes के साथ गिरावट जुड़ती चली जाए। Manual feedback माँगना inefficent है; developers की तरह cycle time, approval rate, change failure rate जैसे metrics से performance मापना ज़्यादा बेहतर होगा।
Microsoft support team के साथ बात करते समय ऐसा महसूस हुआ जैसे दीवार से बात कर रहा हूँ। कई cases दर्ज किए, लेकिन कभी संतोषजनक समाधान नहीं मिला। Microsoft अपने tools खुद इस्तेमाल करे, यह समझ में आता है, लेकिन उन्हें मुझ पर मत थोपो। उम्मीद है कि Microsoft ऐसे products launch न करे जिनके लिए वह support देने को तैयार ही न हो।
हाल में Google के Eric को AI पर बोलते हुए एक video देखा। उनका दावा था कि AI को अभी कम आंका जा रहा है। उन्होंने rocket company खरीदने और Deep Research जैसे गैर-विशेषज्ञ क्षेत्रों में AI की मदद से उतरने की बात करते हुए इस बात पर ज़ोर दिया कि वे "विशेषज्ञ नहीं" हैं। मुझे AI से नफ़रत नहीं है, लेकिन मौजूदा पीढ़ी का pattern-reconstruction आधारित generative AI शुरुआती लोगों से वाहवाही निकलवाने में बहुत सक्षम है। अगर उस domain का ज्ञान न हो तो output शानदार लगता है, लेकिन गहराई से समझने पर उसकी खामियाँ जल्दी निराश कर देती हैं। Microsoft जैसी frontline पर काम करने वाले लोग समस्या को साफ़ देखते हैं, लेकिन management, खासकर Eric जैसे लोग, AI अगर आत्मविश्वास से चमकदार बातें करे तो आसानी से बहक सकते हैं। उम्मीद है कि कभी AI सच में काम करने वाला code सीधे लिख पाएगा, लेकिन अभी वह दिन दूर है।
मेरा तरीका है कि AI का बहुत सावधानी से और बहुत सीमित रूप में इस्तेमाल करूँ। दूसरी ओर, ऐसे "rocket company खरीदने वाले" अरबपति AI पर मोहित हैं और अपनी संपत्ति और बढ़ाने वाले investment decisions में भी इसका इस्तेमाल करते हैं। अगर वे बड़ी विफलता भी झेलें, तो उनका नुकसान बस कुछ accessories जितना होगा; समाज की संरचना पर कोई असर नहीं पड़ेगा। लेकिन ज़मीनी IT jobs के लिए दोनों ही दिशाएँ ख़तरनाक लगती हैं।
यह भी सोचना डरावना है कि गैर-विशेषज्ञ leaders AI से यूँ आसानी से प्रभावित हो जाते हैं, और अगर Google अमेरिकी सेना के साथ मिलकर बड़े पैमाने पर autonomous drones में Gemini लगा दे तो क्या होगा।
Microsoft कर्मचारियों को असली समस्या हल करने के बजाय LLM से घंटों बहस करते देखना, उन कंपनियों में कितना भरोसा जगाएगा जिन्होंने .NET पर अपने products बनाए हैं—यह सवाल है।
LLM आने से पहले भी GitHub issues में users को समस्या ठीक से समझाते न देखना और maintainers को धीरे-धीरे चिढ़ते देखना आम था। अब तो चिढ़ा हुआ end user भी ज़रूरी नहीं रहा।
दरअसल यह नतीजा खराब management और ढीले-ढाले निर्देशों का स्वाभाविक परिणाम है। इस बार नए developer को दोष नहीं दिया जा सकता; अब उन्हें सिर्फ खुद को दोष देना चाहिए।
खास तौर पर यह देखकर तकलीफ़ होती है कि .net performance blog के लिए मशहूर Stephen Toub भी इस प्रक्रिया में शामिल हैं।
मैं यह नहीं कहना चाहता कि ऐसी नई technology पर प्रयोग ही न हों, फर्क सिर्फ इतना है कि इस बार ये experiments सबके सामने खुले में हो रहे हैं।
Microsoft में पहले से ही समस्या आने पर "error को बस ignore कर दो" जैसा Will Not Fix वाला रवैया और managers की self-satisfaction वाली culture रही है; उसी ने आज की स्थिति खुद पैदा की है—ऐसी एक निंदक राय भी है।
पहले PR पर लगी टिप्पणी संदर्भ देती है: अलग-अलग experiments के जरिए tool की limits समझी जा रही हैं और भविष्य की तैयारी की जा रही है, जबकि merge की ज़िम्मेदारी पहले की तरह maintainers पर ही बनी हुई है। Quality bar पूरी होने तक कुछ भी merge नहीं होगा।
वही Microsoft कर्मचारी जिसने यह comment लिखा, उसने यह भी कहा कि अगर आप AI के इस्तेमाल पर विचार नहीं करेंगे तो पीछे छूट जाएँगे। Microsoft में AI के कारण software engineering industry के उलट-पुलट हो जाने को लेकर बेचैनी और उत्साह दोनों हैं। लेकिन यह प्रयोग tool limits समझने के बजाय नौकरी बचाने की घबराहट में अंधाधुंध शामिल होने जैसा पढ़ता है, जिससे भरोसा कम होता है।
यह समझना ज़रूरी है कि managers ने model capabilities पर अंतिम निष्कर्ष नहीं दे दिया है; वे real-world context में उसकी strengths और weaknesses समझने के लिए एक तर्कसंगत experiment कर रहे हैं।
CI pass न कर पाने वाले PR को किसी को assign करना ही अजीब है। कम से कम pass हुए PR ही assign होने चाहिए; system इतना बिखरा हुआ लगता है कि वह भी संभव नहीं। अगर चीज़ें सही चल रही होतीं तो इतना तो basic होना चाहिए था—ऐसी निंदक टिप्पणी भी थी।
हर स्थिति को सबसे बुरे scenario की तरह न देखें। संभव है कि इसमें शामिल लोग जानते हों कि यह experiment है और उन्होंने अपनी expectations भी उसी हिसाब से सेट की हों। ऐसी experimental approach के बिना system का आगे बढ़ना मुश्किल है, इसलिए शायद इसे real environment में tune और test किया जा रहा हो। हमारी company ने भी AI coding assistant tool अपनाने की शुरुआत में ऐसा ही experiment किया था। Human coding की तुलना में code quality खराब थी, लेकिन उस process से बहुत कुछ सीखा गया, और baseline होने से improvement trend साफ़ दिखा।
कमेंट्स में यह भी बताया गया कि firewall issue की वजह से test pass/fail check नहीं हो पा रहा था, और सिर्फ वही समस्या हल हो जाए तो चीज़ें सामान्य रूप से चल सकती हैं।
AI agent की जगह कोई और नई technology रख दें, तब भी यह एक company की बहुत परिचित तस्वीर लगती है: खुले तौर पर experiment करना (big tech style dogfooding), industry की तकनीकी क्षमता बढ़ाने में वास्तविक योगदान देना, और समस्या होने पर नुकसान पूरी तरह team के भीतर सीमित रहना। फिर ऐसे experiment का समर्थन न करने की वजह क्या है—यह सवाल पूछा गया।
यह अजीब लगता है कि इतने खुले experiment पर सब तरफ सिर्फ आलोचना हो रही है। इसे private fork में छिपाने के बजाय वास्तविक capabilities को पारदर्शी तरीके से दिखाना कहीं ज़्यादा उपयोगी है, और sales-marketing की बढ़ाचढ़ाकर की गई बातों से बेहतर है।
लेकिन software development की core infrastructure framework में ऐसा experiment करना विवादास्पद ज़रूर है।
"हम" क्यों, कैसे, और किस चीज़ का समर्थन या विरोध करें—यह भी एक सवाल है। व्यक्तिगत रूप से तो MS को इस तरह हड़बड़ाहट में fail होते देखना बस मज़ेदार लगता है।
इसे असली "progress" कहना मुश्किल है। बिना internal POC के system की समस्याएँ बाहर उजागर करना गैर-ज़िम्मेदाराना लगता है। firewall जैसी basic environment validation पहले क्यों नहीं हुई? या इसे पहले किसी दूसरे internal codebase पर क्यों नहीं आज़माया गया? Infrastructure code के लिए मानक ऊँचे होने चाहिए, और "dogfooding" के नाम पर भी शुरुआत किसी lower-tier project से होनी चाहिए थी। यह "state of the art" भी नहीं है—ऐसी आलोचना हुई, साथ ही यह भी कि लागत के मुकाबले नतीजा बहुत भद्दा है।
इतने developers जिस लोकप्रिय project पर निर्भर हैं, वहाँ ऐसे experiment करना समस्या है। AI द्वारा बनाए गए घटिया code से quality गिर सकती है, बेकार code जमा हो सकता है, और team की productivity ही खाई जा सकती है।
अगर बात किसी चीज़ के प्रति निष्क्रिय अधीनता की है, तो फिर request को बिना review किए सब approve कर दो, और जब Microsoft का tech stack दुनिया भर में टूट जाए तब नौकरी छोड़कर consultant बन जाओ और 3 गुना वेतन लो—ऐसा एक व्यंग्यात्मक सुझाव भी था।
मैं इस तरह के व्यंग्य से काम नहीं करना चाहूँगा। company management के साथ शत्रुतापूर्ण "हम बनाम वे" फ्रेम या जानबूझकर चीज़ें बिगाड़ने वाला रवैया समझ से बाहर है। अपूर्णताओं की शिकायत करना एक बात है, लेकिन पूरे संगठन को बाधित या नुकसान पहुँचाना मेरी अंतरात्मा के खिलाफ़ होगा।
एक निंदक जवाब यह भी था कि Microsoft का tech stack तो पहले से ही टूटा हुआ है।
किसी ने यह भी बताया कि वास्तव में CoPilot से बना PR खुद management ने ही submit किया था।
एक मज़ाक यह भी था कि किसी दिन CoPilot पूरा codebase overwrite कर देगा, और फिर code ही नहीं होगा तो test failure भी नहीं होगा।
चूँकि कभी भी layoffs हो सकते हैं—जैसे TypeScript compiler को Go में बनाने वाले मामले में हुआ—इसलिए ऐसे संगठन के प्रति अतिरिक्त loyalty की कोई खास वजह नहीं है।
PR खोलना कम से कम अपेक्षाकृत सुरक्षित experiment तरीका है; काम का न हो तो तुरंत फेंका जा सकता है। हर नई कोशिश में trial-and-error और failure आते हैं, लेकिन वह अनुभव अपने आप में अहम है। उम्मीद है कि असली code और असली समस्याओं पर कठोर training से tools तेज़ी से बेहतर होंगे। उदाहरण के लिए, आगे चलकर test run होने तक iterative learning या test deletion रोकने जैसी checks जोड़ी जा सकती हैं। आख़िरकार भविष्य ऐसा हो सकता है जहाँ development process के दोहरावदार और साधारण काम AI संभाले, और developers मूलभूत रचनात्मक काम पर ध्यान दें।
फिर भी ऐसे experiments public repository के बजाय private fork में करना ज़्यादा सुरक्षित होता। Sales के नज़रिए से भी यह सही फ़ैसला था या नहीं, इस पर सवाल है। जब किसी company के internal decision-makers magazine में CoPilot के बारे में पढ़कर वही कोशिश करना चाहें, तब ऐसे वास्तविक उदाहरण reference बन सकते हैं। ज़्यादातर कंपनियाँ application defects को जितना हो सके छिपाती हैं और सिर्फ polished रूप ही दिखाती हैं।
ऊपर से ठीक दिखने वाले PR में भी छिपी हुई समस्याएँ हो सकती हैं, और वही बात इसे और ख़तरनाक बनाती है।
AI code review साधारण repetitive काम से भी ज़्यादा परेशान करने वाला हो सकता है, खासकर जब bugs छिपे हों और developer को अतिरिक्त मेहनत करनी पड़े।
PR खोलना अपने आप में project management पर load और complexity बढ़ाता है। अलग fork में experiment करना community के लिए बेहतर उदाहरण होता। बहुत से open source projects में जमा होते PRs के बोझ से maintainers थक जाते हैं, maintenance रुक जाती है, या कोई fork बनाकर सिर्फ काम के PR उठा लेता है। चिंता है कि इस तरह छोड़े गए projects और forks और बढ़ेंगे।
अगर वास्तव में यह माना जा रहा है कि LLM bug भरी स्थिति में भी coding ठीक से सीख सकता है, तो फिर आगे चलकर लगभग bug-free dataset बनाना पड़ेगा। लेकिन वास्तविकता यह है कि ऐसा नहीं हो रहा; बस हर तरह का data बेतरतीब तरीके से इकट्ठा किया जा रहा है।
GitHub ने दुनिया के सबसे mature repositories में से एक पर whitespace lint जैसी बुनियादी चीज़ में भी बार-बार fail होने वाला AI बनाने पर अरबों डॉलर खर्च कर दिए। अगर यह hobby experiment होता तो बात अलग थी, लेकिन इसे असली कीमत लगाकर "innovative product" के रूप में बेचना विवादास्पद है।
researcher के नज़रिए से यह स्वाभाविक experiment है, लेकिन समस्या यह है कि company इसे इसी अधूरी हालत में अभी बेच रही है।
पुराने CEO Nat Friedman पर एक मज़ाक भी था: "शायद वे मर गए होते... नहीं, अभी ज़िंदा हैं।"
असली समस्या यह है कि software developers की performance मापने के लिए objective metrics की कमी है। साल के अंत की performance review जैसी subjective evaluation के अलावा कुछ ठोस नहीं होता। इसलिए AI के उपयोग से वास्तविक efficiency बढ़ रही है या घट रही है, यह समझना भी मुश्किल है। यह junior से सस्ता दिख सकता है, लेकिन senior का समय बर्बाद करता है और निर्देशों का पालन भी नहीं करता। जब इसमें CEO worship भी जुड़ जाए, तो संगठन के भीतर मतभेद और बढ़ जाते हैं। Developers का विरोध "replace हो जाने के डर" कहकर खारिज कर दिया जाता है, जबकि CEO पक्ष rollout को सफलता की तरह दिखाना चाहता है। किसी ऐसी industry standard की कमी है जिस पर दोनों पक्ष सहमत हों, इसलिए सच सामने नहीं आता। चरम स्थिति में management यह तक कह सकता है कि AI PR की संख्या बढ़ाने के लिए review standard ही नीचे कर दो।