സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറിംഗ് എക്കാലത്തും തെറ്റായ ഉൽപ്പാദനക്ഷമത മാനദണ്ഡങ്ങളാണ് പിന്തുടർന്നിട്ടുള്ളത്. മാനേജർമാർ കോഡിന്റെ വരികൾ എണ്ണിക്കൊണ്ടിരുന്നു. അജൈൽ (Agile) ടീമുകൾ സ്റ്റോറി പോയിന്റുകൾ ട്രാക്ക് ചെയ്തു. എന്നാൽ ഒരു ഡെവലപ്പർ വ്യക്തമായി ചിന്തിക്കുന്നുണ്ടോ അതോ വെറുതെ ടൈപ്പ് ചെയ്യുകയാണോ എന്ന് ഇവയൊന്നും കൃത്യമായി അളക്കുന്നില്ല. എൻവിഡിയ (Nvidia) സിഇഒ ജെൻസൺ ഹുവാങ്ങിന് ഇതിലും മികച്ച ഒരു അളവുകോൽ ഉണ്ടെന്നാണ് കരുതുന്നത്, അതിന് കീബോർഡുകളുമായി യാതൊരു ബന്ധവുമില്ല. GTC 2026-ന് ശേഷം All-In പോഡ്‌കാസ്റ്റിൽ പങ്കെടുത്തുകൊണ്ട് ഹുവാങ് വാദിച്ചത്, ഒരു ആധുനിക എഞ്ചിനീയറുടെ മൂല്യം അളക്കേണ്ടത് അവരുടെ ശമ്പളത്തിന് ആനുപാതികമായി അവർ എത്ര AI ടോക്കണുകൾ ഉപയോഗിക്കുന്നു എന്നതിനെ അടിസ്ഥാനമാക്കിയാണെന്നാണ്. സന്ദേശം വ്യക്തമായിരുന്നു: നിങ്ങൾ വർഷത്തിൽ അഞ്ച് ലക്ഷം ഡോളർ സമ്പാദിക്കുന്നുണ്ടെങ്കിലും, ലാർജ് ലാംഗ്വേജ് മോഡൽ (LLM) സേവനങ്ങൾക്കായി അതിന്റെ പകുതിയിൽ താഴെ മാത്രം ചെലവാക്കുന്നുണ്ടെങ്കിൽ, നിങ്ങളുടെ ശമ്പളത്തെ ന്യായീകരിക്കാൻ ആവശ്യമായ ടൂളുകൾ ഉപയോഗിക്കുന്നതിൽ നിങ്ങൾ പരാജയപ്പെടുന്നു എന്നാണ് ഇതിനർത്ഥം.

ഒരു കൃത്യമായ അനുപാതം

ഹുവാങ് വിവരിച്ച ഈ മാനദണ്ഡം ലളിതവും എന്നാൽ ഞെട്ടിക്കുന്നതുമാണ്. ഒരു എഞ്ചിനീയറുടെ വാർഷിക ശമ്പളം എടുക്കുക. അത് അവരുടെ വാർഷിക LLM API കോളുകൾ, ഫൈൻ-ട്യൂണിംഗ് റണ്ണുകൾ, ഏജന്റിക് ഇൻഫറൻസ് എന്നിവയ്ക്കായുള്ള ചെലവുമായി താരതമ്യം ചെയ്യുക. വർഷത്തിൽ $500,000 സമ്പാദിക്കുന്ന ഒരു ഉയർന്ന വൈദഗ്ധ്യമുള്ള എഞ്ചിനീയർ AI ടോക്കൺ ചെലവായി $250,000-ൽ താഴെ മാത്രം ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, അവിടെ ഒരു പ്രശ്നമുണ്ടെന്ന് ഹുവാങ് കാണുന്നു. ഡെവലപ്പർ ആധുനിക സഹായങ്ങളിൽ നിന്ന് ഒറ്റപ്പെട്ട രീതിയിൽ ജോലി ചെയ്യുന്നു എന്നോ, അല്ലെങ്കിൽ AI-യെ ഒരു യഥാർത്ഥ സഹകാരിയായി കാണുന്നതിന് പകരം വെറുമൊരു സെർച്ച് എഞ്ചിനായി മാത്രം ഉപയോഗിക്കുന്നു എന്നോ ഇത് സൂചിപ്പിക്കുന്നു.

