La programación asistida por IA está entrando en una fase menos cómoda para las empresas. Después de meses de entusiasmo con 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. Y no porque las empresas vayan a sustituir programadores por máquinas sin coste, sino porque si el uso de agentes de programación escala sin control, el gasto en 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. Con los modelos de precio por consumo, eso ha cambiado.
Del coste por asiento al coste por uso
Pasar de licencias por usuario a pago por consumo introduce una variable muy difÃcil de presupuestar. Una empresa puede saber cuántos desarrolladores tiene y cuánto cuesta la suscripción mensual de cada uno. Lo que no puede prever fácilmente 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 factura ese consumo. Para los responsables de ingenierÃa, eso 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 primar la velocidad y la comodidad sobre el ahorro de tokens. Si una petición larga resuelve antes un problema, la usarán. 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 le 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 pasado de ser simples asistentes de autocompletado a agentes capaces de planificar, modificar archivos, ejecutar comandos, analizar errores y repetir ciclos hasta conseguir un resultado. Esa autonomÃa puede ser muy ú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. Y 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 acabar 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 girar en torno a 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 es 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 trabajo repetitivo. 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, y 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 resolverÃa de sobra.
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, porque no todo desarrollo necesita un agente completo. Algunas tareas deben seguir siendo lideradas por el desarrollador, otras pueden resolverse con asistencia parcial y solo unas pocas 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 los modelos frontera para problemas complejos, de alto valor o con mucho contexto técnico.
El tercer paso es aplicar ingenierÃa de contexto, lo que significa 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 contexto que considera útil. Eso 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, y después descubrieron que sin FinOps, etiquetas, presupuestos, alertas y arquitectura eficiente, la nube se les descontrolaba. Con los agentes de código puede pasar lo mismo: sin "token discipline", el gasto crecerá por inercia.
Esto no significa frenar a los desarrolladores, sino darles herramientas y reglas para usar la IA de forma eficiente. Un buen modelo operativo deberÃa permitir experimentar con visibilidad, acelerar tareas sin convertir cada petición en una consulta cara, y usar agentes con autonomÃa proporcional al riesgo y al valor de lo que se les encarga.
Qué deben hacer los CIO y CTO
Para los responsables tecnológicos, el mensaje es directo: 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, y 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. El presupuesto puede agotarse antes de lo previsto, y la dirección financiera puede perder confianza en los proyectos de IA si no ve una relación clara entre gasto y resultados. La consecuencia serÃa una reacción pendular: 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 depende de cómo se use. Un agente mal gobernado puede ser rápido y caro a la vez. Uno bien integrado puede ser útil y medible.
Lo que decida la próxima etapa de la programación con IA no será solo qué herramienta escribe mejor código, sino qué organizaciones aprenden antes a medir, controlar y ajustar 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, por el aumento del consumo de tokens y 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?
- 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.
Imagen: Pexels / Pavel Danilyuk