- सॉफ़्टवेयर डेवलपमेंट चुपचाप deterministic systems से probabilistic systems की ओर शिफ्ट हो रहा है, और AI agents के रातभर code generate, review और merge करने के दौर में डेवलपर की भूमिका और संगठनात्मक संरचना बुनियादी रूप से बदल रही है
- AI-native teams के भीतर भूमिकाएँ ऊपर की ओर शिफ्ट होने के साथ-साथ नीचे की ओर विभाजित भी हो रही हैं, और agent output को मैनेज करने वाले साधारण काम नए low-wage job category के रूप में स्थिर हो जाने का जोखिम रखते हैं
- code generation की लागत शून्य के करीब पहुँचने पर Jevons paradox की तरह code production विस्फोटक रूप से बढ़ता है, लेकिन generation सस्ती हुई है जबकि verification सस्ती नहीं हुई — यही मुख्य चुनौती है
- junior engineers AI पर निर्भर होकर शुरुआत से ही polished code आउटपुट कर रहे हैं, जिससे debugging, judgment और craftsmanship के प्रशिक्षण का संकट पहले ही वास्तविकता बन चुका है
- मौजूदा model, आगे उपयोग किए जाने वाले models में सबसे कमजोर model है, इसलिए संगठनों को आज की क्षमताओं के बजाय अब तक रिलीज़ न हुए भविष्य के models के लिए तैयार systems बनाने होंगे
प्रायिकतामूलक इंजीनियरिंग की ओर बदलाव
- सॉफ़्टवेयर इंडस्ट्री कई दशकों तक deterministic contract पर बनी रही — code लिखो, test करो, release करो और उसके काम करने की गारंटी होती थी
- यह contract टूट रहा है, और AI-native कंपनियों के top operators के बीच codebase अब ऐसी चीज़ बन रहा है जिसके बारे में केवल यह माना जाता है कि यह काम करता है, जहाँ सटीक probability बताना अब संभव नहीं
- इसका ट्रिगर Compound Loop नाम के एक side project को बनाते समय मिला — ऐसा system जो कई frontier models को एक-दूसरे के खिलाफ चलाकर autonomously code लिखता, review करता और merge करता है
- सोने से पहले अगर system को किसी वास्तविक समस्या पर चलाया जाए, तो सुबह पिछली रात मौजूद न रहे PR stack को triage करना पड़ता है
- कुछ शानदार होते हैं, कुछ में गलतियाँ होती हैं, और कुछ ऐसे सवाल सामने लाते हैं जो पूछे ही नहीं गए थे
- knowledge work के इतिहास में पहली बार, काम से जाने वाला व्यक्ति अपने साथ दिमाग की एकमात्र कॉपी लेकर नहीं जाता
- 9-9-6 की अवधारणा व्यावहारिक रूप से खत्म हो चुकी है, और 24/7 कर्मचारी का मतलब 24 घंटे काम करने वाला इंसान नहीं, बल्कि वह व्यक्ति है जिसके लिए agents बड़े पैमाने पर parallelization के साथ काम करते हैं
- 2026 में भी ज़्यादातर teams में bottleneck typing नहीं बल्कि coordination है, और organizational restructuring अभी शुरुआती अवस्था में है
भूमिकाओं का विभाजन — एक साथ ऊपर और नीचे
- AI-native teams के भीतर "सबका level up होता है" जैसी साफ-सुथरी कहानी से कहीं अधिक जटिल pattern मौजूद है
- ऊपर की ओर शिफ्ट: बेहतरीन engineers अधिक प्रभावी PM बन रहे हैं, बेहतरीन PM system architect बन रहे हैं, और बेहतरीन architect distribution, growth और market structure पर सोचने की ओर बढ़ रहे हैं
- इस समूह के लिए यह इतिहास का सबसे अधिक high-leverage work वाला माहौल है
- नीचे की ओर विभाजन: साथ ही, कई engineers architect नहीं बन रहे बल्कि spec writers, reviewers और agent babysitters में बदल रहे हैं
- उनका काम इरादे को ऐसे prompts में बदलना है जिन्हें machine पढ़ सके, और उन standards पर machine के काम को score करना है जिन पर खुद उनकी पूरी पकड़ भी नहीं होती
- इनमें कुछ महत्वपूर्ण काम हैं, लेकिन कुछ बस नए शब्दों में पैक किया गया 2026 संस्करण का data entry है
- ऐसे विभाजित roles का भविष्य कम वेतन, कम valuation और कई मामलों में career dead end जैसा दिखता है
- agent fleet को प्रभावी ढंग से चलाने वाले ऊपरी एक-तिहाई और outputs को मैनेज करने वाले middle layer के बीच वेतन अंतर पिछले दौर के engineer-sales compensation gap से भी बड़ा होगा
- AI infrastructure में kernel performance, compiler design और hardware abstraction अब भी बचाव योग्य moat बने हुए हैं — system engineering के सबसे निचले स्तर पर अभी भी high deterministic precision की ज़रूरत है
Jevons paradox — code संस्करण
- 1865 में अर्थशास्त्री William Stanley Jevons ने देखा कि अधिक efficient steam engines ने coal consumption कम नहीं किया बल्कि और बढ़ा दिया — efficiency ने यह दायरा बढ़ा दिया कि किस चीज़ के लिए engine बनाना सार्थक था
- code लिखने की unit cost शून्य के करीब आने पर software भी वही अनुभव कर रहा है — कम लिखने के बजाय हम बहुत अधिक लिख रहे हैं और बहुत अधिक release कर रहे हैं
- जो कंपनियाँ मानती हैं कि scaling laws अनंत हैं, वे उसी अनुसार निर्माण कर रही हैं, और वही power-law distribution की विजेता बनेंगी
- ज़मीन पर यह पहले ही हो रहा है:
- agents PR खोलते हैं, एक-दूसरे के काम की review करते हैं, और इंसान के keyboard छुए बिना उन्हें बंद भी कर देते हैं
- self-healing test suite underlying code बदलने पर खुद को rewrite कर लेते हैं
- autonomous experiment loops वहाँ 100 hypotheses चला, माप और खत्म कर रहे हैं जहाँ team पहले 3 ही चला पाती थी
- documentation merge के समय auto-update होती है और self-improving AI skills का उपयोग करती है
- agent-centric restructuring करने वाली teams एक साल पहले की तुलना में 3x, 5x, 10x output हासिल कर रही हैं, और curve flatten नहीं हो रहा बल्कि ऊपर जा रहा है
- Jevons का दूसरा सबक: supply फट पड़ने पर selection ही मुख्य चीज़ बन जाती है
- जो operator agent fleet को सही समस्याओं पर निर्देशित करता है, output में से मूल्यवान चीज़ें filter करता है और नतीजों को एक coherent रूप में जोड़ता है, वह आज software में सबसे high-leverage काम कर रहा है
- काम का मूल्य अब production effort से नहीं बल्कि direction setting, selection और coherence से तय होगा
deterministic engineering से probabilistic engineering तक
- deterministic engineering वह contract था जिसने software के अधिकांश इतिहास पर राज किया — code लिखो, test करो, review करो, और एक समझे हुए दायरे में उसके behavior को जाना जा सकता था; bugs reproducible entities थे
- probabilistic engineering frontier teams तक पहुँच चुकी है — codebase का अधिकांश हिस्सा probabilistic systems द्वारा generate होता है, time pressure में review होता है, और ऐसे पूरे सिस्टम में integrate होता है जिसे किसी एक इंसान ने डिज़ाइन नहीं किया
- मुख्य asymmetry: generation सस्ती हो गई है, verification नहीं
- agent 1 मिनट में 500-line PR बना सकता है, लेकिन concurrency issues, spec misinterpretation या intent से अलग implementation जैसे सूक्ष्म bugs पकड़ने में senior engineer को 1 घंटे से अधिक लग सकते हैं
- review generation से अधिक धीरे scale होती है, और output volume के साथ linear से भी बदतर scale करती है — codebase का अधिक हिस्सा agents द्वारा लिखे जाने पर हर टुकड़े को evaluate करने के लिए ज़रूरी context बढ़ता जाता है
- एक निश्चित scale के बाद system उतना अधिक produce करने लगता है जितना इंसान भरोसेमंद ढंग से evaluate नहीं कर सकता, और accuracy probabilistic हो जाती है
- ठोस उदाहरण: race condition जो 10 में 9 बार test suite पास कर जाती है, feature जो staging में perfect है लेकिन अनपेक्षित prompt distribution पर fail हो जाता है, migration जो 10,000 लाइनों में 1 लाइन को चुपचाप corrupt करती है और 3 हफ्ते बाद पता चलती है
- Proximal और Modular ने frontier agent systems के base task tests पर संयुक्त research प्रकाशित की है, और documented failure patterns सीधे इस phenomenon से मेल खाते हैं
- failure mode नाटकीय collapse नहीं बल्कि धीमा, शांत degradation है — generation बढ़ती है, review quality गिरती है, अनदेखे defects जमा होते हैं, और trust धीरे-धीरे तब तक क्षीण होती है जब तक customer, audit या production incident समस्या उजागर न कर दे
- इस समस्या को सही तरह हल करने वाले tools अभी मौजूद नहीं हैं — small merges, strict gates, polished outputs के प्रति निर्दयी skepticism, observability और rollback discipline जैसी cultural responses मदद करती हैं, लेकिन एक सीमा के बाद culture scale नहीं करती
- जो भी इस समस्या को हल करेगा, वही अगले दशक के गंभीर software development का operating system परिभाषित करेगा
इंडस्ट्री के अनुसार बदलाव की गति
- deterministic से probabilistic engineering की ओर संक्रमण एकसमान नहीं है, बल्कि industry और risk profile के अनुसार परतों में बँटा हुआ है
-
deterministic layer
- avionics, medical devices, financial trading infrastructure, nuclear control systems, payment network core जैसे highly regulated, high-risk domains
- agent assistance को formal verification, extensive simulation और human sign-off chains के पीछे सावधानी से अपनाया जाएगा
- यह कल्पनाशक्ति की कमी नहीं बल्कि risk level का सही आकलन है
-
probabilistic layer
- consumer software, internal tools, marketing systems, अधिकांश SaaS, content infrastructure, experimental और early-stage products
- यहाँ bug की लागत rollback, apology और hotfix के स्तर की होती है, और बदले में deterministic दुनिया से संरचनात्मक रूप से असंभव iteration speed मिलती है
- probabilistic teams हर quarter deterministic competitors की तुलना में 10x अधिक सीख सकती हैं
-
Convergence Zone
- जैसे-जैसे models अधिक smart होते हैं और harnesses बेहतर होती हैं, वैसे-वैसे वह frontier खिसकती रहती है जहाँ "probabilistically करना भी पर्याप्त सुरक्षित" माना जा सकता है
- insurance, healthcare, enterprise infrastructure के कुछ हिस्सों जैसे अभी deterministic दिखने वाले domains में probabilistic methods नीचे से 10% करके प्रवेश करेंगे
- probabilistic engineering के leaders deterministic guardrails को फिर से बना रहे हैं — formal checks, verified critical paths, और hybrid systems जहाँ probabilistic generation deterministic verification से सीमाबद्ध होती है
- अगले दशक के विजेता वे teams होंगी जो जानती हैं कि वे किस layer में हैं, दूसरी layer में होने का दिखावा करने के प्रलोभन का विरोध करती हैं, और अपने stack के भीतर boundaries को सटीक रूप से तय करती हैं
Agentic Fleet
- "factory shift" सही रूपक नहीं है — factory workers तो उस system के हिस्से थे जिसे automate किया जा सकता था, लेकिन यहाँ मामला वैसा नहीं है
- बेहतर रूपक है agentic fleet — हालांकि "fleet" जिस व्यवस्था, hierarchy और reliability का संकेत देता है, वास्तविकता अभी वहाँ नहीं पहुँची है
- वास्तव में अधिकांश operators जो चला रहे हैं, वह अच्छी तरह प्रशिक्षित navy से अधिक नाज़ुक contractors का झुंड है
- agents की क्षमता असमान है, behavior probabilistic है, वे कभी-कभी पूरे आत्मविश्वास से गलत होते हैं, और बड़े scale पर उन्हें चलाना महँगा है
- orchestration layer टूटती है, context windows फटती हैं, और inference cost ऐसे bills में दिखती है जिन्हें board को दिखाना पसंद नहीं किया जाता
- फिर भी fleet की अवधारणा उपयोगी है: composition (अलग कामों के लिए अलग agents), coordination (handoff, dependencies, escalation), chain of command (mission तय करना, rules of engagement, outcome review), shift work (commander के सोने पर भी agents निर्देश की सीमा में काम जारी रखें और सुबह रिपोर्ट दें)
- अच्छी fleet की परिभाषा output volume नहीं बल्कि outputs की consistency है
- काम का नया रूप:
- सुबह triage और merge
- बीच में high-leverage human work — ग्राहक बातचीत, strategy, product decisions, और रात की execution को चलाने वाले specs लिखना
- दोपहर में पहले agents लौटें तो review और दिशा पुनर्निर्धारण
- दिन के अंत में वह काम जो पिछली पीढ़ी नहीं करती थी — handoff — काम को queue में डालना और agent fleet को रातभर प्रयास करने के लिए specs देना; उनमें कुछ गलत होंगे, कुछ चमकेंगे, और दोनों में फर्क करना ऐसा काम है जो केवल इंसान कर सकता है
उन models के लिए बनाइए जो अभी रिलीज़ नहीं हुए हैं
- पिछले कुछ वर्षों से लगातार ज़ोर दिया गया एक बिंदु: आज आप जो model उपयोग कर रहे हैं, वह उन models में सबसे मूर्ख है जिन्हें आप आगे उपयोग करेंगे
- हालांकि यह गारंटी नहीं कि capability growth smooth होगी — cost, latency, reliability और scaling limits इस curve को जटिल बना सकते हैं
- फिर भी directional bet को infrastructure layer पर दिखती चीज़ें मज़बूती से support करती हैं: frontier capabilities अगले 6–12 महीनों में आज से अर्थपूर्ण रूप से आगे होंगी, और आज तथा एक साल बाद के best model के बीच का gap पिछले साल और इस साल के gap से भी बड़ा हो सकता है
- रणनीतिक अर्थ: संगठनों को मौजूदा models के लिए नहीं बल्कि उन models का लाभ उठाने की क्षमता बनानी चाहिए जो उनके पास अभी नहीं हैं
- specs लिखने का तरीका, review culture, observability wiring, agent fleet operations, juniors की skills बनाए रखने के training rituals — यह सब 2026 की capability के लिए नहीं बल्कि 2027–2028 के लिए scaffolding है
- जो कंपनियाँ यह scaffolding अभी बनाती हैं, वे अगले capability jump को leverage के साथ absorb करेंगी; जो tools mature होने का इंतज़ार करेंगी, वे अपने पहले साल में वही सीखती रह जाएँगी जो early movers पहले से जानते होंगे
- ज़रूरत है कि मौजूदा models की माँग से भी अधिक specs, review और operational discipline में overinvest करने की इच्छा हो
- इस युग में irrelevancy खुद की घोषणा नहीं करती — वह धीरे-धीरे आई अक्षमता के रूप में आती है, जब आप उन teams के साथ नहीं चल पाते जो एक साल पहले आपसे स्पष्ट रूप से बेहतर नहीं थीं
खोने वाली मांसपेशियाँ
- चाहे यह मान लिया जाए कि AI समाज को निर्णायक रूप से stratify करेगी या व्यापक रूप से democratize, इंसान वैसे भी least resistance path को optimize करने में माहिर है
- मुख्य thesis: अगर आप खुद कुछ बनाना छोड़ देते हैं, तो बने हुए को evaluate करने की क्षमता भी खो देते हैं
- यह पहले ही दिख रहा है: जो junior engineers पहले सप्ताह से AI पर निर्भर हैं, वे तेज़ी से ship करते हैं और polished code बनाते हैं, लेकिन जब model किसी अनपेक्षित तरीके से fail होता है तो वे bug ढूँढ़ नहीं पाते — क्योंकि उन्होंने वह internal model विकसित ही नहीं किया जो रात 2 बजे stack trace से सौवीं बार जूझने पर बनता है
- taste polished draft पर approve दबाने से नहीं सीखी जा सकती, judgment इस तरह विकसित नहीं होती कि किसी कठिन समस्या पर एक दोपहर बिताने के बजाय machine का plausible उत्तर 5 सेकंड में स्वीकार कर लिया जाए, और craftsmanship दूसरे agent के काम की review करके हासिल नहीं होती
- यही वह training crisis है जिसे अधिकांश संगठन अभी तक पहचान नहीं रहे
- software engineering का apprenticeship model (junior छोटी चीज़ ship करता है → senior review करता है → junior red ink से taste absorb करता है) टूट रहा है — junior agents के माध्यम से ship करता है, और senior इंसानी output के बजाय agent output review करता है
- अगली पीढ़ी की craftsmanship कहाँ से आएगी? repetition के बिना taste कैसे train होगी? अगर mentee ने शुरुआत से खुद लिखा ही नहीं, तो mentoring की भरपाई कैसे होगी?
- अधिकांश पारंपरिक संगठनों में आज की senior engineer पीढ़ी पुराने तरीकों से पूरी तरह प्रशिक्षित अंतिम cohort है
- संतुलित प्रतिक्रिया: जानबूझकर और नियमित रूप से, किसी महत्वपूर्ण चीज़ पर fleet के बिना कठिन तरीके से खुद काम करें — आपके अधिकतर peers यह muscle नहीं बचाए रखेंगे, और 10 साल बाद यही फर्क पैदा कर सकता है
बेचैन करने वाला हिस्सा
- यह essay जानबूझकर optimism पर समाप्त नहीं होता — यह दिखावा करना कि बदलाव नहीं आएगा, उसके आने को नहीं रोकता
- काम पहले ही हमेशा के लिए बदल चुका है, और AI की गति के साथ evolutionary और incremental तरीके से बदल रहा है
- इंसान उस काम के लिए दिन वापस पाएगा जिसकी सच में उसे ज़रूरत है, और machine उस काम के लिए रात वापस लेगी जो हमेशा से साधारण labor था
- आने वाले कुछ वर्षों में संभावित परिदृश्य:
- review load से थकी हुई employees की परत
- system को चाहिए लेकिन reward न मिलने वाली विभाजित roles की परत
- juniors की ऐसी पीढ़ी जो वह craftsmanship विकसित नहीं कर पाती जिससे आज के seniors judgment बनाते हैं
- ऐसी teams जो output volume को work quality समझ बैठती हैं और incident होने तक gap पहचान नहीं पातीं
- अगले model के लिए operational muscles बना चुकी organizations और ऐसा न करने वाली organizations के बीच लगातार बढ़ता अंतर
- मुख्य संदेश: उन models के लिए organization बनाइए जो अभी आपके पास नहीं हैं, कभी-कभी कठिन चीज़ें खुद बनाइए ताकि तरीका याद रहे, रात की fleet को रवाना कीजिए और यह जानकर चैन से सोइए कि काम चल रहा है — लेकिन इस संभावना के प्रति सजग रहिए कि लौटकर आने वाली कुछ चीज़ें ऐसे तरीके से गलत होंगी जिन्हें पहचानने के लिए आप शायद अब प्रशिक्षित नहीं रहे
- 24/7 कर्मचारी कोई वादा नहीं बल्कि पुनर्स्थापन और probabilistic engineering के भविष्य पर दाँव है — ऐसा दाँव कि loop में मौजूद इंसान पर्याप्त तेज़, ईमानदार और प्रशिक्षित है ताकि loop में होना सार्थक रहे, और उस इंसान के आसपास का संगठन आज के models के लिए नहीं बल्कि अब तक रिलीज़ न हुए models के लिए बनाया गया हो
अभी कोई टिप्पणी नहीं है.