Uber quema en 4 meses todo su presupuesto de IA de 2026 con Claude Code

• Uber agotó en solo 4 meses todo su presupuesto de IA para 2026 por la expansión del uso de Claude Code y Cursor, y lo que comenzó como un experimento de productividad llevó de inmediato a replantear el presupuesto
• El CTO de Uber señaló que el costo mensual de API por ingeniero estaba en un rango de 500 a 2,000 dólares, y que el 95% de los ingenieros ya usa herramientas de IA cada mes
• El 70% del código enviado a Uber provino de la IA, lo que muestra que las herramientas de programación con IA ya entraron al flujo central del trabajo de ingeniería
• Claude Code fue desplegado al equipo de ingeniería en diciembre de 2025, confirmó su capacidad para tareas de varios pasos y duplicó su uso para febrero de 2026; en abril ya había consumido todo el presupuesto anual
• Mientras el crecimiento de uso de Cursor se estancó, Claude Code se convirtió en la herramienta dominante, y Uber ahora debe recalcular el costo de sus herramientas de programación con IA dentro de su gasto anual de I+D de 3,400 millones de dólares

---

Expansión de la adopción y revisión del presupuesto

• Uber vio un aumento acelerado en el uso de Claude Code y Cursor, y pese al fuerte incremento de costos, los ingenieros perciben tanto valor en ambas herramientas que les resulta difícil dejar de usarlas
• En diciembre de 2025 se distribuyó el acceso a Claude Code al equipo de ingeniería, y tras comprobarse su capacidad para tareas de varios pasos, su uso se duplicó para febrero de 2026
• En abril de 2026, el costo consumió todo el presupuesto anual de IA, dejando al liderazgo ante una decisión que no esperaba tomar
• El CTO de Uber dijo que la empresa llevó la planeación de su presupuesto de IA “back to the drawing board”

Cambios de uso por herramienta

• Cursor era otra herramienta importante en la competencia por adopción, pero el crecimiento de su uso se estancó
• Claude Code se convirtió en la herramienta dominante dentro del flujo de trabajo de ingeniería
• Lo que comenzó como un experimento de productividad se expandió con rapidez, consolidando el uso de herramientas de IA en el trabajo interno de ingeniería de la empresa

Lo que implica la presión de costos

• El agotamiento inesperado del presupuesto de Uber muestra qué tan valiosas se perciben las herramientas de IA para la productividad en ingeniería
• El papel de estas herramientas ha crecido hasta el punto de que limitar el acceso incluso puede sentirse contraproducente
• A medida que más desarrolladores adopten Claude Code, es posible que otras empresas enfrenten impactos similares
• Las empresas de software enfrentarán presión para administrar costos mientras mantienen la velocidad de desarrollo
• Si las herramientas de productividad para desarrolladores resultaron tan valiosas que los ingenieros agotaron todo el presupuesto en 4 meses, la conclusión es que el problema no era la herramienta en sí, sino que el presupuesto se definió demasiado pronto como para anticipar la curva de adopción

[picopress]

Qué manera de derrochar.

[GN⁺]

Opiniones de Hacker News

