La factura anual de los tokens de IA está empezando a rivalizar con la nómina de ingeniería en algunas empresas, y el liderazgo no sabe si celebrar o entrar en pánico. Las empresas han pasado los últimos años inyectando capital en modelos de lenguaje de gran tamaño, esperando que una inferencia más barata se tradujera automáticamente en plantillas más pequeñas y ciclos de entrega más rápidos. En cambio, muchas organizaciones de ingeniería se encuentran pagando dos veces: una por el talento que esperaban aumentar, y otra por la capacidad de cómputo que se suponía que los reemplazaría. La pregunta ya no es si la IA puede escribir código. Es si el código que escribe justifica la fortuna que se está quemando para producirlo.
El punto de referencia del medio salario
Jensen Huang expuso las matemáticas de forma tajante al cierre de GTC 2026, hablando en el All-In Podcast. El CEO de Nvidia propuso medir la eficiencia de un ingeniero comparando su salario directamente con su consumo de tokens de IA. Su umbral fue contundente. Tomemos a un ingeniero de software que gana 500.000 dólares al año. Si ese ingeniero utiliza menos de 250.000 dólares en tokens anualmente, aproximadamente la mitad de su salario, Huang lo considera una señal de advertencia. El liderazgo debería estar "profundamente alarmado", en sus palabras, no porque la empresa esté gastando demasiado en personas, sino porque es probable que las esté subutilizando.
La lógica invierte la mentalidad tradicional de control de costes. Durante años, los equipos financieros trataron el cómputo como un gasto variable que debía minimizarse. Huang argumenta lo contrario. Un ingeniero caro que apenas toca un modelo es un ingeniero caro operando sin un multiplicador de fuerza. La expectativa es que el talento de alto coste actúe como un embudo, impulsando enormes volúmenes de trabajo a través de sistemas de IA, revisando el resultado y orquestando los resultados. Un bajo gasto en tokens no indica ahorro. Indica que el humano todavía está realizando el trabajo mecánico que un modelo podría haber gestionado.
Cómo se ve ese gasto en la práctica
Para entender por qué este punto de referencia es importante, considere lo que representan realmente 250.000 dólares en tokens. Con las tasas actuales de los modelos de frontera, no se trata de unas pocas sugerencias de autocompletado. Son millones de tokens procesados cada día laborable en una amplia gama de tareas. Sugiere un ingeniero que no se limita a aceptar las completaciones del editor, sino que está realizando un razonamiento arquitectónico extenso, refactorización masiva mediante agentes inteligentes, canales de pruebas automatizadas, generación de datos sintéticos y exploración de diseño iterativo.
Un ingeniero sénior que trabaje de esta manera podría encadenar múltiples llamadas al modelo para una sola funcionalidad: generar la estructura inicial (scaffolding), analizar dependencias para detectar cambios disruptivos, simular comportamientos en casos límite y producir documentación en paralelo. El rendimiento es masivo porque el humano ya no está escribiendo cada línea. Está dirigiendo. Para Huang, el salario se justifica solo cuando el humano opera a esa escala, multiplicando su producción mediante una interacción constante con el modelo.
Dónde se pierden los rendimientos
A pesar de esta visión, la industria se enfrenta a una brecha cada vez mayor entre el gasto en infraestructura y los resultados entregados. Las empresas se han precipitado hacia estrategias con un uso intensivo de tokens, contratando servicios empresariales con proveedores de IA y adaptando sus canales de desarrollo en torno a herramientas generativas. El gasto de capital ha sido asombroso. Los rendimientos de productividad, para muchos, han sido decepcionantes.
Los desarrolladores son, de hecho, más rápidos en las tareas aburridas. El código repetitivo (boilerplate), los esqueletos de pruebas unitarias y las operaciones CRUD repetitivas avanzan rápidamente cuando un modelo genera el primer borrador. Pero la ingeniería de software nunca se trató realmente de la velocidad de escritura. El trabajo duro y costoso reside en mantener sistemas complejos, razonar sobre modos de fallo distribuidos, garantizar la seguridad en dependencias por capas y gestionar la deuda técnica que cada atajo acumula. Estos