Hay una noticia que se está repitiendo demasiado para ser anecdótica: empresas que despliegan herramientas de inteligencia artificial para programar y, pocos meses después, frenan en seco porque el consumo de tokens se ha comido el presupuesto anual de tecnología. No hablo de startups improvisadas. Hablo de Microsoft, de Uber, de departamentos de TI con cientos de desarrolladores. Y ha aparecido una idea que conviene examinar con frialdad: la de que, en ciertos escenarios, el programador humano vuelve a salir más barato que la máquina que prometía sustituirlo.
He sido programador casi toda mi vida. Lo sigo siendo en la definición que más me importa de mí mismo. Por eso lo que voy a decir no es una crítica al programador, sino justo lo contrario: una defensa del criterio que solo aporta quien ha programado de verdad. Y mi tesis es sencilla. El problema no es que la IA sea cara. El problema es que se la estamos dando a la gente equivocada en el momento equivocado y sin un plan.
Índice de contenidos
Dar un Ferrari a quien cortaba el césped con una segadora
Imagina a un jardinero acostumbrado a su pequeña máquina de cortar césped. Hace su trabajo, mantiene el jardín bonito, y el coste de esa máquina es perfectamente previsible: la amortizas en años. Un día le entregas las llaves de un Ferrari. Lo más probable no es que pode mejor el seto. Lo más probable es que se vaya a Las Vegas a probarlo, vuelva encantado y te diga que se ha gastado tres mil dólares en gasolina. Y tú piensas: con eso pagaba un año entero de la segadora que mantenía el jardín en condiciones.
Esa es la imagen que mejor describe lo que está pasando. Pero quiero corregirme a mí mismo, porque la analogía del Ferrari se queda corta. Una herramienta como Claude Code o Cursor no es solo un coche caro. Es a la vez un Ferrari —velocidad y potencia desmedidas— y un tráiler capaz de transportar las cargas más pesadas que te imagines. La Inteligencia Artificial es una maquinaria extraordinaria. El problema de fondo no es la potencia. Es que la potencia sin destino se convierte en gasto.
Porque hay un matiz que la analogía del Ferrari no captura y que es el verdadero corazón del asunto: el taxímetro. Un programador cobra por horas pensadas; la herramienta cobra por cada token que consume, encendida como un taxímetro que no para mientras el agente «razona» en segundo plano. Y ahí es donde el despilfarro deja de ser una metáfora y se convierte en una factura.
«Necesito que el trabajo sea facturable»
Cuando empecé en Ibermática, a finales de los ochenta, tuve un jefe y excelente persona, Josemi Gracia, que me dejó una frase clavada para siempre. Los programadores nos quejábamos de que teníamos muchísimo trabajo. Él escuchaba, asentía, y luego soltaba: «Sí, sí, siempre decís que tenéis mucho trabajo. Pero lo que yo necesito es que el trabajo sea facturable. Vosotros siempre estáis pensando en optimizaciones, en mejoras, en cosas interesantes. Y yo necesito horas que pueda cobrar a un cliente.»
Tenía toda la razón, y me costó años entenderlo del todo. El instinto de un buen programador es mejorar el código continuamente. Es un impulso casi estético, y no es malo en sí mismo. El problema aparece cuando le das a ese impulso una herramienta que elimina toda la fricción que antes lo contenía.
Coge a cualquier programador con experiencia y pregúntale si el código de la aplicación en la que trabaja se podría mejorar y optimizar. Todos, sin excepción, te dirán que sí. Y todos tendrán razón. Hay una frase que se atribuye popularmente a Warren Buffett —aunque el dicho es bastante anterior a él— que lo resume mejor que cualquier manual de gestión: nunca le preguntes a un peluquero si necesitas un corte de pelo. La respuesta siempre será que sí. No porque mienta, sino porque ve cortes de pelo donde tú ves una cabeza normal. El programador ve refactorizaciones donde el negocio ve un programa que ya funciona.
El refactor que mejora el código puede generar valor de aquí a cinco años. Es verdad. Pero las cuentas se presentan en diciembre. Esto no es estar en contra de la calidad ni de la mejora continua. Es entender que el valor a largo plazo y el valor facturable este año son dos cosas distintas, y que alguien tiene que decidir cuánto presupuesto va a cada uno. Eso no lo decide el entusiasmo del que tiene las manos en el teclado. Eso lo decide quien gestiona la cartera.
Si funciona, no lo toques
Hay un segundo principio, más viejo todavía, que todo programador veterano lleva grabado a fuego: si algo funciona, no lo toques. Y este, técnicamente, es el más serio de todos.
Yo me crié profesionalmente viendo programas en COBOL que eran una auténtica porquería de diseño: caóticos, sin comentarios, imposibles de leer. Más de una vez caí en la tentación: «voy a poner un poco de orden aquí». Y el resultado, demasiadas veces, era que el programa dejaba de funcionar y yo no sabía exactamente qué había tocado. En teoría todo eran mejoras. En la práctica, había introducido un fallo donde antes había años de estabilidad. La lección se aprende a golpes: volvías a la versión antigua o, directamente, decidías no tocar nada.
Ese código feo que funciona tiene un valor que no está en su elegancia, sino en sus años de producción sin caerse. Y aquí está el peligro real de las herramientas de IA actuales: bajan tanto la fricción de «meter mano» que invitan a reescribir lo que estaba estable. Lo que antes te frenaba —la pereza, el riesgo, las horas que costaba— ahora desaparece. La máquina lo hace en segundos. Y con ello reintroduces regresiones en sistemas que llevaban años sin dar un problema.
Conviene ser honesto con el matiz, porque «no lo toques nunca» llevado al extremo es exactamente cómo se acumula la deuda técnica que un día revienta. El propio COBOL que nadie se atrevía a tocar acabó costando fortunas en migraciones bancarias. El principio correcto no es «no toques», sino «no toques sin que un proyecto maestro lo haya priorizado y sin red de seguridad»: control de versiones, tests, un entorno de pruebas donde el experimento no cueste la producción.
Lo que falta no es freno, es un director
Cuando juntas las tres piezas —el Ferrari sin destino, el peluquero que siempre ve un corte que hacer, y el impulso de tocar lo que ya funcionaba— el patrón se ve claro. Todas apuntan a lo mismo: estas herramientas amplifican el sesgo natural del programador hacia el trabajo técnicamente atractivo pero económicamente no priorizado. Y lo amplifican con un taxímetro encendido.
Por eso creo que la respuesta de las empresas que cancelan contratos a los cuatro meses, aunque comprensible, es la equivocada. El error no fue adoptar la herramienta. El error fue repartirla sin un proyecto maestro. Volvamos al jardinero: el problema no era el Ferrari, era que nadie le dijo para qué lo tenía. Su trabajo seguía siendo mantener el jardín bonito, no irse a Las Vegas a probar la máquina.
Una empresa que despliega IA para programar necesita antes una figura que sepa leer el contexto: un analista-programador —no un programador a secas, ni un gestor que no haya tocado código— capaz de entender qué software tiene la compañía, qué necesita actualizarse de verdad, y qué va a producir un rendimiento monetario efectivo. Esa figura tiene que coordinarse con todos los departamentos y construir un proyecto maestro que dé sentido al gasto. Sin eso, te dan la herramienta y la devuelves a los cuatro días porque «gasta mucho». Y la conclusión que sacas —»la IA es cara»— es falsa. Lo caro fue no tener un plan.
Yo trabajo con estas herramientas a diario, y mi convicción es la contraria a la del titular pesimista. No hay que frenar la IA. Hay que ponerle un director de orquesta delante. La potencia no sobra: lo que falta es criterio sobre dónde aplicarla. Y ese criterio, paradójicamente, lo aporta mejor que nadie quien lleva décadas programando y ha aprendido, a base de facturas y de programas rotos, que la pregunta correcta nunca fue «¿cuánto puede hacer esta máquina?», sino «¿qué necesita de verdad la compañía?».
Anexo: el problema en datos. Qué está pasando realmente con el coste de la IA para programar (2025-2026)
La opinión anterior se apoya en un fenómeno bien documentado. Este anexo resume los datos más relevantes de un informe de investigación sobre el sobrecoste por consumo de tokens en herramientas de IA para desarrollo durante 2025 y 2026. Las cifras proceden de casos corporativos públicos, análisis de consultoras y modelización económica de la industria.
Los casos que encendieron la alarma
Microsoft. En diciembre de 2025 desplegó Claude Code en su división Experiences & Devices (responsable de Windows, Microsoft 365, Outlook, Teams y Surface). La adopción interna fue masiva y espontánea: los ingenieros prefirieron la herramienta de Anthropic incluso por encima de las desarrolladas por la propia Microsoft. Apenas seis meses después, la compañía canceló la mayoría de licencias y forzó la vuelta a GitHub Copilot CLI con fecha límite el 30 de junio de 2026. El motivo no fue la calidad del código, sino que el consumo de tokens había agotado el presupuesto anual de IA de la división mucho antes de lo previsto. La paradoja es brutal: cuanto más útil era la herramienta, más rápido destruía el presupuesto.
Uber. En abril de 2026 su CTO reconoció internamente que la empresa había consumido todo su presupuesto de IA del año en cuatro meses. Tras dar acceso a Claude Code y Cursor a unos 5.000 ingenieros en diciembre de 2025, el uso se duplicó en febrero. Para abril, el 95% de los ingenieros usaba estas herramientas mensualmente y el coste de API oscilaba entre 500 y 2.000 dólares por desarrollador al mes. El 11% del código en producción lo escribían ya agentes de IA. La respuesta: un límite estricto de 1.500 dólares mensuales por empleado. Esa cifra, anualizada y con dos herramientas, ronda los 36.000 dólares por ingeniero, alrededor del 11% del coste laboral total de un desarrollador de Uber en EE. UU.
Replit. En 2025 cambió a un modelo de «facturación por esfuerzo» coincidiendo con su Agent 3, «diez veces más autónomo». El resultado: una edición rutinaria podía costar 0,10 dólares y una petición ambigua escalar por encima de los 5 sin aviso. Cuentas que promediaban 180-200 dólares al mes vieron facturas de hasta 1.000 dólares en una semana. Un caso documentado: 20 dólares de un solo comando porque el agente rediseñó por su cuenta toda la interfaz del proyecto. Los usuarios empezaron a comparar la experiencia con un casino. En febrero de 2026 Replit eliminó su plan Teams (40 dólares/mes) y forzó la migración a un Pro de 100 dólares base.
GitHub Copilot. Desde el 1 de junio de 2026 abandona la tarifa plana y pasa a facturar por consumo real de tokens mediante «créditos de IA». La cuota base de los planes se agota en días u horas con flujos de trabajo agénticos, y a partir de ahí llegan los excedentes. Es el fin del «coste marginal cero» que dominó la primera fase de adopción.
Empresa mediana (500 desarrolladores). Caso de estudio: desplegó IA agéntica con la directriz de que «se amortizaría sola». Ocho meses después, la factura de inferencia de un solo trimestre fue de 87.000 dólares, con una proyección anual de más de 340.000. El CFO exigió ROI y la empresa solo pudo presentar métricas proxy: 85% de adopción diaria, alta satisfacción y una reducción del 12% en el tiempo de fusión de pull requests. No fue posible correlacionar ese gasto con un aumento de ingresos. Un detalle revelador: si un manager hubiera pedido contratar a tres ingenieros por ese importe, habría necesitado varias aprobaciones; como gasto de software, el sobrecoste pasó «por debajo del radar».
El debate humano vs. máquina, en cifras
El argumento de que «los tokens son baratos» se desmonta al proyectarlo sobre el uso real. Las tarifas nominales parecen inofensivas (del orden de unos pocos dólares por millón de tokens de entrada y hasta cinco o seis veces más por los de salida). Pero un equipo de solo 10 desarrolladores usando agentes de forma integrada consume con facilidad varios millones de tokens al día, por la naturaleza iterativa del trabajo: reinyección constante del contexto del proyecto, reintentos cuando el código falla, y los largos «monólogos internos» de razonamiento del modelo.
Extrapolado a un mes, eso sitúa la factura de un equipo pequeño en torno a los 7.000-10.000 dólares mensuales solo en inferencia. La conclusión del análisis es incómoda: un flujo de trabajo intensivo en IA repartido entre cinco o diez personas puede salir más caro que contratar a un desarrollador junior a tiempo completo. Y eso sin contar observabilidad, bases de datos vectoriales, orquestación ni —lo más importante— el tiempo de los ingenieros senior que deben auditar y corregir las alucinaciones del modelo.
La diferencia estructural con un salario humano es que este es una línea presupuestaria fija y predecible a doce meses. El gasto en tokens, no: cuando un junior comete un error, aprende y el coste de iterar ya está cubierto por su sueldo; cuando el modelo se equivoca o entra en un bucle, la empresa paga el precio completo de cada token de cada iteración fallida. No hay descuento por incompetencia algorítmica.
Por qué se dispara el gasto: las causas técnicas
El sobrecoste no es solo entusiasmo. Tiene causas técnicas concretas:
- Asimetría entrada/salida. Generar un token de salida cuesta entre cinco y seis veces más que leer uno de entrada. Y todo el «razonamiento interno» (cadenas de pensamiento, planes, reintentos) se factura a precio de salida, a espaldas del presupuesto.
- Despliegue en abanico de subagentes. Un agente orquestador puede lanzar 20 o más subagentes en paralelo, cada uno cargando su propio contexto completo. Esto añade entre un 200% y un 500% de sobrecoste frente a hacer el mismo trabajo en secuencia. Hay un incidente documentado de 47.000 dólares por un bucle infinito de reintentos desatendido.
- Relleno de contexto y servidores MCP. Sin una arquitectura de recuperación selectiva, el comportamiento por defecto es inyectar todo el repositorio y todo el historial en cada petición. Servidores MCP mal auditados pueden añadir más de 18.000 tokens innecesarios por interacción.
- Inflación de tokenizadores. Cambios del lado del proveedor pueden encarecer la misma carga de trabajo hasta un 35% sin que el usuario haya cambiado nada.
- Vulnerabilidades de gasto. La ausencia de límites duros obligatorios y la latencia de la facturación (cargos que aparecen horas o días después) abren la puerta a que un token filtrado o una mala configuración drenen un presupuesto en un fin de semana.
Las dos visiones del mercado
La industria está dividida. Andreessen Horowitz (a16z) defiende la adopción sin reservas: sostiene que estas herramientas multiplican la productividad de los mejores ingenieros entre 10 y 20 veces, que el talento técnico siempre fue el recurso más caro y escaso, y que por tanto el ROI es innegable. Proyecta un mercado de 3 billones de dólares para el software automatizado por IA.
En el lado opuesto, Gartner y Forrester piden prudencia. Gartner prevé que para finales de 2026 el 40% de las aplicaciones empresariales incorporarán agentes de IA, pero también que más del 40% de los proyectos de IA agéntica desplegados serán cancelados, abandonados o recortados antes de finales de 2027, por tres motivos: costes incontrolables, incapacidad de demostrar valor comercial y controles de riesgo inadecuados.
El consenso emergente es que la unidad de medida correcta no es «el precio por millón de tokens», sino «el coste por unidad de trabajo terminado en el que se pueda confiar». Un agente barato que necesita seis reintentos y horas de revisión humana es una ilusión de ahorro; un modelo premium puede salir más económico si requiere menos supervisión. La pregunta ya no es cuántos tokens consumió, sino si produjo algo en lo que la empresa pueda confiar tras pasar las pruebas, o solo un volumen de código que un humano ahora tiene que vigilar.
Las cifras de este anexo proceden de un informe de investigación documental sobre fuentes públicas (casos corporativos, consultoras y prensa especializada) con fecha de acceso de junio de 2026. Las proyecciones de Gartner, Forrester y a16z son estimaciones de cada firma, no hechos consumados.
