सॉफ्टवेअर इंजिनीअरिंगने नेहमीच चुकीच्या उत्पादकता मेट्रिक्सचा (productivity metrics) पाठलाग केला आहे. मॅनेजर्स कोडच्या ओळी मोजत असत. अजाईल (Agile) टीम्स स्टोरी पॉइंट्सचा मागोवा घेत असत. यापैकी कशातूनही डेव्हलपर स्पष्टपणे विचार करत आहे की फक्त खूप टाइप करत आहे, याचे विश्वसनीय मोजमाप होत नव्हते. Nvidia चे CEO जेन्सन हुआंग यांच्या मते त्यांच्याकडे एक उत्तम मापदंड आहे आणि त्याचा कीबोर्डशी काहीही संबंध नाही. GTC 2026 नंतर All-In पॉडकास्टवर उपस्थित असताना, हुआंग यांनी असा युक्तिवाद केला की आधुनिक इंजिनीअरच्या मूल्याचे खरे मोजमाप म्हणजे त्यांच्या पगाराच्या तुलनेत ते किती AI tokens वापरतात. संदेश थेट होता: जर तुम्ही वर्षाला पाच लाख डॉलर्स कमावत असाल पण त्यातील अर्ध्यापेक्षा कमी रक्कम Large Language Model (LLM) सेवांवर खर्च करत असाल, तर तुम्ही कदाचित तुमच्या पगाराला न्याय देणारी साधने वापरण्यात अपयशी ठरत आहात.
एक कठीण गुणोत्तर
हुआंग यांनी वर्णन केलेले मेट्रिक आश्चर्यकारकपणे सोपे आहे. इंजिनीअरचे वार्षिक उत्पन्न घ्या. त्याची तुलना त्यांच्या वार्षिक LLM API कॉल्स, fine-tuning runs आणि agentic inference च्या खर्चाशी करा. जर वर्षाला $500,000 कमावणारा उच्च कुशल इंजिनीअर AI token खर्चात $250,000 पेक्षा कमी खर्च करत असेल, तर हुआंग यांना त्यात समस्या वाटते. यावरून असे सूचित होते की डेव्हलपर एकतर आधुनिक मदतीपासून दूर काम करत आहे किंवा AI कडे खऱ्या सहकाऱ्याऐवजी केवळ एक प्रगत सर्च इंजिन म्हणून पाहत आहे.
हे बेजबाबदार खर्च करण्याचे परवाने नाहीत. हा 'load-bearing cognition' (भार सहन करण्याची संज्ञानात्मक क्षमता) चाtest आहे. हुआंग यांचा असा तर्क आहे की उच्च श्रेणीतील इंजिनीअर्सनी शक्य तितका मानसिक कंटाळवाणा भाग (mental drudgery) उपलब्ध असलेल्या सर्वात सक्षम मॉडेल्सकडे सोपवला पाहिजे. ज्या डीबगिंग (debugging) सत्रांना पूर्वी तीन दिवस लागायचे, ती आता काही तासांत पूर्ण होऊ शकतात जेव्हा एखादे मॉडेल संपूर्ण कोडबेस संदर्भासह (context) लक्षात ठेवते. सिस्टिम डिझाइनच्या ज्या चर्चांसाठी पूर्वी लांब मीटिंग्स घ्याव्या लागायच्या, त्या आता रिझनिंग मॉडेलच्या (reasoning model) मदतीने जलद प्रोटोटाइपिंगद्वारे सोडवता येऊ शकतात. हुआंग यांच्यासाठी, $250,000 ची मर्यादा ही बजेटची कमाल मर्यादा नसून ती एक किमान मर्यादा (floor) आहे. हे एका उच्च दर्जाच्या इंजिनीअरला पूर्ण क्षमतेने काम करण्यासाठी आवश्यक असलेल्या किमान 'intelligence subsidy'चे प्रतिनिधित्व करते.
जे डेव्हलपर्स या मर्यादेच्या खाली राहतात, ते स्वतः खूप जास्त काम करत आहेत. ते मॅन्युअली बग्स शोधतात, हाताने boilerplate कोड लिहितात आणि असे डॉक्युमेंटेशन पुन्हा पुन्हा वाचतात जे एखादे चांगले प्रॉम्प्ट दिलेले मॉडेल काही सेकंदात सारांशित करू शकते. ज्या युगात inference खर्च कमी होत आहेत आणि context windows विस्तारत आहेत, तिथे टोकन्सचा कंजूस वापर हा शिस्त नसून साधनांचा अपूर्ण वापर दर्शवतो. जो इंजिनीअर आपले आउटपुट वाढवण्यासाठी AI चा आक्रमकपणे वापर करण्यात अपयशी ठरतो, तो या तर्कानुसार कमी कामगिरी (underperforming) करत आहे.
लिव्हरेजसाठी प्रॉक्सी म्हणून टोकन्स
पारंपारिक इंजिनीअरिंग मॅनेजमेंटला मूर्त आउटपुट आवडते. क्लोज केलेले Jira tickets. पुश केलेले Commits. शिप केलेले Features. हे आकडे सुरक्षित वाटतात कारण ते मोजता येतात. हुआंग यांचा फ्रेमवर्क या गोष्टी मोठ्या प्रमाणावर नाकारतो. त्यांच्या तर्कानुसार, एक सिनियर स्टाफ इंजिनीअर मिडल-लेव्हल भरती केलेल्या व्यक्तीपेक्षा कमी raw commits तयार करू शकतो, परंतु तरीही अधिक मूल्य निर्माण करू शकतो, कारण त्यांचे खरे उत्पादन म्हणजे 'निर्णय' (decisions) असतात. टोकन्स हे त्या निर्णयांचे खाते (ledger) बनतात.
जेव्हा एखादा इंजिनीअर LLM inference वर मोठ्या प्रमाणात खर्च करतो, तेव्हा ते केवळ मजकूर निर्मिती (text generation) विकत घेत नसतात. ते 'parallelized thought' (समांतर विचार प्रक्रिया) विकत घेत असतात. $500,000 कमावणारा इंजिनीअर जेव्हा refactoring समस्येसाठी मोठ्या context windows वापरतो, तेव्हा तो प्रत्यक्षात एकाच वेळी डझनभर संज्ञानात्मक धागे (cognitive threads) चालवत असतो, microservices मधील edge cases तपासत असतो आणि उत्पादन कोडची एकही ओळ न लिहिता architectural गृहितकांची चाचणी घेत असतो. टोकन्स पगाराच्या तासांचे संक्षिप्त परिणामांमध्ये रूपांतर करतात. ते वेग, architectural foresight आणि debugging क्षमता खरेदी करतात, ज्यासाठी अन्यथा शेकडो मॅन्युअल तास खर्च झाले असते.
हे जुन्या प्रोत्साहन रचनेला (incentive structure) उलट करते. इंजिनीअरिंग लीडर्सनी ऐतिहासिकदृष्ट्या cloud compute डिस्काउंटसाठी कडक वाटाघाटी केल्या आहेत आणि SaaS खरेदीला कमी करण्यासाठी एक 'cost center' मानले आहे. हुआंग सुचवतात की AI साठी ही मानसिकता चुकीची आहे. टोकन बजेट हे टॅलेंटनुसार वाढले पाहिजे. जर तुम्ही महागडे मेंदू (talents) कामावर घेतले आणि नंतर त्यांना सर्वात महागड्या मॉडेल्सपासून वंचित ठेवले, तर तुम्ही त्यांना मॅन्युअल वर्कफ्लोमध्ये अडकवता. ते महागडे 'typists' बनतात. हुआंग ज्याला 'intelligence density' म्हणतात, तेच ध्येय आहे: प्रति मानवी तास जास्तीत जास्त लागू केलेली संज्ञानात्मक क्षमता (applied cognition), जरी क्लाउड बिल पहिल्या नजरेत धक्कादायक वाटले तरीही. जर एखादा इंजिनीअर त्याच्या उच्च पगाराला न्याय देण्यासाठी पुरेसे टोकन्स वापरत नसेल, तर तो बहुधा संज्ञानात्मक कष्टाचे काम AI कडे सोपवण्यात अपयशी ठरत आहे, ज्यामुळे संस्थेवरील त्याचा संभाव्य प्रभाव मर्यादित होत आहे.
टीम ठेवा, कॉम्प्युट वाढवा
वाढत्या ऑपरेशनल खर्चामुळे सहसा कर्मचारी संख्येचा (headcount) आढावा घेतला जातो. CFOs वाढलेले API बिल पाहतात आणि आपोआप विचारतात की कोणाला कमी करता येईल. हुआंग याच्या अगदी उलट उपाय सुचवतात. बजेटमध्ये बसण्यासाठी टीम कमी करण्याऐवजी, कंपन्यांनी टीमला सक्षम करण्यासाठी बजेट ऑप्टिमाइझ केले पाहिजे.
हा युक्तिवाद बदली खर्च (replacement costs) आणि समन्वयाचा अतिरिक्त भार (coordination overhead) यावर अवलंबून आहे. एखादी जुनी (legacy) सॉफ्टवेअर संस्था एका मोनोलिथची (monolith) देखभाल करण्यासाठी, एकमेकांच्या पुल रिक्वेस्ट्स (pull requests) तपासण्यासाठी आणि सेवा हळूहळू स्थलांतरित (migrate) करण्यासाठी तीस अभियंत्यांची नियुक्ती करू शकते. पाच अत्यंत प्रगत (deeply augmented) अभियंत्यांची एक लहान टीम, ज्यातील प्रत्येक अभियंता एंटरप्राइझ-ग्रेड टोकन कोटा वापरत आहे, ती टीम त्या थ्रूपुटशी (throughput) बरोबरी करू शकते किंवा त्यापेक्षा जास्त कामगिरी करू शकते. बचत केवळ API च्या खर्चात नसते. ती संवादातील विलंब (communication latency), भरती प्रक्रिया (hiring cycles) आणि नोकरशाहीचा अडथळा (bureaucratic drag) कमी झाल्यामुळे दिसून येते.
ही रणनीती तेव्हाच यशस्वी होते जेव्हा तुम्ही असे अभियंते नियुक्त करता जे मोठ्या प्रमाणात टोकन प्रवाह (token flows) हेतूने नियंत्रित करू शकतात. जो डेव्हलपर चॅटबॉटमध्ये स्टॅक ट्रेस (stack trace) पेस्ट करतो आणि जो मल्टी-एजंट पाइपलाइन्स (multi-agent pipelines) आयोजित करतो, समृद्ध कॉन्टेक्स्ट लायब्ररी (context libraries) राखतो आणि चुकीच्या (hallucinated) आउटपुट्सची काटेकोरपणे पडताळणी करतो, या दोघांमध्ये मोठा फरक आहे. दुसरा प्रकार शोधणे कठीण आहे. म्हणूनच हुआंग (Huang) हे मोजमाप पगाराशी जोडतो. उच्च मोबदला हा उच्च ऑर्केस्ट्रेशन कौशल्याशी (orchestration skill) संबंधित असावा. तुम्ही एखाद्याला आठवड्यातून एकदा मॉडेलला प्रॉम्प्ट (prompt) देण्यासाठी पाच लाख डॉलर्स देत नाही. तुम्ही त्यांना स्वयंचलित तर्काचे (automated reasoning) असे एक इकोसिस्टम व्यवस्थापित करण्यासाठी पैसे देता जे अभूतपूर्व वेगाने जटिल प्रणाली तयार करते.
याचा प्रत्यक्ष अर्थ काय?
इंजिनिअरिंग संस्थांसाठी, टोकन-टू-सॅलरी रेशो (token-to-salary ratio) हा केवळ एक कडक लेखा नियम नसून तो एक सांस्कृतिक चेकपॉइंट (cultural checkpoint) आहे. नेत्यांनी विचारले पाहिजे की त्यांच्या सर्वाधिक पगार असलेल्या डेव्हलपर्सना AI चा आक्रमकपणे वापर करण्यासाठी आवश्यक प्रवेश (access), प्रशिक्षण आणि अधिकार आहेत का. ते जुन्या (legacy) कोडवर लाँग-कॉन्टेक्स्ट विश्लेषण (long-context analysis) करत आहेत की अजूनही लॉग्स (logs) ओळीने ओळ तपासत आहेत? ते इंटिग्रेशन टेस्टिंगसाठी (integration testing) एजेंटिक कोडिंग टूल्स (agentic coding tools) वापरत आहेत की मक्स (mocks) हाताने लिहित आहेत? त्यांच्या प्रकल्पांमध्ये मानवी लक्षामुळे अडथळे येत आहेत की API रेट लिमिट्समुळे (rate limits)?
जर उत्तर मानवी अडथळ्यांकडे (human bottlenecks) निर्देश करत असेल, तर उपाय म्हणून जास्त तास काम मागणे हा पर्याय क्वचितच असतो. त्याऐवजी टोकनची मर्यादा (token ceiling) वाढवणे हा सहसा योग्य उपाय असतो. अभियंत्यांना अधिक एजंट्स (agents) सुरू करू द्या. त्यांना संपूर्ण सर्व्हिस मेशसाठी (service mesh) एक पर्सिस्टंट कॉन्टेक्स्ट विंडो (persistent context window) उघडी ठेवू द्या. त्यांना आठवड्यातून दोनदा करण्याऐवजी एका दुपारी आर्किटेक्चरवर पन्नास वेळा काम (iterate) करू द्या. जेव्हा टोकनचा वापर अनावश्यक खर्च न मानता उच्च-लेव्हरेज इंजिनिअरिंगचे (high-leverage engineering) लक्षण म्हणून पाहिला जातो, तेव्हा कंपन्यांमधील परवानगीची रचना बदलते.
अर्थात, केवळ खर्च करणे काहीही सुनिश्चित करत नाही. क्षुल्लक प्रश्न किंवा चुकीच्या व्याप्तीचे प्रॉम्प्ट्स (prompts) मध्ये वापरलेले टोकन्स म्हणजे केवळ वाया जाणारा पैसा आहे. शिस्त ही मोठ्या प्रमाणात संगणकीय शक्ती (heavy compute) उच्च-मूल्य असलेल्या समस्यांवर केंद्रित करण्यात आहे: क्रॉस-सर्व्हिस डिझाइन (cross-service design), सुरक्षा ऑडिटिंग (security auditing), लेगसी मायग्रेशनसाठी बिहेवियर-क्लोनिंग (behavior-cloning) आणि सिंथेटिक ट्रेनिंग डेटा (synthetic training data) तयार करणे. जे अभियंते यावर प्रभुत्व मिळवतात ते 'मल्टिप्लायर्स' (multipliers) बनतात. जे तसे करू शकत नाहीत, त्यांच्या पगाराचा विचार केला तरी, ते चुकीच्या अर्थाने महाग वाटतात.
मुख्य निष्कर्ष
हुआंगचा सिद्धांत शेवटी AI खर्चाला नवीन दृष्टिकोन देण्याबद्दल आहे. LLM टोकन्सकडे ऑपरेशनल टॅक्स (operational tax) म्हणून पाहणे थांबवा. त्यांना कच्चा माल (raw material) समजा ज्याचे रूपांतर इंजिनिअरिंग वेगामध्ये (engineering velocity) होते. या दृष्टिकोनातून, तो अभियंता जो