El presupuesto que el éxito reventó

El director de tecnología de Uber, Praveen Neppalli Naga, dio a The Information la cifra que debería frenar a cualquier propietario a mitad de frase: la empresa había gastado todo su presupuesto planeado de programación con IA de 2026 en cuatro meses. Uber había desplegado la herramienta entre unos 5.000 ingenieros en diciembre de 2025, y la adopción subió del 32 por ciento de los ingenieros en febrero al 84 por ciento clasificados como usuarios agénticos intensivos en marzo de 2026. Para la primavera, los informes situaban el coste mensual por ingeniero entre 150 y 250 dólares de media y entre 500 y 2.000 dólares para los usuarios más intensivos. Nada había salido mal. La herramienta funcionaba, los ingenieros la usaban, y usarla fue lo que vació el presupuesto.

El mismo patrón apareció en Microsoft. Varios informes, encabezados por The Verge, describen que Microsoft corta la mayor parte del acceso interno a Claude Code en su división Experiences and Devices - el grupo detrás de Windows, Microsoft 365, Outlook, Teams y Surface - para el 30 de junio de 2026, trasladando a los ingenieros a GitHub Copilot CLI. El encuadre oficial es la unificación de herramientas, pero los informes son claros sobre el motivo: con precios por consumo, el uso intensivo de una herramienta de programación con agentes revienta el presupuesto anual, porque la herramienta se mide por tokens consumidos, no por asientos ocupados. Cuanto mejor funciona, más se usa, y cuanto más se usa, más alta es la factura.

Por qué importa: es un error de tasa base, no de herramienta

Por qué importa: el error no es elegir la herramienta equivocada. Es presupuestar una herramienta nueva con la tasa base antigua. Las empresas pusieron precio a la programación con IA como si fuera un autocompletado barato - un pequeño coste por asiento que apenas se mueve con el uso. Las herramientas con agentes rompen ese supuesto porque ejecutan ciclos de razonamiento continuos, y están tarifadas para ello: el coste escala con cuánto trabajo hace la herramienta, es decir, con lo exitoso que es el despliegue. Quien presupuesta el piloto - un puñado de ingenieros curiosos con consultas ligeras - modela la tasa base equivocada para una herramienta cuya propuesta de valor es que todos la usarán constantemente.

Sí, pero: esto no es un argumento de que la IA con agentes sea demasiado cara para usarla. Uber la sigue desplegando, y la productividad es real - para la primavera, cerca del 70 por ciento del código confirmado de Uber provenía de herramientas de IA. El punto es más concreto: el precio por consumo convierte la adopción en una curva de coste, y el caso de éxito, no el piloto, es el que tiene que ser asumible. La respuesta de Microsoft, cambiar de herramienta, es una salida; medir y poner topes por usuario desde el primer día es otra, y normalmente la más barata.

En resumen: presupuesta el caso de adopción total y mide desde el primer día

En resumen: antes de comprar una herramienta de IA de pago por consumo, modela el coste del escenario en que funciona. Toma el coste por usuario de tu usuario más intensivo esperado, multiplícalo por la plantilla a la que de verdad piensas desplegar, y comprueba si esa cifra cabe en el presupuesto anual. Si no cabe, la herramienta es inasumible en el caso de éxito por barato que pareciera el piloto, y el movimiento disciplinado es poner topes y medir por usuario desde el primer día en lugar de descubrir el techo en el cuarto mes, como le pasó a Uber.

El principio de decisión más amplio va más allá de esta categoría de producto. Cuando un proveedor cobra por unidad del comportamiento exacto cuyo aumento le pagas, el coste del piloto no significa nada y el coste del éxito lo es todo. Modela el resultado que esperas, no la prueba que estás haciendo, y si no puedes permitirte la herramienta funcionando a la perfección, no compres la herramienta que te cobra más por funcionar.

Leer a continuación: Halo mató el motor que se comía su estudio  |  El CEO de Microsoft: por la IA se paga dos veces