- Codex ने .txt में एक साल से अधिक समय से टल रहे structured generation algorithm experiment का पहला काम करने वाला वर्ज़न कुछ ही घंटों में बना दिया, लेकिन असली बदलाव व्यक्तिगत coding speed से ज़्यादा collaboration bottleneck के सामने आने में था
- जब implementation एजेंट संभालते हैं, तो टीम की रफ्तार धीमी करने वाली चीज़ code writer नहीं बल्कि roadmap, acceptance criteria, और design docs जैसी ऐसी सटीक specification बनाना हो जाती है जिन्हें एजेंट तुरंत execute कर सकें
- जब code लिखने की लागत कम हो जाती है, तो ऐसे prototype और internal tools बढ़ते हैं जिन्हें पहले बनाया ही नहीं जाता, और क्योंकि users जितनी गति absorb कर सकते हैं वह लगभग वही रहती है, इसलिए क्या नहीं बनाना है यह तय करने वाला focus और भी महत्वपूर्ण हो जाता है
- एजेंट Slack, PR, issue, commit, और design docs से implicit decisions और conventions निकालकर knowledge base बना सकते हैं, लेकिन वे इंसानों द्वारा सीधे बनाए गए shared context को पूरी तरह पुनर्स्थापित नहीं कर सकते
- अगले 10 साल में बढ़त शायद उन कंपनियों के पास होगी जो सबसे अच्छे model से ज़्यादा 50, 200, 2,000 लोगों के स्तर पर भी घटते हुए decision set के साथ aligned organizational consistency बनाए रख सकें
coding agents ने बॉटलनेक कैसे बदला
- .txt में एक साल से अधिक समय से टल रहा experiment structured generation algorithm और open source alternatives को test करने का था, और इसमें सिर्फ “क्या यह string स्वीकार होती है” नहीं बल्कि “क्या यह सही token distribution generate करता है” जैसे प्रश्न की जांच करनी थी
- यह experiment roadmap पर बना हुआ था, लेकिन Codex को लगभग 30 मिनट तक approach समझाने के बाद कुछ ही घंटों में इसका पहला working version तैयार हो गया
- coding agents पहले ही यह बदल रहे हैं कि व्यक्ति code कैसे लिखते हैं, लेकिन यह मानना मुश्किल है कि व्यक्तिगत productivity में सुधार सीधे पूरे software industry की गति बढ़ा देगा
- प्रभावशाली software अक्सर कई लोगों के collaboration से बनता है, इसलिए analysis की ज़्यादा दिलचस्प इकाई व्यक्तिगत productivity नहीं बल्कि collaboration है
- software उस चीज़ के अधिक करीब है जो लोगों द्वारा system को क्या करना चाहिए इस पर negotiation के बाद बचती है; code महत्वपूर्ण है, लेकिन वह उससे भी कठिन काम का residue है
roadmap ही सीमा बन जाता है
- जिन टीमों में implementation एजेंट करते हैं, वहाँ रफ्तार धीमी करने वाली चीज़ वह सटीक specification बनाना है जिसे एजेंट सीधे उठाकर execute कर सकें
- roadmap, acceptance criteria, और “हम वास्तव में क्या चाहते हैं” जैसी बातें test suite, ticket, और design docs जैसे रूपों में स्पष्ट रूप से लिखी जानी चाहिए
- features बहुत तेज़ी से implement हो जाते हैं, और engineers दूसरे engineers का इंतज़ार करने के बजाय अगली सही तरह से लिखी specification का इंतज़ार करने लगते हैं
- bottleneck code लिखने वाले व्यक्ति से हटकर उस व्यक्ति पर आ जाता है जो तय करता है कि कौन-सा code होना चाहिए, और यह अंततः management की समस्या है
सस्ता हुआ code, ज़्यादा सहमति की मांग करता है
- जब code लिखने की लागत कम होती है, तो इसका मतलब यह नहीं कि वही परिणाम पाने के लिए सिर्फ 10% मेहनत लगेगी; बल्कि वही मेहनत अब उन परिणामों पर लगने लगती है जिन्हें पहले बनाना ही उचित नहीं समझा जाता था
- जो prototype 3 महीने पहले “time waste” समझा जाता, वह अब एक दोपहर में बन सकता है, और जिन internal tools की स्पष्ट demand नहीं थी वे बनते भी हैं और भुला भी दिए जाते हैं
- users जितनी तेज़ी से features absorb कर सकते हैं, वह आम तौर पर लगभग वही रहती है, चाहे टीम 10 चीज़ें ship करे या 50
- जैसा Steve Jobs ने 1997 में कहा था, “focus is saying no”, और Apple ने उसी साल अपने product line का लगभग 70% हटा दिया था
- एजेंट होने पर नए features ship करना और आसान महसूस होता है, इसलिए सिर्फ क्या बनाना है नहीं बल्कि क्या नहीं बनाना है, यह तय करने की discipline और कठिन हो जाती है
context सबसे महत्वपूर्ण resource बन जाता है
- negotiation और agreement संगठन के भीतर के shared context पर चलते हैं
- context में यह शामिल होता है कि क्या बनाया जा रहा है, वह क्यों महत्वपूर्ण है, क्या-क्या आज़माया गया, किसने क्या तय किया, क्या core है और क्या सिर्फ leftover artifact है
- टीम के लोग एक ही कमरे में होते हैं, एक ही Slack channel पढ़ते हैं, और रात 2 बजे एक ही outage debug करते हुए स्वाभाविक रूप से context जमा करते हैं
- इस context का अधिकतर हिस्सा document नहीं होता, और जब कोई senior engineer PR review में कहता है, “यह migration तोड़ देगा”, तब भी वह अक्सर undocumented context का उपयोग कर रहा होता है
- एजेंट इस तरह का osmosis नहीं कर सकते; वे कमरे में मौजूद नहीं होते, planning conversation आधी-अधूरी नहीं सुनते, और न ही उनके पास पुराने outage की स्मृतियाँ होती हैं
- जो context prompt, file tree, tools, और explicit instructions में नहीं डाला गया, वह एजेंट के पास विश्वसनीय रूप से मौजूद नहीं होता
- context के बिना एजेंट थोड़ा गलत सवाल का भी plausible जवाब बना सकता है
- .txt में जब एजेंट उपयोगी काम करते थे, तब भी वास्तव में context वाला काम इंसानों ने पहले से किया हुआ था; ऐसा नहीं कि अगले 10 engineers को वह तस्वीर अपने-आप मिल जाएगी
- जिस context पर संगठन हमेशा से implicitly निर्भर रहे हैं, वही अब गति सीमित करने वाला input बन गया है, और इंसानों की प्रवृत्ति इसे implicit छोड़ देने की होती है क्योंकि पहले इसे पढ़ने के लिए कोई explicit version चाहिए ही नहीं था
एजेंट context पैदा करने वाला loop
- ऐसा context बनाना जिसे इंसान आसानी से consume कर सकें, आम तौर पर लोगों को पसंद नहीं आता
- एजेंट PR comments, closed issues, commit messages, पुराने design docs, और Slack archives को बिना थके पढ़ सकते हैं, और उन patterns को निकालने में अच्छे होते हैं जिन्हें किसी ने document नहीं किया
- .txt में codebase, issues, PRs, और threads को crawl करके implicit decisions, conventions, और “यह ऐसे क्यों किया गया” जैसी बातों को knowledge base में बदलने वाले एजेंट बनाना शुरू किया गया
- यह knowledge base सिर्फ “यह module मौजूद है” जैसा नहीं होता, बल्कि इसमें “यह module अजीब है क्योंकि migration को existing behavior preserve करना था” या “यह benchmark महत्वपूर्ण है क्योंकि पिछली optimization ने distribution को चुपचाप बदल दिया था” जैसा context होता है
- जब दूसरे एजेंटों को codebase में काम करना होता है, तो वे इस knowledge base का उपयोग करते हैं
- जिस osmosis को इंसान अनौपचारिक रूप से करते थे, उसे एजेंट और इंसान दोनों के पढ़ने योग्य रूप में externalize किया जाता है
- context consume करने वाले एजेंटों के लिए context produce करने वाले एजेंट भी चाहिए होते हैं, और जब यह loop चलने लगता है, तो संगठन के पास ऐसा documented foundation आ जाता है जिसे वे शायद अपने-आप कभी नहीं बनाते
- फिर भी यह loop हमेशा एक आंशिक तस्वीर ही बनाता है
- Michael Polanyi के शब्दों में, “हम जितना कह सकते हैं उससे ज़्यादा जानते हैं”, और कुछ महत्वपूर्ण context सिर्फ इसलिए मौजूद होता है क्योंकि उसे कभी शब्दों में लिखा ही नहीं गया; उसे लिखते ही वह बदल भी सकता है
- लोगों के सीधे मिलकर बनाने वाली osmosis की परत को सिर्फ documented byproducts से पूरी तरह पुनर्निर्मित नहीं किया जा सकता
- नतीजा पूर्ण पुनर्स्थापन नहीं बल्कि एक उपयोगी शुरुआती बिंदु के अधिक करीब होता है, और क्या यह cumulative effect देने के लिए पर्याप्त है, यह अभी भी एक experimental question है
नया moat तकनीक से ज़्यादा संगठन में है
- अगले 10 साल के विजेता ज़रूरी नहीं कि वही कंपनियाँ हों जिनके पास सबसे अच्छे models या सबसे अच्छा agent infrastructure हो, बल्कि शायद वे हों जो 50, 200, 2,000 लोगों तक बढ़ते हुए भी घटते हुए decision set के साथ aligned रहकर प्रति व्यक्ति अधिक output दे सकें
- ऐसी कंपनियाँ वे संगठन हैं जिन्हें agents आने से पहले ही पता था कि सबसे कठिन समस्या consistency है
- यह culture और management का प्रश्न है, और हमेशा से रहा है
- IDE, version control, CI, microservices, और DevOps जैसे पिछली पीढ़ी के tools ने बेहतर tools के ज़रिए coordination हल करने का वादा किया था, लेकिन व्यवहार में उन्होंने पहले से मौजूद organizational consistency को ही amplify किया
- छोटी टीमों को consistency लगभग मुफ्त में मिल जाती है, इसलिए amplification effect आम तौर पर सकारात्मक होता है; agents के समर्थन में मज़बूत आवाज़ें छोटी टीमों से ज़्यादा आने का कारण भी यही है, क्योंकि उनके context में यह अधिकांशतः सही है
- एक सीमा के बाद consistency को बनाना और बनाए रखना पड़ता है, और amplification effect दोनों दिशाओं में तीखा हो जाता है
- अच्छे संगठन और बेहतर होते हैं, और खराब संगठन और तेज़ी से टूटते हैं
- agents पिछले tools की तुलना में कहीं बड़े amplifier हैं; उन्हें व्यक्ति को तेज़ी से code लिखाने के साधन के रूप में बढ़ा-चढ़ाकर आंका गया है, और संगठन जो जानता है उसे externalize कराने के साधन के रूप में कम आंका गया है
कंपनी culture के विस्तार के रूप में agents
- agents अपने ही सोच-विचार के विस्तार जैसे महसूस हो सकते हैं, और यह एहसास शक्तिशाली है
- ज़्यादा कठिन काम agents को कंपनी culture के विस्तार में बदलना है
- इसके लिए writing culture, ऐसा thoughtful management जो पहचान सके कि bottleneck अब भी कहाँ context में है, और ऐसे लोग चाहिए जो consistency को बनाए रखने योग्य वास्तविक output की तरह लें
- नई बात यह है कि अब इनमें से कुछ चीज़ें बनाई जा सकती हैं
- पढ़ने और extract करने वाला loop उसी का एक रूप है, और आगे इसके दूसरे रूप भी आ सकते हैं
1 टिप्पणियां
Hacker News की टिप्पणियाँ
अपने पूरे करियर में टीम मीटिंग्स, agile rituals, issue trackers, backlog, Slack, email, design reviews जैसी हर उस चीज़ की शिकायत करने वाले इंजीनियर, जो उन कुछ घंटों की coding flow state में बाधा डालती थी जिसे वे सबसे मूलभूत और पवित्र काम बताते थे, अब जब मशीनें उनसे तेज़ code लिखने लगी हैं तो बिना किसी झिझक के अचानक सहयोगी गतिविधियों के महत्व और code/coding की तुच्छता पर उपदेश देने लगे हैं — यह काफ़ी हास्यास्पद लगता है
बात ग़लत नहीं है, लेकिन सिर्फ़ एक साल पहले तक हर टीम में सबसे असामाजिक और कम सहयोग करने वाले लोग जो इतनी खुली पाखंडता दिखा रहे हैं, वह अब भी चौंकाती है
वैसे, दोनों बातें एक साथ सही हो सकती हैं: code लिखना bottleneck न हो, इसलिए features deploy होने की क्षमता से भी तेज़ी से develop किए जा सकते हों; और साथ ही deep focus वाले काम के दौरान बार-बार interruption होना झुंझलाहट पैदा करता हो और flow तोड़ता हो
https://en.wikipedia.org/wiki/Group_attribution_error
customer और coder के बीच synchronization बढ़ाने वाली meetings दुर्लभ और क़ीमती होती हैं। बड़े संगठनों में rituals अक्सर ग़लत कारणों से बढ़ते जाते हैं। लोग customer और coder के बीच की प्रक्रिया में खुद को घुसाकर अपनी उपयोगिता दिखाना चाहते हैं
व्यक्तिगत रूप से मुझे customer, end user, UX designer और असली stakeholders के साथ meetings पसंद हैं। लेकिन corporate influence के लिए bandwidth खा जाने वाले office-politics प्रकार के व्यस्त लोगों के साथ meetings से मुझे नफ़रत है। मेरे users और मेरे बीच किसी और middle manager की ज़रूरत नहीं है
इसके उलट, अगर अब code लिखना बहुत तेज़ हो गया है और मुश्किल हिस्सा business/technical requirements को समझना बन गया है, तो वही व्यक्ति ऐसे rituals को ज़्यादा प्राथमिकता दे सकता है और AI agent के code लिखते समय interruption सह सकता है
जब हालात के तथ्य बदलते हैं, तो सोच बदलना पाखंड नहीं होता
अगर आप कंपनी के बाहर किसी के साथ creative project कर रहे हों, तो बहुत से कारण हैं कि आप Scrum rituals या Jira से शुरुआत नहीं करेंगे। collaboration को महत्व देते हुए भी इन चीज़ों की आलोचना करना पूरी तरह सुसंगत है
team शिकायत करती है कि काम इतना ज़्यादा है कि कुछ हो ही नहीं पा रहा, इसलिए manager मुझे लाता है। फिर अचानक वे कुछ भी handoff नहीं करना चाहते। मैं अभी भी ठीक उसी स्थिति के बीच में हूँ
team कहती है कि वे “पूरी तरह डूबे हुए” हैं, लेकिन फिर भी उनमें इतनी ऊर्जा है कि लगभग हर वह काम जिसे मैं संभाल सकता हूँ, उस पर दावा करें कि वही लोग सबसे अच्छे हैं और उन्हें मदद की ज़रूरत नहीं। मुझे कोई दिक्कत नहीं, बैठकर पैसे मिलते हैं। लेकिन गंध वही है
A: वे यह मानना नहीं चाहते कि उन्हें replace किया जा सकता है और उनका काम इतना अनोखा नहीं है, B: वे यह भी नहीं मानना चाहते कि bottleneck process या workload नहीं, बल्कि वे खुद हैं
ऐसा लगता है कि अनुभवी इंजीनियर हमेशा से जानते थे कि speed की समस्या का असली कारण तकनीक से ज़्यादा organization में होता है
business का focused, productive roadmap define न कर पाना software engineering की पुरानी समस्या रही है। अगली चमकीली चीज़ के पीछे भागते रहना, जबकि उसका ROI लगभग शून्य हो, और साथ ही systemic technical debt को address न करने देना — यही मैंने जिन कई कंपनियों में काम किया, उन्हें लंबे समय में नुकसान पहुँचाते देखा है
मैं ऐसे junior engineers को जानता हूँ जो एक साल C++ लिखने के बाद भी std::unique_ptr नहीं समझ पाए, और ऐसे लोग पूरी team में हमेशा सबसे धीमे होते हैं
पहले जब मैं junior engineer performance reviews लिखता था, तो performance सचमुच speed से बहुत प्रभावित होती थी, और मोटे तौर पर किसी समयावधि में लिखी गई bug-free code lines से मापी जाती थी। अच्छे juniors स्पष्ट रूप से defined feature लेकर जल्दी अच्छा code लिखते थे; कमज़ोर juniors वही काम लेकर या तो धीरे लिखते थे, या जल्दी bug भरा code लिखते थे जिससे debugging और rewrite का बहुत ज़्यादा काम पैदा होता था
business rationale, scope, inputs और desired outputs को साफ़-साफ़ समझ लेने पर data model, system design और code लगभग अपने-आप निकल आते हैं, या कम से कम बहुत अधिक स्पष्ट हो जाते हैं
— Melvin E. Conway, 1967
पहले यह समझना चाहिए कि Chinchilla जैसे scaling laws क्या होते हैं, और verification के साथ reinforcement learning मूल रूप से कैसे काम करती है
मैं पूरी तरह सहमत हूँ कि मूल सीमा इस बात में है कि business खुद को और अपनी strategy को लगातार स्पष्ट रूप से व्यक्त कर सकता है या नहीं
लेकिन अभी का फ़ायदा यह है कि prototype बनाना लगभग मुफ़्त हो गया है। पहले engineering headcount में निवेश करते समय अत्यधिक सावधानी रखनी पड़ती थी, अब उसी समय-सीमा में कहीं अधिक चीज़ें आज़माई जा सकती हैं
कौन-से features और bug fixes कब release करने हैं, और पूरे product को कैसे develop और manage करना है — यही हमेशा असली चुनौती रही है, और इस strategy का बड़ा हिस्सा उन feedback loops पर निर्भर करता है जिन्हें AI जल्दी produce नहीं कर सकता
साथ ही मुझे यह भी लगता है कि business side के leaders अक्सर अपनी ख़राब decisions की ज़िम्मेदारी लेने के बजाय engineering speed को scapegoat बना देते हैं
आम तौर पर bottleneck code ही होता है, लेकिन code writing नहीं बल्कि code खुद। मेरे करियर में slow applications की वजह से होने वाली देरी असंख्य रही है
Eclipse-आधारित editor इस्तेमाल करना पड़ता है, जो धीमा है और समय-समय पर freeze या crash होता है। build jobs में 15–20 मिनट लगते हैं। ऐसी web apps भी अक्सर मिलती हैं जो वह काम करने में अनंत समय लेती हैं जिसे अधिकतम 50ms लगने चाहिए
ऐसी सूची अंतहीन हो सकती है। हर delay एक interruption है जो मेरी concentration को टुकड़े-टुकड़े कर देता है। अब मैं management में हूँ और दर्जनों लोगों तथा administrative interruptions से जूझता हूँ, फिर भी कंपनी में code लिखता हूँ
software धीमा हो तो वह मेरी सबसे निचली प्राथमिकता बन जाता है। इसका किस पर असर पड़ता है, मुझे फ़र्क नहीं पड़ता। अगर यह सचमुच महत्वपूर्ण होता, तो हम सब उस धीमे software syrup के बंधक न होते जो हम सबको नीचे खींच रहा है
Code debt है
code को asset मानना आसान हो सकता है, लेकिन मूल रूप से वह debt है। नए code की ओर जाने वाले कुछ “bottlenecks” इसीलिए मौजूद होते हैं ताकि यह सुनिश्चित हो कि output, बढ़े हुए debt से बड़ा हो। जो agents तेज़ी से ज़्यादा code बनाते हैं, वे तेज़ी से ज़्यादा debt भी बना रहे होते हैं
coding agents को लेकर जो उत्साह और संदेह है, उसका बड़ा हिस्सा इसी बात पर है कि immediate productivity gains — यानी नए features, नए products, नई revenue — क्या long-term debt वृद्धि की भरपाई करते हैं। इसका जवाब शायद अगले 1–3 साल में ही पता चलेगा, और क्षेत्र के अनुसार अलग होगा
इस नज़रिए से, ऐसे bottlenecks को agentic workflow के भीतर सीधे डालने की कोशिश कुछ हद तक समझ में आती है। coding agents को project vision की निरंतरता पर ज़ोर देने वाला और नए features या uncontrolled process का विरोध कर सकने वाला अतिरिक्त context देना उपयोगी हो सकता है
क्या लेख का मतलब यह है? कि कुछ agents product management की ज़िम्मेदारी लें, जितना संभव हो उतना material एक coherent product vision में synthesize करें, और फिर उस vision को coding agents को यथासंभव सख़्ती से याद दिलाते रहें?
क्या ऐसे agents को नए proposals और नए pull requests की समीक्षा “big picture के साथ alignment” के नज़रिए से करनी चाहिए? चाहे उसे context कहें, vision कहें, या कुछ और
ऐसे agents context को synthesize करने और team values तथा vision के हिसाब से भाषाई रूप से ठीक लगने वाला coherent roadmap पेश करने में बहुत अच्छे हो सकते हैं। लेकिन क्या उनमें अच्छे manager या अच्छी team जैसी judgment होगी, इस पर मुझे संदेह है। किसी खास roadmap को तेज़ी से और प्रभावशाली ढंग से approve कर देना फ़ायदे से ज़्यादा नुकसान भी कर सकता है
business requirement को बिना अतिरिक्त complexity के हल करने के लिए जितना न्यूनतम code चाहिए, वह maintenance debt से जुड़ा हुआ एक asset है। जैसे किसान का tractor एक asset है जिसे maintenance चाहिए, और छोड़ देने पर वह bit rot से depreciate होता है
लेकिन जो code अनावश्यक complexity पैदा करने के लिए लिखा गया हो, वह शुद्ध debt है
सही है, लेकिन code लिखना हमेशा कुछ सिखाता है
मैंने founder-scale startups और सैकड़ों अरब डॉलर की listed companies — दोनों में काम किया है, लेकिन मैंने कभी ऐसा product spec, pitch deck या PRD नहीं देखा, जिसे specification के अनुसार implement कर देने भर से समस्या का समाधान करने वाला solution मिल जाए। असल में बनाकर ही पता चलता है कि चीज़ को कैसे काम करना चाहिए
software एक complex और interactive medium है। समस्या को समझना और हल करना चाहने वाले लोगों के साथ code के भीतर iterate करना ही हमेशा वह एकमात्र तरीका रहा है जिससे कोई मूल्यवान product बनता है। meetings और diagrams मदद करते हैं, लेकिन working software लिखने से पहले यह पता नहीं चलता कि आपके पास वास्तव में कुछ है भी या नहीं
“लक्ष्य हमारी structured generation algorithms और उनके open-source counterparts को test करना था, और भोले ‘क्या यह string accept करता है?’ को वास्तविक समस्या के ज़्यादा क़रीब ‘क्या यह सही token distribution generate करता है?’ से बदलना था… पिछले महीने मैंने Codex को 30 मिनट तक तरीका समझाया। कुछ घंटों बाद पहला working version आ गया। बस इतना ही”
यह साबित करता है कि bottleneck वास्तव में code ही था। अब बस AI ने वह code लिख दिया
जिसने भी सोचा कि “bottleneck code नहीं था”, वह पहले ही लक्ष्य पर चर्चा कर चुका था और उसे अपने दिमाग़ में व्यवस्थित रूप से साफ़ कर चुका था
यह कहने का मतलब कि code bottleneck था, ज़रूरी नहीं कि “मुझे यह feature चाहिए था लेकिन इसे code करने में महीनों लगते”। इसका यह अर्थ भी हो सकता है: “मैं यह feature दो साल से चाहता था, लेकिन बैठकर इसे code में बदलने और उस पर 5–10 दिन खर्च करने की friction की वजह से टालता रहा”
अगर code bottleneck न होता, तो वह बस बैठकर खुद लिख लेता। लेकिन वह खुद coding में समय और मेहनत नहीं लगाना चाहता था, और यह भी जानता था कि इसमें LLM जितना कम effort नहीं लगेगा
यहाँ तक कि जब final specification साफ़ न हो, तब भी exploratory coding, verify करना, फेंक देना, और नया design फिर आज़माना — यह सब LLM के साथ तेज़ होता है। क्योंकि ठीक वही “code” वाला हिस्सा तेज़ हो जाता है
दूसरे शब्दों में, bottleneck code ही था
यह लेख खुद भी ऐसा लगता है जैसे AI-generated text हो जिसमें बस घिसे-पिटे expressions से बचने का निर्देश डाला गया हो, इसलिए इसे पढ़ना अब भी उबाऊ है
लेख में लिखा था, “Jevons Paradox: जब कोई चीज़ सस्ती हो जाती है, तो हम उसका कम नहीं बल्कि ज़्यादा इस्तेमाल करते हैं”, लेकिन यह Jevons paradox को बिगाड़ देने वाला कथन है
वह वाक्य paradox नहीं, बल्कि एक बहुत स्वाभाविक प्रभाव है। कोई चीज़ सस्ती हो जाए तो उसका उपयोग बढ़ना सामान्य बात है
Jevons paradox वास्तव में उस स्थिति का वर्णन करता है जहाँ किसी resource का उपयोग अधिक efficient हो जाता है, यानी किसी काम के लिए उसकी ज़रूरत कम पड़ती है, फिर भी उस resource का कुल उपयोग बढ़ जाता है
लेकिन अगर resource usage अधिक efficient हो जाता है, तो क्या उस “usage” की कीमत सस्ती होना भी उतना ही स्वाभाविक नहीं है?
इसलिए efficiency बढ़ती है, और उपयोग भी स्वाभाविक रूप से बढ़ता है। इसे paradox इसलिए कहा जाता है क्योंकि कुछ लोग भोलेपन में मान लेते हैं कि efficiency gains consumption घटाने का अच्छा तरीका हैं
“paradox” कहे जाने वाली लगभग हर चीज़ ऐसी ही स्पष्ट होती है
या यह भी कि कोई process ज़्यादा effective हो जाए, यानी कम समय लेने लगे, और फिर भी हम उसी process पर और ज़्यादा समय खर्च करने लगें
bottleneck किस चीज़ के लिए? ज़्यादा features?
मुझे नहीं लगता कि software की मात्रा किसी कंपनी की सफलता तय करती है। और मैं यह भी नहीं मानता कि context की मात्रा को पकड़ लेना इतना महत्वपूर्ण है
महत्वपूर्ण context की quality है। इंसान कितनी अच्छी reasoning करते हैं?
उसके बाद attitude आता है। इंसान बुरी परिस्थितियों पर कितनी अच्छी प्रतिक्रिया देते हैं?
उसके बाद resource management है। कंपनी लोगों और पैसे को कितनी अच्छी तरह संभालती है?
आख़िर में luck है। जो चीज़ें आपके नियंत्रण में नहीं हैं, उनमें से कितनी आपके पक्ष में जाती हैं?
ये काफ़ी अच्छे company bottlenecks हैं। नहीं लगता agents इन्हें जल्द हल कर देंगे
non-software business जिन software applications का उपयोग करते हैं, उन्हें बेहतर बनाने में bottleneck इस बात में है कि software सचमुच वही सारे software tasks करे जो business के लिए लाभकारी हों
यानी समय बचाए, इंसानों को अधिक productive बनाए, human error घटाए, business को अधिक efficient बनाए, और margins बढ़ाए
इन सब चीज़ों का अनुमान लगाना और उन्हें quantify करना काफ़ी मुश्किल है। आप business के लिए उपयोगी किसी idea से शुरू कर सकते हैं, design कर सकते हैं, prototype बना सकते हैं, test कर सकते हैं। अंत में आप software application बनाते या सुधारते हैं, और यह मापने की कोशिश करते हैं कि उसने business को कितना बेहतर बनाया
इस पूरे process में यह सुनिश्चित करना कि software सही समस्या को सही तरीके से address कर रहा है, और अंततः business को बेहतर बना रहा है — यही कठिन समस्या है। software बनाना कितना तेज़ या आसान हो गया है, इससे यह नहीं बदलता
फिर भी speed सचमुच मदद कर सकती है। आप prototypes बना सकते हैं, tests चला सकते हैं, और feedback loops बेहतर कर सकते हैं
AI coding assistants के साथ, वे चीज़ें जो पहले junior developer के काम मानी जाती थीं, अब एक तेज़ prompt और background में चल रहे agent से पूरी हो जाती हैं
ऐसे junior developer tasks अब coding assistants लगभग बिना मानवीय हस्तक्षेप के आसानी से deliver कर देते हैं। backlog उसमें नए items जुड़ने की गति से भी तेज़ खाली हो रही है। और जब throughput अब समस्या नहीं रहता, तो नए items भी और तेज़ी से जुड़ने लगते हैं
अब चुनौती बदलावों की मात्रा के साथ बने रहने की है। मैं इसे अपनी organization में सीधे देख रहा हूँ
सिर्फ़ इसलिए कि आप दूसरे bottlenecks सोच सकते हैं, इसका मतलब यह नहीं कि code generation bottleneck नहीं था, या अब नहीं है। backlog की अवधारणा ही दिखाती है कि वह bottleneck है
“software वह चीज़ है जो इस बात पर मनुष्यों के एक समूह की बातचीत और सौदेबाज़ी के बाद बचती है कि system को क्या करना चाहिए”
मुझे यह अभिव्यक्ति पसंद आई। खासकर context वाली बात से मैं सहमत हूँ। लंबे समय तक साथ रहने वाली अनुभवी teams का असली इनाम वहीं मिलता है
मैंने दशकों तक ऐसी teams को manage किया है। अंत में जब हमारे department का integration हुआ, तब सबसे कम senior engineer भी 10 साल का अनुभव रखता था
जब team इतने लंबे समय तक साथ रहती है, तो communication overhead लगभग नगण्य स्तर तक गिर जाता है
इसलिए आजकल की अल्पकालिक tenure वाली संस्कृति मुझे सबसे ज़्यादा दुख देती है
आजकल मैं ज़्यादातर अकेले काम करता हूँ। productivity बहुत ऊँची है, लेकिन scope सचमुच सीमित है
अच्छी team का हिस्सा होने के दिन याद आते हैं
आख़िर आप किस तरह के projects पर काम करते हैं, जहाँ management जो features चाहता है उन्हें समझ लेना ही मुश्किल हिस्सा है, और बाक़ी बस “type out” करना होता है या आजकल LLM को सौंप देना?
अगर आपका काम यही है, तो हैरानी नहीं कि HN पर बहुत से लोग सोचते हैं कि LLM उन्हें replace कर सकता है
इसलिए हम फिर वही गोल-गोल चक्कर लगाते हैं, अपनी बेचैनी बताते हैं, एक-दूसरे से अलग बातें करते हैं, और 30 मिनट बाद अगली टिप्पणी के मौके का इंतज़ार करते हैं
ज़्यादातर code quality के हिसाब से जलता हुआ कचरा हैं, offshore outsourcing और layoff cycles की वजह से