ഇത് അമിതമായി പണം ചെലവാക്കാനുള്ള അനുവാദമല്ല. മറിച്ച്, ബുദ്ധിപരമായ അധ്വാനത്തിന്റെ ശേഷി അളക്കുന്ന ഒരു പരീക്ഷണമാണ്. ലഭ്യമായ ഏറ്റവും മികച്ച മോഡലുകൾ ഉപയോഗിച്ച് മാനസികമായ കഠിനമായ ജോലികൾ പരമാവധി ഒഴിവാക്കണമെന്നാണ് ഹുവാങ്ങിന്റെ വാദം. ഒരു മോഡലിന് മുഴുവൻ കോഡ്ബേസും മനസ്സിലാക്കാൻ സാധിക്കുമെങ്കിൽ, മുമ്പ് മൂന്ന് ദിവസം നീണ്ടുനിന്നിരുന്ന ഡീബഗ്ഗിംഗ് സെഷനുകൾ മണിക്കൂറുകൾക്കുള്ളിൽ പൂർത്തിയാക്കാൻ കഴിയും. ദൈർഘ്യമേറിയ മീറ്റിംഗുകൾ ആവശ്യമായിരുന്ന സിസ്റ്റം ഡിസൈൻ ചർച്ചകൾ ഒരു റീസണിംഗ് മോഡൽ ഉപയോഗിച്ചുള്ള വേഗത്തിലുള്ള പ്രോട്ടോടൈപ്പിംഗിലൂടെ പരിഹരിക്കാനാകും. ഹുവാങ്ങിനെ സംബന്ധിച്ചിടത്തോളം, $250,000 എന്ന പരിധി ഒരു ബജറ്റ് പരിധിയല്ല, മറിച്ച് ഒരു അടിസ്ഥാന നിലവാരമാണ്. ഒരു മികച്ച എഞ്ചിനീയർ തന്റെ പൂർണ്ണ ശേഷിയിൽ പ്രവർത്തിക്കാൻ ആവശ്യമായ കുറഞ്ഞ ബുദ്ധിശക്തിയുടെ സബ്‌സിഡിയാണിത്.

ഈ പരിധിയിൽ താഴെ നിൽക്കുന്ന ഡെവലപ്പർമാർ അമിതമായി ജോലികൾ സ്വയം ചെയ്യുന്നു. അവർ ബഗുകൾ മാനുവലായി കണ്ടെത്തുന്നു, ബോയിലർപ്ലേറ്റ് കോഡുകൾ കൈകൊണ്ട് എഴുതുന്നു, കൂടാതെ ഒരു മോഡലിന് നിമിഷങ്ങൾക്കുള്ളിൽ സംഗ്രഹിക്കാൻ കഴിയുന്ന ഡോക്യുമെന്റേഷനുകൾ വീണ്ടും വീണ്ടും വായിക്കുന്നു. ഇൻഫറൻസ് ചെലവുകൾ കുറയുകയും കോൺടെക്സ്റ്റ് വിൻഡോകൾ വികസിക്കുകയും ചെയ്യുന്ന ഈ കാലഘട്ടത്തിൽ, ടോക്കണുകൾ ലാഭിക്കുന്നത് അച്ചടക്കമല്ല, മറിച്ച് സാങ്കേതികവിദ്യയുടെ കുറഞ്ഞ ഉപയോഗമാണ് സൂചിപ്പിക്കുന്നത്. തന്റെ ഔട്ട്പുട്ട് വർദ്ധിപ്പിക്കാൻ AI ഉപയോഗിക്കുന്നതിൽ പരാജയപ്പെടുന്ന ഒരു എഞ്ചിനീയർ, ഈ യുക്തി അനുസരിച്ച്, വേണ്ടത്ര പ്രകടനം കാഴ്ചവെക്കുന്നില്ല എന്നാണ് അർത്ഥം.

ലിവറേജ് എന്നതിന്റെ സൂചകമായി ടോക്കണുകൾ

