Cuando un desarrollador le encarga una tarea de programación a un agente de IA, este hace mucho más que dar una única respuesta. 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 de chat básico. Cuanto más útil resulta el agente, más llamadas realiza. Con los precios por token, los flujos de trabajo que generan más valor también pueden convertirse en los más caros.
La presión económica ya es evidente. Según ha trascendido, Uber agotó todo su presupuesto de IA para 2026 en el mes de abril tras ampliar el uso de Claude Code. GitHub Copilot ha pasado de una tarifa plana a un sistema de créditos por consumo. Gartner prevé que el coste de los tokens de IA para programar superará 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. Sin embargo, los límites generalizados pueden restringir los flujos de trabajo que aportan valor. Además, optimizan la métrica equivocada. El coste por token mide el consumo, no los resultados. Parte del gasto refleja un desperdicio, que incluye reintentos y bucles descontrolados. Otra parte representa el trabajo de entregar software. Un contador no puede distinguirlos, y un tope de gasto tampoco.
Mide el software que se entrega
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 económicos no oculten una calidad inferior.
Si ese coste disminuye a medida que aumenta el uso de la IA, sin comprometer la calidad, los desarrolladores están convirtiendo más 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 de frontera, o un modelo insignia en local cuando las políticas internas lo exijan, para la planificación compleja y el razonamiento novedoso. Deriva el trabajo adecuado, como 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 peticiones según la complejidad de la tarea, la sensibilidad 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 precios prémium a todo el flujo de trabajo. Mide la excepción, no la carga de trabajo.
Los modelos de pesos abiertos hacen que esta división sea cada vez más práctica. Los benchmarks de ingeniería de software muestran que los principales modelos de pesos abiertos pueden acercarse al rendimiento de frontera en algunas tareas. Esto no demuestra 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 trabajo en producción.
Cambia la economía del uso recurrente
A continuación, decide quién posee la capacidad. Con la inferencia alquilada, cada llamada se suma a la factura. Con la capacidad en propiedad, la mayor parte del coste se compromete 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 realmente importa es el coste total repercutido por pull request integrada.
Disponer de capacidad propia también aporta un tipo de valor que nunca aparece en una factura: el control sobre el código sensible. Cuando la generación de código y las pruebas se ejecutan on-premises, el código propietario permanece dentro de la empresa. Solo los prompts de planificación aprobados y las excepciones reguladas se envían a modelos externos, a través de una pasarela que la organización controla. Esto abre los repositorios sensibles donde la seguridad suele frenar la adopción y donde aguardan los mayores beneficios.
Pon a prueba el modelo operativo
En HPE, una plataforma híbrida de IA enruta las cargas de trabajo rutinarias de más de 150 aplicaciones internas hacia modelos de pesos abiertos que se ejecutan en local, entre ellos en HPE Private Cloud AI. El resultado: una reducción de entre el 30 % y el 50 % en los costes de los tokens.
Esa es la clave del enfoque híbrido. Con HPE Private Cloud AI, tener tu propia inferencia no significa renunciar a los modelos frontera. Ejecuta el volumen principal en tu propia capacidad y deja que una pasarela derive las tareas más exigentes.
Los datos también demuestran que lo que dispara el gasto es el uso y no el número de empleados con licencia. El 5 % de los usuarios principales generó la mayor parte del consumo, y los perfiles más intensivos consumieron aproximadamente 450 veces más que los más moderados con la misma licencia. Si los usuarios avanzados pasan de ser una pequeña minoría a representar la mitad de la plantilla, el gasto mensual puede multiplicarse unas 4,4 veces manteniendo el mismo número de empleados. Tu caso particular será distinto, y ese es precisamente el motivo por el que debes medirlo.
HPE monitoriza dos métricas y recomienda a sus clientes que hagan lo mismo. En primer lugar, mide 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 conecta el gasto en IA con el software que realmente se entrega.
Establece la línea base de ambos costes antes de cambiar de infraestructura. A continuación, 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 escaso o imprevisible favorece las API, sin capital inmovilizado en infraestructuras inactivas. Tenerla en propiedad compensa cuando una demanda sostenida la mantiene ocupada. La mayoría de las empresas optarán por un modelo híbrido: API de frontera para tareas exigentes o intermitentes, y capacidad propia para volúmenes repetitivos. Una pasarela con gobernanza decide qué sale al exterior, lo que te permite aprovechar modelos de frontera sin renunciar a la soberanía sobre tu código.
A medida que los desarrolladores recurran cada vez más a los agentes de programación, su uso seguirá en aumento. La verdadera disyuntiva es si ese crecimiento se traducirá en una factura más abultada de 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 perjudicarla.
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.