3 पॉइंट द्वारा GN⁺ 2025-12-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एजेंटिक कोडिंग (Agentic Coding) टूल्स के आने से सॉफ्टवेयर डेवलपमेंट की श्रम लागत में तेज़ गिरावट देखी जा रही है
  • पहले जो इन-हाउस वेब ऐप प्रोजेक्ट एक महीने में होता था, अब वह एक हफ्ते के अंदर पूरा हो सकता है, यानी इम्प्लीमेंटेशन स्पीड घट गई है
  • Claude Code जैसे टूल सैकड़ों टेस्ट को कुछ ही घंटों में बना देते हैं, जिससे छोटी टीम द्वारा बड़े परिणाम देने का मॉडल उभर रहा है
  • लागत में गिरावट Jevons Paradox जैसी छिपी मांग में विस्फोट को जन्म दे सकती है, जिससे अधिक संगठन कस्टम सॉफ्टवेयर बनाने की तरफ़ बढ़ेंगे
  • डेवलपरों की डोमेन नॉलेज और मानव-एजेंट सहयोग क्षमता नई प्रतिस्पर्धी बढ़त बन रही है और 2026 में उद्योग स्तर पर तेज़ बदलाव की उम्मीद है

सॉफ्टवेयर डेवलपमेंट लागत संरचना में बदलाव

  • ओपन सोर्स के प्रसार ने सॉफ्टवेयर डेवलपमेंट की शुरुआती लागत घटाने में पहली बड़ी भूमिका निभाई
    • पहले SQL Server, Oracle जैसी तकनीकों के लिए सालाना कई हजार डॉलर लाइसेंस फीस देनी पड़ती थी, जबकि MySQL से नेटवर्क एप्लीकेशन मुफ्त में बनाई जा सकती थी
  • उसके बाद क्लाउड अपनाने से प्रारंभिक कैपेक्स कम हुआ, लेकिन कुल लागत बचत का प्रभाव सीमित रहा
  • दूसरी तरफ, हाल के सालों में TDD, माइक्रोसर्विस, कॉम्प्लेक्स React फ्रंटएंड, Kubernetes जैसे तत्वों ने उल्टा कॉम्प्लेक्सिटी बढ़ाकर खर्च बचत को लगभग रोक दिया
  • इसके विपरीत AI एजेंट ने डेवलपमेंट प्रक्रिया की श्रम लागत को भारी मात्रा में घटाया है

90% कटौती का आधार

  • 2025 की शुरुआत तक कई लोगों को AI coding टूल पर भरोसा नहीं था, लेकिन हाल ही में एजेंटिक कोडिंग CLI ने बड़े पैमाने पर दक्षता साबित कर दी
  • उदाहरण के लिए, एक इन-हाउस टूल के 300 से ज्यादा टेस्ट कोड Claude Code ने कुछ ही घंटों में generate कर दिए
  • पहले जो एक महीने में पूरा होने वाला प्रोजेक्ट था, वह एक हफ्ते के अंदर पूरा हो सकता है
    • इम्प्लीमेंटेशन टाइम तेज़ी से गिरा, जबकि डिज़ाइन/आर्किटेक्चर (सोच/प्लानिंग) टाइम लगभग वही रहा
    • टीम साइज घटने से कम्युनिकेशन ओवरहेड लगभग खत्म हो गया
  • नतीजतन, छोटी टीमों ने 10x से ज्यादा प्रोडक्टिविटी हासिल कर ली

संभावित मांग में विस्फोट

  • खर्च में गिरावट को उद्योग-व्यापी मांग घटने के बजाय बढ़ने वाला Jevons Paradox के रूप में समझा जा सकता है
  • कई संगठन अभी भी Excel-आधारित वर्कफ़्लो पर काम कर रहे हैं, और इन्हें SaaS ऐप में बदलने की संभावित मांग मौजूद है
  • अगर पहले $50,000 वाला कोटेशन घटकर लगभग $5,000 हो जाए, तो नॉन-क्रिटिकल प्रोजेक्ट भी बिल्ड टारगेट बन जाते हैं
  • इसलिए सॉफ्टवेयर इंडस्ट्री का कुल आउटपुट बढ़ने की संभावना है

