Medir el uso de inteligencia artificial por volumen de tokens consumidos es equivalente a medir la productividad de una fábrica por cuánta electricidad consume. El indicador capta actividad, no valor. Sin embargo, la respuesta más común ante el crecimiento del gasto en IA sigue siendo la misma: límites de uso, restricciones de acceso y aprobaciones previas que frenan los flujos de trabajo antes de que puedan demostrar su utilidad.

El problema estructural es que un límite de gasto no distingue entre tokens desperdiciados —intentos fallidos, ciclos sin resolución, prompts mal formulados— y tokens que efectivamente produjeron código funcional. Optimizar esa métrica equivale a reducir el consumo sin saber si se está eliminando desperdicio o capacidad productiva.

La métrica que sí importa: costo por cambio fusionado

Una alternativa más precisa es el costo por pull request fusionado: el gasto total en desarrollo asistido por IA dividido entre el número de cambios que superan revisión e integración. Complementar ese indicador con seguimiento de retrabajo y defectos evita que los cambios más baratos oculten una caída en la calidad del código.

Si ese costo disminuye a medida que crece el uso de IA —sin deterioro en calidad— significa que los equipos están convirtiendo más inversión en software útil. La pregunta de gestión deja de ser cuántos tokens se consumen y pasa a ser cuánto trabajo terminado produce cada peso invertido.

Enrutamiento por complejidad: el modelo correcto para cada tarea

No toda tarea de desarrollo requiere el modelo más potente disponible. La planificación compleja, el razonamiento sobre arquitectura y los problemas sin precedente justifican modelos de frontera. La generación de código repetitivo, la creación de pruebas y la refactorización estructurada pueden resolverse con modelos de pesos abiertos operados internamente, con costos significativamente menores.

Un sistema de enrutamiento que clasifique solicitudes según complejidad, sensibilidad de datos, costo y latencia permite reservar la inferencia premium para los momentos que realmente la justifican. Los estándares actuales de ingeniería de software muestran que los modelos de pesos abiertos líderes se aproximan al rendimiento de frontera en categorías específicas de tareas, aunque esa proximidad no es universal. La validación sobre el propio repositorio y los criterios de aceptación del equipo es indispensable antes de asignar trabajo de producción a cualquier modelo alternativo.

Capacidad propia versus inferencia alquilada

La estructura de costos cambia según quién posee la capacidad de inferencia. Con modelos alquilados vía API, cada llamada incrementa la factura de forma variable. Con capacidad propia —ya sea en infraestructura interna o mediante acuerdos de capacidad comprometida—, el costo se concentra al inicio y cada llamada adicional resulta más económica conforme aumenta el volumen de uso.

Esa diferencia tiene implicaciones directas sobre el umbral de rentabilidad del desarrollo asistido por IA. Las organizaciones con volúmenes altos y flujos de trabajo predecibles encuentran en la capacidad propia una palanca para mejorar la ecuación costo-resultado sin sacrificar velocidad de entrega.