പരമ്പരാഗത എഞ്ചിനീയറിംഗ് മാനേജ്‌മെന്റ് എപ്പോഴും ദൃശ്യമായ ഔട്ട്പുട്ടുകൾ ഇഷ്ടപ്പെടുന്നു. ക്ലോസ് ചെയ്ത Jira ടിക്കറ്റുകൾ, പുഷ് ചെയ്ത കമ്മറ്റുകൾ, ഷിപ്പ് ചെയ്ത ഫീച്ചറുകൾ എന്നിവ ഇതിൽ ഉൾപ്പെടുന്നു. ഇവ എണ്ണാൻ കഴിയുന്നതുകൊണ്ട് സുരക്ഷിതമായി തോന്നാം. എന്നാൽ ഹുവാങ്ങിന്റെ രീതി ഇവയെ വലിയതോതിൽ അവഗണിക്കുന്നു. അദ്ദേഹത്തിന്റെ യുക്തി അനുസരിച്ച്, ഒരു സീനിയർ സ്റ്റാഫ് എഞ്ചിനീയർ ഒരു മിഡ്-ലെവൽ ജീവനക്കാരനേക്കാൾ കുറഞ്ഞ കമ്മറ്റുകൾ ചെയ്തേക്കാം, എന്നാൽ അവർ കൂടുതൽ മൂല്യം സൃഷ്ടിക്കുന്നുണ്ടാകും; കാരണം അവരുടെ യഥാർത്ഥ ഉൽപ്പന്നം തീരുമാനങ്ങളാണ്. ആ തീരുമാനങ്ങളുടെ കണക്കുപുസ്തകമാണ് ടോക്കണുകൾ.

ഒരു എഞ്ചിനീയർ LLM ഇൻഫറൻസിനായി വലിയ തുക ചെലവാക്കുമ്പോൾ, അവർ വെറുതെ ടെക്സ്റ്റ് ജനറേഷൻ മാത്രമല്ല വാങ്ങുന്നത്. അവർ സമാന്തരമായ ചിന്താപ്രക്രിയകളാണ് (parallelized thought) വാങ്ങുന്നത്. $500,000 ശമ്പളമുള്ള ഒരു എഞ്ചിനീയർ ഒരു റീഫാക്റ്ററിംഗ് പ്രശ്നത്തിനായി വലിയ കോൺടെക്സ്റ്റ് വിൻഡോകൾ ഉപയോഗിക്കുമ്പോൾ, അവർ യഥാർത്ഥത്തിൽ ഒരേസമയം ഡസൻ കണക്കിന് ചിന്താപ്രക്രിയകൾ നടത്തുകയാണ്; മൈക്രോ സർവീസുകളിലെ എഡ്ജ് കേസുകൾ പരിശോധിക്കുകയും, ഒരു വരി പ്രൊഡക്ഷൻ കോഡ് പോലും എഴുതുന്നതിന് മുമ്പ് ആർക്കിടെക്ചറൽ അനുമാനങ്ങൾ പരിശോധിക്കുകയും ചെയ്യുന്നു. ടോക്കണുകൾ ശമ്പള സമയത്തെ ചുരുക്കിയ ഫലങ്ങളാക്കി മാറ്റുന്നു. അവ വേഗതയും, ആർക്കിടെക്ചറൽ ദീർഘവീക്ഷണവും, നൂറുകണക്കിന് മണിക്കൂറുകൾ എടുക്കുന്ന ഡീബഗ്ഗിംഗ് കഴിവുകളും വാങ്ങി നൽകുന്നു.

ഇത് പഴയ ഇൻസെന്റീവ് ഘടനയെ മാറ്റിമറിക്കുന്നു. ക്ലൗഡ് കമ്പ്യൂട്ട് ഡിസ്കൗണ്ടുകൾക്കായി എഞ്ചിനീയറിംഗ് ലീഡർമാർ ചരിത്രപരമായി കഠിനമായി ചർച്ചകൾ നടത്താറുണ്ട്, കൂടാതെ SaaS ചെലവുകൾ കുറയ്ക്കാൻ ശ്രമിക്കാറുമുണ്ട്. എന്നാൽ AI-യുടെ കാര്യത്തിൽ ആ ചിന്താഗതി തെറ്റാണെന്ന് ഹുവാങ് പറയുന്നു. ടോക്കൺ ബജറ്റ് പ്രതിഭയ്ക്ക് അനുസരിച്ച് വർദ്ധിപ്പിക്കണം. നിങ്ങൾ ഉയർന്ന ശമ്പളം നൽകി കഴിവുള്ളവരെ നിയമിക്കുകയും എന്നാൽ അവർക്ക് ഏറ്റവും മികച്ച മോഡലുകൾ ഉപയോഗിക്കാൻ അനുവദിക്കാതിരിക്കുകയും ചെയ്താൽ, അവരെ മാനുവൽ ജോലികളിൽ കുടുക്കിയിട്ടാലുമാകും. അവർ വെറും ഉയർന്ന ശമ്പളം വാങ്ങുന്ന ടൈപ്പിസ്റ്റുകളായി മാറും. ഹുവാങ് ഉദ്ദേശിക്കുന്നത് 'ഇന്റലിജൻസ് ഡെൻസിറ്റി' (intelligence density) ആണ്: ഒരു മനുഷ്യൻ ജോലി ചെയ്യുന്ന ഓരോ മണിക്കൂറിലും പരമാവധി ബുദ്ധിശക്തി ഉപയോഗിക്കുക, ആദ്യ കാഴ്ചയിൽ ക്ലൗഡ് ബില്ല് ഭയപ്പെടുത്തുന്നതാണെങ്കിൽ പോലും. ഒരു എഞ്ചിനീയർ തന്റെ ഉയർന്ന ശമ്പളത്തെ ന്യായീകരിക്കാൻ ആവശ്യമായ ടോക്കണുകൾ ഉപയോഗിക്കുന്നില്ലെങ്കിൽ, അവർ ബുദ്ധിപരമായ കഠിനമായ ജോലികൾ AI-ക്ക് കൈമാറുന്നതിൽ പരാജയപ്പെടുന്നു എന്നാണ്, ഇത് സ്ഥാപനത്തിൽ അവരുടെ സ്വാധീനം പരിമിതപ്പെടുത്തുന്നു.

