- जिस दौर में AI सारा software लिखेगा, उस दौर में टोकन (inference cost) बचाने वाला software ही evolutionary selection pressure के जरिए जीवित रहेगा
- Survival Ratio फ़ॉर्मूले के ज़रिए software की fitness मापी जाती है, और तभी survival संभव है जब cognitive savings, cognitive cost से अधिक हो (यानी 1 से ऊपर)
- Git, grep जैसे tools insight compression और substrate efficiency की वजह से ऐसे उदाहरण हैं जिन्हें AI द्वारा फिर से बनाकर इस्तेमाल करना बेहद महंगा पड़ता है
- किसी agent के लिए tool अपनाने में awareness और minimum friction अनिवार्य हैं, और Desire Paths डिज़ाइन प्रभावी है
- AI-केंद्रित युग में भी Human Coefficient काम करता रहेगा, इसलिए वे क्षेत्र जहाँ मानवीय हस्तक्षेप और पसंद सीधे मूल्य बनाते हैं आगे भी जीवित रहेंगे
पृष्ठभूमि: AI युग में software का पूर्वानुमान
- 2024 जून में Death of the Junior Developer, 10 महीने पहले orchestrator के आगमन का पूर्वानुमान, और Gas Town प्रोजेक्ट आदि के माध्यम से AI की विकास-रेखा का लगातार सही अनुमान लगाया गया
- 2023 में code autocomplete → 2024 में conversational interface → 2025 की शुरुआत में agents → 2026 की शुरुआत में orchestration तक जाने वाले प्रवाह को extrapolate करके Gas Town विकसित किया गया
- सभी पूर्वानुमानों की नींव exponential development curve पर वैसा ही भरोसा रखने के रवैये में है
- Dario Amodei और Andrej Karpathy ने software के भविष्य के बारे में जिस दिशा की बात की है, उस पर पूरा भरोसा है
- Gas Town ऐसा उदाहरण है जो दिखाता है कि यह extrapolation वास्तव में काम करता है; 2025 के अंत के models और कई अस्थायी workarounds के सहारे मुश्किल से संभव होने वाला रूप पहले ही देख लिया गया
ख़तरे में पड़ा software ecosystem
- SaaS कंपनियों पर दबाव बढ़ रहा है, और buy बनाम build की cost structure बदलने से business departments खुद vibe coding के जरिए अपना SaaS बनाने लगे हैं
- सिर्फ़ 3 साल पहले GPT-3.5 एक single function लिखने में भी जूझता था, लेकिन अब छोटे लेकिन वास्तविक मूल्य वाले SaaS सीधे बनाए जा सकते हैं
- Stack Overflow और Chegg को शुरुआती झटका लगा, और उसके बाद दबाव Tier-1 customer support software, low-code·no-code systems, content generation tools और तरह-तरह के productivity tools तक फैल गया
- IDE vendors भी Claude Code के आने के बाद competitive pressure महसूस करने लगे हैं
- AI researchers के अनुमान लगभग 40 वर्षों तक उच्च सटीकता दिखाते रहे हैं, इसलिए यह मानकर तैयारी ज़रूरी है कि software के हर क्षेत्र पर ख़तरा आ सकता है
Selection pressure model (Selection Argument)
- inference के लिए tokens चाहिए, token consumption energy use में बदलता है, और energy अंततः cost में बदलती है
- {tokens, energy, money} को एक ही resource constraint की तरह देखा जा सकता है, और ये हमेशा सीमित रहते हैं
- cognitive cost घटाने वाला software ही जीवित रहता है — यही सरल नियम पूरे software ecosystem को आकार देता है
- सीमित संसाधनों वाले वातावरण में जो इकाइयाँ संसाधनों का अधिक कुशल उपयोग करती हैं, वे कम कुशल इकाइयों को बाहर कर देती हैं; यह वही संरचना है जो evolutionary selection pressure में दिखती है
Survival Ratio फ़ॉर्मूला
- Survival(T) ∝ (Savings × Usage × H) / (Awareness_cost + Friction_cost)
- Savings: tool का उपयोग करके बचाई गई cognitive cost, यानी वही functionality शुरुआत से synthesize करने की तुलना में बचने वाले tokens
- Usage: कितनी बार और कितने व्यापक संदर्भों में tool को दोबारा इस्तेमाल किया जा सकता है
- H (Human Coefficient): efficiency से अलग, इंसानों द्वारा बनाई चीज़ों को दी जाने वाली value को दर्शाने वाला coefficient
- Awareness_cost: agent द्वारा उस tool के अस्तित्व को जानने, याद रखने और सही समय पर चुनने में लगने वाली energy
- Friction_cost: वास्तविक उपयोग के दौरान errors, failures, retries और misunderstandings से खर्च होने वाली energy
- survival के लिए न्यूनतम अनुपात 1 है, और जहाँ competition मौजूद हो वहाँ इससे काफ़ी अधिक अनुपात चाहिए
- उदाहरण: 1.2 survival ratio वाला tool, 2.5 ratio दर्ज करने वाले competitor से बाहर हो सकता है
Lever 1: Insight Compression
- software industry ने लंबे समय में जो ऐसा ज्ञान जमा किया है जिसे दोबारा खोज निकालना बहुत महंगा है, उसे reusable रूप में compress किया जाता है
- Git इसका प्रतिनिधि उदाहरण है; commit DAG, pointer के रूप में ref, index, reflog आदि दशकों के trial-and-error का संकेंद्रित रूप हैं
- अगर AI इसे शुरू से reimplement करे, तो उसे वही बौद्धिक इतिहास फिर से तय करना पड़ेगा, इसलिए यह आर्थिक रूप से बिल्कुल तर्कसंगत नहीं है
- यही सिद्धांत databases, compilers, operating systems, workflow engines और monitoring systems पर भी लागू होता है
- Kubernetes जटिल इसलिए नहीं है कि उसका design उलझा हुआ है, बल्कि इसलिए कि distributed systems स्वयं मूल रूप से जटिल हैं
- Temporal सीधे saga pattern को idempotent retries के साथ implement करना लगभग research project जैसा कठिन होने के कारण, उसके बदले durable execution प्रदान करता है
- मज़बूत software की साझा विशेषता यह है कि उसे फिर से synthesize करने की कोशिश ही बेतुकी लगे, इतनी अधिक insight density उसमें होती है
- Gas Town में character role model या
gt sling जैसे verbs भी जटिल concepts को छोटे और याद रखने में आसान expression में compress करने के उदाहरण हैं
Lever 2: Substrate Efficiency
- grep ऐसा ही एक और उदाहरण है, जिसे फिर से बनाना लगभग पागलपन होगा
- Ken Thompson ने इसे एक आधे दिन में बना दिया था, लेकिन यह CPU-आधारित processing के जरिए भारी cognitive cost बचाता है
- text pattern matching में CPU, GPU को कई orders of magnitude से पीछे छोड़ देता है
- LLM की multiplication शैली pattern matching को जोड़कर पहले “लगभग 94” जैसा अनुमान बनाती है, फिर याद किए गए lookup table से digits को adjust करती है
- यह पूरा computation GPU inference phase जैसी बेहद अक्षम substrate पर किया जाता है
- calculator, parser, ImageMagick जैसे complex transformation tools, और कई Unix CLI utilities इस lever का सक्रिय उपयोग करते हैं
- अच्छे algorithms लागू करके, या computation को CPU·human जैसी सस्ती substrates पर शिफ्ट करके tokens और energy की बचत की जा सकती है
Lever 3: Broad Utility
- survival ratio model में यह Usage वाले भाग से मेल खाता है
- जितना व्यापक उपयोग होगा, awareness cost उतनी अधिक फैल जाएगी, और प्रति-उपयोग आवश्यक token savings की threshold उतनी कम होगी
- सचमुच के general-purpose token-saving tools को, भले AI सैद्धांतिक रूप से reimplement कर सके, फिर भी पहले से हर जगह मौजूद और व्यापक रूप से इस्तेमाल हो रहे विकल्प को प्राथमिकता मिलेगी
- Temporal अपेक्षाकृत ऊँची awareness cost और friction cost के बावजूद PostgreSQL जितना general workflow model देता है
- इसमें aggressive insight compression, computation substrate का कुशल उपयोग, और broad utility — तीनों levers मौजूद हैं
- Dolt एक Git-versioned database है, जो 8 साल से चला आ रहा open source project है
- agent-based production और DevOps workflows में इसे देर से killer app मिला
- अगर agents production environment में गलती करें, तब भी Git की पूरी functionality से rollback·rollforward संभव है
- code search engines की अहमियत तेज़ी से बढ़ रही है क्योंकि LLM पहले की तुलना में 10 से 100 गुना अधिक code बना रहे हैं
- एक बड़े general-purpose niche का निर्माण हो रहा है, यानी वह क्षेत्र जो “इतना बड़ा कि grep से नहीं संभलता”
- वे non-trivial समस्याएँ हल करते हैं जिनमें ढूँढना मुश्किल edge cases बहुत होते हैं, सस्ती computation substrate का उपयोग करते हैं, और broadly applicable होते हैं — इसलिए तीनों levers को पूरा करते हैं
Lever 4: Publicity
- सिर्फ़ cognitive cost बचाना काफ़ी नहीं है; awareness problem, यानी pre-selection stage की समस्या, भी हल करनी होती है
- Dolt के पास lever 1~3 थे, लेकिन शुरुआत में lever 4 की कमी के कारण वह व्यापक उपयोग तक नहीं पहुँच पाया
- awareness cost चुकाने के कई तरीके हैं
- शानदार product बनाकर लोकप्रिय होना, और फिर community के जरिए स्वाभाविक रूप से training data में शामिल होने का इंतज़ार करना
- या फिर cost लगाकर agent-oriented documentation में निवेश करना या advertising चलाना
- एक अधिक सीधा तरीका यह है कि OpenAI, Anthropic, Google जैसी frontier labs के ज़िम्मेदार लोगों के साथ मिलकर tool को model training process में शामिल कराया जाए
- paid service के रूप में, tool के सही उपयोग और misuse दोनों दिखाने वाले evals बनाए जाते हैं, और फिर researchers training को adjust करते हैं
- agents के लिए SEO की अवधारणा अब गंभीर रूप से उभर रही है
- यदि बड़े बजट लगाना कठिन हो, तो post-selection stage की energy, यानी lever 5, पर निर्भर रहना होगा; इसके लिए tool को अधिकतम agent-friendly बनाना ज़रूरी है
Lever 5: Minimizing Friction
- अगर awareness pre-selection stage की समस्या है, तो product friction post-use stage की समस्या है
- agents हमेशा ऐसे व्यवहार करते हैं मानो उन पर समय का दबाव हो, और कुछ अटकते ही तुरंत workaround आज़माते हैं
- ज़रा-सी friction भी फ़ैसला बदल देती है, और agent अधिक efficient tool छोड़कर कम efficient लेकिन परिचित और predictable तरीक़े पर लौट जाता है
- इसके उलट, किसी agent की पसंद के हिसाब से ठीक-ठाक डिज़ाइन किया गया tool वह लगभग ज़िद की हद तक बार-बार इस्तेमाल करता है
- documentation approach training stage की बजाय inference time तक awareness cost को टालने का तरीका है
- tool किस काम में अच्छा है, कब और क्यों इस्तेमाल करना चाहिए, quick start guide, और आगे की docs का रास्ता सीधे context में inject किया जाता है
- लेकिन इससे भी बेहतर हल है ऐसा tool बनाना जो agent को स्वाभाविक रूप से intuitive लगे
- Desire Paths design के उदाहरण के तौर पर, Beads की CLI 4 महीनों में 100 से अधिक subcommands, कई sub-subcommands, aliases और alternative syntax से होकर विकसित हुई
- यह जटिल CLI इंसानों के लिए नहीं, बल्कि agents के usage patterns के लिए डिज़ाइन की गई है
- agents कैसे कोशिश करते हैं इसे देखकर, hallucinations को वास्तविक functionality में implement किया गया; अब लगभग हर अनुमान सच में काम करता है
- Hallucination Squatting वह तकनीक है जिसमें LLM जिन domain names को अक्सर hallucinate करते हैं, उन्हें उल्टा खोजकर register किया जाता है, और वहाँ artifacts रखे जाते हैं ताकि वे सचमुच download हो जाएँ
- इससे पता चलता है कि nation-state स्तर के hacker groups भी Agent UX को समझते और इस्तेमाल करते हैं
- Agent UX निर्णायक रूप से महत्वपूर्ण है, लेकिन अभी भी ज़्यादातर tools में इसे नज़रअंदाज़ किया जाता है
- आदर्श tool या तो agent के पहले से परिचित किसी दूसरे tool जैसा लगे, या समस्या को ठीक उसी तरह हल करे जिस तरह agent सोचना चाहता है
Lever 6: Human Coefficient
- token efficiency से अलग, ऐसा software भी मौजूद है जिसे सिर्फ़ इस तथ्य से value मिलती है कि उसमें इंसानी भागीदारी है
- value human curation, social proof, creativity, physical presence और approval जैसे तत्वों से निकलती है
- मानव द्वारा चुनी गई playlist समान quality और अधिक energy-efficient AI-generated playlist को हरा सकती है
- gaming में वास्तविक इंसानों की मौजूदगी वाला environment आम तौर पर जीतता है, और सिर्फ़ साफ़ तौर पर इंसान से बेहतर AI के साथ ही खेलना चाहने वाले लोग कम होते हैं
- agents को बाहर रखने वाले social networks उलटे अधिक आकर्षक माने जा सकते हैं
- भले AI सबसे अच्छा teacher बन जाए, कुछ लोग जानबूझकर मानव शिक्षक चुनेंगे
- उच्च Human Coefficient वाले क्षेत्रों में भी competition तीव्र रहेगा
- Karpathy की कल्पित दुनिया में agents किसी के लिए भी कुछ भी बन सकते हैं, और उनमें मूलतः तेज़ addictive quality होती है
- नतीजतन बेहद अक्षम लेकिन बहुत ऊँचे H value वाले software की बड़ी संख्या होने की संभावना है
उम्मीद की वजह
- वह software जो humans और AI के बीच बिचौलिये की तरह काम करता है, या वह “स्मार्ट दिखने वाली भूमिका” निभाता है जिसे AI जल्द सीधे कर सकेगा, संरचनात्मक रूप से जोखिम में है
- इसके बावजूद जो software लिखा जाना चाहिए उसकी मात्रा लगभग असीमित है
- सभी बीमारियों का इलाज, हर protein के behavior का modeling, हर ग्रह-अन्वेषण scenario अब भी बाकी है
- मानवीय महत्वाकांक्षा हमेशा उपलब्ध cognitive capacity से आगे होती है, और token cost गिरने पर भी हम तुरंत और दूर के frontier की ओर बढ़ जाते हैं
- attention की समस्या को print media, internet, social media, real-time advertising और aggregators के दौरों में हम पहले भी कई बार हल कर चुके हैं
- Desire Paths design वास्तव में काम करता है, और OpenAI जैसी जगहों के बड़े training budgets के बिना भी ऐसे tools बनाए जा सकते हैं जिन्हें agents स्वाभाविक रूप से इस्तेमाल करना चाहें
- Human Coefficient सचमुच मौजूद है, और लोग पहले ही ऐसी चीज़ों से थकान महसूस करने लगे हैं जिनमें agent-जैसी गंध बहुत ज़्यादा है
- अगर design का केंद्र मानव-से-मानव connection और creativity हो, तो आख़िरकार बात फिर traditional marketing और branding के क्षेत्र में लौट आती है
- इन छह levers से मिलने वाले जीवित रहने के कई रास्ते मौजूद हैं
- अगर आप ऐसा कुछ बनाते हैं जिसे दोबारा बनाना ही पागलपन लगे, और उसे खोजना आसान व इस्तेमाल करना आसान बनाते हैं, तो काफ़ी मज़बूत संभावना बनती है
अभी कोई टिप्पणी नहीं है.