डोमेन नॉलेज नई प्रतिस्पर्धी ताकत

  • अभी भी मानव पर्यवेक्षण और निर्णय क्षमता अनिवार्य है
    • एजेंट की approach को मॉनिटर करके गलत दिशा को सुधारना पड़ता है
  • जो डेवलपर इस तकनीक में माहिर हैं, उनकी बिजनेस समस्या समाधान क्षमता काफी बेहतर हो जाती है
  • डोमेन नॉलेज + तकनीकी दक्षता का संयोजन मुख्य प्रतिस्पर्धी ताकत के रूप में उभर रहा है
    • बिजनेस एक्सपर्ट और डेवलपर छोटे-छोटे सहयोग यूनिट्स में तेजी से iterative development कर सकते हैं
  • सॉफ्टवेयर अब ‘फेंककर दोबारा बनाने योग्य एसेट’ बनता जा रहा है; अगर दिशा गलत हो तो तुरंत discard करके फिर से build किया जा सकता है

बदलाव के लिए तैयार रहें

  • LLM और एजेंट मॉडल तेजी से बेहतर हो रहे हैं, जबकि पुराने benchmarks अभी इसे पर्याप्त नहीं पकड़ते
    • उदाहरण: Opus 4.5 10–20 मिनट सेशन को स्थिरता से संभाल सकता है
  • बड़े GPU इंफ्रास्ट्रक्चर निवेश के साथ आगे मॉडल perf में तेज़ सुधार की अपेक्षा है
  • कुछ डेवलपर अभी भी कहते हैं कि “LLM में errors ज्यादा हैं” या “time saving नहीं होता”, लेकिन यह तर्क धीरे-धीरे कमजोर पड़ रहा है
  • 2007 में iPhone को ignore करने वाले desktop engineers के उदाहरण की तरह, बदलाव न अपनाने पर पीछे छूटने का risk बना रहता है
  • बड़े enterprises में administrative/ब्यूरोक्रेटिक सेटअप के कारण adoption धीमी होगी, जबकि small टीम तुरंत उपयोग कर सकती है
  • LLM केवल नए प्रोजेक्ट्स में ही नहीं, existing codebase की analysis और maintenance में भी प्रभावी हैं
    • पुराने कोड की structure समझने, bug खोजने, fix suggest करने जैसे कामों में भी बहुत high efficiency देता है
  • परिणामस्वरूप, 2026 विकास मॉडल के बड़े बदलाव का संभावित वर्ष हो सकता है

