काही कंपन्यांमध्ये AI टोकन्सचे वार्षिक बिल आता इंजिनीअरिंग पेरोलला टक्कर देऊ लागले आहे, आणि नेतृत्व साजरे करावे की घाबरून जावे, हे समजत नाहीये. मोठ्या भाषा मॉडेल्समध्ये (large language models) भांडवल गुंतवून कंपन्यांनी गेल्या काही वर्षांत अशी अपेक्षा केली होती की, स्वस्त इन्फरन्समुळे (inference) आपोआप कर्मचाऱ्यांची संख्या कमी होईल आणि कामाचे सायकल (shipping cycles) वेगवान होतील. त्याऐवजी, अनेक इंजिनीअरिंग संस्थांना आता दुहेरी खर्च करावा लागत आहे: एकदा त्या टॅलेंटसाठी ज्यांच्या कार्यक्षमतेत वाढ होईल अशी त्यांना आशा होती, आणि पुन्हा त्या कम्प्युटसाठी (compute) ज्याने त्यांना पर्याय म्हणून आणले होते. प्रश्न आता असा उरलेला नाही की AI कोड लिहू शकते की नाही. प्रश्न असा आहे की, तो लिहिण्यासाठी खर्च केला जाणारा प्रचंड पैसा त्या कोडच्या उपयुक्ततेतून वसूल होतो का?

अर्ध्या पगाराचा बेंचमार्क

Jensen Huang ने GTC 2026 च्या शेवटी, All-In Podcast वर बोलताना हे गणित स्पष्टपणे मांडले. Nvidia च्या CEO ने इंजिनीअरची कार्यक्षमता मोजण्यासाठी त्यांच्या पगाराची थेट तुलना त्यांच्या AI टोकन वापराशी (consumption) करण्याची सूचना केली. त्यांची मर्यादा अत्यंत स्पष्ट होती. समजा, एखादा सॉफ्टवेअर इंजिनीअर वर्षाला $500,000 कमावतो. जर तो इंजिनीअर वर्षाला $250,000 पेक्षा कमी किमतीचे टोकन्स वापरत असेल, जे त्यांच्या पगाराच्या साधारण अर्ध्या आहेत, तर Huang याला धोक्याची घंटा मानतात. त्यांच्या मते, नेतृत्वाने "गंभीरपणे सावध" झाले पाहिजे, कारण कंपनी लोकांवर जास्त खर्च करत आहे म्हणून नाही, तर ते लोकांचा पुरेसा वापर करत नाहीये म्हणून.

हे तर्क पारंपारिक खर्च-नियंत्रण (cost-control) मानसिकतेला उलट करते. अनेक वर्षांपासून, फायनान्स टीम्स कम्प्युटला कमी करण्यायोग्य एक 'व्हेरिएबल खर्च' (variable expense) मानत आल्या आहेत. Huang याच्या अगदी उलट तर्क मांडतात. असा महागडा इंजिनीअर जो मॉडेलचा फारसा वापर करत नाही, तो प्रत्यक्षात 'फोर्स मल्टिप्लायर' (force multiplier) शिवाय काम करणारा महागडा इंजिनीअर आहे. अशी अपेक्षा आहे की, उच्च-खर्च असलेल्या टॅलेंटने एका फनेलप्रमाणे (funnel) काम करावे, जे AI सिस्टम्सद्वारे कामाचा प्रचंड ओघ पुढे ढकलतील, आउटपुटची पडताळणी करतील आणि निकालांचे नियोजन (orchestrating) करतील. कमी टोकन खर्च करणे म्हणजे बचत नाही. तर याचा अर्थ असा आहे की, माणूस अजूनही तेच यांत्रिक काम करत आहे जे एखादे मॉडेल सहज करू शकले असते.

प्रत्यक्ष व्यवहारात तो खर्च कसा दिसतो

