Cuando un desarrollador asigna una tarea de programación a un agente de IA, este no se limita a responder una sola vez. Planifica, genera código, ejecuta pruebas y repite el proceso para corregir errores. Una sola tarea puede consumir entre 10 y 50 veces más tokens que un prompt básico de chat. Cuanto más útil resulta el agente, más llamadas realiza. Con un modelo de precios por token, los flujos de trabajo que más valor aportan también pueden convertirse en los más caros.
La presión económica ya es evidente. Según ha trascendido, Uber agotó en abril todo su presupuesto de IA para 2026 tras ampliar el uso de Claude Code. GitHub Copilot pasó de una tarifa plana a un sistema de créditos por consumo. Gartner prevé que los costes en tokens para programar con IA superarán el salario medio de un desarrollador para 2028.
La respuesta natural es racionar: topes de uso, límites de licencias y aprobaciones antes de que los desarrolladores lancen agentes. Pero los límites generalizados pueden restringir los flujos de trabajo que aportan valor. Además, optimizan la cifra equivocada. El coste por token mide el consumo, no los resultados. Parte del gasto refleja un desperdicio, incluidos los reintentos y los bucles descontrolados. Otra parte representa el trabajo de publicar software. Un contador no puede distinguirlos, y un límite de gasto, tampoco.
Mide el software que se publica
Una métrica mejor es el coste por pull request fusionada: el coste total del desarrollo asistido por IA dividido entre el número de cambios que superan la revisión y se fusionan. Monitoriza el retrabajo y los defectos en paralelo para que unos cambios más baratos no oculten una menor calidad.
Si ese coste se reduce a medida que aumenta el uso de la IA, sin comprometer la calidad, los desarrolladores están convirtiendo un mayor consumo en software útil. La cuestión no es cuántos tokens utilizan, sino cuánto trabajo terminado produce la inversión.
Mejorar esa ecuación requiere dos cambios: reservar la inferencia costosa para las tareas que la necesitan y reducir el coste del trabajo rutinario.
Adapta el modelo a la tarea
La programación agéntica no requiere el modelo más potente en cada paso. Utiliza un modelo frontera, o un modelo insignia on-premises cuando las políticas lo exijan, para la planificación compleja y el razonamiento novedoso. Deriva el trabajo adecuado, incluida la generación de código, la creación de pruebas y la refactorización recurrente, a modelos de pesos abiertos que gestiones tú mismo.
Una pasarela puede enrutar las solicitudes según la complejidad de la tarea, la confidencialidad de los datos, el coste y la latencia. Esto reserva la inferencia prémium para los momentos que realmente lo justifican, en lugar de aplicar tarifas prémium a todo el flujo de trabajo. Tarifica la excepción, no la carga de trabajo.
Los modelos de pesos abiertos hacen que esta división resulte cada vez más práctica. Los benchmarks de ingeniería de software demuestran que los principales modelos de pesos abiertos pueden acercarse al rendimiento de frontera en algunas tareas. Esto no establece una equivalencia en todos los repositorios o flujos de trabajo. Evalúa a los candidatos con tu propio código, pruebas y criterios de aceptación antes de asignarles tareas en producción.
Cambia la economía del uso recurrente
A continuación, decide quién es el propietario de la capacidad. Con la inferencia alquilada, cada llamada se suma a la factura. Con la capacidad en propiedad, la mayor parte del coste se asume por adelantado, por lo que cada llamada adicional resulta más barata a medida que aumenta el uso.
La lógica económica es sencilla: la tarificación por token encarece el uso intensivo, mientras que la capacidad propia resulta más eficiente a medida que los equipos la utilizan más. Sin embargo, contar con infraestructura propia no sale gratis. Hay que tener en cuenta el consumo energético, las operaciones, el mantenimiento y la amortización. La cifra que de verdad importa es el coste total repercutido por cada pull request integrada.
Contar con capacidad propia también aporta un tipo de valor que nunca figura en una factura: el control sobre el código sensible. Cuando la generación y las pruebas de código se ejecutan on-premise, el código propietario permanece dentro de la empresa. Hacia los modelos externos solo salen los prompts de planificación aprobados y las excepciones supervisadas, a través de una pasarela bajo el control de la organización. Esto permite acceder a los repositorios sensibles donde la seguridad suele frenar la adopción y donde aguardan las mayores ventajas.
Pon a prueba el modelo operativo
En HPE, una plataforma de IA híbrida enruta las cargas de trabajo rutinarias de más de 150 aplicaciones internas hacia modelos de pesos abiertos que se ejecutan en local, incluido en HPE Private Cloud AI. El resultado: una reducción de entre el 30 % y el 50 % en los costes por token.
Esa es la clave del enfoque híbrido. Con HPE Private Cloud AI, ser dueño de tu propia inferencia no significa renunciar a los modelos de frontera. Ejecuta el volumen en tu propia capacidad y deja que una pasarela desvíe el trabajo más exigente.
Los datos también demuestran que el uso, y no el número de licencias contratadas, es lo que determina el gasto. El 5 % de los usuarios con mayor actividad generó la mayor parte del consumo, y los más intensivos utilizaron unas 450 veces más recursos que los más moderados con la misma licencia. Si los usuarios avanzados pasan de ser una pequeña minoría a la mitad de la plantilla, el gasto mensual puede multiplicarse aproximadamente por 4,4 sin que varíe el número de empleados. Tu caso particular será distinto, y esa es precisamente la razón por la que necesitas medirlo.
HPE monitoriza dos métricas y recomienda a sus clientes que hagan lo mismo. En primer lugar, monitoriza el coste por desarrollador activo, ya que calcular la media de todas las licencias oculta a los usuarios avanzados que disparan el gasto. En segundo lugar, monitoriza el coste por pull request fusionada, porque vincula el gasto en IA con el software que se entrega.
Establece una línea base para ambos costes antes de cambiar de infraestructura. Después, ejecuta un ciclo de desarrollo completo con capacidad propia. Si ambas métricas no mejoran a medida que aumenta el uso, puede que tu modelo actual siga siendo la mejor opción.
Construye para la adopción, no para el racionamiento
Disponer de capacidad propia no es para todo el mundo. Un uso bajo o impredecible favorece las API, sin capital inmovilizado en infraestructura inactiva. La propiedad compensa cuando una demanda sostenida la mantiene a pleno rendimiento. La mayoría de las empresas operarán de forma híbrida: API de vanguardia para tareas exigentes o intermitentes, y capacidad propia para volúmenes repetitivos. Una pasarela gobernada decide qué sale de la organización, de modo que obtienes modelos de vanguardia sin renunciar a la soberanía sobre tu código.
A medida que los desarrolladores recurran más a los agentes de programación, el uso seguirá aumentando. La verdadera disyuntiva es si ese crecimiento se traducirá en una factura más abultada por costes variables o en más software lanzado con capacidad propia. Las empresas que lideren el desarrollo asistido por IA no racionarán su adopción para controlar los costes. Construirán un modelo operativo en el que un mayor uso de la IA mejore la rentabilidad en lugar de socavarla.
Para obtener más información sobre HPE Private Cloud AI, visita HPE.
Este contenido ha sido elaborado por HPE. No ha sido redactado por el equipo editorial de MIT Technology Review.