• Cuando reviso los gastos de la empresa una vez al mes más o menos, me confunde ver que cada vez más gente gasta $1k al mes en tokens y no entiendo cómo lo logran
  Uso LLM todos los días, e incluso usando los modelos más caros con modo de razonamiento profundo, normalmente el tope está entre $200 y $400. No es que sea un ludita que se opone al uso en sí, sino que me cuesta entender cómo se puede quemar responsablemente tanto al mes. Me gustaría ver a alguien que gasta $5k~$10k al mes mostrar cómo eso se convierte en un valor de $50k~$100k. Desde la perspectiva de una empresa, me parece mejor contratar a un ingeniero junior que use $100~$200/mes y sea productivo, en vez de justificar un gasto anual de $100k en tokens

  • Parece que hay básicamente tres casos en los que se quema ese dinero “responsablemente”. Los principiantes no crean compresión de contexto ni checkpoints de resumen por reutilizar conversaciones largas, y siguen arrastrando una única conversación gigantesca porque sienten que el agente ya fue “entrenado”
    Los intermedios descubren patrones como “lanza 5 subagentes para que analicen la solución desde distintos ángulos y la resuman” y es fácil volverse adicto a eso. No es un mal hábito en sí, pero si no tienes cuidado te pasas muchísimo de créditos. Los avanzados pueden estar ejecutando 10 árboles de tareas en paralelo todo el tiempo, saltando entre respuestas de agentes y haciendo multitarea extrema, así que el costo puede crecer exponencialmente
  • Primero está la razón obvia: “si la empresa lo permite, la gente desperdicia”. Eso incluye no limpiar ni comprimir el contexto con frecuencia. La ventana de contexto de 1M de Opus ya existe, y hasta 200K la calidad sigue siendo bastante buena, así que antes de vaciarla se queman muchos tokens en cada consulta
    También influye mucho si el codebase es grande o el problema es complejo. Si eres nuevo en el equipo y hay muchas partes que no conoces, cuando te asignan trabajo haces que Claude encuentre el código relevante, entienda el flujo existente y recién entonces intente cambiarlo. Se acumula menos conocimiento propio, pero con Claude puedes terminar en 1 día algo que tomaría 5, y si todos hacen eso no puedes quedarte atrás. Por eso tomo una ruta intermedia: terminar en 2~3 días en vez de 1, pero mirando algo del código. En especial porque con AI la velocidad de cambio del código es brutal, hasta hice herramientas para que el LLM explique en profundidad los pull requests. No es para revisar, sino para seguir el trabajo del equipo. Todavía ni siquiera he pensado mucho más en cómo usar mejor los LLM, y si estuviera más familiarizado con el codebase probablemente lo usaría mucho más. El cuello de botella sigue siendo hacer pruebas y revisión adecuadas. En código interno menos importante o en proyectos personales, siento que casi se lo dejo todo a la AI, y si usas la skill “superpowers” se queman muchos tokens incluso para funciones básicas. Normalmente empiezas en 20~40K tokens y al final llegas a 80~90K, así que varias solicitudes justo antes de terminar básicamente están enviando 80K tokens. Es un desperdicio, pero si otro paga, pasa eso
  • He visto a Claude Code elegir soluciones absurdamente ineficientes en tokens para ciertos problemas. Dividimos un problema complejo de machine learning/predicción entre varios agentes, y cada agente usaba, ejecutaba y leía notebooks de Jupyter
    Al principio iba bien, pero un agente escribió cientos de miles de filas en la salida de una celda y generó un archivo ipynb de 500MB; luego Claude intentó leerlo varias veces y se comió todo el límite de contexto. La solución fue definir una mejor estructura de trabajo con scripts de análisis por CLI y carpetas para guardar resultados de investigación, pero yo, como operador, tuve que hacer la planeación y el diseño. Me cuesta ver a la gente que gasta $10k al mes en tokens como otra cosa que personas resolviendo problemas de forma perezosa con Claude Code como un martillo carísimo. Por ejemplo, hacer que Claude lea todos los correos cada día, cuando la solución más inteligente sería primero quitar ruido del HTML de esos correos
  • Depende muchísimo del repositorio en el que estés trabajando. Si es enorme y, sobre todo, si tienes que consultar documentación de frameworks y APIs personalizados con muchas herramientas, necesitas una ventana de contexto grande y los tokens se consumen mucho más rápido
    En cambio, si es pequeño o usa frameworks comunes en los que el modelo ya fue entrenado, puedes hacer mucho con una ventana de contexto más pequeña y el uso de tokens baja muchísimo
  • Más que el costo, tampoco entiendo el tema del cupo. Tengo el plan de 200 euros de ChatGPT, así que supongo que es el mayor cupo, y aun usando el modelo más caro, el máximo razonamiento y modo rápido, programando con agentes casi todo el día, no me acerco al límite
    Desde que empecé a usar agentes de código, la única vez que estuve cerca del límite fue haciendo desarrollo multiplataforma al mismo tiempo en 3 computadoras bajo las mismas condiciones, y aun así solo me acerqué al límite semanal. Normalmente bajo a cerca del 20% del límite, pero casi nunca menos que eso. Hasta por diversión estoy lanzando muchos prompts y consultas, y aun así no sé cómo gastar más