हा बेंचमार्क का महत्त्वाचा आहे हे समजून घेण्यासाठी, $250,000 च्या टोकन्सचा नेमका अर्थ काय आहे याचा विचार करा. सध्याच्या प्रगत मॉडेल्सच्या (frontier models) दरांचा विचार करता, हे केवळ काही 'ऑटो-कम्प्लीट' सूचना नसून, विविध कामांसाठी दररोज लाखो टोकन्सवर प्रक्रिया करणे आहे. याचा अर्थ असा इंजिनीअर आहे जो केवळ एडिटरच्या सूचना स्वीकारत नाही, तर व्यापक आर्किटेक्चरल रिझनिंग (architectural reasoning), इंटेलिजेंट एजंट्सद्वारे मोठ्या प्रमाणावर रिफॅक्टरिंग (bulk refactoring), ऑटोमेटेड टेस्टिंग पाइपलाइन्स, सिंथेटिक डेटा जनरेशन आणि इटरेटिव्ह डिझाइन एक्सप्लोरेशन यांसारखी कामे करत आहे.

अशा प्रकारे काम करणारा एक वरिष्ठ इंजिनीअर एकाच फीचरसाठी अनेक मॉडेल कॉल्स एकत्र जोडू शकतो: स्कॅफोल्डिंग (scaffolding) तयार करणे, ब्रेकिंग चेंजेससाठी डिपेंडन्सीजचे विश्लेषण करणे, एज-केस बिहेविअर सिम्युलेट करणे आणि समांतरपणे डॉक्युमेंटेशन तयार करणे. कामाचा वेग (throughput) प्रचंड असतो कारण माणूस आता प्रत्येक ओळ टाईप करत नाहीये. ते फक्त दिशा दाखवत आहेत (steering). Huang यांच्या मते, जेव्हा माणूस अशा मोठ्या प्रमाणावर काम करतो आणि मॉडेलसोबत सतत संवाद साधून आपले आउटपुट अनेक पटींनी वाढवतो, तेव्हाच तो पगार सार्थ ठरतो.

परतावा (Returns) कुठे हरवत आहे

या दृष्टीकोन असूनही, उद्योग क्षेत्र इन्फ्रास्ट्रक्चरवरील खर्च आणि मिळणारे निकाल यांच्यातील वाढती दरी पाहत आहे. कंपन्यांनी टोकन-केंद्रित धोरणांचा अवलंब केला आहे, AI विक्रेत्यांशी एंटरप्राइझ करार केले आहेत आणि त्यांच्या डेव्हलपमेंट पाइपलाइन्सना जनरेटिव्ह टूल्सनुसार बदलले आहे. भांडवली खर्च (capital expenditure) अवाढव्य राहिला आहे. मात्र, अनेकांसाठी उत्पादकता (productivity) वाढीचा परतावा अपेक्षेपेक्षा कमी राहिला आहे.

डेव्हलपर्स खरोखरच कंटाळवाण्या कामात वेगवान झाले आहेत. जेव्हा एखादे मॉडेल पहिला मसुदा (draft) तयार करते, तेव्हा बॉयलरप्लेट कोड (boilerplate code), युनिट टेस्ट स्केलेटन्स (unit test skeletons) आणि पुनरावृत्ती होणाऱ्या CRUD ऑपरेशन्स वेगाने पूर्ण होतात. पण सॉफ्टवेअर इंजिनीअरिंग हे कधीही केवळ टाईपिंगच्या वेगाबद्दल नव्हते. खरे कठीण आणि महागडे काम म्हणजे विस्तारलेल्या सिस्टम्सची देखभाल करणे, डिस्ट्रिब्युटेड फेल्युअर मोड्सचे (distributed failure modes) विश्लेषण करणे, लेअर्ड डिपेंडन्सीजमध्ये सुरक्षा सुनिश्चित करणे आणि प्रत्येक शॉर्टकटमुळे निर्माण होणारे तांत्रिक कर्ज (technical debt) व्यवस्थापित करणे हे आहे. हे