Software engineering has always chased the wrong productivity metrics. Managers counted lines of code. Agile teams tracked story points. None of it reliably measured whether a developer was thinking clearly or simply typing a lot. Nvidia CEO Jensen Huang thinks he has a better gauge, and it has nothing to do with keyboards. During a recent appearance on the All-In Podcast following GTC 2026, Huang argued that the real measure of a modern engineer’s value is how many AI tokens they consume relative to their salary. The message was direct: if you earn half a million dollars a year but spend less than half that on large language model services, you are probably failing to use the tools that justify your paycheck.
A Hard Ratio
The metric Huang described is jarringly simple. Take an engineer’s annual compensation. Compare it to their yearly tab for LLM API calls, fine-tuning runs, and agentic inference. If a highly skilled engineer earning $500,000 per year racks up less than $250,000 in AI token costs, Huang sees a problem. It suggests the developer is either working in isolation from modern assistance or treating AI like a glorified search engine rather than a genuine collaborator.
This is not a license for reckless spending. It is a test of load-bearing cognition. Huang’s premise is that elite engineers should offload as much mental drudgery as possible to the most capable models available. Debugging sessions that once sprawled across three days can compress into hours when a model holds the entire codebase in context. System design debates that used to require lengthy meetings can resolve through rapid prototyping with a reasoning model. For Huang, the $250,000 threshold is less a budget ceiling and more a floor. It represents the minimum intelligence subsidy a top-tier engineer should need to operate at full capacity.
Developers who fall below that line are doing too much of the work themselves. They trace bugs manually, write boilerplate by hand, and reread documentation that a well-prompted model could synthesize in seconds. In an era where inference costs are falling and context windows are expanding, frugality with tokens signals underutilization, not discipline. An engineer who fails to aggressively utilize AI to augment their output is, by this logic, underperforming.
Tokens as a Proxy for Leverage
Traditional engineering management loves tangible output. Jira tickets closed. Commits pushed. Features shipped. These numbers feel safe because they are countable. Huang’s framework largely discards them. Under his logic, a senior staff engineer might produce fewer raw commits than a mid-level hire while generating far more value, because their real product is decisions. Tokens become the ledger for those decisions.
When an engineer spends heavily on LLM inference, they are not merely buying text generation. They are buying parallelized thought. A $500,000 engineer throwing massive context windows at a refactoring problem is essentially running a dozen simultaneous cognitive threads, checking edge cases across microservices, and stress-testing architectural assumptions without yet writing a single line of production code. The tokens convert salary hours into compressed outcomes. They purchase speed, architectural foresight, and debugging capabilities that would otherwise eat hundreds of manual hours.
This flips the old incentive structure. Engineering leaders have historically negotiated hard for cloud compute discounts and treated SaaS procurement as a cost center to minimize. Huang suggests that mindset is backwards for AI. The token budget should scale with talent. If you hire expensive brains and then starve them of the most expensive models, you trap them in manual workflows. They become high-priced typists. The goal is what Huang implies is intelligence density: maximum applied cognition per human hour, even if the cloud bill looks alarming at first glance. If an engineer is not consuming enough tokens to justify their high compensation, they are likely failing to offload the cognitive heavy lifting to AI, thereby limiting their potential impact on the organization.
Keep the Team, Expand the Compute
Rising operational costs usually trigger headcount reviews. CFOs see ballooning API bills and reflexively ask who can be cut. Huang offers the opposite prescription. Instead of shrinking the team to fit a budget, companies should optimize the budget to empower the team.
যুক্তিটি মূলত প্রতিস্থাপন খরচ এবং সমন্বয় সংক্রান্ত অতিরিক্ত ব্যয়ের (coordination overhead) ওপর নির্ভর করে। একটি লেগাসি সফটওয়্যার সংস্থা একটি মনোলিথ (monolith) রক্ষণাবেক্ষণ করতে, একে অপরের পুল রিকোয়েস্ট (pull requests) পর্যালোচনা করতে এবং ধীরে ধীরে সার্ভিসগুলো মাইগ্রেট করতে ত্রিশজন ইঞ্জিনিয়ার নিয়োগ করতে পারে। অন্যদিকে, মাত্র পাঁচজন অত্যন্ত দক্ষ (deeply augmented) ইঞ্জিনিয়ারের একটি ছোট দল, যারা প্রত্যেকে এন্টারপ্রাইজ-গ্রেড টোকেন কোটা ব্যবহার করছেন, তারা সেই কাজের গতি বা থ্রুপুট (throughput) সমান বা এমনকি ছাড়িয়ে যেতে পারেন। সাশ্রয়টি কেবল API খরচের খাতায় পাওয়া যায় না। এটি মূলত যোগাযোগের বিলম্ব (communication latency), নিয়োগ প্রক্রিয়া (hiring cycles) এবং আমলাতান্ত্রিক জটিলতা (bureaucratic drag) না থাকার মাধ্যমে প্রকাশ পায়।
এই কৌশলটি তখনই কাজ করবে যদি আপনি এমন ইঞ্জিনিয়ার নিয়োগ করেন যারা উদ্দেশ্যপ্রণোদিতভাবে বিশাল টোকেন প্রবাহ পরিচালনা করতে পারেন। একজন ডেভেলপার যিনি চ্যাটবটে কেবল একটি স্ট্যাক ট্রেস (stack trace) পেস্ট করেন এবং একজন যিনি মাল্টি-এজেন্ট পাইপলাইন (multi-agent pipelines) পরিচালনা করেন, সমৃদ্ধ কনটেক্সট লাইব্রেরি (context libraries) রক্ষণাবেক্ষণ করেন এবং ভুল বা হ্যালুসিনেশনযুক্ত আউটপুটগুলো কঠোরভাবে যাচাই করেন—তাদের মধ্যে একটি মৌলিক পার্থক্য রয়েছে। দ্বিতীয় ধরনের প্রোফাইল খুঁজে পাওয়া অনেক বেশি কঠিন। আর ঠিক এই কারণেই হুয়াং (Huang) এই মেট্রিকটিকে বেতনের সাথে যুক্ত করেছেন। উচ্চ বেতন উচ্চতর অর্কেস্ট্রেশন দক্ষতার (orchestration skill) সাথে সম্পর্কিত হওয়া উচিত। আপনি কাউকে সপ্তাহে মাত্র একবার একটি মডেল প্রম্পট করার জন্য পাঁচ লক্ষ ডলার দেবেন না। আপনি তাদের বেতন দেন স্বয়ংক্রিয় যুক্তিনির্ভর (automated reasoning) একটি ইকোসিস্টেম পরিচালনা করার জন্য, যা অভূতপূর্ব গতিতে জটিল সিস্টেম তৈরি করতে পারে।
বাস্তবে এর অর্থ কী
ইঞ্জিনিয়ারিং সংস্থাগুলোর জন্য, টোকেন-টু-স্যালারি রেশিও (token-to-salary ratio) কোনো কঠোর অ্যাকাউন্টিং নিয়ম নয়, বরং এটি একটি সাংস্কৃতিক মাপকাঠি (cultural checkpoint)। নেতাদের নিজেদের প্রশ্ন করা উচিত যে, তাদের সর্বোচ্চ বেতনভুক্ত ডেভেলপারদের কি এআই (AI) ব্যাপকভাবে ব্যবহারের জন্য প্রয়োজনীয় অ্যাক্সেস, প্রশিক্ষণ এবং অনুমতি রয়েছে কি না। তারা কি লেগাসি কোডের ওপর লং-কনটেক্সট অ্যানালাইসিস (long-context analysis) চালাচ্ছেন, নাকি এখনও লাইন বাই লাইন লগ (logs) খুঁজছেন? তারা কি ইন্টিগ্রেশন টেস্টিংয়ের জন্য এজেন্টিক কোডিং টুল (agentic coding tools) ব্যবহার করছেন, নাকি হাতে লিখে মক (mocks) তৈরি করছেন? তাদের প্রজেক্টগুলো কি মানুষের মনোযোগের অভাবে আটকে যাচ্ছে, নাকি API রেট লিমিটের কারণে?
যদি উত্তরটি মানুষের সীমাবদ্ধতার দিকে নির্দেশ করে, তবে এর সমাধান সাধারণত কাজের সময় বাড়ানো নয়। বরং টোকেনের সীমা (token ceiling) বাড়ানো। ইঞ্জিনিয়ারকে আরও বেশি এজেন্ট চালানোর সুযোগ দিন। তাদের পুরো সার্ভিস মেশের (service mesh) জন্য একটি পারসিস্টেন্ট কনটেক্সট উইন্ডো (persistent context window) খোলা রাখার সুযোগ দিন। তাদের সপ্তাহে দুবার নয়, বরং এক বিকেলে পঞ্চাশবার আর্কিটেকচার নিয়ে কাজ করার সুযোগ দিন। যখন টোকেন ব্যবহারকে অপ্রয়োজনীয় খরচ হিসেবে না দেখে উচ্চ-লেভারেজ ইঞ্জিনিয়ারিংয়ের (high-leverage engineering) লক্ষণ হিসেবে দেখা হয়, তখন কোম্পানির অভ্যন্তরীণ অনুমতি কাঠামো বা পারমিশন স্ট্রাকচার বদলে যায়।
অবশ্যই, শুধু খরচ করলেই কোনো নিশ্চয়তা পাওয়া যায় না। তুচ্ছ প্রশ্ন বা অস্পষ্ট প্রম্পটে টোকেন খরচ করা মানেই হলো অপচয়। আসল শৃঙ্খলা হলো উচ্চ-মূল্যের সমস্যাগুলোতে ভারী কম্পিউটেশন (heavy compute) ব্যবহার করা: যেমন ক্রস-সার্ভিস ডিজাইন, সিকিউরিটি অডিটিং, লেগাসি মাইগ্রেশনের জন্য বিহেভিয়ার-ক্লোনিং (behavior-cloning) এবং সিন্থেটিক ট্রেনিং ডেটা তৈরি করা। যারা এই লক্ষ্য অর্জনে দক্ষ হন, তারা হয়ে ওঠেন মাল্টিপ্লায়ার (multipliers)। আর যারা তা পারেন না, তাদের বেতন যাই হোক না কেন, তারা ভুলভাবে ব্যয়বহুল বলে বিবেচিত হন।
আসল শিক্ষা
হুয়াং-এর থিসিসটি মূলত এআই (AI) খরচের ধারণাটিকে নতুনভাবে সাজানোর বিষয়ে। LLM টোকেনকে কোনো অপারেশনাল ট্যাক্স বা পরিচালন কর হিসেবে দেখা বন্ধ করুন। সেগুলোকে কাঁচামাল হিসেবে বিবেচনা করুন যা ইঞ্জিনিয়ারিং ভেলোসিটি বা গতির (engineering velocity) রূপান্তরিত হয়। সেই প্রেক্ষাপটে, যে ইঞ্জিনিয়ার