क्या LLM वास्तव में प्रोग्रामर की उत्पादकता को कितना बढ़ा रहे हैं?

 (lesswrong.com)
26 पॉइंट द्वारा GN⁺ 2025-03-11 | 6 टिप्पणियां | WhatsApp पर शेयर करें
  • LLM-आधारित कोडिंग सहायक टूल्स आए हुए लगभग 2 साल हो चुके हैं
  • कुछ डेवलपर्स ने बताया है कि उनकी उत्पादकता अधिकतम 5x से 10x तक बढ़ी है
  • लेकिन पूरे software industry की उत्पादकता 5~10x बढ़ गई है, इसका स्पष्ट प्रमाण नहीं है
  • वास्तव में, codebase में साधारण boilerplate फीचर जोड़ने से आगे के कामों में LLM टूल्स अक्सर मुश्किल साबित होते हैं
  • अधिकांश programmers या तो LLM टूल्स को प्रभावी ढंग से इस्तेमाल करना नहीं जानते, या उनमें रुचि नहीं रखते

उत्पादकता में बढ़ोतरी कुछ खास उपयोगकर्ताओं तक ही सीमित क्यों है

  • अगर उत्पादकता 5x से 10x बढ़ी भी है, तो बहुत संभव है कि यह LLM को अच्छी तरह संभालने वाले कुछ power users या अनुभवी डेवलपर्स तक सीमित हो
  • इस बात के संकेत नहीं हैं कि पूरी software industry अचानक बहुत ज़्यादा उपयोगी फीचर्स दे रही है या गुणवत्ता में साफ़ तौर पर सुधार हुआ है
  • लेखक को पिछले 1~2 वर्षों में LLM का प्रभाव लगभग महसूस ही नहीं हुआ

वास्तव में LLM ने किस तरह के प्रोजेक्ट संभव बनाए हैं?

  • यह स्पष्ट नहीं है कि LLM की क्षमता की वजह से कौन से प्रोजेक्ट वास्तव में संभव हुए
  • शोध परिणामों में भी ठोस उदाहरण लगभग नहीं मिलते (COBOL refactoring शायद एकमात्र उदाहरण है)
  • AGI labs के LLM-आधारित products भी कोई खास प्रभावशाली नतीजे नहीं दिखाते
    • chat box में PDF upload जैसी बुनियादी सुविधाएँ देने के स्तर तक सीमित
    • LLM को अलग-अलग software और data types के साथ सहज interface कराने वाली क्षमताओं की कमी

सवाल: क्या कोई ऐसा क्षेत्र है जहाँ उत्पादकता सचमुच बढ़ी हो?

  • LLM की वजह से कौन से प्रोजेक्ट जल्दी लॉन्च हुए, इसका स्पष्ट प्रमाण नहीं है
  • software ecosystem में किसी खास क्षेत्र के 10x बढ़ने के निशान दिखाई नहीं देते

ज़रूरत है स्पष्ट और ठोस सबूत की

  • नीचे जैसी जानकारी उपयोगी नहीं है
    • 10x उत्पादकता बढ़ोतरी के बारे में अस्पष्ट दावे
    • अमूर्त आर्थिक संकेतकों या code production बढ़ने की बातें
    • साधारण LLM-आधारित टूल या फीचर बनाने के उदाहरण
    • "ChatGPT से Snake clone बनाना" जैसे तुच्छ उदाहरण

एक शंका: क्या LLM वास्तव में उत्पादकता बढ़ा ही नहीं रहे?

  • LLM द्वारा बनाए गए code को ठीक करने और समस्याएँ सुलझाने में उल्टा समय खर्च हो सकता है
  • LLM से बने बड़े codebase एक निश्चित जटिलता के बाद इतने कठिन हो सकते हैं कि उन्हें ठीक करना असंभव लगे और अंततः शुरुआत से फिर लिखना पड़े
  • LLM नए software बना भी दें, तब भी उनके ज़्यादातर one-off tools या unused proof-of-concept code बनकर रह जाने की संभावना अधिक है
  • वास्तविक उपयोगी software में code की मात्रा बढ़ने पर अनावश्यक फीचर्स या bloatware बढ़ने का जोखिम भी है
  • संभव है कि programmers, LLM से तुरंत परिणाम मिलने वाले 'जादू' जैसे अनुभव से भ्रमित हो रहे हों