• Ya sé que le estoy respondiendo a la AI ahora mismo, pero eso de “averiguar si la empresa puede sostener este nivel de productividad a escala” suena raro. Si realmente fuera productivo, aumentaría los ingresos y la pregunta de si es sostenible ni siquiera existiría

  • Exacto. Productividad, por definición, produce algo, idealmente algo valioso. Lo que hay que ver es si el costo adicional en chatbots genera suficiente valor. La duda es si Uber se volvió dramáticamente más eficiente y efectiva gracias a este enorme sobrepresupuesto, o si solo les dio a las personas una forma brillante y cara de mover el mismo trabajo de siempre
  • Los ingresos sí aumentaron. Si ves los resultados recientes de Meta, incluso en esta economía están en +33% de ingresos. La sostenibilidad no es el problema, y hay una razón por la que a empresas como Meta no les importa que un ingeniero gaste $1k al día en tokens. Comparado con lo que genera cada empleado, no es tanto dinero
  • No todos los cambios que hace un desarrollador aumentan ingresos, y aun los que sí lo hacen suelen tener desfase temporal
  • Dándole la mejor lectura posible al argumento contrario, un contraejemplo sería que los competidores usen las mismas herramientas y obtengan las mismas mejoras de productividad
  • Bien usado, sí es extremadamente productivo. De hecho me preocupa lo inteligentes que podrían volverse estos modelos de AI similares el próximo año

• Eso de que “el 95% de los ingenieros de Uber ya usa herramientas de AI cada mes, y el 70% del código comiteado viene de AI” era esperable. Cuando el uso de herramientas de AI se incorpora a la evaluación de desempeño, pasa eso

  • Sorprende lo fácil que la gente subestima cuánto se puede manipular esto cuando no desarrolladores imponen KPI a desarrolladores. Da igual si es AI o contar pull requests/líneas
  • En el momento en que el KPI deja de ser “¿qué lanzaste?” y pasa a ser “¿cuánto AI usaste?”, el desborde de presupuesto viene por sí solo. La gente va a intentar cumplir el número
  • Si managers y vicepresidentes les dicen a todos “si no usas AI, no puedes trabajar aquí”, entonces claro que la gente la va a usar
  • No termino de entender esta crítica. ¿No se supone que te pagan justamente por hacer lo que la empresa quiere y considera productivo? Y también me pregunto si asumen que todo el código generado por AI es inútil

• No entiendo la parte de “averiguar si la empresa puede sostener este nivel de productividad a escala”. Ya se gastó el presupuesto y hay 4 meses de datos; la clave es qué resultados pueden mostrar
  No soy hater de la AI ni ludita, uso el plan Max de $200. Pero, ¿están diciendo que Uber abrió esta herramienta, animó a todos a usarla y ahora que funcionó bien están confundidos por lo que pasó? Otra cosa distinta es concluir que la productividad por costo no da. Hasta me pregunto si ya se quedaron sin cosas nuevas para construir

  • Los planes Max para uso personal y Teams son una ganga impresionante comparados con el costo por uso vía API de Enterprise. Supongo que necesitaban funciones de Enterprise. Si no, podían simplemente reembolsarles a los usuarios la suscripción Max de $200. Las empresas, al final, actúan como empresas
  • Puede que todavía no se vea nada. Los cambios grandes visibles para usuarios externos tardan mucho más en desplegarse ampliamente. Internamente, varias funciones probablemente avanzaron más rápido
    En Salesforce también vi cambios donde cosas que tomaban semanas parecían hacerse en días. Eso no se convierte de inmediato en dinero, pero sí aumenta el potencial de ganarlo
  • También vale preguntar qué más le queda por construir a Uber. Ya tienen la plataforma de viajes y funciona. También se expandieron a entrega de comida, supermercado y “cualquier cosa que quepa en un auto”. No sé qué más queda en el ámbito de alguien conduciendo un auto
  • Si los mecanismos para controlar el gasto son buenos, no entiendo por qué no pusieron un tope. También podían exigir a los ingenieros justificar ese gasto
    Hay que preguntar por qué necesitan usar tantos tokens y qué obtienen a cambio. Si esto fuera AWS, todos estarían señalando “¿no viste el gasto mensual?”
  • Siento que la discusión sobre AI ya llegó al punto en que, para que cualquier crítica no sea tratada como herejía, primero hay que decir “yo también soy miembro del culto, no un incrédulo”

