วิศวกรรมซอฟต์แวร์มักจะวิ่งไล่ตามตัวชี้วัดประสิทธิภาพที่ผิดมาโดยตลอด ผู้จัดการมักจะนับจำนวนบรรทัดของโค้ด ทีม Agile ก็ติดตามสตอรี่พอยต์ (story points) แต่ไม่มีสิ่งใดเลยที่สามารถวัดได้อย่างแม่นยำว่านักพัฒนาคนนั้นกำลังใช้ความคิดอย่างชัดเจน หรือเพียงแค่กำลังพิมพ์งานอย่างหนัก Jensen Huang ซีอีโอของ Nvidia คิดว่าเขามีเกณฑ์วัดที่ดีกว่านั้น และมันไม่เกี่ยวข้องกับคีย์บอร์ดเลย ในการปรากฏตัวครั้งล่าสุดในพอดแคสต์ All-In หลังงาน GTC 2026 Huang แย้งว่าตัวชี้วัดที่แท้จริงของมูลค่าวิศวกรยุคใหม่คือพวกเขาใช้โทเคน AI (AI tokens) มากน้อยเพียงใดเมื่อเทียบกับเงินเดือน ข้อความของเขานั้นตรงไปตรงมา: หากคุณมีรายได้ปีละห้าแสนดอลลาร์ แต่ใช้จ่ายกับบริการโมเดลภาษาขนาดใหญ่ (LLM) น้อยกว่าครึ่งหนึ่งของจำนวนนั้น คุณอาจกำลังล้มเหลวในการใช้เครื่องมือที่ช่วยสร้างความคุ้มค่าให้กับเงินเดือนที่คุณได้รับ
อัตราส่วนที่ชัดเจน
ตัวชี้วัดที่ Huang อธิบายนั้นเรียบง่ายจนน่าตกใจ ลองพิจารณาค่าตอบแทนรายปีของวิศวกรคนหนึ่ง แล้วนำมาเปรียบเทียบกับค่าใช้จ่ายรายปีสำหรับการเรียกใช้ LLM API, การทำ fine-tuning และการทำ agentic inference หากวิศวกรที่มีทักษะสูงซึ่งมีรายได้ 500,000 ดอลลาร์ต่อปี มีค่าใช้จ่ายด้านโทเคน AI ไม่ถึง 250,000 ดอลลาร์ Huang มองว่านั่นคือปัญหา มันบ่งชี้ว่านักพัฒนาคนนั้นอาจกำลังทำงานโดยแยกขาดจากการสนับสนุนสมัยใหม่ หรือกำลังปฏิบัติกับ AI เหมือนเป็นเพียงเครื่องมือค้นหาที่ถูกยกยอเกินจริง แทนที่จะเป็นผู้ร่วมงานที่แท้จริง
นี่ไม่ใช่ใบอนุญาตให้ใช้จ่ายอย่างบ้าคลั่ง แต่มันคือการทดสอบความสามารถในการรับภาระทางความคิด (load-bearing cognition) สมมติฐานของ Huang คือวิศวกรระดับหัวกะทิควรโอนย้ายงานที่ต้องใช้พลังสมองที่น่าเบื่อหน่ายให้มากที่สุดเท่าที่จะเป็นไปได้ไปยังโมเดลที่มีความสามารถสูงสุดที่มีอยู่ เซสชันการดีบั๊ก (debugging) ที่เคยลากยาวถึงสามวันสามารถย่อเหลือเพียงไม่กี่ชั่วโมงได้เมื่อโมเดลสามารถถือครองโค้ดเบส (codebase) ทั้งหมดไว้ในบริบท (context) การถกเถียงเรื่องการออกแบบระบบ (system design) ที่เคยต้องใช้การประชุมอันยาวนานสามารถหาข้อสรุปได้ผ่านการทำต้นแบบอย่างรวดเร็วด้วยโมเดลการใช้เหตุผล (reasoning model) สำหรับ Huang เกณฑ์ 250,000 ดอลลาร์นั้นไม่ใช่เพดานงบประมาณ แต่เป็นพื้นฐานขั้นต่ำ มันคือเงินอุดหนุนด้านสติปัญญาขั้นต่ำที่วิศวกรระดับแนวหน้าควรได้รับเพื่อให้สามารถทำงานได้อย่างเต็มศักยภาพ
นักพัฒนาที่ทำได้ต่ำกว่าเส้นนั้นกำลังทำงานด้วยตัวเองมากเกินไป พวกเขาไล่หาบั๊กด้วยมือ เขียนโค้ดพื้นฐาน (boilerplate) ด้วยตัวเอง และอ่านเอกสารซ้ำไปซ้ำมา ทั้งที่โมเดลที่ได้รับคำสั่ง (prompt) อย่างดีสามารถสรุปข้อมูลให้ได้ภายในไม่กี่วินาที ในยุคที่ต้นทุนการประมวลผล (inference costs) กำลังลดลงและหน้าต่างบริบท (context windows) กำลังขยายใหญ่ขึ้น ความตระหนี่ในการใช้โทเคนคือสัญญาณของการใช้งานไม่เต็มประสิทธิภาพ ไม่ใช่ความมีวินัย ตามตรรกะนี้ วิศวกรที่ไม่ใช้ AI อย่างจริงจังเพื่อเพิ่มพูนผลงานของตนเอง ถือเป็นผู้ที่มีประสิทธิภาพการทำงานต่ำ
โทเคนในฐานะตัวแทนของอำนาจทวีคูณ
การบริหารจัดการวิศวกรรมแบบดั้งเดิมชอบผลลัพธ์ที่จับต้องได้ เช่น ตั๋ว Jira ที่ปิดไปแล้ว, การคอมมิต (commits) ที่ถูกส่งออกไป หรือฟีเจอร์ที่ถูกปล่อยออกมา ตัวเลขเหล่านี้ให้ความรู้สึกปลอดภัยเพราะมันนับได้ แต่กรอบแนวคิดของ Huang กลับละทิ้งสิ่งเหล่านี้เป็นส่วนใหญ่ ภายใต้ตรรกะของเขา วิศวกรระดับ senior staff อาจสร้างคอมมิตดิบๆ ได้น้อยกว่าพนักงานระดับกลาง แต่กลับสร้างมูลค่าได้มากกว่ามหาศาล เพราะผลผลิตที่แท้จริงของพวกเขาคือ "การตัดสินใจ" และโทเคนก็กลายเป็นบัญชีที่บันทึกการตัดสินใจเหล่านั้น
เมื่อวิศวกรใช้จ่ายอย่างหนักกับการทำ LLM inference พวกเขาไม่ได้เพียงแค่ซื้อการสร้างข้อความ แต่พวกเขากำลังซื้อ "ความคิดแบบขนาน" วิศวกรเงินเดือน 500,000 ดอลลาร์ที่ใช้ context windows ขนาดมหึมาในการแก้ปัญหาการรีแฟกเตอร์ (refactoring) แท้จริงแล้วกำลังรันกระบวนการคิดพร้อมกันนับสิบสาย ตรวจสอบกรณีขอบเขต (edge cases) ในไมโครเซอร์วิสต่างๆ และทดสอบสมมติฐานทางสถาปัตยกรรมอย่างหนัก โดยที่ยังไม่ได้เขียนโค้ดสำหรับใช้งานจริงแม้แต่บรรทัดเดียว โทเคนเหล่านี้เปลี่ยนชั่วโมงการทำงานตามเงินเดือนให้กลายเป็นผลลัพธ์ที่รวบยอด พวกเขาซื้อความเร็ว การมองการณ์ไกลทางสถาปัตยกรรม และความสามารถในการดีบั๊ก ซึ่งหากทำด้วยมือจะต้องใช้เวลาหลายร้อยชั่วโมง
สิ่งนี้พลิกโครงสร้างแรงจูงใจแบบเดิม ในอดีตผู้นำด้านวิศวกรรมมักจะต่อรองอย่างหนักเพื่อขอส่วนลดการประมวลผลบนคลาวด์ และมองว่าการจัดซื้อ SaaS เป็นศูนย์ต้นทุนที่ต้องลดให้เหลือน้อยที่สุด Huang เสนอว่าแนวคิดนั้นผิดสำหรับการใช้ AI งบประมาณด้านโทเคนควรขยายตัวตามความสามารถของบุคลากร หากคุณจ้างสมองราคาแพงมาแล้วปล่อยให้พวกเขาขาดแคลนโมเดลที่แพงที่สุด คุณกำลังกักขังพวกเขาไว้ในเวิร์กโฟลว์แบบทำด้วยมือ พวกเขาจะกลายเป็นเพียงพนักงานพิมพ์ดีดราคาแพง เป้าหมายคือสิ่งที่ Huang บ่งชี้ว่าเป็น "ความหนาแน่นของสติปัญญา" (intelligence density): การใช้พลังสมองประยุกต์สูงสุดต่อชั่วโมงการทำงานของมนุษย์ แม้ว่าบิลค่าคลาวด์จะดูน่าตกใจในตอนแรกก็ตาม หากวิศวกรไม่ได้ใช้โทเคนมากพอที่จะคุ้มค่ากับค่าตอบแทนที่สูงลิ่ว เป็นไปได้ว่าพวกเขากำลังล้มเหลวในการโอนย้ายงานที่ต้องใช้พลังสมองอย่างหนักไปให้ AI ซึ่งเป็นการจำกัดศักยภาพในการสร้างผลกระทบต่อองค์กร
รักษาทีมไว้ แล้วขยายการประมวลผล
ต้นทุนการดำเนินงานที่เพิ่มขึ้นมักจะนำไปสู่การทบทวนจำนวนพนักงาน CFO มักจะเห็นบิลค่า API ที่พุ่งสูงขึ้นและถามโดยสัญชาตญาณว่าใครสามารถถูกลดจำนวนลงได้บ้าง แต่ Huang เสนอแนวทางที่ตรงกันข้าม แทนที่จะลดขนาดทีมเพื่อให้พอดีกับงบประมาณ บริษัทควรปรับปรุงงบประมาณเพื่อเสริมพลังให้กับทีมแทน
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