Uber Quemó Todo su Presupuesto de IA 2026 en Cuatro Meses — Y el Tuyo Probablemente También Está Mal Armado
En abril, el CTO de Uber, Praveen Neppalli Naga, hizo una declaración que debería caerle pesado a cualquiera que esté al frente de un equipo de ingeniería: la empresa había quemado todo su presupuesto anual de herramientas de IA antes de que arrancara el segundo trimestre. Cuatro meses. Listo.
El culpable no fue el derroche. No fue experimentación irresponsable. Fue Claude Code y Cursor funcionando exactamente como se supone que tienen que funcionar.
El 95% de los ingenieros de Uber usa herramientas de IA todos los meses. El 70% del código comprometido viene de IA. El costo mensual de API por ingeniero osciló entre $500 y $2.000. El gasto total relacionado con IA creció aproximadamente 6× desde 2024. Las palabras del propio CTO: “de vuelta a cero” en materia de presupuesto de IA.
Estuve siguiendo cómo circuló esta historia — llegó a Hacker News hoy con casi 90 comentarios en la primera hora — y lo que me llama la atención no es el número del titular. Lo que me llama la atención es que casi todos los líderes de ingeniería que conozco van a leer esto y van a pensar “a nosotros no nos va a pasar”. Probablemente se equivoquen.
Por Qué el Modelo de Presupuesto Se Rompe
Las herramientas de software tradicionales escalan de forma predecible. Comprás X licencias, pagás Y por licencia, podés proyectarlo. Las herramientas de coding con IA no funcionan así.
El consumo de Claude Code escala con tres variables que los modelos tradicionales de procurement no contemplan: la complejidad del codebase, el tipo de tarea y la profundidad de adopción. Los repositorios más grandes requieren más contexto por operación. Las tareas agénticas de múltiples pasos queman tokens a una tasa completamente diferente que el autocompletado. Y la diferencia entre un desarrollador que lo usa para consultas rápidas y uno que corre sesiones autónomas completas es enorme.
Uber desplegó Claude Code en diciembre de 2025. El uso se duplicó en febrero. En abril, la curva había consumido el año entero. Eso no es un fallo de la herramienta — eso es lo que parece la adopción genuina. El error fue asumir que el viejo marco presupuestario iba a aguantar.
El thread de HN es ilustrativo. Un desarrollador reporta $400–$500 por día durante fases de desarrollo activo. Otro señala que en codebases grandes con frameworks personalizados, el consumo de tokens explota porque el modelo tiene que orientarse en territorio desconocido en cada sesión. Un tercero hace el cálculo que parece obvio en retrospectiva: un ingeniero de $160k anuales gastando $1k al mes en tokens que le sacan el trabajo mecánico de encima sigue siendo un negocio — si lo contabilizás bien. El problema es que casi nadie lo contabiliza bien de antemano.
Esto No Es Una Historia de Advertencia Sobre la IA. Es un Problema de Arquitectura Presupuestaria.
La mayoría de las coberturas lo enmarcan como una advertencia. Yo lo leo distinto.
Uber no quemó su presupuesto porque las herramientas de IA fallaron. Lo quemó porque esas herramientas entregaron suficiente valor como para que el 95% de su organización de ingeniería las adoptara con alta intensidad en pocos meses. Eso es un resultado extraordinario. La pregunta no es si usar estas herramientas. La pregunta es si tu modelo financiero refleja cómo se comportan realmente a escala.
Algunas cosas que rompen la lógica tradicional de procurement:
La intuición de licenciamiento por puesto no aplica. La varianza de uso entre ingenieros es enorme — algunos gastarán $200 al mes, otros $2.000, y ambos pueden estar completamente justificados según el trabajo que hacen.
“Presupuesto de IA” como línea presupuestaria es un error de categoría. Si el 70% de tu código comprometido viene de IA, eso no es un gasto en herramientas. Es un costo central de producción. Hay que modelarlo como infraestructura, no como una suscripción de software.
Las curvas de adopción son no lineales. Si armás un presupuesto para el mes uno y no construís techos dinámicos, vas a chocar contra la misma pared que Uber.
Lo Que Haría Diferente
Si hoy estuviera armando infraestructura de coding con IA para un equipo de ingeniería de cualquier tamaño relevante, esto es lo que construiría antes del día uno de despliegue amplio:
Observabilidad de costos primero. Instrumentá el seguimiento de gasto por ingeniero y por equipo antes de darle acceso a todos. La mayoría de las plataformas de API lo exponen — usalo.
Acceso escalonado por caso de uso. El prompting exploratorio y las sesiones agénticas críticas para producción deberían estar en niveles de costo diferentes, con umbrales de monitoreo distintos.
Ventanas de presupuesto rotativas, no anuales. Los presupuestos anuales de IA son una ficción. Armá revisiones trimestrales con datos reales de consumo incorporados.
Establecé un objetivo de costo por commit. Si la IA genera el 70% de tu código, sabé cuánto cuesta producir ese código. Esto conecta el gasto en IA con el output de ingeniería de una manera en que los CFOs pueden participar — y te da munición cuando necesitás ampliar el presupuesto.
La Variable LatAm
Para los equipos que operan en América Latina, este problema tiene una dimensión adicional. Los costos de API están denominados en dólares. Un equipo de 20 ingenieros en el punto medio del rango de $500–$2.000 quema entre $15.000 y $30.000 USD al mes. Ese número se ve muy diferente dependiendo de en qué moneda están denominados tus ingresos.
Esto no significa evitar las herramientas. Significa construir la arquitectura de gobernanza de costos antes del despliegue amplio — no después de haber chocado contra la pared.
Uber tenía $3.400 millones de dólares en gasto anual de I+D y aun así lo tomó por sorpresa. Para equipos que operan con márgenes más ajustados y costos denominados en dólares, ser tomado por sorpresa no es “volver a cero”. Es una crisis presupuestaria.
La Conclusión
Claude Code rompió el presupuesto de Uber porque fue genuinamente útil a escala. Esa es la historia.
Si estás planificando el despliegue de herramientas de IA para tu equipo en 2026 y todavía trabajás con un modelo mental de licenciamiento por puesto, construí primero la capa de observabilidad de costos. No porque las herramientas no funcionen — sino porque sí funcionan. Los equipos que lo hagan bien no van a estar evitando el gasto en IA. Van a estar midiéndolo como infraestructura y presupuestando en consecuencia.
Eso es una conversación distinta a la que la mayoría de las organizaciones todavía está teniendo.