ടീമിനെ നിലനിർത്തുക, കമ്പ്യൂട്ട് വർദ്ധിപ്പിക്കുക

വർദ്ധിച്ചുവരുന്ന പ്രവർത്തനച്ചെലവുകൾ സാധാരണയായി ജീവനക്കാരുടെ എണ്ണം കുറയ്ക്കുന്നതിലേക്കാണ് നയിക്കുന്നത്. ക്ലൗഡ് ബില്ലുകൾ വർദ്ധിക്കുന്നത് കാണുമ്പോൾ CFO-മാർ ഉടൻ തന്നെ ആരെ ഒഴിവാക്കാം എന്ന് ചിന്തിക്കുന്നു. എന്നാൽ ഹുവാങ് ഇതിന് വിപരീതമായ ഒരു നിർദ്ദേശമാണ് നൽകുന്നത്. ബജറ്റിന് അനുസരിച്ച് ടീമിനെ ചുരുക്കുന്നതിന് പകരം, ടീമിനെ ശാക്തീകരിക്കുന്നതിനായി ബജറ്റ് ഒപ്റ്റിമൈസ് ചെയ്യുകയാണ് കമ്പനികൾ ചെയ്യേണ്ടത്.

ഈ വാദം നിലനിൽക്കുന്നത് പകരം വെക്കാനുള്ള ചിലവുകളിലും (replacement costs) ഏകോപനത്തിനായുള്ള അധിക അധ്വാനത്തിലും (coordination overhead) ആണ്. ഒരു പഴയ സോഫ്റ്റ്‌വെയർ സ്ഥാപനം ഒരു മോണോലിത്ത് (monolith) പരിപാലിക്കാനും, പരസ്പരം പുൾ റിക്വസ്റ്റുകൾ (pull requests) പരിശോധിക്കാനും, സേവനങ്ങൾ സാവധാനം മാറ്റിയെടുക്കാനും മുപ്പത് എഞ്ചിനീയർമാരെ നിയമിച്ചേക്കാം. എന്നാൽ എൻ്റർപ്രൈസ് ഗ്രേഡ് ടോക്കൺ ക്വാട്ടകൾ (enterprise-grade token quotas) ഉപയോഗിക്കുന്ന അഞ്ച് എഞ്ചിനീയർമാരടങ്ങുന്ന ഒരു ചെറിയ ടീമിന് ആ ഉൽപ്പാദനക്ഷമതയോട് (throughput) കിടപിടിക്കാനോ അതിനേക്കാൾ മുന്നേറാനോ സാധിക്കും. ലാഭം ലഭിക്കുന്നത് API ചിലവുകളിൽ നിന്നല്ല. ആശയവിനിമയത്തിലെ കാലതാമസം (communication latency), നിയമന പ്രക്രിയകൾ (hiring cycles), ഉദ്യോഗസ്ഥതലത്തിലുള്ള കാലതാമസം (bureaucratic drag) എന്നിവ ഒഴിവാക്കുന്നതിലൂടെയാണ് അത് ഉണ്ടാകുന്നത്.