• Es interesante cómo cuando salen artículos así, de repente mucha gente cree que medir la productividad de desarrollo es simple. Es cierto que la productividad puede traducirse en ingresos o ahorro de costos, y que los ingresos se pueden medir, pero no es tan sencillo
  Gastas dinero hoy para crear funciones que generen ingresos futuros, así que aunque hoy suba mucho el costo, todavía no hay ingresos que medir. Si con AI terminaste una función hoy, no puedes decir de inmediato que la AI fue productiva o improductiva; tienes que estimar qué habrías hecho sin AI y qué ingresos habría habido entonces. Los negocios muchas veces son una carrera de la Reina Roja, donde si no mejoras terminas perdiendo ingresos frente a la competencia. Es muy probable que el uso de AI mezcle trabajo importante con “como ahora es fácil, probemos de todo”, y para medir la mejora real de productividad hay que aprender a quedarse con lo primero y evitar lo segundo. No se trata de estar a favor o en contra de la AI, sino de no decir perezosamente “si es productivo, se podrá medir”

  • Yo diría que el consenso principal es más bien que medir la productividad del desarrollador es muy difícil. Cada vez que intentas medirla, esa métrica se convierte en el objetivo y, aunque originalmente fuera sólida, deja de significar algo
    No sé de dónde salió la idea de que medir la productividad de personas que no son obreros de fábrica sea fácil
  • No creo que nuevas funciones o mejor software vayan a aumentar mucho los ingresos/ganancias de Uber
  • La alternativa no es solo productividad cero o algo de productividad; también puede haber productividad negativa. Por mi experiencia usando Claude Code, sospecho porque meterle tantos tokens a una organización no solo puede ser improductivo, sino activamente dañino
  • Los cambios pequeños en productividad son difíciles de medir, pero un salto grande se habría visto claramente. Si la AI está afectando la productividad, parece ser como mucho en una medida pequeña
  • Si fuera 10x de productividad, se habría podido medir al menos indirectamente; de hecho sería imposible no medirlo. Las afirmaciones iniciales eran claramente falsas, y la verdadera pregunta de investigación es si es mayor que 1.0x
    Estoy de acuerdo en que eso es muy difícil de medir. Pero considerando este costo, sí o sí tendría que poder responderse, y además el multiplicador tendría que justificar el gasto

