ಸಾಫ್ಟ್ವೇರ್ ಎಂಜಿನಿಯರಿಂಗ್ ಯಾವಾಗಲೂ ತಪ್ಪು ಉತ್ಪಾದಕತೆಯ ಮಾಪನಗಳನ್ನು ಬೆನ್ನಟ್ಟುತ್ತಾ ಬಂದಿದೆ. ಮ್ಯಾನೇಜರ್ಗಳು ಕೋಡ್ನ ಸಾಲುಗಳನ್ನು (lines of code) ಎಣಿಸುತ್ತಿದ್ದರು. ಅಜೈಲ್ (Agile) ತಂಡಗಳು ಸ್ಟೋರಿ ಪಾಯಿಂಟ್ಗಳನ್ನು (story points) ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತಿದ್ದವು. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಒಬ್ಬ ಡೆವಲಪರ್ ಸ್ಪಷ್ಟವಾಗಿ ಯೋಚಿಸುತ್ತಿದ್ದಾರೆಯೇ ಅಥವಾ ಕೇವಲ ಅತಿ ಹೆಚ್ಚು ಟೈಪ್ ಮಾಡುತ್ತಿದ್ದಾರೆಯೇ ಎಂಬುದನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಅಳೆಯಲಿಲ್ಲ. Nvidia ಸಿಇಒ ಜೆನ್ಸನ್ ಹೂಯಾಂಗ್ (Jensen Huang) ಇದಕ್ಕಿಂತ ಉತ್ತಮವಾದ ಮಾಪಕವನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ, ಮತ್ತು ಅದಕ್ಕೆ ಕೀಬೋರ್ಡ್ಗಳೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ. GTC 2026 ನಂತರ All-In ಪಾಡ್ಕಾಸ್ಟ್ನಲ್ಲಿ ಇತ್ತೀಚೆಗೆ ಕಾಣಿಸಿಕೊಂಡಾಗ, ಹೂಯಾಂಗ್ ಅವರು ಆಧುನಿಕ ಎಂಜಿನಿಯರ್ನ ಮೌಲ್ಯದ ನಿಜವಾದ ಅಳತೆಗೋಲು ಎಂದರೆ ಅವರು ತಮ್ಮ ಸಂಬಳಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಎಷ್ಟು AI ಟೋಕನ್ಗಳನ್ನು ಬಳಸುತ್ತಾರೆ ಎಂಬುದಾಗಿದೆ ಎಂದು ವಾದಿಸಿದರು. ಸಂದೇಶ ನೇರವಾಗಿತ್ತು: ನೀವು ವರ್ಷಕ್ಕೆ ಐದು ಲಕ್ಷ ಡಾಲರ್ ಗಳಿಸುತ್ತಿದ್ದೀರಿ ಮತ್ತು ಅದರಲ್ಲಿ ಅರ್ಧಕ್ಕಿಂತ ಕಡಿಮೆ ಮೊತ್ತವನ್ನು ಲಾರ್ಜ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ (LLM) ಸೇವೆಗಳಿಗಾಗಿ ಬಳಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಸಂಬಳವನ್ನು ಸಮರ್ಥಿಸುವ ಪರಿಕರಗಳನ್ನು ಬಳಸುವಲ್ಲಿ ನೀವು ಬಹುಶಃ ವಿಫಲರಾಗುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ.
ಒಂದು ಕಠಿಣ ಅನುಪಾತ
ಹೂಯಾಂಗ್ ವಿವರಿಸಿದ ಮಾಪನವು ಅತ್ಯಂತ ಸರಳವಾಗಿದೆ. ಒಬ್ಬ ಎಂಜಿನಿಯರ್ನ ವಾರ್ಷಿಕ ಸಂಭಾವನೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ. ಅದನ್ನು ಅವರ ವಾರ್ಷಿಕ LLM API ಕರೆಗಳು, ಫೈನ್-ಟ್ಯೂನಿಂಗ್ ರನ್ಗಳು ಮತ್ತು ಏಜೆಂಟಿಕ್ ಇನ್ಫರೆನ್ಸ್ (agentic inference) ವೆಚ್ಚಗಳಿಗೆ ಹೋಲಿಸಿ ನೋಡಿ. ವರ್ಷಕ್ಕೆ $500,000 ಗಳಿಸುವ ಅತ್ಯಂತ ನುರಿತ ಎಂಜಿನಿಯರ್ AI ಟೋಕನ್ ವೆಚ್ಚದಲ್ಲಿ $250,000 ಕ್ಕಿಂತ ಕಡಿಮೆ ಖರ್ಚು ಮಾಡುತ್ತಿದ್ದರೆ, ಹೂಯಾಂಗ್ ಅದರಲ್ಲಿ ಒಂದು ಸಮಸ್ಯೆಯನ್ನು ಕಾಣುತ್ತಾರೆ. ಇದು ಡೆವಲಪರ್ ಆಧುನಿಕ ನೆರವುಗಳಿಂದ ದೂರವಿದ್ದು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ ಅಥವಾ AI ಅನ್ನು ನಿಜವಾದ ಸಹಯೋಗಿಯಂತೆ ಬಳಸುವ ಬದಲು ಕೇವಲ ಒಂದು ಸುಧಾರಿತ ಸರ್ಚ್ ಇಂಜಿನ್ನಂತೆ ಬಳಸುತ್ತಿದ್ದಾರೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ.
ಇದು ಅಜಾಗರೂಕವಾಗಿ ಖರ್ಚು ಮಾಡಲು ನೀಡಿದ ಪರವಾನಗಿಯಲ್ಲ. ಇದು ಜ್ಞಾನಾತ್ಮಕ ಸಾಮರ್ಥ್ಯದ (load-bearing cognition) ಪರೀಕ್ಷೆಯಾಗಿದೆ. ಲಭ್ಯವಿರುವ ಅತ್ಯಂತ ಸಮರ್ಥ ಮಾಡೆಲ್ಗಳಿಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹೆಚ್ಚಿನ ಮಾನಸಿಕ ಶ್ರಮವನ್ನು ವಹಿಸಿಕೊಡಬೇಕು ಎಂಬುದು ಹೂಯಾಂಗ್ ಅವರ ಮೂಲ ಉದ್ದೇಶವಾಗಿದೆ. ಒಂದು ಮಾಡೆಲ್ ಇಡೀ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ತನ್ನ ಸಂದರ್ಭದಲ್ಲಿ (context) ಇಟ್ಟುಕೊಂಡಾಗ, ಹಿಂದೆ ಮೂರು ದಿನಗಳ ಕಾಲ ನಡೆಯುತ್ತಿದ್ದ ಡಿಬಗ್ಗಿಂಗ್ ಸೆಷನ್ಗಳು ಗಂಟೆಗಳೊಳಗೆ ಮುಗಿಯಬಹುದು. ರೀಸನಿಂಗ್ ಮಾಡೆಲ್ (reasoning model) ಬಳಸಿ ವೇಗವಾಗಿ ಪ್ರೊಟೊಟೈಪಿಂಗ್ ಮಾಡುವ ಮೂಲಕ, ಹಿಂದೆ ದೀರ್ಘ ಸಭೆಗಳ ಅಗತ್ಯವಿದ್ದ ಸಿಸ್ಟಮ್ ಡಿಸೈನ್ ಚರ್ಚೆಗಳನ್ನು ಸುಲಭವಾಗಿ ಬಗೆಹರಿಸಬಹುದು. ಹೂಯಾಂಗ್ ಅವರಿಗೆ, $250,000 ರ ಮಿತಿಯು ಬಜೆಟ್ನ ಮೇಲ್ಛಾವಣಿಯಲ್ಲ, ಬದಲಾಗಿ ಅದು ಒಂದು ತಳಮಟ್ಟವಾಗಿದೆ. ಒಬ್ಬ ಉನ್ನತ ಮಟ್ಟದ ಎಂಜಿನಿಯರ್ ಪೂರ್ಣ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅಗತ್ಯವಿರುವ ಕನಿಷ್ಠ ಬುದ್ಧಿಮತ್ತೆಯ ಸಹಾಯಧನವನ್ನು ಇದು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.
ಆ ಮಿತಿಗಿಂತ ಕೆಳಗೆ ಬರುವ ಡೆವಲಪರ್ಗಳು ಹೆಚ್ಚಿನ ಕೆಲಸವನ್ನು ತಾವೇ ಮಾಡುತ್ತಿದ್ದಾರೆ. ಅವರು ಬಗ್ಗಳನ್ನು (bugs) ಮ್ಯಾನುಯಲ್ ಆಗಿ ಪತ್ತೆಹಚ್ಚುತ್ತಾರೆ, ಬಾಯ್ಲರ್ಪ್ಲೇಟ್ ಕೋಡ್ ಅನ್ನು ಕೈಯಿಂದ ಬರೆಯುತ್ತಾರೆ ಮತ್ತು ಸರಿಯಾಗಿ ಪ್ರಾಂಪ್ಟ್ ಮಾಡಿದ ಮಾಡೆಲ್ ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಸಂಶ್ಲೇಷಿಸಬಹುದಾದ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಅನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಓದುತ್ತಾರೆ. ಇನ್ಫರೆನ್ಸ್ ವೆಚ್ಚಗಳು ಕಡಿಮೆಯಾಗುತ್ತಿರುವ ಮತ್ತು ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋಗಳು ವಿಸ್ತರಿಸುತ್ತಿರುವ ಈ ಯುಗದಲ್ಲಿ, ಟೋಕನ್ಗಳ ಉಳಿತಾಯವು ಶಿಸ್ತನ್ನು ತೋರಿಸುವುದಿಲ್ಲ, ಬದಲಾಗಿ ಅಧಿಯಳಿಕೆಯನ್ನು (underutilization) ಸೂಚಿಸುತ್ತದೆ. ತನ್ನ ಉತ್ಪಾದನೆಯನ್ನು ಹೆಚ್ಚಿಸಲು AI ಅನ್ನು ತೀವ್ರವಾಗಿ ಬಳಸಲು ವಿಫಲನಾಗುವ ಎಂಜಿನಿಯರ್, ಈ ತರ್ಕದ ಪ್ರಕಾರ, ಕಡಿಮೆ ಕಾರ್ಯಕ್ಷಮತೆ ಹೊಂದಿದ್ದಾರೆ ಎಂದರ್ಥ.
ಲಿವರೇಜ್ನ ಪ್ರಾದರ್ಶಕವಾಗಿ ಟೋಕನ್ಗಳು
ಸಾಂಪ್ರದಾಯಿಕ ಎಂಜಿನಿಯರಿಂಗ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ಗೆ ಭೌತಿಕ ಫಲಿತಾಂಶಗಳೆಂದರೆ ಇಷ್ಟ. ಕ್ಲೋಸ್ ಮಾಡಿದ Jira ಟಿಕೆಟ್ಗಳು, ಪುಶ್ ಮಾಡಿದ ಕಮಿಟ್ಗಳು (commits), ಶಿಪ್ ಮಾಡಿದ ಫೀಚರ್ಗಳು. ಈ ಸಂಖ್ಯೆಗಳು ಎಣಿಸಬಹುದಾದ ಕಾರಣ ಸುರಕ್ಷಿತವಾಗಿವೆ ಎಂದು ಅನಿಸುತ್ತವೆ. ಹೂಯಾಂಗ್ ಅವರ ಚೌಕಟ್ಟು ಇವುಗಳನ್ನು ಬಹುಪಾಲು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ಅವರ ತರ್ಕದ ಪ್ರಕಾರ, ಒಬ್ಬ ಸೀನಿಯರ್ ಸ್ಟಾಫ್ ಎಂಜಿನಿಯರ್ ಒಬ್ಬ ಮಿಡ್-ಲೆವೆಲ್ ಉದ್ಯೋಗಿಗಿಂತ ಕಡಿಮೆ ಕಮಿಟ್ಗಳನ್ನು ಮಾಡಬಹುದು, ಆದರೆ ಅವರು ಹೆಚ್ಚಿನ ಮೌಲ್ಯವನ್ನು ಸೃಷ್ಟಿಸಬಹುದು, ಏಕೆಂದರೆ ಅವರ ನಿಜವಾದ ಉತ್ಪನ್ನವೆಂದರೆ ನಿರ್ಧಾರಗಳು. ಆ ನಿರ್ಧಾರಗಳ ಲೆಡ್ಜರ್ ಆಗಿ ಟೋಕನ್ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.
ಒಬ್ಬ ಎಂಜಿನಿಯರ್ LLM ಇನ್ಫರೆನ್ಸ್ ಮೇಲೆ ಹೆಚ್ಚಿನ ಹಣ ವ್ಯಯಿಸಿದಾಗ, ಅವರು ಕೇವಲ ಪಠ್ಯ ಉತ್ಪಾದನೆಯನ್ನು ಖರೀದಿಸುತ್ತಿಲ್ಲ. ಅವರು ಸಮಾನಾಂತರವಾಗಿ ನಡೆಯುವ ಆಲೋಚನೆಯನ್ನು (parallelized thought) ಖರೀದಿಸುತ್ತಿದ್ದಾರೆ. $500,000 ಗಳಿಸುವ ಎಂಜಿನಿಯರ್ ಒಂದು ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಸಮಸ್ಯೆಗೆ ಬೃಹತ್ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋಗಳನ್ನು ಬಳಸಿದಾಗ, ಅವರು ಮೂಲಭೂತವಾಗಿ ಒಂದು ಡಜನ್ ಏಕಕಾಲಿಕ ಜ್ಞಾನಾತ್ಮಕ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಡೆಸುತ್ತಿದ್ದಾರೆ, ಮೈಕ್ರೋಸರ್ವಿಸ್ಗಳಲ್ಲಿ ಎಡ್ಜ್ ಕೇಸ್ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಕೇವಲ ಒಂದು ಸಾಲಿನ ಪ್ರೊಡಕ್ಷನ್ ಕೋಡ್ ಬರೆಯುವ ಮೊದಲೇ ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಅಸಂಮತಿಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದಾರೆ. ಟೋಕನ್ಗಳು ಸಂಬಳದ ಗಂಟೆಗಳನ್ನು ಸಂಕುಚಿತ ಫಲಿತಾಂಶಗಳಾಗಿ ಪರಿವರ್ತಿಸುತ್ತವೆ. ಅವು ವೇಗ, ಆರ್ಕಿಟೆಕ್ಚರಲ್ ದೂರದೃಷ್ಟಿ ಮತ್ತು ಡಿಬಗ್ಗಿಂಗ್ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಖರೀದಿಸುತ್ತವೆ, ಇಲ್ಲದಿದ್ದರೆ ಇವುಗಳಿಗೆ ನೂರಾರು ಗಂಟೆಗಳ ಮ್ಯಾನುಯಲ್ ಕೆಲಸ ಬೇಕಾಗುತ್ತಿತ್ತು.
ಇದು ಹಳೆಯ ಪ್ರೇರಣಾ ರಚನೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಎಂಜಿನಿಯರಿಂಗ್ ನಾಯಕರು ಐತಿಹಾಸಿಕವಾಗಿ ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟ್ ಡಿಸ್ಕೌಂಟ್ಗಳಿಗಾಗಿ ಕಠಿಣವಾಗಿ ಚೌಕಾಸಿ ಮಾಡುತ್ತಾರೆ ಮತ್ತು SaaS ಖರೀದಿಗಳನ್ನು ಕನಿಷ್ಠಗೊಳಿಸಬೇಕಾದ ವೆಚ್ಚದ ಕೇಂದ್ರವಾಗಿ ಪರಿಗಣಿಸುತ್ತಾರೆ. ಆದರೆ AI ವಿಷಯದಲ್ಲಿ ಅಂತಹ ಮನೋಭಾವವು ತಪ್ಪು ಎಂದು ಹೂಯಾಂಗ್ ಸೂಚಿಸುತ್ತಾರೆ. ಟೋಕನ್ ಬಜೆಟ್ ಪ್ರತಿಭೆಗೆ ಅನುಗುಣವಾಗಿ ಹೆಚ್ಚಾಗಬೇಕು. ನೀವು ದುಬಾರಿ ಮೆದುಳನ್ನು (talent) ನೇಮಿಸಿಕೊಳ್ಳುತ್ತೀರಿ ಮತ್ತು ನಂತರ ಅವರಿಗೆ ಅತ್ಯಂತ ದುಬಾರಿ ಮಾಡೆಲ್ಗಳನ್ನು ಬಳಸಲು ಬಿಡುವುದಿಲ್ಲವೆಂದರೆ, ನೀವು ಅವರನ್ನು ಮ್ಯಾನುಯಲ್ ಕೆಲಸಗಳಲ್ಲಿ ಸಿಲುಕಿಸುತ್ತೀರಿ. ಅವರು ಕೇವಲ ಹೆಚ್ಚಿನ ಬೆಲೆಯ ಟೈಪಿಸ್ಟ್ಗಳಾಗುತ್ತಾರೆ. ಹೂಯಾಂಗ್ ಸೂಚಿಸುವ ಗುರಿ ಎಂದರೆ 'ಬುದ್ಧಿಮತ್ತೆಯ ಸಾಂದ್ರತೆ' (intelligence density): ಅಂದರೆ ಮಾನವ ಗಂಟೆಗೆ ಗರಿಷ್ಠ ಅನ್ವಯಿಕ ಜ್ಞಾನಾತ್ಮಕ ಸಾಮರ್ಥ್ಯ, ಕ್ಲೌಡ್ ಬಿಲ್ ಮೊದಲ ನೋಟಕ್ಕೆ ಆತಂಕಕಾರಿಯಾಗಿ ಕಂಡರೂ ಸಹ. ಒಬ್ಬ ಎಂಜಿನಿಯರ್ ತನ್ನ ಹೆಚ್ಚಿನ ಸಂಭಾವನೆಯನ್ನು ಸಮರ್ಥಿಸಿಕೊಳ್ಳಲು ಸಾಕಷ್ಟು ಟೋಕನ್ಗಳನ್ನು ಬಳಸುತ್ತಿಲ್ಲದಿದ್ದರೆ, ಅವರು ಜ್ಞಾನಾತ್ಮಕ ಭಾರವನ್ನು AI ಗೆ ವಹಿಸಲು ವಿಫಲರಾಗುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಇದರಿಂದ ಸಂಸ್ಥೆಯ ಮೇಲೆ ತಮ್ಮ ಪ್ರಭಾವವನ್ನು ಸೀಮಿತಗೊಳಿಸುತ್ತಿದ್ದಾರೆ ಎಂದರ್ಥ.
ತಂಡವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ, ಕಂಪ್ಯೂಟ್ ಅನ್ನು ವಿಸ್ತರಿಸಿ
ಹೆಚ್ಚುತ್ತಿರುವ ಕಾರ್ಯಾಚರಣೆಯ ವೆಚ್ಚಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಸಿಬ್ಬಂದಿ ಪರಿಷ್ಕರಣೆಗಳಿಗೆ (headcount reviews) ಕಾರಣವಾಗುತ್ತವೆ. CFOಗಳು ಹೆಚ್ಚುತ್ತಿರುವ 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