La programación asistida por inteligencia artificial está entrando en una fase menos cómoda para las empresas. Después de meses de entusiasmo por el aumento de productividad, la velocidad de desarrollo y la promesa de agentes capaces de escribir, revisar y desplegar código, empieza a aparecer una pregunta más incómoda: cuánto cuesta realmente todo ese trabajo cuando se factura por consumo de tokens.
Gartner prevé que en 2028 los costes de las herramientas de programación con IA superarán el salario medio de un desarrollador. La predicción no apunta a que las empresas vayan a sustituir programadores por máquinas sin coste, sino justo a lo contrario: si el uso de agentes de programación escala sin control, el gasto asociado a modelos de lenguaje puede crecer más rápido que las mejoras de productividad que prometen.
Los tokens son las unidades de texto que procesan los modelos generativos. Cada petición, cada archivo incluido en el contexto, cada conversación larga, cada revisión de código y cada agente que ejecuta varios pasos consume tokens. Mientras las herramientas se pagaban sobre todo por licencia por usuario, el coste era más previsible. Pero la transición hacia modelos de precio por consumo está cambiando la economía del desarrollo de software.
Del coste por asiento al coste por uso
El cambio de las licencias por usuario a modelos de pago por consumo introduce una variable difícil de presupuestar. Una empresa puede saber cuántos desarrolladores tiene y cuánto cuesta una suscripción mensual por cada uno. Lo que no siempre puede prever es cuántos tokens consumirá cada equipo cuando los agentes de IA empiecen a revisar repositorios completos, generar pruebas, explicar código heredado, depurar errores o ejecutar tareas encadenadas.
Gartner advierte de que muchos proveedores todavía no ofrecen suficiente transparencia sobre cómo se calcula y se factura ese consumo. Para los responsables de ingeniería, esto complica la planificación presupuestaria y dificulta medir el retorno real. Una herramienta puede parecer barata durante una prueba piloto y convertirse en una partida difícil de justificar cuando la usa toda la organización.
El problema se agrava porque los desarrolladores, de forma natural, tienden a elegir velocidad y comodidad antes que ahorro de tokens. Si una petición larga resuelve antes un problema, lo normal es usarla. Si un agente puede revisar todo un proyecto en lugar de un archivo concreto, muchos equipos lo harán. Sin reglas, límites y visibilidad, el consumo se dispara.
| Modelo de coste | Ventaja | Riesgo |
|---|---|---|
| Licencia por usuario | Presupuesto más estable y fácil de prever | Puede infrautilizarse si el uso real es bajo |
| Pago por consumo | Ajuste al uso real y escalabilidad | Coste variable y difícil de controlar |
| Modelos híbridos | Equilibrio entre acceso y consumo | Complejidad contractual y de seguimiento |
| Agentes autónomos | Más automatización de tareas | Consumo de tokens elevado y menos visible |
La predicción de Gartner pone nombre a una preocupación que ya empieza a verse en equipos técnicos: la inteligencia artificial no elimina el coste del desarrollo. Lo desplaza hacia una nueva capa de infraestructura, modelos, contexto y agentes.
El nuevo riesgo: agentes que consumen sin control
Las herramientas de programación con IA han evolucionado desde simples asistentes de autocompletado hacia agentes capaces de planificar, modificar archivos, ejecutar comandos, analizar errores y repetir ciclos hasta conseguir un resultado. Esa autonomía puede ser útil, pero también multiplica el consumo.
Un agente no hace una única petición. Puede generar una hipótesis, leer varios archivos, llamar herramientas, revisar la respuesta, cambiar código, ejecutar pruebas, interpretar errores y volver a intentarlo. Cada paso implica entrada y salida de tokens. Si además se le entrega demasiado contexto, como repositorios completos o documentación innecesaria, la factura crece sin que el desarrollador lo perciba en el momento.
Gartner identifica varios fallos habituales: autonomía no gobernada en flujos de trabajo agentic, ventanas de contexto demasiado grandes, falta de mecanismos de feedback para ajustar el uso y ausencia de capacidades maduras de optimización de costes en los propios proveedores.
| Fuente de sobrecoste | Qué ocurre |
| Contextos demasiado grandes | Se envían más archivos y documentación de la necesaria |
| Agentes con demasiada autonomía | Ejecutan múltiples pasos sin revisión intermedia |
| Modelos sobredimensionados | Se usan modelos frontera para tareas simples |
| Falta de medición | El equipo no sabe qué flujos consumen más tokens |
| Ausencia de límites | No hay umbrales, alertas ni políticas de escalado |
El resultado puede ser paradójico. Una herramienta diseñada para ahorrar tiempo puede terminar consumiendo presupuesto antes de que la organización haya demostrado con claridad su impacto en productividad, calidad, seguridad o velocidad de entrega.
La productividad no basta si no se mide el coste
El debate sobre IA en programación suele centrarse en cuántas líneas de código puede generar, cuánto acelera una tarea o cuántos tickets puede resolver un equipo. Pero en entornos empresariales el cálculo debe ser más amplio. Hay que medir coste, valor, calidad, deuda técnica, seguridad, mantenibilidad y tiempo ahorrado.
Una empresa puede aceptar un gasto elevado en IA si reduce plazos críticos, mejora la calidad del código, acelera migraciones o libera a los equipos de tareas repetitivas. El problema aparece cuando el gasto crece sin una relación clara con resultados de negocio. Gartner señala que muchas organizaciones todavía no tienen la madurez ni los marcos necesarios para medir coste frente a impacto.
La falta de visibilidad también dificulta comparar casos de uso. No cuesta lo mismo pedir a un asistente que genere una función sencilla que poner a un agente a modernizar un módulo heredado. Tampoco tiene el mismo valor. Sin separar tareas por complejidad y beneficio, las empresas pueden terminar pagando modelos caros para trabajos que un modelo pequeño o un flujo más limitado resolvería de forma suficiente.
El modelo operativo que propone Gartner
La recomendación de Gartner no es dejar de usar IA para programar. Es gobernarla. La firma propone un modelo disciplinado que obligue a decidir cuándo usar agentes, con qué nivel de autonomía, qué modelo conviene emplear y cómo revisar el consumo.
El primer paso es clasificar las tareas. No todo desarrollo necesita un agente completo. Algunas tareas deben seguir siendo lideradas por el desarrollador. Otras pueden resolverse con asistencia parcial. Y solo algunas deberían delegarse en flujos agentic más autónomos.
| Tipo de tarea | Modelo recomendado |
| Cambios sensibles o críticos | Developer-led |
| Refactorizaciones acotadas | Developer-with-agent |
| Generación de pruebas repetitivas | Developer-with-agent o agent-led supervisado |
| Búsqueda en documentación | Modelo pequeño o especializado |
| Migraciones complejas | Agente con límites, revisión y escalado |
| Cambios en producción | Control humano y políticas estrictas |
El segundo paso es ajustar el modelo a la tarea. Usar siempre el modelo más potente no es eficiente. Las empresas deberían enviar tareas simples y frecuentes a modelos pequeños, y reservar modelos frontera para problemas complejos, de alto valor o con mucho contexto técnico.
El tercer paso es aplicar ingeniería de contexto. Esto implica enseñar a los desarrolladores a incluir solo la información necesaria, resumir contenidos cuando sea posible, evitar archivos irrelevantes y estructurar mejor las peticiones. En la práctica, una buena gestión del contexto puede reducir costes sin empeorar la calidad de la respuesta.
El cuarto paso es implantar controles: umbrales de tokens, alertas, políticas de escalado, monitorización automática y revisiones periódicas. Gartner recomienda incorporar revisiones de consumo en las retrospectivas de sprint para detectar flujos de alto coste, compartir buenas prácticas y corregir hábitos.
Una nueva disciplina para los equipos de ingeniería
La predicción de Gartner apunta a un cambio de cultura. Hasta ahora, muchos equipos han tratado las herramientas de IA como una mejora individual de productividad. Cada desarrollador usa el asistente como quiere, en las tareas que quiere y con el nivel de contexto que considera útil. Ese enfoque puede funcionar en pilotos pequeños, pero no en despliegues empresariales a gran escala.
La programación con IA necesita una disciplina parecida a la que ya existe en cloud. Al principio, muchas empresas migraron cargas a la nube pensando en elasticidad y rapidez. Después descubrieron que sin FinOps, etiquetas, presupuestos, alertas y arquitectura eficiente, la nube podía descontrolarse. Algo parecido puede ocurrir con los agentes de código: sin “token discipline”, el gasto crecerá por inercia.
Esto no significa frenar a los desarrolladores. Significa darles herramientas y reglas para usar la IA de forma eficiente. Un buen modelo operativo debería permitir experimentar, pero con visibilidad. Debería acelerar tareas, pero sin convertir cada petición en una consulta cara. Y debería fomentar agentes útiles, pero con autonomía proporcional al riesgo y al valor de la tarea.
Qué deben hacer los CIO y CTO
Para los responsables tecnológicos, el mensaje es claro: la IA de programación ya no puede comprarse como una suscripción más. Debe entrar en la gestión financiera, de seguridad y de arquitectura de la organización.
Los CIO y CTO deberían exigir a los proveedores más transparencia sobre consumo, facturación, límites, telemetría y optimización. También deberían definir métricas internas: coste por tarea, coste por repositorio, ahorro de tiempo, tasa de aceptación de código, errores introducidos, vulnerabilidades detectadas, velocidad de entrega y satisfacción del equipo.
El riesgo de no hacerlo es doble. Por un lado, el presupuesto puede agotarse antes de lo previsto. Por otro, la dirección financiera puede perder confianza en proyectos de IA si no ve una relación clara entre gasto y resultados. La consecuencia sería una reacción pendular: pasar del entusiasmo inicial al recorte indiscriminado.
La inteligencia artificial aplicada al desarrollo de software tiene potencial real. Puede ayudar a entender código heredado, generar pruebas, acelerar documentación, detectar errores, proponer refactorizaciones y reducir trabajo repetitivo. Pero su valor dependerá de cómo se use. Un agente mal gobernado puede ser rápido y caro. Un agente bien integrado puede ser útil y medible.
La próxima etapa de la programación con IA no se decidirá solo por qué herramienta escribe mejor código. Se decidirá por qué organizaciones aprenden antes a medir, controlar y optimizar el consumo de tokens. La productividad importa, pero el coste también. Y Gartner acaba de recordar que, en 2028, esa diferencia puede aparecer directamente en la cuenta de resultados.
Preguntas frecuentes
¿Qué predice Gartner sobre los costes de programación con IA?
Gartner prevé que en 2028 los costes de las herramientas de programación con IA superarán el salario medio de un desarrollador debido al aumento del consumo de tokens y a los modelos de precio por uso.
¿Por qué suben tanto los costes?
Porque los agentes de programación consumen tokens en cada petición, archivo, respuesta, paso intermedio y acción autónoma. Cuanto más contexto y autonomía reciben, mayor es el gasto.
¿Qué pueden hacer las empresas para controlar el coste?
Pueden clasificar tareas, usar modelos pequeños para trabajos simples, limitar contextos, establecer umbrales de tokens, monitorizar consumo y revisar flujos de alto coste en cada sprint.
¿Significa esto que la IA no compensa en programación?
No necesariamente. La IA puede aportar mucho valor, pero necesita gobierno, medición y control financiero para que el coste no crezca más rápido que la productividad.