• Según [1], la organización de ingeniería de Uber tiene unas 5,500 personas. Si tomamos el punto medio del rango de gasto como $1,250, el gasto de AI en ingeniería sería de unos $6.8M, con un rango de $2.75M~$12M. El artículo dice que el gasto en R&D fue de $3.4B
  El gasto en AI no es una parte grande del gasto de R&D. En 4 meses sería 0.3%, anualizado cerca de 1%. Si no estaba planeado, no es cambio suelto en el presupuesto, pero en contexto tampoco es enorme. La verdadera pregunta es qué se obtuvo con ese monto. El artículo afirma que el 70% de los commits de código son generados por AI, así que probablemente pasaron revisión y pruebas. Lo importante es si aumentó la velocidad de entrega de funciones, si hubo menos problemas de calidad o si aparecieron otros beneficios. Lamentablemente el artículo no dice nada sobre resultados más allá del aumento de gasto. Tal vez 4 meses sea demasiado pronto para evaluar beneficios. Aunque en el mundo ágil quizá se vería distinto. [1] https://www.unifygtm.com/insights-headcount/uber

  • La fuente real https://www.theinformation.com/newsletters/applied-ai/uber-c... dice que “aproximadamente 11% de las actualizaciones reales de código en vivo en sistemas backend están siendo escritas por agentes de AI construidos principalmente con Claude Code, frente a una fracción menor al 1% hace tres meses”
    También dice que “no reveló cifras exactas del presupuesto de software de la empresa ni del gasto en herramientas de coding con AI”
  • Todo en este artículo parece pura invención. Los números no cuadran, no coincide con la información reportada y simplemente parece ficción

• Como alguien que bootstrappea, muchas veces envidio a los ingenieros de grandes empresas, pero también me preocupa que los incentivos estén rotos
  Si yo fuera ingeniero en Uber, no tendría ninguna razón para no poner algo como gpt 5.5 pro @ very high thinking + fast mode en el prompt incluso para cambios pequeños. No hay incentivo para no usar el modelo más potente y, por lo tanto, más caro. Probé un prompt así en una prueba de conversión de imagen a HTML y ese solo prompt costó $40. Si lo pagara yo mismo, casi nunca usaría esa configuración, pero en una gran empresa, si otro paga, la usaría seguido. El resultado sí fue claramente mejor. A los ingenieros se les evalúa por lo que entregan, no por el costo del proceso. Hay maneras de hacerlo más barato, pero no tienen incentivo para hacerlo

  • Los ingenieros de software son caros. El salario medio es de $133k, y eso sin contar seguro médico, impuestos de nómina, etc. Si con $40 de créditos LLM puedes ahorrarte 1 hora de tiempo de desarrollo, entonces en papel es $26.50 más barato que no usarlo
    Todavía no estoy convencido de que así funcione en la práctica, pero la teoría sería esa. Y tratar de bajar el costo del LLM también es un arma de doble filo. El ahorro en LLM tendría que ser mayor que lo que cuesta esa persona. Si pasas un día entero reduciendo $1 por llamada, tardarías casi 2 años en recuperar eso solo en costo salarial. Además, los LLM cambian tan rápido que es difícil confiar en que esa solución no se rompa antes de 2 años. Nadie sabe si en 2 años seguirás haciendo llamadas a herramientas, si seguirá existiendo el modo de razonamiento, ni siquiera el proveedor de frontera lo sabe
  • Puede que la empresa primero quiera ver qué tan rápido puede escalar el trabajo y luego quiera recortar para ganar eficiencia
  • Imagen→HTML es una tarea bastante compleja. En la práctica es trabajo de frontend, y con $40 ni siquiera compras 1 hora de uno de esos desarrolladores