उत्पादकता बढ़ने की यथार्थवादी सीमा

  • लेखक के अनुभव के अनुसार, LLM केवल कुछ खास मामलों में उपयोगी हैं
    • छोटे-मोटे फीचर्स लिखना
    • किसी library या codebase को सीखने में मदद
    • साधारण refactoring काम करना
  • उत्पादकता में बढ़ोतरी लगभग 10~30% के दायरे में होने की संभावना ज़्यादा है
  • उत्पादकता को चरम स्तर तक ले जाना AGI (Artificial General Intelligence) आने से पहले मुश्किल दिखता है

[Richard Horvath की टिप्पणी]

वे स्थितियाँ जहाँ LLM 10x गति बढ़त दे सकते हैं

  • छोटे standalone scripts लिखना
    • सरल कामों (जैसे file manipulation के लिए bash script, Excel VBA code) में बड़े लाभ दिखते हैं
    • छोटी सी व्याख्या से आसानी से तैयार हो जाते हैं और verification भी आसान होता है
    • language की गहरी जानकारी के बिना भी लिखा जा सकता है
    • maintenance, modularization, unit testing आदि की चिंता करने की ज़रूरत नहीं होती
    • खासकर regular expressions (regex) वाले कामों में बहुत प्रभावी
  • अनजान stack पर काम करते समय सीखने की गति बढ़ना
    • नई library की classes और methods जल्दी समझे जा सकते हैं
    • code पूरी तरह काम न भी करे, तब भी यह problem-solving approach देता है
    • documentation या lectures खोजने में लगने वाला समय काफ़ी कम हो जाता है
    • लेकिन generated code को फिर भी खुद ठीक और refactor करना पड़ता है

जो लोग 10x उत्पादकता वृद्धि की रिपोर्ट करते हैं, वे संभवतः इन श्रेणियों में आते हैं

  • जिनकी development knowledge कम है
    • अगर बुनियादी coding क्षमता कम हो, तो LLM की मदद से बना code पहले की तुलना में बहुत बेहतर लग सकता है
    • लेकिन ऐसे मामलों में LLM code के लंबे समय में नकारात्मक असर पड़ने की संभावना अधिक होती है
  • जिन्हें बहुत से छोटे और स्वतंत्र solutions लिखने होते हैं
    • Excel automation या DevOps में shell scripts लिखने जैसे काम LLM के लिए खास तौर पर उपयोगी हैं
  • जिन्हें अलग-अलग stacks और libraries के साथ बार-बार प्रयोग करना होता है
    • यह उन कामों से अलग है जहाँ लंबे समय तक किसी एक खास stack पर काम किया जाता है; यहाँ experiment-heavy काम अधिक होते हैं
  • Anchoring Effect होना
    • LLM किसी एक काम में तुरंत अच्छा नतीजा दे दे, तो लोग उसे दीर्घकालिक उत्पादकता लाभ मानकर बढ़ा-चढ़ाकर आँक सकते हैं

[Davidmanheim की टिप्पणी]

  • सामान्य कंपनियों में coding करने वाले लोगों और management के नज़रिये से LLM की उत्पादकता बढ़ोतरी वास्तव में सीमित ही हो सकती है
  • इसे Theory of Constraints के दृष्टिकोण से समझाया जा सकता है:
    • मान लीजिए पहले काम इस workflow से पूरा होता था:
      • Business Analyst → 1 दिन
      • QA tester → 1 दिन
      • programmer → 1 दिन
    • programmer की उत्पादकता 2x या 5x बढ़ जाए, तब भी कुल काम का समय कम नहीं होता
      • क्योंकि दूसरे चरण (business analysis और QA) bottleneck बने रहते हैं, इसलिए पूरी process की गति वैसी ही रहती है
  • कंपनी प्रक्रियाओं को फिर से डिज़ाइन करने की ज़रूरत है
    • LLM की उत्पादकता बढ़त का पूरा लाभ लेने के लिए पूरी company process को फिर से बनाना होगा
    • लेकिन अभी सिर्फ कुछ कंपनियों में ही ऐसी process restructuring शुरू हुई है

