Frente al aumento de los gastos relacionados con la IA, la respuesta más común consiste en limitar su uso: límites de consumo, número de licencias y validaciones previas al lanzamiento de agentes. Sin embargo, estas restricciones indiferenciadas pueden frenar usos útiles y medir el indicador equivocado, según el análisis.
- Limitar el uso de la IA puede frenar usos útiles y medir el indicador equivocado.
- El costo por token mide el consumo, no los resultados entregados.
- Conviene medir el costo por solicitud de fusión aceptada, vigilando la calidad del código.
- Reservar los modelos potentes para tareas complejas y usar modelos de pesos abiertos para el trabajo corriente reduce los costos.
El costo por token (unidad de texto procesada por un modelo de lenguaje) mide el consumo, no los resultados. Una parte del gasto corresponde a desperdicio, como las repeticiones de consultas o los bucles incontrolados, mientras que otra representa el trabajo real de entrega de un software. Un contador no permite distinguirlos, al igual que un límite de gastos.
Medir el software entregado
Un indicador más pertinente sería el costo por solicitud de fusión aceptada, es decir, el costo total del desarrollo asistido por IA dividido por el número de modificaciones que pasan la revisión y se integran al código, llamadas « pull requests » en la jerga. Hay que seguir en paralelo las correcciones y los defectos, para que las modificaciones menos costosas no oculten una baja de calidad.
Si este costo baja mientras que el uso aumenta, sin degradación de la calidad, los desarrolladores transforman más consumo en software útil. La pregunta no es entonces el número de tokens utilizados, sino la cantidad de trabajo terminado que produce la inversión. Para mejorar este equilibrio, se proponen dos palancas: reservar la inferencia costosa a las tareas que la necesitan, y reducir el costo del trabajo corriente.
Adaptar el modelo a la tarea
El desarrollo agencial, en el que un agente escribe y modifica código de manera autónoma, no exige el modelo más potente en cada etapa. Un modelo de punta, o un modelo insignia alojado en las instalaciones cuando la política de la empresa lo impone, puede reservarse para la planificación compleja y el razonamiento novedoso. Las tareas más simples, como la generación de código, la creación de pruebas o las refactorizaciones repetidas, pueden confiarse a modelos de pesos abiertos (« open-weight »), explotados directamente por la empresa.
Una pasarela, o « gateway », puede orientar cada solicitud según su complejidad, la sensibilidad de los datos, su costo y su latencia. El primer modelo se emplea así únicamente cuando la situación lo justifica. Como resume el autor, « Meter the exception, not the workload », es decir: medir la excepción, y no la carga de trabajo.
Los modelos de pesos abiertos hacen que esta distribución sea cada vez más practicable. Según los benchmarks de ingeniería de software citados, los mejores entre ellos pueden aproximarse a las prestaciones de punta en ciertas tareas. Esta observación no garantiza la equivalencia en todos los repositorios de código ni en todos los flujos de trabajo. Por lo tanto, se recomienda evaluar a los candidatos con el propio código, las propias pruebas y los propios criterios de aceptación antes de confiarles trabajo en producción.
Cambiar la economía de los usos repetidos
Queda por determinar quién posee la capacidad de cálculo. Con una inferencia alquilada, cada llamada se suma a la factura. Con una capacidad propia, la mayor parte del costo se asume desde el principio, de modo que cada llamada adicional se vuelve más barata a medida que aumenta el uso.
