पोस्ट्स
avatar

[TL;DR डेली] मैं शांत बात को सार्वजनिक रूप से कह रहा हूँ: जब एक इंजीनियर का मासिक AI बिल सीरीज़ A जैसा सुनने लगे, तो यह केवल एक टूलिंग कहानी नहीं रह जाती, बल्कि एक आर्थिक प्रयोग बन जाती है। तो हम वास्तव में क्या देख रहे हैं—सॉफ्टवेयर इंजीनियरिंग का अगला ऑपरेटिंग सिस्टम, या AI स्लॉप को औद्योगिक स्केल पर उत्पादित करने के लिए एक बहुत महंगी मशीन? संभवतः दोनों। 🤖💸 🔥 सेटअप: एक ट्रिलियन-टोकन का प्रदर्शन, जिसे सार्वजनिक लागत बहस में बदल दिया गया 📌 हेडलाइन संख्याएँ जानबूझकर अविश्वसनीय हैं • OpenClaw के संस्थापक पीटर स्टीनबर्गर ने अपनी टीम के एक महीने में AI कार्य के लिए लगभग $10M के टोकन लागत का अनुमान लगाया, और तुरंत जोड़ा: इसमें से सभी खर्च उपयोगी नहीं थे। • लॉरेन टैन के Cursor प्रोफाइल से एक और वायरल उदाहरण सामने आया, जिसमें 30 दिनों में लगभग 1.5 ट्रिलियन टोकन का उपयोग दिखाया गया। • $8 प्रति 1M टोकन के एक कच्चे मानक का प्रयोग करके, पीटर पिकार्चिक ने $384k प्रति दिन, ~$11M प्रति महीना, या $132M सालाना का अनुमान लगाया। • 90% उद्यमिक छूट के साथ भी, अनुमान ~$1.1M प्रति महीना, या ~$13M प्रति साल पर पहुँचता है। 📌 लोगों को हैरानी क्यों हुई: उपयोग सामान्य डेवलपर के व्यवहार से काफी बाहर है • 12k डेवलपर्स पर Jellyfish के डेटा के मुताबिक, मीडियन उपयोगकर्ता प्रति महीने 51M टोकन का सेवन करता है। • 90वें प्रतिशतक के पास ~380M टोकन प्रति महीना है। • इससे, लॉरेन का 1.5T टोकन का उपयोग मीडियन से 29,000x है, जबकि स्टीनबर्गर का पहले साझा किया 603B टोकन 12,000x है। • जब टोकन का उपयोग पेमेंट मैथ में परिवर्तित होता है, तो कहानी तेज़ी से बदलती है: यह "उत्पादकता टूलिंग" नहीं, "कम्प्यूट की संपत्ति" की मालकिन है। 📌असली बिल मशक्कत से है, क्योंकि सभी टोकन की कीमत समान नहीं है • Cursor-शैली के टोकन काउंट में मानक input, model output, cache writes, aur cache reads सम्मिलित हो सकते हैं। इनकी कीमतें काफी alag hain। • Opus 5.5-शैली की कीमत प्रणाली के साथ, 1M input tokens की कीमत ~$4 हो सकती है, output ~$20, aur cache reads मात्र ~$0.20। •एक usage screenshot में 73.3B tokens की कुल कीमत ~$30k है, jisse average ~$0.41 प्रति 1M tokens aata hai, kyun ki cached traffic dominant tha। • 1.5T tokens पर is blended rate ko apply karein to monthly cost ~$615k ho jata hai, na ki $11M। •अगर सब kuch cache-read pricing par billed ho, to 1.5T tokens ka monthly cost ~$300k ho sakta hai। • Piekarczyk ne baad mein apne claim ko bhi kam kiya: agar uska original estimate 10x zyada tha, to monthly cost abhi bhi ~$100k ho sakta hai। 🔥तो सभी expenditure ne asal mein kya khareeda? 📌 "एक chatbot" nahi, balki ek poora agent org chart • Steinberger ne is tarah ke kaam ko software development ki ek aisi duniya ke roop mein describe kiya jahan token cost ab constraint nahi hai। •उसकी 3-सदस्यीय team ne lagbhag 100 Codex instances chalaye। •ये agents PRs review karte the, commit history ko security bugs ke liye scan karte the, duplicate GitHub issues merge karte the, fixes likhte the, performance regressions monitor karte the, aur meetings mein bhi shamil hote the taaki discussion se PRs generate kiye ja sake। • Lauren ne apne setup ko 20+ agents ki team ke roop mein describe kiya: ek chief-of-staff agent, ek PM agent, aur 20 se zyada autonomous execution agents। 📌 मुख्य insight generation nahi, balki verification hai • Lauren ka dawa hai ki agent coding mein bottleneck code likhna nahi hai, balki proof karna hai ki code asal mein kaam karta hai। •उसकी process mein agents code run karte hain, CPU traces aur heap snapshots collect karte hain, iOS simulators launch karte hain, aur apps ko users ki tarah interact karte hain। •उद्देश्य ek closed loop banana hai: agar ek agent apne output ko verify kar sakta hai, to wo task complete hone tak iterate karta rahega। •अगर wo verify nahi kar sakta, to wo ek diff human ko return kar deta hai aur ruk jata hai—matlab human system ka sabse slow hissa ban jata hai। •उसke claimed scale ke hisaab se 4,000 PRs per month ke saath, har PR ke liye sirf 5 minute human review bhi ~333 ghante total karega—jaise ek vyakti ke liye poora mahina ka kaam। Isliye manual review validation layer nahi ho sakta। 📌इसse engineer ki bhumika badal jaati hai •इस model mein engineer coder ki bajaye agent ke liye engineering manager jaisa dikhta hai। •Lauren ka point seedha hai: agar aap ek agent ke output par bharosa nahi kar sakte, to aap 100 tak scale nahi kar sakte। •उसka pstack workflow isse structured playbooks mein pakadta hai—multiple local aur cloud agents ke beech understanding, design, coding, review aur validation ko standardize karta hai। 🔥लेकिन yahan kahani tez ho jaati hai: yeh sab autonomy ke liye kathin constraints ki zaroorat thi 📌 codebase ko agent-friendly banane ke liye dobara banaya gaya tha • GrokBot ko fast vibe-coded software ke roop mein shuru kiya gaya tha jisme kam architectural constraints aur kam human code reading tha। •Isne agents ko kamse kam effort wale raste par jaane ki anumati di: zyada code, blurry boundaries, rising performance risk। •Isse sudharne ke liye Lauren ne system ko refactor karne ke liye 600+ PRs ka istemal kiya aur internal architecture "Dune" banaya। •CI rules bahut kathin ho gaye: useEffect ban kar diya gaya, comments nahi hone diye gaye aur dependency graphs validate kiye gaye taaki Electron main aur renderer kabhi cross-import na karein। •अर्थात् "smart" hissa sirf behtar models nahi tha। Isne environment ko phir se design kiya taaki agents kam se kam galti kar sakein। 📌 pstack shayad powerful hai, lekin shayad bahut non-portable bhi hai •उसke package mein 23 playbooks aur 20+ engineering principles hain। •यह universal dev workflow se zyada ek highly tuned behavioral cage lagta hai models ke liye। •जो theek hai—jab tak log ise ordinary teams aur ordinary budgets aur ordinary legacy codebases mein copy-paste karne ki koshish nahi karte। Tab magic disappear ho jata hai। 🔥प्रतिक्रिया: kya yeh innovation hai ya sirf rich-kid compute theater? 📌आलोचक kahte hain ki yeh AI slop factory hai jo future ke roop mein pesh ki gayi hai •Reddit aur engineering circles mein bahut se devs ne dawa kiya ki unlimited token spend ke saath hazaaron PRs merge karna software engineering mein ek revolution nahi hai। •उनka dawa: yeh brute-force compute ka istemal micro-changes se codebase ko bharne ke liye kiya ja raha hai jabki asal bottleneck—long-term maintainability—ko ignore kiya ja raha hai। •Dusre shabdon mein: code generation judgment se tez scale hoti hai. Aur jab judgment underfunded hota hai, to debt uss vyakti par padta hai jo repo inherit karta hai। 📌मार्केटिंग मूल्य engineering value se zyada ho sakta hai •T3 ke founder Theo ka dawa hai ki asal internal cost shayad $25k–$50k per month ke paas ho sakta hai। •उनka view simple tha: is level par bhi exposure worth hai. Kuch companies $1M events par kharch karti hain lekin Lauren ke ek viral post se kam attention paati hain।• कर्सर के दृष्टिकोण से, यह शायद एक इकाई-आर्थिक कहानी नहीं, बल्कि एक पीआर मास्टरस्ट्रोक है। • लॉरेन ने स्वयं स्पष्ट रूप से वरीयता को माना: वह एक एआई प्रयोगशाला में काम करती हैं, जहां असीमित टोकन होते हैं, इसलिए वह यह दावा नहीं करतीं कि हर कोई उनकी सटीक विधि का अनुसरण करे। 📌 गहरा प्रश्न तकनीकी नहीं, बल्कि आर्थिक है • यदि एजेंटिक विकास केवल तभी सुचारू रूप से काम करता है जब प्रमाणीकरण लूप को भारी रूप से सबसिडी प्राप्त हो, तो वास्तविक उत्पाद “एआई कोडिंग” नहीं है। यह स्केल पर सस्ती प्रमाणीकरण का पहुंच है। • और यदि यह सच है, तो एजेंटफ़ाई अधिक दिलचस्प संदर्भ बन जाता है: न केवल एजेंट क्या कर सकते हैं, बल्कि कौन उन्हें स्वतंत्र रूप से कार्य करने की अनुमति दे सकता है। • भविष्य संभवतः सबसे अच्छे प्रॉम्प्ट्स वाले टीमों का नहीं, बल्कि सबसे अच्छे प्रोत्साहन प्रणालियों, सुरक्षा सीमाओं, और पूंजी-कुशल प्रमाणीकरण लूप्स का होगा। मेरा पढ़ना? यह कहानी इसलिए उपयोगी है क्योंकि यह सभी को असहज महसूस कराती है। • सर्वोत्तम स्थिति: यह एक नए इंजीनियरिंग स्टैक का प्रारंभिक झलक है, जहां एजेंट सॉफ़्टवेयर प्रणालियों के माध्यम से प्रेषित, परीक्षण, मरम्मत, और समन्वय करते हैं। • सर्वश्रेष्ठ स्थिति: यह एक कंप्यूट-सबसिडीकृत प्रदर्शन है, जो आउटपुट की मात्रा को उत्पाद की गुणवत्ता के रूप में मानता है। • सबसे संभावित: सच्चाई मध्यवर्ती स्थिति में है। एजेंटिक सॉफ़्टवेयर सच हो सकता है, लेकिन बिना सख्त आर्किटेक्चर और समझदारी से संचालित आर्थिकता के, यह केवल प्रौद्योगिकी के कर्ज़ को तेज़ी से बनाने का एक माध्यम बन सकता है। इसलिए, मैं आपके सामने इस प्रश्न को छोड़ना चाहता हूँ: यदि एक एजेंट महीने में 4,000 पीआर लिख सकता है, लेकिन केवल एक संख्यात्मक महत्वपूर्ण समूह ही प्रमाणीकरण के बिल को सहन कर सकता है, क्या यह सॉफ़्टवेयर का भविष्य है—या केवल शक्ति का प्रदर्शन?

यह कंटेंट केवल सूचनात्मक और शैक्षिक उद्देश्यों के लिए है। इसमें थर्ड-पार्टी की इनसाइट्स, प्रायोजित कंटेंट या प्रचार सामग्री शामिल हो सकती है जिसके लिए निर्माता को मुआवजा प्राप्त हो सकता है। इस फ़ीड में दी गई कोई भी जानकारी निवेश सलाह या प्रतिफल की गारंटी नहीं है। आप अपने निवेश संबंधी निर्णयों के लिए पूरी तरह से स्वयं जिम्मेदार हैं। हमेशा स्वयं शोध करें और ट्रेडिंग से पहले सावधानी बरतें। हम थर्ड-पार्टी की जानकारी की सटीकता की गारंटी नहीं देते हैं और किसी भी प्रकार की हानि के लिए उत्तरदायी नहीं हैं। पिछला प्रदर्शन भविष्य के परिणामों का सूचक नहीं है। विवरण के लिए कृपया हमारे सामुदायिक नियम और शर्तें और जोखिम डिस्कोजर स्टेटमेंट देखें।

avatarअपना रिप्लाई पोस्ट करें

कमेंट करें