1 टिप्पणियां

 
GN⁺ 2025-12-09
Hacker News की राय
  • सुना कि Claude Code ने कुछ ही घंटों में 300 से ज़्यादा टेस्ट बना दिए
    लेकिन क्या वे टेस्ट सच में इच्छित व्यवहार को सत्यापित करते हैं, और अगले डेवलपर को सिस्टम कैसे काम करता है यह साफ़ तौर पर बता सकते हैं, इस पर संदेह है
    AI तेज़ी से कोड बना दे, तब भी उतना ही बारीक रिव्यू का समय न दिया जाए तो क्वालिटी गिरने का बड़ा जोखिम रहता है

  • मैंने भी AI coding को “सक्रिय रूप से अपनाकर देखो” वाली सलाह मानी
    लेकिन शायद robotics और embedded क्षेत्र में होने की वजह से, AI से webapp या game बनाना बहुत उबाऊ और झुंझलाहट भरा अनुभव था
    Cursor से समस्या ठीक करने को कहो तो वह चीज़ों को और बिगाड़ देता था, और आखिर में Flask और JS खुद सीख लेना कहीं ज़्यादा प्रभावी रहा
    docs या error messages खोजने में AI शानदार था, लेकिन “स्टीयरिंग उसके हाथ में देना” बिल्कुल भी मददगार नहीं था

    • मेरा अनुभव भी काफ़ी ऐसा ही रहा
      AI से “10x productivity” मिलती है, इस दावे पर संदेह है
      असल में इसे supercharged Google/Stack Overflow की तरह इस्तेमाल करना ज़्यादा यथार्थवादी है
      ज़्यादातर कोड मैं खुद लिखता हूँ, और AI बस repetitive कामों या script लिखने में मदद करता है
    • AI को कोड सौंपना भी सीखने वाली skill है
      सफल होने के लिए ‘mentor’ की तरह साफ़ निर्देश देना और समझाना आना चाहिए
      खुद सीधे हाथ लगाए बिना prompt के ज़रिए बदलाव माँगने की आदत महत्वपूर्ण है, और यह प्रक्रिया आख़िरकार communication skill को मज़बूत करती है
  • ऐसे लेखों को देखकर मैदान में काम करने वाली dev team और management की समझ का फ़र्क साफ़ दिखता है
    ऊपर बैठे लोग कुछ लाइनों की requirements देखकर समझ लेते हैं कि उन्हें पूरा सिस्टम समझ आ गया, जबकि वास्तव में उन्हें dependencies और context का लगभग पता नहीं होता
    एक अच्छी dev team उस अस्पष्ट मांग को वास्तविक product में बदलती है, वही असली कला है, और इसे automate कर सकने वाली technology अभी मौजूद नहीं है

  • सिर्फ़ code लिखने की लागत 90% घटी है
    लेकिन समस्या को simple code में घटाकर व्यक्त करने के लिए अब भी काफ़ी अनुभव और समय चाहिए

    • ज़्यादातर development तो legacy code maintenance ही है
      Claude Code पुराने codebase को समझने और उसमें बदलाव करने में बेहतरीन रहा
      उसने testing और debugging में भी मदद की, इसलिए productivity सचमुच 10 गुना जैसी लगी
      वह सिर्फ़ तेज़ी से कोड लिखने का टूल नहीं, बल्कि तेज़ दूसरा दिमाग़ जैसा काम करता है
    • AI की वजह से मैं अब वे छोटे automation काम भी जल्दी कर लेता हूँ जिन्हें पहले झंझट समझकर टाल देता था
      एक घंटे के भीतर script या mini web service बनाकर समस्या हल कर सका
    • CRUD app बनाने की लागत 90% घटी है, इस बात से सहमत हूँ,
      लेकिन सच कहूँ तो ऐसे simple काम AI से पहले भी automate हो जाने चाहिए थे
    • जटिल सिस्टम भी आखिरकार simple code की परत-दर-परत बनी संरचना ही होते हैं
      LLM ऐसा लगता है जैसे एक फावड़े से 10 excavator पर अपग्रेड हो गए हों,
      लेकिन अगर project को fail होना है, तो वह बस ज़्यादा तेज़ी से fail होगा
    • कोड simple है या नहीं, यह आखिरकार इस बात पर निर्भर है कि वह online example patterns से कितना मिलता-जुलता है
      Claude Code सीखे हुए patterns के भीतर जटिल code भी अच्छी तरह लिख लेता है
  • अगर सच में custom software development की लागत 90% कम हो गई होती,
    तो बाज़ार सस्ते SaaS से भर जाना चाहिए था, लेकिन हक़ीक़त ऐसी नहीं है
    आखिरकार लगता है कि सबसे बड़ी समस्या कोड लिखना नहीं है

    • सही बात, development के बाद की operational cost कहीं ज़्यादा बड़ी है
      maintenance, security, upgrades, hosting, customer support, नई features जोड़ना वगैरह
      SaaS subscription fee में शामिल असली value यही चीज़ें हैं
      AI को इस हिस्से तक पहुँचने में अभी शायद 3~5 साल लगेंगे
    • डेवलपर का वास्तविक coding time कुल काम का लगभग आधा ही होता है
      बाकी समय meetings, coordination, इंतज़ार वगैरह में जाता है
      मान लें coding cost 90% घट भी जाए, तो कुल लागत का आधे से ज़्यादा हिस्सा फिर भी बचा रहेगा
      और ऊपर से AI natural language summary तक ठीक से नहीं बना पाता,
      तो क्या वह code का अर्थ पूरी तरह समझकर लिख पाएगा, इस पर भी सवाल है
      संबंधित वीडियो: YouTube लिंक
    • सिर्फ़ code सस्ता हो जाने से कोई चीज़ अच्छा business नहीं बन जाती
      अभी भी SaaS की भरमार है, लेकिन अच्छे features होने पर भी business चलाना मुश्किल है
    • SaaS, साधारण app की तुलना में दो से तीन गुना ज़्यादा मेहनत माँगने वाला क्षेत्र है
      बहुत-सी engineering असल में vendor lock-in के लिए की जाती है
    • यह मान लेना ही ग़लत है कि बाज़ार पूरी तरह सही तरह काम करता है
      platform exposure, trust, algorithmic control की वजह से नए SaaS का बढ़ना मुश्किल होता है
      बड़ी कंपनियाँ उसे जल्दी copy कर देती हैं, और consumers के पास पैसे भी कम होते जा रहे हैं
      आख़िरकार बाज़ार निष्पक्ष नहीं है, इसलिए बहुत से लोग राजनीतिक क्षेत्र की ओर देख रहे हैं
  • जिसने बड़े enterprise में काम किया है, उसे ऐसे लेखों से सहमति नहीं होगी
    उदाहरण के लिए Shutterstock जैसी जगहों पर, एक simple request के लिए भी 5 systems को छूना पड़ता है
    AI कोड को समझने और बदलने में मदद कर सकता है,
    लेकिन कुल development cost 90% घट गई है, यह बिल्कुल सच नहीं है

    • ऊपर से लेखक “AI development workshop instructor” है,
      इसलिए यह लेख असल में कंपनियों के लिए promotional article जैसा ज़्यादा लगता है
  • “हर संगठन में सैकड़ों Excel sheets होती हैं, और उन्हें SaaS में बदलना बेहतर है” इस दावे पर
    मैं सच में पूछना चाहूँगा कि किसके लिए बेहतर?
    spreadsheet को domain knowledge रखने वाले लोग सीधे संभाल सकते हैं,
    और उनकी accessibility भी अच्छी होती है, इसलिए वे अब भी शक्तिशाली tool हैं

    • मुझे भी spreadsheet बहुत पसंद हैं, लेकिन ज़रा-सी complexity बढ़ते ही errors बहुत बढ़ जाते हैं
      formulas और UI इतने जुड़े होते हैं कि अंदर का logic समझना मुश्किल हो जाता है
    • spreadsheet शक्तिशाली हैं, लेकिन उनका दुरुपयोग आसान है
      खासकर Excel में maintenance मुश्किल है, और जैसे-जैसे complexity बढ़ती है, उसे code में ले जाना बेहतर लगता है
    • लेखक के रूप में कहूँ तो मेरा मतलब यह नहीं था कि हर sheet को webapp बना दो,
      बल्कि collaboration, access control, testing जैसी संरचनात्मक मजबूती की ज़रूरत है
    • असली सवाल यह है कि spreadsheet ने अपनी सीमा कब पार कर ली, यह पहचानने का समय कौन-सा है
      जब उसे database की तरह इस्तेमाल किया जाने लगे, या कई users एक साथ उसे संभालने लगें, वही बदलाव का बिंदु है
    • ज़्यादातर spreadsheets मूल निर्माता के साथ ही गायब हो जाती हैं
      SAP जैसी solutions साझा समस्याओं का समाधान करती हैं,
      लेकिन ज़्यादातर sheets सिर्फ़ एक ग्राहक वाले custom problem के लिए होती हैं
  • लगता है 90/90 नियम अब भी लागू होता है
    AI पहला 90% जल्दी कर देता है, लेकिन बाकी 10% ही असली कठिन हिस्सा है
    LLM खुदाई वाले शुरुआती चरण में उपयोगी है, लेकिन बारीक finishing चरण में उल्टा बाधा बन जाता है
    साधारण website बनाते समय यह जादू जैसा लगेगा,
    लेकिन आगे चलकर ऐसा काम रोज़ी-रोटी कमाने के लिए मुश्किल क्षेत्र बन सकता है

    • खासकर जहाँ नए scenarios में accuracy महत्वपूर्ण हो, वहाँ AI की सीमाएँ साफ़ दिखती हैं
      generated output को रोककर ध्यान से देखो, तो सच में सही है या नहीं, इस पर संदेह होने लगता है
  • यह देखकर हैरानी होती है कि बहुत लोग अब भी AI को सिर्फ़ copy-paste chatbot की तरह इस्तेमाल करते हैं
    लेकिन सही निर्देश दिए जाएँ, तो Claude Code कई हफ़्तों का experiment कुछ ही मिनटों में दोहरा सकता है
    वास्तविक काम में perfect code से ज़्यादा तेज़ी से परिणाम देना महत्वपूर्ण होता है
    बेशक security bugs या business logic errors अभी भी जोखिम हैं
    अगर domain expert साथ हो, तो ऐसे मुद्दे धीरे-धीरे कम हो सकते हैं

    • लेकिन सिर्फ़ तेज़ परिणाम के पीछे भागने से code quality तेज़ी से गिरती है
      feature development और codebase management के संतुलन का महत्व है
      Cursor जैसे agents यह संतुलन अच्छी तरह बना पाते हैं या नहीं, इस पर अभी भी संदेह है
  • LLM boom के बाद, मैंने Excel को replace करने वाले एक project में हिस्सा लिया था
    लेकिन असलियत में वह non-experts द्वारा AI से app बनाने की असफल कोशिश निकला
    data analysts ने Python app को ‘vibe coding’ से बनाया,
    लेकिन न state management था, न structure ठीक था
    नतीजतन customer data ग़लत तरीके से process होने लगा, और लगभग आपदा जैसी स्थिति बन गई
    ऐसे संगठनों में technical staff नहीं होता, इसलिए AI उल्टा जोखिम को तेज़ कर देता है

    • “post-LLM era का Excel modernization project” यह वाक्य ही काफ़ी डरावना विचार लगता है