سافٹ ویئر انجینئرنگ ہمیشہ غلط پروڈکٹیوٹی میٹرکس (productivity metrics) کے پیچھے بھاگتی رہی ہے۔ مینیجرز کوڈ کی لائنیں گنتے تھے۔ Agile ٹیمیں story points کو ٹریک کرتی تھیں۔ ان میں سے کوئی بھی چیز یہ قابلِ بھروسہ پیمائش نہیں کر سکتی تھی کہ آیا ایک ڈویلپر واضح طور پر سوچ رہا ہے یا محض بہت زیادہ ٹائپنگ کر رہا ہے۔ Nvidia کے CEO Jensen Huang کا خیال ہے کہ ان کے پاس ایک بہتر پیمانہ ہے، اور اس کا کی بورڈز سے کوئی تعلق نہیں ہے۔ GTC 2026 کے بعد All-In پوڈ کاسٹ پر اپنی حالیہ موجودگی کے دوران، Huang نے دلیل دی کہ ایک جدید انجینئر کی قدر کا اصل پیمانہ یہ ہے کہ وہ اپنی تنخواہ کے مقابلے میں کتنے AI tokens استعمال کرتا ہے۔ پیغام بالکل واضح تھا: اگر آپ سالانہ پانچ لاکھ ڈالر کماتے ہیں لیکن اس کا نصف حصہ بھی large language model services پر خرچ نہیں کرتے، تو غالباً آپ ان ٹولز کو استعمال کرنے میں ناکام ہو رہے ہیں جو آپ کی تنخواہ کا جواز ہیں۔
ایک سخت تناسب
Huang نے جس میٹرک کی وضاحت کی ہے وہ حیرت انگیز طور پر سادہ ہے۔ ایک انجینئر کی سالانہ آمدنی لیں۔ اس کا موازنہ LLM API calls، fine-tuning runs، اور agentic inference کے لیے ان کے سالانہ اخراجات سے کریں۔ اگر ایک انتہائی ہنرمند انجینئر جو سالانہ $500,000 کما رہا ہے، AI token کی لاگت کے طور پر $250,000 سے کم خرچ کرتا ہے، تو Huang اس میں ایک مسئلہ دیکھتے ہیں۔ اس سے یہ ظاہر ہوتا ہے کہ ڈویلپر یا تو جدید معاونت سے الگ تھلگ کام کر رہا ہے یا AI کو ایک حقیقی ساتھی کے بجائے محض ایک بہتر سرچ انجن کے طور پر استعمال کر رہا ہے۔
یہ بے احتیاطی سے خرچ کرنے کا لائسنس نہیں ہے۔ یہ ذہنی صلاحیت (load-bearing cognition) کا امتحان ہے۔ Huang کا مفروضہ یہ ہے کہ ایلیٹ انجینئرز کو زیادہ سے زیادہ ذہنی مشقت دستیاب بہترین ماڈلز پر منتقل کر دینی چاہیے۔ ڈیبگنگ (Debugging) کے سیشنز جو کبھی تین دن تک جاری رہتے تھے، وہ چند گھنٹوں میں سمٹ سکتے ہیں جب ایک ماڈل پورے codebase کو context میں رکھتا ہو۔ سسٹم ڈیزائن کی بحثیں جن کے لیے طویل میٹنگز کی ضرورت ہوتی تھی، اب reasoning model کے ساتھ تیز رفتار prototyping کے ذریعے حل ہو سکتی ہیں۔ Huang کے لیے، $250,000 کی حد بجٹ کی حد (ceiling) نہیں بلکہ ایک بنیاد (floor) ہے۔ یہ اس کم از کم ذہانت کی سبسڈی کو ظاہر کرتا ہے جس کی ایک اعلیٰ درجے کے انجینئر کو اپنی پوری صلاحیت کے ساتھ کام کرنے کے لیے ضرورت ہونی چاہیے۔
وہ ڈویلپرز جو اس حد سے نیچے گر جاتے ہیں، وہ بہت زیادہ کام خود کر رہے ہوتے ہیں۔ وہ دستی طور پر بگ ٹریس (trace bugs) کرتے ہیں، ہاتھ سے boilerplate لکھتے ہیں، اور ایسی دستاویزات کو بار بار پڑھتے ہیں جنہیں ایک بہتر طریقے سے prompt کیا گیا ماڈل سیکنڈوں میں خلاصہ کر سکتا ہے۔ ایک ایسے دور میں جہاں inference costs کم ہو رہی ہیں اور context windows پھیل رہی ہیں، tokens کے معاملے میں کفایت شعاری کم استعمال (underutilization) کی علامت ہے، نظم و ضبط کی نہیں۔ ایک انجینئر جو اپنے آؤٹ پٹ کو بڑھانے کے لیے AI کا جارحانہ طور پر استعمال کرنے میں ناکام رہتا ہے، وہ اس منطق کے مطابق کم کارکردگی دکھا رہا ہے۔
لیوریج کے طور پر ٹوکنز
روایتی انجینئرنگ مینجمنٹ ٹھوس آؤٹ پٹ کو پسند کرتی ہے۔ بند کیے گئے Jira tickets۔ پش کیے گئے Commits۔ بھیجے گئے Features۔ یہ نمبر محفوظ محسوس ہوتے ہیں کیونکہ انہیں گنا جا سکتا ہے۔ Huang کا فریم ورک انہیں بڑی حد تک مسترد کر دیتا ہے۔ ان کی منطق کے تحت، ایک سینئر اسٹاف انجینئر ایک مڈ لیول ملازم کے مقابلے میں کم خام (raw) commits پیدا کر سکتا ہے جبکہ کہیں زیادہ ویلیو پیدا کر رہا ہو، کیونکہ ان کی اصل پروڈکٹ فیصلے ہیں۔ Tokens ان فیصلوں کا کھاتہ (ledger) بن جاتے ہیں۔
جب ایک انجینئر LLM inference پر بھاری خرچ کرتا ہے، تو وہ محض ٹیکسٹ جنریشن نہیں خرید رہا ہوتا۔ وہ متوازی سوچ (parallelized thought) خرید رہا ہوتا ہے۔ ایک $500,000 کما والا انجینئر جو refactoring کے مسئلے کے لیے بڑے context windows استعمال کرتا ہے، وہ بنیادی طور پر ایک ساتھ درجن بھر ذہنی دھاگے (cognitive threads) چلا رہا ہوتا ہے، microservices میں edge cases کو چیک کر رہا ہوتا ہے، اور پروڈکشن کوڈ کی ایک بھی لائن لکھے بغیر ہی آرکیٹیکچرل مفروضوں کا تجربہ کر رہا ہوتا ہے۔ Tokens تنخواہ کے گھنٹوں کو مختصر نتائج میں تبدیل کر دیتے ہیں۔ وہ رفتار، آرکیٹیکچرل بصیرت، اور ڈیبگنگ کی صلاحیتیں خریدتے ہیں جو بصورتِ دیگر سینکڑوں گھنٹوں کا دستی کام کھا جائیں گی۔
یہ پرانے ترغیبی ڈھانچے (incentive structure) کو الٹ دیتا ہے۔ انجینئرنگ لیڈرز نے تاریخی طور پر کلاؤڈ کمپیوٹ ڈسکاؤنٹ کے لیے سخت مذاکرات کیے ہیں اور SaaS کی خریداری کو کم سے کم کرنے والے لاگت کے مرکز (cost center) کے طور پر دیکھا ہے۔ Huang کا کہنا ہے کہ AI کے لیے یہ سوچ الٹی ہے۔ ٹوکن بجٹ ٹیلنٹ کے ساتھ بڑھنا چاہیے۔ اگر آپ مہنگے دماغ بھرتی کرتے ہیں اور پھر انہیں مہنگے ترین ماڈلز سے محروم رکھتے ہیں، تو آپ انہیں دستی ورک فلو میں پھنسا دیتے ہیں۔ وہ مہنگے ٹائپسٹ بن کر رہ جاتے ہیں۔ مقصد وہ ہے جسے Huang 'intelligence density' کہتے ہیں: فی انسانی گھنٹہ زیادہ سے زیادہ اطلاقی ادراک (applied cognition)، چاہے کلاؤڈ بل پہلی نظر میں پریشان کن ہی کیوں نہ لگے۔ اگر کوئی انجینئر اپنی زیادہ تنخواہ کا جواز پیش کرنے کے لیے کافی ٹوکنز استعمال نہیں کر رہا، تو وہ غالباً ذہنی بوجھ کو AI پر منتقل کرنے میں ناکام ہو رہا ہے، جس سے تنظیم پر اس کے ممکنہ اثرات محدود ہو جاتے ہیں۔
ٹیم کو برقرار رکھیں، کمپیوٹ کو بڑھائیں
بڑھتی ہوئی آپریشنل لاگتیں عام طور پر ہیڈ کاؤنٹ ریویو کا باعث بنتی ہیں۔ CFOs بڑھتے ہوئے API بل دیکھتے ہیں اور خود بخود پوچھتے ہیں کہ کسے کم کیا جا سکتا ہے۔ Huang اس کے برعکس نسخہ پیش کرتے ہیں۔ بجٹ میں فٹ ہونے کے لیے ٹیم کو چھوٹا کرنے کے بجائے، کمپنیوں کو ٹیم کو بااختیار بنانے کے لیے بجٹ کو بہتر (optimize) بنانا چاہیے۔
یہ بحث متبادل اخراجات اور کوآرڈینیشن کے بوجھ (coordination overhead) پر منحصر ہے۔ ایک پرانی سافٹ ویئر تنظیم ایک مونو لیتھ (monolith) کو برقرار رکھنے، ایک دوسرے کی پل ریکویسٹس (pull requests) کا جائزہ لینے، اور خدمات کو آہستہ آہستہ منتقل کرنے کے لیے تیس انجینئرز تعینات کر سکتی ہے۔ پانچ انتہائی باصلاحیت (augmented) انجینئرز کی ایک چھوٹی ٹیم، جہاں ہر ایک انٹرپرائز گریڈ ٹوکن کوٹہ استعمال کر رہا ہو، اس پیداواری صلاحیت (throughput) کا مقابلہ کر سکتی ہے یا اس سے آگے نکل سکتی ہے۔ بچت صرف API کے اخراجات میں نہیں ملتی۔ یہ مواصلاتی تاخیر (communication latency)، بھرتی کے چکروں، اور بیوروکریٹک رکاوٹوں کے خاتمے سے ظاہر ہوتی ہے۔
یہ حکمت عملی صرف اس صورت میں کام کرتی ہے اگر آپ ایسے انجینئرز کو ملازمت پر رکھیں جو بڑے پیمانے پر ٹوکن کے بہاؤ کو مقصد کے ساتھ निर्देशित کر سکیں۔ اس ڈویلپر کے درمیان ایک واضح فرق ہے جو چیٹ بوٹ میں اسٹیک ٹریس (stack trace) پیسٹ کرتا ہے، اور اس کے درمیان جو ملٹی ایجنٹ پائپ لائنز (multi-agent pipelines) کو منظم کرتا ہے، بھرپور سیاق و سباق کی لائبریریاں (context libraries) برقرار رکھتا ہے، اور غلط یا فرضی نتائج (hallucinated outputs) کی سختی سے تصدیق کرتا ہے۔ دوسرا پروفائل تلاش کرنا زیادہ مشکل ہے۔ یہی وجہ ہے کہ ہوانگ (Huang) اس پیمانے کو تنخواہ سے جوڑتے ہیں۔ زیادہ معاوضہ، اعلیٰ آرکیسٹریشن مہارت (orchestration skill) کے ساتھ منسلک ہونا چاہیے۔ آپ کسی کو ہفتے میں ایک بار ماڈل کو پرامپٹ (prompt) دینے کے لیے پانچ لاکھ ڈالر نہیں دیتے، بلکہ آپ انہیں خودکار استدلال (automated reasoning) کے ایک ایسے نظام کو سنبھالنے کے لیے ادائیگی کرتے ہیں جو بے مثال رفتار سے پیچیدہ نظام بناتا ہے۔
عملی طور پر اس کا کیا مطلب ہے
انجینئرنگ تنظیموں کے لیے، ٹوکن سے تنخواہ کا تناسب (token-to-salary ratio) محض ایک سخت اکاؤنٹنگ اصول نہیں بلکہ ایک ثقافتی چیک پوائنٹ ہے۔ لیڈروں کو یہ پوچھنا چاہیے کہ آیا ان کے سب سے زیادہ تنخواہ لینے والے ڈویلپرز کے پاس AI کا بھرپور استعمال کرنے کے لیے رسائی، تربیت اور اختیار موجود ہے۔ کیا وہ پرانے کوڈ پر لانگ کانٹیکسٹ اینالیسس (long-context analysis) کر رہے ہیں، یا وہ اب بھی لائن بہ لائن لاگز (logs) تلاش کر رہے ہیں؟ کیا وہ انٹیگریشن ٹیسٹنگ کے لیے ایجنٹک کوڈنگ ٹولز (agentic coding tools) استعمال کر رہے ہیں، یا وہ خود سے مکس (mocks) لکھ رہے ہیں؟ کیا ان کے منصوبے انسانی توجہ کی کمی کی وجہ سے رک رہے ہیں یا API کی حد (rate limits) کی وجہ سے؟
اگر جواب انسانی رکاوٹوں کی طرف اشارہ کرتا ہے، تو اس کا حل زیادہ کام کے اوقات کا مطالبہ کرنا نہیں ہے۔ اس کا حل عام طور پر ٹوکن کی حد (token ceiling) کو بڑھانا ہے۔ انجینئر کو مزید ایجنٹس چلانے دیں۔ انہیں پورے سروس میش (service mesh) کے لیے ایک مستقل کانٹیکسٹ ونڈو (context window) کھلی رکھنے دیں۔ انہیں ہفتے میں دو بار کے بجائے ایک دوپہر میں آرکیٹیکچر پر پچاس بار کام کرنے دیں۔ جب ٹوکن کے استعمال کو غیر ضروری اخراجات کے بجائے ہائی لیوریج انجینئرنگ (high-leverage engineering) کی علامت کے طور پر دیکھا جاتا ہے، تو کمپنیوں کے اندر اجازت دینے کے ڈھانچے بدل جاتے ہیں۔
یقیناً، صرف خرچ کرنا کسی چیز کی ضمانت نہیں دیتا۔ معمولی سوالات یا ناقص پرامپٹس پر ضائع کیے گئے ٹوکن محض فضول خرچی ہیں۔ اصل مہارت بھاری کمپیوٹنگ کو اعلیٰ قدر والے مسائل پر مرکوز کرنے میں ہے: کراس سروس ڈیزائن، سیکیورٹی آڈٹ، پرانے نظاموں کی منتقلی کے لیے بیہیویئر کلوننگ (behavior-cloning)، اور مصنوعی تربیتی ڈیٹا (synthetic training data) تیار کرنا۔ جو انجینئرز اس مہارت میں مہارت حاصل کر لیتے ہیں وہ 'ملٹی پلائرز' (multipliers) بن جاتے ہیں۔ جو ایسا نہیں کر پاتے، ان کا معاوضہ چاہے کتنا ہی زیادہ کیوں نہ ہو، وہ بالکل غلط طریقے سے مہنگے نظر آتے ہیں۔
اصل نتیجہ
ہوانگ کا نظریہ دراصل AI کے اخراجات کو نئے انداز میں دیکھنے کے بارے میں ہے۔ LLM ٹوکنز کو آپریشنل ٹیکس (operational tax) سمجھنا بند کریں۔ انہیں خام مال (raw material) کے طور پر سمجھیں جو انجینئرنگ کی رفتار (engineering velocity) میں تبدیل ہو جاتا ہے۔ اس تناظر میں، وہ انجینئر جو