لطالما سعت هندسة البرمجيات وراء مقاييس إنتاجية خاطئة. كان المديرون يحصون أسطر الكود، بينما تتبعت فرق Agile نقاط القصة (story points). لم ينجح أي منها في قياس ما إذا كان المطور يفكر بوضوح أم أنه يكتفي بالكتابة الكثيرة فحسب. يعتقد جينسن هوانغ، الرئيس التنفيذي لشركة Nvidia، أنه يمتلك مقياساً أفضل، ولا علاقة له بلوحات المفاتيح. خلال ظهوره الأخير في بودكاست All-In عقب مؤتمر GTC 2026، جادل هوانغ بأن المقياس الحقيقي لقيمة المهندس الحديث هو عدد رموز الذكاء الاصطناعي (AI tokens) التي يستهلكها مقارنة براتبه. كانت الرسالة مباشرة: إذا كنت تتقاضى نصف مليون دولار سنوياً ولكنك تنفق أقل من نصف ذلك على خدمات النماذج اللغوية الكبيرة (LLM)، فمن المحتمل أنك تفشل في استخدام الأدوات التي تبرر راتبك.
نسبة صارمة
المقياس الذي وصفه هوانغ بسيط بشكل صادم. خذ التعويض السنوي للمهندس، وقارنه بما ينفقه سنوياً على استدعاءات LLM API، وعمليات الضبط الدقيق (fine-tuning)، والاستدلال الوكيل (agentic inference). إذا كان المهندس عالي المهارة الذي يتقاضى 500,000 دولار سنوياً ينفق أقل من 250,000 دولار على تكاليف رموز الذكاء الاصطناعي، فإن هوانغ يرى في ذلك مشكلة. فهذا يشير إلى أن المطور إما يعمل بمعزل عن المساعدات الحديثة أو يعامل الذكاء الاصطناعي كمجرد محرك بحث متطور بدلاً من كونه شريكاً حقيقياً في العمل.
هذا ليس ترخيصاً للإنفاق المتهور، بل هو اختبار للقدرة الإدراكية الأساسية. تفترض فرضية هوانغ أن المهندسين النخبة يجب أن يلقوا بكل قدر ممكن من الأعمال الذهنية الرتيبة على أكثر النماذج قدرة المتاحة. فجلسات تصحيح الأخطاء (debugging) التي كانت تستغرق ثلاثة أيام يمكن ضغطها في ساعات عندما يمتلك النموذج سياقاً كاملاً لقاعدة الكود (codebase). ونقاشات تصميم الأنظمة التي كانت تتطلب اجتماعات طويلة يمكن حلها من خلال النماذج الأولية السريعة باستخدام نموذج استدلالي (reasoning model). بالنسبة لهوانغ، فإن عتبة الـ 250,000 دولار ليست سقفاً للميزانية بقدر ما هي أرضية؛ فهي تمثل الحد الأدنى من دعم الذكاء الذي يجب أن يحتاجه مهندس من الطراز الأول للعمل بكامل طاقته.
أما المطورون الذين يقل استهلاكهم عن هذا الخط، فهم يقومون بالكثير من العمل بأنفسهم؛ يتتبعون الأخطاء يدوياً، ويكتبون الكود النمطي (boilerplate) يدوياً، ويعيدون قراءة الوثائق التي كان بإمكان نموذج تمت صياغة أوامره (prompted) جيداً أن يلخصها في ثوانٍ. وفي عصر تنخفض فيه تكاليف الاستدلال وتتوسع فيه نوافذ السياق (context windows)، فإن التقشف في استخدام الرموز (tokens) يشير إلى عدم الاستغلال الأمثل للموارد، وليس إلى الانضباط. ومن هذا المنطلق، فإن المهندس الذي يفشل في استخدام الذكاء الاصطناعي بقوة لتعزيز مخرجاته يُعد مقصراً في أدائه.
الرموز كوسيلة لتعظيم التأثير
تحب إدارة الهندسة التقليدية المخرجات الملموسة: تذاكر Jira المغلقة، عمليات الإرسال (commits) المرفوعة، والميزات التي تم إطلاقها. تبدو هذه الأرقام آمنة لأنها قابلة للعد، لكن إطار عمل هوانغ يتجاهلها إلى حد كبير. فوفقاً لمنطقه، قد ينتج مهندس أول (senior staff engineer) عمليات إرسال (commits) خام أقل من موظف في مستوى متوسط، بينما يولد قيمة أكبر بكثير، لأن منتجه الحقيقي هو القرارات. وتصبح الرموز (tokens) هي السجل لتلك القرارات.
عندما ينفق المهندس بكثافة على استدلال LLM، فهو لا يشتري مجرد توليد نصوص، بل يشتري "تفكيراً متوازياً". فالمهندس الذي يتقاضى 500,000 دولار ويستخدم نوافذ سياق ضخمة لحل مشكلة إعادة هيكلة الكود (refactoring) يقوم أساساً بتشغيل عشرات المسارات الإدراكية المتزامنة، وفحص الحالات الحدية عبر الخدمات المصغرة (microservices)، واختبار الافتراضات المعمارية تحت الضغط دون كتابة سطر واحد من كود الإنتاج بعد. تقوم الرموز بتحويل ساعات الراتب إلى نتائج مضغوطة؛ فهي تشتري السرعة، والاستشراف المعماري، وقدرات تصحيح الأخطاء التي كانت ستستهلك مئات الساعات اليدوية.
هذا يقلب هيكل الحوافز القديم. تاريخياً، تفاوض قادة الهندسة بجدية للحصول على خصومات على الحوسبة السحابية وعاملوا شراء برمجيات SaaS كمركز تكلفة يجب تقليصه. يقترح هوانغ أن هذا العقلية معكوسة بالنسبة للذكاء الاصطناعي. يجب أن تتوسع ميزانية الرموز (tokens) مع الموهبة؛ فإذا وظفت عقولاً باهظة الثمن ثم حرمتها من أغلى النماذج، فإنك تحبسها في سير عمل يدوي، ويتحولون إلى مجرد كاتبين (typists) بأسعار باهظة. الهدف هو ما يلمح إليه هوانغ بـ "كثافة الذكاء": أقصى قدر من الإدراك المطبق لكل ساعة عمل بشرية، حتى لو بدت فاتورة السحابة مقلقة للوهلة الأولى. إذا لم يكن المهندس يستهلك ما يكفي من الرموز لتبرير راتبه المرتفع، فمن المرجح أنه يفشل في إسناد المهام الإدراكية الشاقة إلى الذكاء الاصطناعي، مما يحد من تأثيره المحتمل على المؤسسة.
حافظ على الفريق، ووسع نطاق الحوسبة
عادة ما تؤدي التكاليف التشغيلية المتزايدة إلى مراجعات لعدد الموظفين؛ حيث يرى المديرون الماليون (CFOs) فواتير الـ API المتضخمة ويسألون بشكل تلقائي عن الأشخاص الذين يمكن الاستغناء عنهم. يقدم هوانغ وصفة معاكسة: بدلاً من تقليص الفريق ليتناسب مع الميزانية، يجب على الشركات تحسين الميزانية لتمكين الفريق.
The argument hinges on replacement costs and coordination overhead. A legacy software organization might staff thirty engineers to maintain a monolith, review each other’s pull requests, and slowly migrate services. A smaller team of five deeply augmented engineers, each burning through enterprise-grade token quotas, could match or exceed that throughput. The savings are not found in the API line item itself. They appear in the absence of communication latency, hiring cycles, and bureaucratic drag.
This strategy only works if you hire engineers who can direct massive token flows with intent. There is a material difference between a developer who pastes a stack trace into a chatbot and one who orchestrates multi-agent pipelines, maintains rich context libraries, and rigorously validates hallucinated outputs. The latter profile is harder to find. That is precisely why Huang ties the metric to salary. High compensation should correlate with high orchestration skill. You do not pay someone half a million dollars to prompt a model once a week. You pay them to manage an ecosystem of automated reasoning that builds complex systems at unprecedented speeds.
What This Means in Practice
For engineering organizations, the token-to-salary ratio is less a rigid accounting rule and more a cultural checkpoint. Leaders should ask whether their highest-paid developers have the access, training, and mandate to consume AI aggressively. Are they running long-context analysis on legacy code, or are they still grepping through logs line by line? Are they using agentic coding tools for integration testing, or are they writing mocks by hand? Are their projects bottlenecked by human attention or by API rate limits?
If the answer points toward human bottlenecks, the fix is rarely to demand more hours. It is usually to raise the token ceiling. Let the engineer spin up more agents. Let them keep a persistent context window open for the entire service mesh. Let them iterate on architecture fifty times in an afternoon instead of twice in a week. When token consumption is viewed as a sign of high-leverage engineering rather than unnecessary cost, permission structures inside companies change.
Of course, spending alone guarantees nothing. Tokens poured into trivial queries or poorly scoped prompts are simply waste. The discipline lies in aiming heavy compute at high-value problems: cross-service design, security auditing, behavior-cloning for legacy migrations, and generating synthetic training data. The engineers who master that aim become multipliers. Those who do not, regardless of their compensation, look expensive in exactly the wrong way.
The Real Takeaway
Huang’s thesis is ultimately about reframing AI spend. Stop treating LLM tokens as an operational tax. Treat them as raw material that gets converted into engineering velocity. In that framing, the engineer who