• Mientras más común se vuelva que la gerencia piense que puede reemplazar la ingeniería de software con agentes, más me pregunto si no están tomando decisiones basadas en una visión poco realista del ingeniero de software promedio
  Por un lado, está el tema de que obtienes lo que pones. Un CTO brillante puede entusiasmarse muchísimo con lo que se puede hacer con agentes y asumir equivocadamente que todos los ingenieros pueden hacer lo mismo. En realidad, puede que el ingeniero promedio de la organización ni siquiera tenga la creatividad para imaginar dónde podría recortar trabajo. Así que si obligas el uso de agentes, puede que la productividad no suba y solo aumente el gasto en AI. Por otro lado, usar AI vuelve más visibles dos brechas: quién le va a decir a los agentes qué hacer, y cómo se va a absorber el ciclo de QA/revisión. En muchas organizaciones, las personas de producto no son lo bastante técnicas como para crear especificaciones o planes detallados que un LLM pueda usar, y los desarrolladores engrane tampoco están en posición de escribir especificaciones porque solo quieren implementar. Si además esperas que los desarrolladores que usan agentes también implementen, podrías terminar con más gente ociosa esperando a que les llegue trabajo. Estoy a favor de una adopción selectiva de LLM que mejore la velocidad y calidad de los desarrolladores existentes, pero la corriente de “reorganicemos toda la empresa” me parece bastante peligrosa, especialmente en empresas medianas y pequeñas

  • Más allá de eso, la AI es un amplificador de fuerza y no le importa si esa fuerza es positiva o negativa. Si alguien con malos principios de ingeniería de software usa AI, puede convertir todo en un caos total en muy poco tiempo
  • Sobre el punto 2, en nuestra empresa estamos empujando fuerte para que los desarrolladores tengan mentalidad de producto y sean menos engranes simples
    Yo mismo probablemente estoy sesgado porque tengo más mentalidad de producto que otros desarrolladores, pero creo que esa gente está mejor posicionada para ser más productiva con agentes. Porque saben suficiente de tecnología para implementar con agentes y suficiente de producto para saber qué hay que implementar. Espero que otras empresas sigan ese camino
  • Al final, eso equivale a hablar de una reducción masiva de personal

• No tengo idea de qué está desarrollando Uber. Ya tienen la app y el backend de asignación de autos, y ambos funcionan razonablemente bien. Me pregunto por qué gastan tanto
  Como ya abandonaron la conducción autónoma, no debe ser por eso

  • Esa es de verdad una pregunta muy subestimada. Muestra bien qué tanto están haciendo las empresas tecnológicas modernas con todos esos recursos. Elon redujo la mayor parte del equipo de Twitter y, después de los tropiezos horribles del inicio, ¿no terminó funcionando casi bien con 80% menos personal?
  • Sería bueno que “ambos funcionan razonablemente bien”, pero no es así. La experiencia de usuario empeoró tanto por la optimización del algoritmo de matching que ahora uso Lyft con regularidad
  • Este tipo de comentario de “X solo es Y, ¿por qué es tan complicado?” es de lo más trillado en HN. Escribir eso en cada artículo sobre una gran empresa que no te gusta es flojo y aburrido de leer

• Con tokens por API, sobre todo si usas contexto de 1M y no limpias con cuidado el contexto viejo, es facilísimo quemar cientos de dólares en una sola sesión
  Al mismo tiempo, las suscripciones permiten ese mismo nivel de uso por unos cientos de dólares al mes. Parece que Anthropic les cobra carísimo a los usuarios de API, o subsidia fuertemente las suscripciones, o ambas cosas

  • https://www.forbes.com/sites/annatong/2026/03/05/cursor-goes...
    “Cursor estimó el año pasado que una suscripción mensual de Claude Code de $200 permitía usar hasta $2,000 en cómputo, lo que sugería un subsidio considerable por parte de Anthropic. Ahora ese subsidio parece todavía más agresivo, con un plan de $200 que permite consumir alrededor de $5,000 en cómputo”
  • Anthropic tiene un modelo de negocio bastante “interesante”. Mientras tienes 150 empleados o menos, te cobra precio de suscripción; en el momento en que llegas a 151, de la noche a la mañana todos los empleados pasan a pagar precio de API y la factura total se multiplica de inmediato
    Es la táctica de engancharte con tokens baratos y luego recuperar cuando escalas. Uber seguramente negocia descuento sobre lista, pero no estará ni cerca del precio de suscripción para equipos de 150 o menos
  • Revisé los precios, pero no pude justificar el salto de Team a Enterprise. Cuando te pasas a Enterprise, la suscripción mensual desaparece por completo y pierdes la capacidad de controlar costos
    Puedes poner topes por usuario, pero sin un tope móvil mensual terminas en una situación en la que tienes que decirle a alguien del equipo “el resto de este mes, sin AI”. Con la estructura actual, me parece un trato bastante arriesgado