[faul_sname की टिप्पणी]

  • LLM के साथ खास तौर पर UI mockup generation में उन्होंने ये नतीजे देखे:
    • पहले UI mockup बनाना कुल काम के समय का लगभग 10% लेता था
    • LLM की वजह से UI mockup बनाने की रफ्तार लगभग 5x हो गई
    • लेकिन कुल working time अपने आप कम नहीं हुआ
      • इसके बजाय UI mockup की detail और interactivity काफ़ी बेहतर हुई
      • ज़्यादा iterations संभव हुए, और नतीजतन product quality में सुधार हुआ
  • "फेंका जाने वाला code" ज़रूरी नहीं कि बेकार ही हो
    • prototype या proof-of-concept code भी बेहतर final product बनाने में योगदान दे सकता है
  • LLM ऐसे खास errors के उत्तर भी दे सकते हैं जिन्हें search engine से खोजना कठिन हो
    • उदाहरण: "xyz stack में चल रहे job में आई error को कैसे ठीक करें"
    • खास stack और Kubernetes settings की स्थिति में debugging में मदद
  • कुल उत्पादकता बढ़ोतरी लगभग 10~30% आँकी गई
    • लेकिन हर तरह के काम में समान रूप से उत्पादकता नहीं बढ़ी
    • कुछ खास कामों में नाटकीय गति बढ़त (जैसे UI mockup, debugging)
    • जटिल या legacy code पर लगभग कोई खास लाभ नहीं
    • प्रोजेक्ट की शुरुआती अवस्था में उत्पादकता लाभ अधिक दिखता है, जबकि जटिल maintenance चरण में प्रभाव घट जाता है
  • इसलिए यहाँ सीमा agency की कमी नहीं, बल्कि context management की समस्या है

[Noosphere89 की टिप्पणी]

  • Ajeya Cotra के विचारों का हवाला देते हुए LLM की programmer productivity पर ये बिंदु रखे गए:
    • coding tasks में AI की उत्पादकता अपेक्षा से अधिक है
      • AI coding कामों में काफ़ी अच्छा प्रदर्शन कर रहा है
      • लेकिन coding के बाहर के कामों में इसका प्रदर्शन काफ़ी कमज़ोर है
      • इसलिए industry पर AI का कुल प्रभाव अभी भी सीमित है
  • Ajeya Cotra के संबंधित वक्तव्यों के links
  • "दीर्घकालिक परिणामों के लिए AGI चाहिए" इस दावे पर
    • AI की वर्तमान प्रगति में generality अपेक्षा से कम दिखती है
    • AI का प्रदर्शन कुछ खास tasks में तेज़ी से बढ़ता है, जबकि कुछ क्षेत्रों में कमज़ोरियाँ बनी रहती हैं
    • इस असंतुलन के कारण AGI (Artificial General Intelligence) जैसी अवधारणा शायद अपेक्षा से कम उपयोगी हो सकती है

[yo-cuddles की टिप्पणी]

  • मेरे दफ़्तर में robotic process automation (RPA) करने वाले एक व्यक्ति का उदाहरण
    • वह ज़ोर देकर कहता है कि वह अब बहुत अधिक productive है
    • लेकिन वास्तव में उसका काम अक्षम और अविश्वसनीय है, इसलिए दूसरे लोग उसका काम ठीक करने में समय बर्बाद करते हैं
    • सहकर्मी उसे workflow से बाहर रखने की कोशिश करते हैं
  • लोग अक्सर अपनी उत्पादकता को सही तरह से माप नहीं पाते, और सिर्फ कुछ खास gains या losses को ही महसूस करते हैं:
    • दिखने वाली उपलब्धियों पर ध्यान
      • automation से काम जल्दी पूरा हो जाए तो तुरंत उपलब्धि का एहसास होता है
      • तेज़ नतीजे तुरंत दिखते हैं, इसलिए उन्हें सकारात्मक प्रभाव माना जाता है
    • दीर्घकालिक लागत को पहचानना कठिन होता है
      • काम के बाद पैदा हुई time cost को आसानी से track नहीं किया जाता
      • खासकर जब समस्या किसी और ने ठीक की हो, तो उसकी लागत दिखाई नहीं देती
      • automated काम से हुई गलती ठीक भी हो जाए, तब भी उससे बर्बाद समय का एहसास कम होता है
  • LLM code से पैदा हुई समस्याओं को पहचानना मुश्किल होने के कारण:
    • bug आने पर यह सही-सही पता लगाना कठिन होता है कि वजह LLM code था
    • समस्या ठीक करने में कोई दूसरा व्यक्ति अतिरिक्त समय खर्च कर सकता है
    • लोग समस्या की जड़ को नहीं पहचानते और यह नहीं समझते कि automation tool का इस्तेमाल इसकी वजह था
    • "automation की वजह से काम जल्दी खत्म हुआ" वाली उपलब्धि बड़ी महसूस होती है, लेकिन "automation की वजह से समय बर्बाद हुआ" उतना महसूस नहीं होता
  • LLM का उपयोग आम हो जाने के बावजूद industry-wide productivity growth साफ़ तौर पर नज़र नहीं आती
    • लोग कहते हैं कि वे "2x अधिक productive" हैं, लेकिन संभव है कि छिपी हुई समस्याओं की वजह से वास्तविक उत्पादकता उल्टा घट गई हो
    • यानी समस्या सुलझाने में लगा समय और संसाधन नज़र न आने के कारण उपलब्धि का आकलन बढ़ा-चढ़ाकर किया जाता है

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