ലക്ഷ്യബോധത്തോടെ വലിയ തോതിലുള്ള ടോക്കൺ പ്രവാഹങ്ങളെ നിയന്ത്രിക്കാൻ കഴിയുന്ന എഞ്ചിനീയർമാരെ നിങ്ങൾ നിയമിച്ചാൽ മാത്രമേ ഈ തന്ത്രം വിജയിക്കുകയുള്ളൂ. ഒരു സ്റ്റാക്ക് ട്രാസ് (stack trace) ചാറ്റ്ബോട്ടിൽ പേസ്റ്റ് ചെയ്യുന്ന ഡെവലപ്പറും, മൾട്ടി-ഏജൻ്റ് പൈപ്പ്‌ലൈനുകൾ (multi-agent pipelines) ഏകോപിപ്പിക്കുകയും, സമ്പന്നമായ കോൺടെക്സ്റ്റ് ലൈബ്രറികൾ (context libraries) പരിപാലിക്കുകയും, തെറ്റായ വിവരങ്ങൾ (hallucinated outputs) കർശനമായി പരിശോധിക്കുകയും ചെയ്യുന്ന ഡെവലപ്പറും തമ്മിൽ വലിയ വ്യത്യാസമുണ്ട്. രണ്ടാമത്തെ വിഭാഗത്തിലുള്ളവരെ കണ്ടെത്തുക പ്രയാസമാണ്. അതുകൊണ്ടാണ് ഹുവാങ് (Huang) ഈ അളവുകോലിനെ ശമ്പളവുമായി ബന്ധിപ്പിക്കുന്നത്. ഉയർന്ന ശമ്പളം ഉയർന്ന ഏകോപന നൈപുണ്യവുമായി (orchestration skill) ബന്ധപ്പെട്ടിരിക്കണം. ആഴ്ചയിലൊരിക്കൽ ഒരു മോഡലിന് പ്രോംപ്റ്റ് നൽകാൻ വേണ്ടി നിങ്ങൾ ഒരാൾക്ക് അരലക്ഷം ഡോളർ നൽകേണ്ടതില്ല. സങ്കീർണ്ണമായ സിസ്റ്റങ്ങൾ അഭൂതപൂർവമായ വേഗതയിൽ നിർമ്മിക്കുന്ന ഓട്ടോമേറ്റഡ് റീസണിംഗ് ഇക്കോസിസ്റ്റം (automated reasoning ecosystem) കൈകാര്യം ചെയ്യുന്നതിനാണ് നിങ്ങൾ അവർക്ക് പ്രതിഫലം നൽകുന്നത്.

പ്രായോഗികമായി ഇതിൻ്റെ അർത്ഥമെന്താണ്

എഞ്ചിനീയറിംഗ് സ്ഥാപനങ്ങളെ സംബന്ധിച്ചിടത്തോളം, ടോക്കൺ-ടു-സാലറി അനുപാതം (token-to-salary ratio) എന്നത് ഒരു കർശനമായ അക്കൗണ്ടിംഗ് നിയമത്തേക്കാൾ ഉപരിയായി ഒരു സാംസ്കാരിക പരിശോധനാ പോയിൻ്റ് (cultural checkpoint) ആണ്. തങ്ങളുടെ ഏറ്റവും ഉയർന്ന ശമ്പളം വാങ്ങുന്ന ഡെവലപ്പർമാർക്ക് AI ആക്സറ്റീവ് ആയി ഉപയോഗിക്കാൻ ആവശ്യമായ അനുമതിയും പരിശീലനവും ഉണ്ടോ എന്ന് നേതാക്കൾ ചോദിക്കണം. അവർ പഴയ കോഡുകളിൽ (legacy code) ലോംഗ്-കോൺടെക്സ്റ്റ് അനാലിസിസ് (long-context analysis) നടത്തുന്നുണ്ടോ, അതോ ഇപ്പോഴും ലോഗുകൾ ഓരോ വരിയായി പരിശോധിച്ചുകൊണ്ടിരിക്കുകയാണോ? അവർ ഇന്റഗ്രേഷൻ ടെസ്റ്റിംഗിനായി ഏജൻ്റിക് കോഡിംഗ് ടൂളുകൾ (agentic coding tools) ഉപയോഗിക്കുന്നുണ്ടോ, അതോ മോക്കുകൾ (mocks) കൈകൊണ്ട് എഴുതുകയാണോ ചെയ്യുന്നത്? അവരുടെ പ്രോജക്റ്റുകൾ തടസ്സപ്പെടുന്നത് മനുഷ്യരുടെ ശ്രദ്ധക്കുറവ് മൂലമാണോ അതോ API റേറ്റ് ലിമിറ്റുകൾ (API rate limits) മൂലമാണോ?

