مهندسی نرمافزار همیشه به دنبال معیارهای بهرهوری اشتباه بوده است. مدیران تعداد خطوط کد را میشمردند. تیمهای Agile امتیازهای داستان (story points) را دنبال میکردند. هیچکدام از اینها بهطور قابلاعتمادی نشان نمیداد که آیا یک توسعهدهنده شفاف فکر میکند یا صرفاً زیاد تایپ میکند. جنسن هوانگ، مدیرعامل Nvidia، فکر میکند معیار بهتری دارد که هیچ ارتباطی به کیبورد ندارد. هوانگ در حضور اخیر خود در پادکست All-In پس از GTC 2026، استدلال کرد که معیار واقعی ارزش یک مهندس مدرن، میزان مصرف توکنهای هوش مصنوعی نسبت به حقوق اوست. پیام او مستقیم بود: اگر سالانه نیم میلیون دلار درآمد دارید اما کمتر از نصف آن را صرف خدمات مدلهای زبانی بزرگ (LLM) میکنید، احتمالاً در استفاده از ابزارهایی که حقوق شما را توجیه میکنند، شکست خوردهاید.
یک نسبت قاطع
معیاری که هوانگ توصیف کرد، به طرز تکاندهندهای ساده است. حقوق سالانه یک مهندس را در نظر بگیرید. آن را با هزینهی سالانهی او برای فراخوانیهای API مدلهای زبانی بزرگ، اجراهای fine-tuning و استنتاجهای عاملمحور (agentic inference) مقایسه کنید. اگر یک مهندس بسیار ماهر با درآمد ۵۰۰,۰۰۰ دلار در سال، کمتر از ۲۵۰,۰۰۰ دلار هزینه توکن هوش مصنوعی داشته باشد، هوانگ یک مشکل میبیند. این نشان میدهد که توسعهدهنده یا در انزوا از کمکهای مدرن کار میکند و یا با هوش مصنوعی مانند یک موتور جستجوی پیشرفته برخورد میکند، نه یک همکار واقعی.
این موضوع مجوزی برای هزینهکرد بیرویه نیست؛ بلکه آزمونی برای توان شناختی است. فرض هوانگ این است که مهندسان نخبه باید تا حد امکان کارهای ذهنی تکراری و خستهکننده را به توانمندترین مدلهای موجود بسپارند. جلسات عیبیابی (debugging) که زمانی سه روز طول میکشید، زمانی که یک مدل کل پایگاه کد را در زمینه (context) خود داشته باشد، میتواند به چند ساعت کاهش یابد. بحثهای طراحی سیستم که قبلاً نیاز به جلسات طولانی داشت، میتواند از طریق نمونهسازی سریع با یک مدل استدلالی (reasoning model) حل شود. از نظر هوانگ، آستانه ۲۵۰,۰۰۰ دلاری کمتر یک سقف بودجه و بیشتر یک کف است. این رقم نشاندهنده حداقل «یارانه هوش» است که یک مهندس سطح بالا برای فعالیت با حداکثر ظرفیت خود به آن نیاز دارد.
توسعهدهندگانی که پایینتر از این خط قرار میگیرند، بیش از حد کار را خودشان انجام میدهند. آنها باگها را دستی ردیابی میکنند، کدهای تکراری (boilerplate) را با دست مینویسند و مستنداتی را دوباره میخوانند که یک مدل با یک پرامپت مناسب میتوانست در چند ثانیه ترکیب و خلاصهسازی کند. در عصری که هزینههای استنتاج در حال کاهش و پنجرههای زمینه (context windows) در حال گسترش است، صرفهجویی در توکنها نشاندهنده عدم بهرهبرداری است، نه انضباط. طبق این منطق، مهندسی که در استفاده تهاجمی از هوش مصنوعی برای تقویت خروجی خود کوتاهی میکند، عملکرد ضعیفی دارد.
توکنها به عنوان جایگزینی برای اهرم (Leverage)
مدیریت سنتی مهندسی عاشق خروجیهای ملموس است. بستن تیکتهای Jira. ارسال کامیتها (commits). عرضه ویژگیها (features). این اعداد امن به نظر میرسند چون قابل شمارش هستند. چارچوب هوانگ تا حد زیادی آنها را کنار میگذارد. طبق منطق او، یک مهندس ارشد (senior staff engineer) ممکن است کامیتهای خام کمتری نسبت به یک نیروی سطح متوسط تولید کند، اما ارزش بسیار بیشتری ایجاد کند، زیرا محصول واقعی او «تصمیمات» است. توکنها به دفتر کل آن تصمیمات تبدیل میشوند.
وقتی یک مهندس هزینه زیادی برای استنتاج LLM صرف میکند، صرفاً در حال خرید تولید متن نیست؛ بلکه در حال خرید «تفکر موازیشده» است. یک مهندس با حقوق ۵۰۰,۰۰۰ دلار که پنجرههای زمینه (context windows) عظیمی را برای یک مسئله بازسازی کد (refactoring) به کار میگیرد، در واقع دهها رشتهی شناختی همزمان را اجرا میکند، موارد خاص (edge cases) را در میکروسرویسها بررسی میکند و فرضیات معماری را بدون نوشتن حتی یک خط کد عملیاتی، تحت فشار آزمایش میکند. توکنها، ساعات حقوق را به نتایج فشرده تبدیل میکنند. آنها سرعت، آیندهنگری معماری و قابلیتهای عیبیابی را میخرند که در غیر این صورت صدها ساعت کار دستی را میبلعید.
این موضوع ساختار انگیزشی قدیمی را دگرگون میکند. رهبران مهندسی در گذشته همواره برای تخفیفهای محاسبات ابری چانه میزدند و تهیه SaaS را به عنوان مرکز هزینهای میدیدند که باید به حداقل برسد. هوانگ پیشنهاد میکند که این طرز فکر برای هوش مصنوعی برعکس است. بودجه توکن باید با استعداد هممقیاس شود. اگر مغزهای گرانقیمت استخدام میکنید و سپس آنها را از گرانترین مدلها محروم میکنید، آنها را در جریانهای کاری دستی گرفتار میکنید. آنها به تایپیستهایی با قیمت بالا تبدیل میشوند. هدف چیزی است که هوانگ آن را «تراکم هوش» مینامد: حداکثر شناختِ بهکارگرفتهشده در هر ساعت انسانی، حتی اگر صورتحساب ابری در نگاه اول نگرانکننده به نظر برسد. اگر مهندسی توکنهای کافی برای توجیه حقوق بالای خود مصرف نمیکند، احتمالاً در سپردن کارهای سنگین ذهنی به هوش مصنوعی شکست خورده و در نتیجه، تأثیر بالقوه خود بر سازمان را محدود کرده است.
تیم را حفظ کنید، محاسبات را گسترش دهید
افزایش هزینههای عملیاتی معمولاً باعث بازنگری در تعداد کارکنان میشود. مدیران ارشد مالی (CFOs) با دیدن صورتحسابهای رو به رشد API، بهطور غریزی میپرسند چه کسی را میتوان حذف کرد. هوانگ نسخه کاملاً متفاوتی ارائه میدهد. شرکتها به جای کوچک کردن تیم برای تطبیق با بودجه، باید بودجه را برای توانمندسازی تیم بهینه کنند.
استدلال بر هزینههای جایگزینی و سربار هماهنگی استوار است. یک سازمان نرمافزاری قدیمی ممکن است سی مهندس را برای نگهداری از یک سیستم یکپارچه (monolith)، بررسی pull requestهای یکدیگر و مهاجرت تدریجی سرویسها به کار بگیرد. یک تیم کوچکتر متشکل از پنج مهندسِ بهشدت تقویتشده (augmented) که هر کدام سهمیههای توکن در سطح سازمانی را مصرف میکنند، میتواند به همان میزان یا حتی بیشتر از آن خروجی داشته باشد. صرفهجویی در خودِ ردیف بودجهی API نیست؛ بلکه در نبودِ تأخیرهای ارتباطی، چرخههای استخدام و کندیهای بوروکراتیک نمایان میشود.
این استراتژی تنها زمانی کار میکند که مهندسانی را استخدام کنید که بتوانند جریانهای عظیم توکن را با هدفمندی هدایت کنند. تفاوت اساسی میان توسعهدهندهای که یک stack trace را در یک چتبات کپی میکند، با کسی که خطلولههای چندعاملی (multi-agent pipelines) را مدیریت میکند، کتابخانههای غنی از بافتار (context) را حفظ میکند و خروجیهای توهمآمیز (hallucinated) را با دقت اعتبارسنجی میکند، وجود دارد. یافتن پروفایل دوم دشوارتر است. دقیقاً به همین دلیل است که هوانگ این معیار را به حقوق بستره است. حقوق بالا باید با مهارت بالای مدیریت (orchestration) همبستگی داشته باشد. شما نیم میلیون دلار به کسی نمیدهید که هفتهای یک بار از یک مدل پرامپت بگیرد؛ بلکه به او پول میدهید تا اکوسیستمی از استدلال خودکار را مدیریت کند که سیستمهای پیچیده را با سرعتهای بیسابقه میسازد.
معنای این موضوع در عمل
برای سازمانهای مهندسی، نسبت توکن به حقوق، کمتر یک قاعده حسابداری سختگیرانه و بیشتر یک نقطه بازرسی فرهنگی است. رهبران باید بپرسند آیا پردرآمدترین توسعهدهندگان آنها دسترسی، آموزش و مجوز لازم برای استفادهی تهاجمی از هوش مصنوعی را دارند یا خیر. آیا آنها تحلیلهای با بافتار طولانی (long-context) را روی کدهای قدیمی اجرا میکنند، یا هنوز خط به خط در لاگها جستجو (grep) میکنند؟ آیا از ابزارهای کدنویسی عاملمحور (agentic) برای تست یکپارچگی استفاده میکنند، یا mockها را دستی مینویسند؟ آیا گلوگاه پروژههای آنها توجه انسانی است یا محدودیتهای نرخ (rate limits) API؟
اگر پاسخ به سمت گلوگاههای انسانی باشد، راه حل بهندرت افزایش ساعات کاری است؛ بلکه معمولاً بالا بردن سقف توکن است. اجازه دهید مهندس عاملهای (agents) بیشتری را راهاندازی کند. اجازه دهید یک پنجره بافتار (context window) پایدار برای کل شبکه سرویس (service mesh) باز نگه دارند. اجازه دهید به جای دو بار در هفته، پنجاه بار در یک بعدازظهر روی معماری تکرار و اصلاح (iterate) کنند. وقتی مصرف توکن به جای یک هزینه غیرضروری، به عنوان نشانهای از مهندسی با اهرم بالا (high-leverage) دیده شود، ساختارهای صدور مجوز در شرکتها تغییر میکند.
البته، صرفاً خرج کردن تضمینکننده هیچ چیز نیست. توکنهایی که صرف پرسوجوهای پیشپاافتاده یا پرامپتهایی با محدوده نامشخص میشوند، صرفاً اتلاف هستند. انضباط در این است که محاسبات سنگین را هدفِ مسائل با ارزش بالا قرار دهید: طراحی بینسرویسی، ممیزی امنیتی، شبیهسازی رفتار (behavior-cloning) برای مهاجرتهای قدیمی و تولید دادههای آموزشی مصنوعی. مهندسانی که در این هدفگیری مهارت پیدا میکنند، به ضریبکننده (multipliers) تبدیل میشوند. کسانی که این کار را نمیکنند، صرفنظر از میزان حقوقشان، دقیقاً به شکلی اشتباه، پرهزینه به نظر میرسند.
نتیجهگیری اصلی
تز هوانگ در نهایت درباره بازتعریف هزینههای هوش مصنوعی است. از برخورد با توکنهای LLM به عنوان یک مالیات عملیاتی دست بردارید. با آنها به عنوان مواد اولیهای برخورد کنید که به سرعت مهندسی تبدیل میشوند. در این چارچوب، مهندسی که