6 टिप्पणियां

 
cosine20 2025-03-13

मेरा अनुभव भी काफ़ी हद तक ऐसा ही रहा है.

  • जब सरल लेकिन याद रखना मुश्किल कोड लिखना हो (जैसे file I/O handling, containers को संभालना आदि)
  • जब compile या runtime error आए और यह समझना हो कि यह किस तरह की error है और किस code की वजह से हुई है
  • जब पहले से लिखे हुए function से मिलता-जुलता, लेकिन थोड़ा अलग feature वाला function फिर से लिखना हो
  • जब किसी library पर निर्भर code को दूसरी library से बदलना हो या अपने खुद के function से replace करना हो
  • जब किसी specific feature को implement करना हो, या किसी specific environment में काम करना हो और यह समझने के लिए guidance चाहिए कि development किस तरह किया जाए

ऊपर जैसे मामलों में काफ़ी समय बचा है। कई बार Google + Stack Overflow के combination से भी चीज़ें आसानी से नहीं मिलतीं, और खासकर Stack Overflow पर अगर कोई answer होता भी है, तो comments में उस पर बहुत आपत्तियाँ आ जाती हैं, या यह कहा जाता है कि वह पुराने version का implementation तरीका है इसलिए उसे इस्तेमाल नहीं करना चाहिए — ऐसी वजहों से काफ़ी झुंझलाहट होती थी...
 
superego 2025-03-12

लगता है कि 10x प्रोडक्टिविटी प्रोटोटाइपिंग करते समय ही सामने आती है
 
hilft 2025-03-12

मुझे यह बहुत पसंद आ रहा है।
 
halfenif 2025-03-11

> ज़्यादातर प्रोग्रामर यह नहीं जानते कि LLM टूल्स का प्रभावी ढंग से उपयोग कैसे करें, या उनमें उनकी रुचि ही नहीं है

आसपास के कई डेवलपर्स को हैरानी की बात है कि तकनीक में दिलचस्पी ही नहीं है। वे अपना ज़्यादातर समय नए या बार-बार दोहराए जाने वाले YouTube Shorts को मशीन की तरह देखते हुए बिताते हैं.
 
