¿Necesita cada funcionalidad que desarrollamos con IA un presupuesto de tokens?

En abril, Praveen Neppalli Naga, CTO de Uber, admitió que la compañía había agotado por completo su presupuesto de IA para 2026. El principal impulsor fue Claude Code, cuya adopción pasó del 32 % al 84 % entre los 5.000 ingenieros de Uber en apenas cuatro meses. Los usuarios más intensivos gastaban entre 500 y 2.000 dólares al mes en costes de API. Naga declaró a The Information que estaba "volviendo a empezar" en materia de presupuestación de IA.

Quizá lo más llamativo de esta historia es que Uber no es una excepción. En Meta, por ejemplo, una clasificación interna convirtió el consumo de tokens en un símbolo de estatus. Según se informa, empleados competían por alcanzar el rango de "Token Legend". En un periodo de 30 días, el personal de Meta consumió 60,2 billones de tokens, una cifra que tendría un coste aproximado de 900 millones de dólares. Existen historias similares en Microsoft y Salesforce. En conjunto, estamos entrando en una era que Gergely Orosz ha denominado tokenmaxxing: un consumo ostentoso de capacidad de cómputo convertido en una especie de símbolo de estatus.

Estimar el valor y establecer un presupuesto

La solución no pasa por nuevas herramientas. En cambio, debemos tratar cada funcionalidad como algo que tiene un valor y un presupuesto a lo largo de toda su vida útil. Esa estimación de valor y ese presupuesto deberían ser visibles antes de que comience el trabajo, aunque puedan cambiar o evolucionar con el tiempo.

En un contexto de IA, debemos pensar en términos de un presupuesto de tokens para cada funcionalidad. Este debería responder tres preguntas:

• Presupuesto de desarrollo. ¿Cuántos tokens y cuánto esfuerzo de ingeniería harán falta para ponerla en producción?

• Presupuesto de operación. ¿Cuánto cuesta por invocación, por usuario y por mes al volumen esperado? 

• Presupuesto de mantenimiento. ¿Cuánto cuesta mantenerla funcionando a medida que cambian los modelos, evolucionan los prompts y se modifican las dependencias? Hay que recordar que es probable que se construyan nuevas funcionalidades sobre esta.

Este último es el aspecto en el que los equipos suelen invertir menos. Los modelos se deprecian, cambian los precios de los proveedores y las evaluaciones deben volver a ejecutarse cada vez que algo aguas arriba se modifica. Son factores que las estimaciones basadas en puntos de historia no suelen contemplar.

Impulsado por hipótesis, no por tecnología

Un presupuesto solo es útil si se está dispuesto a gastarlo en las cosas correctas y a no gastarlo en las equivocadas. Formular la estimación de valor como una hipótesis permite experimentar de forma más rigurosa.

La mayoría de los procesos de desarrollo de funcionalidades en las empresas no están impulsados por hipótesis, sino por opiniones, y normalmente pesa más la opinión de quien ocupa el cargo más alto en la sala. Esto funcionaba, aunque no demasiado bien, cuando el coste marginal de una funcionalidad era principalmente el salario de desarrolladores. Se convierte en un riesgo financiero cuando el coste marginal incluye una factura de API basada en consumo y una cola indefinida de mantenimiento. Con herramientas de programación impulsadas por IA es posible crear una aplicación heredada en un solo día.

Sí, es cierto que la IA acelera la fase de construcción, pero no acelera descubrir si alguien realmente quiere lo que se ha construido. En última instancia, debemos asumir que el cuello de botella se ha desplazado hacia la comprensión del impacto del producto. Y conviene recordar que se trata de cálculos aproximados, no de un problema de investigación en sí mismo.

El software siempre ha tenido un problema de mantenimiento

Aunque las organizaciones suelen estimar razonablemente bien el coste de desarrollar una funcionalidad, a menudo calculan mal cuánto cuesta mantenerla viva. Como resultado, las aplicaciones empresariales terminan llenas de capacidades agradables de tener que nunca fueron rentables, sostenidas por un pequeño núcleo que sí genera ingresos. Las empresas olvidan que cada funcionalidad en una base de código empresarial tiene un coste operativo: servidores, guardias, parches de seguridad y la carga cognitiva de añadir un elemento más al sistema.

La IA agrava este problema. El coste marginal de ejecutar nuevas funcionalidades es variable y aumenta con el uso, en lugar de depender del tamaño de la infraestructura. Un bucle de agentes mal definido puede consumir silenciosamente miles de dólares antes de que alguien lo detecte. La situación recuerda a Fantasía de Disney: en este caso, las escobas están funcionando sobre el clúster de GPU de otra persona.

Presupuestar tokens en la práctica

Afortunadamente, hay medidas que pueden tomarse. Un equipo que adopte presupuestos para funcionalidades puede empezar de forma gradual:

• Asignar un presupuesto de tokens a cada ticket y funcionalidad, junto con la estimación habitual.
• Diferenciar entre presupuesto de desarrollo, operación y mantenimiento, y realizar seguimiento de los tres.
• Vincular la asignación presupuestaria a una hipótesis explícita y, preferiblemente, a una forma económica de validarla.
• Implementar mecanismos de protección para que un agente fuera de control sea detectado en minutos y no al final del mes. La experiencia de Shopify con interruptores de seguridad y paneles de uso resulta ilustrativa.
• Negarse a financiar funcionalidades cuyo presupuesto operativo supere su valor potencial para el negocio, incluso si el presupuesto de desarrollo es bajo.

Esto no consiste en ahorrar por ahorrar; la situación de Uber es interesante precisamente porque las herramientas eran demasiado valiosas como para desconectarlas. La cuestión es saber qué funcionalidades merecen la factura antes de que llegue y reconocer que algunas de las más caras del portafolio serán aquellas que nadie pidió nunca.

¿Qué sigue?

Por ahora, la pregunta es suficiente y merece más consideración y reflexión en los próximos meses: ¿debería cada funcionalidad tener un presupuesto de tokens? O, dicho de otra manera, si no puedes decir qué ingresos generará una funcionalidad y cuánto debería costar ejecutarla y mantenerla, ¿realmente sabes lo suficiente como para construirla?

Por último, conviene recordar la Ley de Goodhart: cuando una medida se convierte en un objetivo, deja de ser una buena medida. Será interesante observar cómo evoluciona esta situación, ya que terminará definiendo la forma que adoptará el desarrollo de software asistido por IA y el desarrollo de software agéntico en el futuro.