ഉത്തരം മനുഷ്യസഹജമായ തടസ്സങ്ങളിലേക്കാണ് വിരൽ ചൂണ്ടുന്നതെങ്കിൽ, കൂടുതൽ സമയം ജോലി ചെയ്യാൻ ആവശ്യപ്പെടുകയല്ല പരിഹാരം. മറിച്ച് ടോക്കൺ പരിധി (token ceiling) വർദ്ധിപ്പിക്കുക എന്നതാണ്. എഞ്ചിനീയർമാരെ കൂടുതൽ ഏജൻ്റുകൾ ഉപയോഗിക്കാൻ അനുവദിക്കുക. മുഴുവൻ സർവീസ് മെഷിനും (service mesh) വേണ്ടി ഒരു പെർസിസ്റ്റൻ്റ് കോൺടെക്സ്റ്റ് വിൻഡോ (persistent context window) തുറന്നു വെക്കാൻ അവരെ അനുവദിക്കുക. ആഴ്ചയിൽ രണ്ടുതവണ എന്നതിന് പകരം ഒരു ഉച്ചനേരത്തിനുള്ളിൽ തന്നെ അമ്പത് തവണ ആർക്കിടെക്ചറിൽ മാറ്റങ്ങൾ വരുത്താൻ അവരെ അനുവദിക്കുക. ടോക്കൺ ഉപയോഗം അനാവശ്യ ചിലവായി കാണുന്നതിന് പകരം ഉയർന്ന ഫലപ്രാപ്തിയുള്ള എഞ്ചിനീയറിംഗിൻ്റെ അടയാളമായി കാണുമ്പോൾ, കമ്പനികൾക്കുള്ളിലെ അനുമതിാ സംവിധാനങ്ങളിൽ മാറ്റം വരും.

തീർച്ചയായും, പണം ചിലവാക്കുന്നത് കൊണ്ട് മാത്രം കാര്യമില്ല. നിസ്സാരമായ ചോദ്യങ്ങൾക്കോ കൃത്യമല്ലാത്ത പ്രോംപ്റ്റുകൾക്കോ വേണ്ടി ടോക്കണുകൾ ഉപയോഗിക്കുന്നത് വെറുതെ പാഴാക്കലാണ്. ഉയർന്ന മൂല്യമുള്ള പ്രശ്നങ്ങളിൽ കമ്പ്യൂട്ടിംഗ് ശേഷി കേന്ദ്രീകരിക്കുക എന്നതാണ് ഇതിലെ അച്ചടക്കം: ക്രോസ്-സർവീസ് ഡിസൈൻ (cross-service design), സെക്യൂരിറ്റി ഓഡിറ്റിംഗ് (security auditing), ലെഗസി മൈഗ്രേഷനുകൾക്കായുള്ള ബിഹേവിയർ ക്ലോണിംഗ് (behavior-cloning for legacy migrations), സിന്തറ്റിക് ട്രെയിനിംഗ് ഡാറ്റ നിർമ്മിക്കൽ എന്നിവ ഇതിൽ ഉൾപ്പെടുന്നു. ഈ ലക്ഷ്യം കൈവരിക്കുന്ന എഞ്ചിനീയർമാർ ഒരു മൾട്ടിപ്ലയർ (multiplier) ആയി മാറുന്നു. എന്നാൽ ഇത് ചെയ്യാത്തവർ, എത്ര ഉയർന്ന ശമ്പളം വാങ്ങുന്നുണ്ടെങ്കിലും, അനാവശ്യമായി ചിലവ് വരുന്നവരായി മാത്രം തോന്നും.

യഥാർത്ഥ പാഠം

ഹുവാങ്ങിൻ്റെ സിദ്ധാന്തം യഥാർത്ഥത്തിൽ AI ചിലവുകളെ പുനർനിർവചിക്കുന്നതിനെക്കുറിച്ചാണ്. LLM ടോക്കണുകളെ ഒരു പ്രവർത്തന നികുതിയായി (operational tax) കാണുന്നത് നിർത്തുക. അവയെ എഞ്ചിനീയറിംഗ് വേഗതയായി (engineering velocity) മാറ്റാൻ കഴിയുന്ന അസംസ്കൃത വസ്തുക്കളായി കാണുക. ആ കാഴ്ചപ്പാടിൽ, ആ എഞ്ചിനീയർ