GN⁺ 2025-03-11
Hacker News राय

  • सिएटल की एक लोकप्रिय टेक कंपनी में काम करता/करती हूँ, और AI के उपयोग के लिए दबाव डाला जा रहा है। लीडरशिप यह ट्रैक कर रही है कि डेवलपर्स AI का कितना उपयोग करते हैं, और मुझसे व्यक्तिगत रूप से यह भी पूछा गया कि मैं AI का अधिक उपयोग क्यों नहीं करता/करती। मेरा मानना है कि सही काम के लिए सही टूल का उपयोग करना महत्वपूर्ण है, और AI हमेशा उपयुक्त नहीं होता

    • कई सीनियर डायरेक्टर और SVP ने 10 साल से अधिक समय पहले कोड लिखा था, और उन्हें यह भी नहीं पता कि कोई साधारण प्रोजेक्ट कैसे शुरू किया जाए। AI ने उन्हें कुछ ऐसा वापस दिया है जो वे खो चुके थे, लेकिन विशेषज्ञों के लिए यह मददगार नहीं है
    • AI शौकिया बागवानी करने वाले के लिए मददगार हो सकता है, लेकिन किसान के लिए उपज बढ़ाने में मददगार नहीं होता

  • सॉफ्टवेयर प्रोजेक्ट्स के बारे में एक पुरानी कहावत है कि आखिरी 10% में 90% समय लगता है। AI शुरुआती 90% में उपयोगी है, लेकिन आखिरी 10% में मदद नहीं करता

    • अगर AI का उपयोग सावधानी से न किया जाए, तो जटिल कोड के कारण ऐसी स्थिति में फँसना आसान है जहाँ AI मददगार नहीं रहता
    • यह उन कारणों में से एक हो सकता है कि सॉफ्टवेयर प्रोडक्टिविटी में विस्फोटक बढ़ोतरी क्यों नहीं दिख रही

  • FAANG में LLM को IDE में इंटीग्रेट करके इस्तेमाल किया जा रहा है, और इसका थोड़ा सकारात्मक असर है

    • IDE के भीतर प्रोडक्टिविटी थोड़ी बढ़ी है, और दोहराए जाने वाले कामों को auto-complete किया जा सकता है
    • लेकिन LLM कभी-कभी भरोसेमंद दिखने वाले परिणाम बनाता है, जो प्रोडक्टिविटी बढ़ाने के बजाय उसे बाधित भी कर सकता है
    • लगता है कि अगर उससे सीधे फीचर बनाने के लिए कहा जाए तो बेहतर नतीजे मिल सकते हैं

  • वास्तव में 10 गुना सुधार का अनुभव करने वाले डेवलपर के उदाहरण के रूप में Pieter Levels का मामला है, जिन्होंने कुछ ही दिनों में 3D multiplayer flight simulator कोड कर लिया

    • साधारण कामों में समय बचाया जा सकता है, लेकिन जटिल कामों में यह मददगार नहीं होता

  • LLM का उपयोग करके कोड जेनरेशन की कोशिश की थी, लेकिन शुरुआत में प्रोडक्टिविटी घट गई थी

    • हाल में Claude Code का उपयोग करके प्रोडक्टिविटी काफी बढ़ी है, और pair programming स्टाइल में काम कर रहा/रही हूँ
    • मुझे नहीं लगता कि non-developers के उच्च-गुणवत्ता वाला output देने की संभावना बहुत अधिक है

  • GitHub में Copilot Autofix विकसित करने वाली टीम का हिस्सा हूँ, जो CodeQL warnings के आधार पर fix suggestions देती है

    • वास्तविक डेवलपर्स के साथ interaction data के आधार पर औसतन 3 गुना, और अधिकतम 12 गुना तक की speedup देखी गई है

  • LLM coding assistants के जवाबों की गुणवत्ता प्रोग्रामर की communication ability से बहुत प्रभावित होती है

    • जूनियर डेवलपर्स अक्सर सवाल स्पष्ट रूप से नहीं पूछ पाते, इसलिए उन्हें गलत जवाब मिलते हैं
    • मैंने ऐसे मामले देखे हैं जहाँ सीनियर प्रोग्रामर्स की क्षमता काफी बढ़ गई, और जब जूनियर या मिड-लेवल डेवलपर्स शिकायत करते हैं कि LLM coding assistants बेकार हैं, तो संभव है कि समस्या उनकी communication ability में हो

  • यह मान लेना गलत हो सकता है कि सॉफ्टवेयर की प्रोडक्टिविटी 5-10 गुना नहीं बढ़ी है

    • एक विकल्प यह है कि कंपनियों को कम engineers की जरूरत हो, जिससे layoffs हों, या लागत घटे और सॉफ्टवेयर प्रोडक्ट्स सस्ते हो जाएँ
    • व्यक्तिगत रूप से, मैंने साधारण scripts लिखकर इतना जरूर किया है कि एक दिन में थोड़ा ज्यादा काम कर सकूँ, लेकिन 5 गुना ज्यादा काम नहीं कर सकता/सकती
 
ignos 2025-03-11

Hacker News राय-सार अनुवाद के आख़िरी बिंदु, 'यह मान लेना गलत हो सकता है कि सॉफ्टवेयर की उत्पादकता 5-10 गुना नहीं बढ़ी है', में शायद गलत अनुवाद हुआ है। मूल पाठ को देखें तो, 'यह कहना कि सॉफ्टवेयर की उत्पादकता 5-10 गुना बढ़ गई है, उत्पादकता वृद्धि के बारे में एक गलत धारणा पर आधारित है' जैसा सार थोड़ा अधिक उपयुक्त लगता है।