Anton Brilliantov mide el coste real de cada iteración de código generado por IA
El ingeniero publica una tabla de métricas por tag que separa el tiempo de ejecución del agente del esfuerzo humano, revelando patrones de calidad y deuda técnica.
Anton Brilliantov, ingeniero de software especializado en PHP y Go, ha publicado un análisis detallado sobre los costes operativos de trabajar con agentes de código en un monólito PHP que está migrando a servicios en Go. Su tesis central es que una iteración costosa no es un defecto del ejecutor, sino del texto o contexto que se le suministra. Para demostrarlo, ha establecido una unidad de medida cerrada y estricta que excluye el tiempo de redacción del prompt y la revisión humana.
La tabla de medición
El artículo se centra en una tabla de datos que va del tag v0.1.0 al HEAD de un servicio específico. La métrica clave que Brilliantov vigila es la relación entre líneas de test y líneas de código. Esta cifra sube de 0.45 en los primeros tags a 1.25 en los últimos, sin bajar de 1.14 desde la versión 1.0.0. Para el autor, este índice es la señal de advertencia temprana más barata disponible: si la relación cae, significa que llega código sin la cobertura de pruebas correspondiente.
Otro dato que destaca es el tamaño medio de archivo. Mientras que en v0.1.0 era de 50 líneas, a partir de v1.4.0 se estabiliza en 39 líneas. Esto ocurre simultáneamente con un crecimiento explosivo del número de paquetes, que pasa de 13 a 252. Brilliantov interpreta esto como la señal de que el servicio crece por expansión lateral (nuevos paquetes) en lugar de engrosar archivos existentes, lo cual es la arquitectura de crecimiento diseñada.
Un punto interesante es la versión v1.0.0, donde las líneas de código cayeron de 28.095 a 25.097. No hubo eliminación de código basura, sino la consolidación de archivos repetidos de dominio en núcleos genéricos. Esa limpieza permitió que la relación test/código saltara a 1.41, el máximo histórico de la tabla, confirmando que la consolidación mejoró la calidad medible.
Metodología y cobertura
Las cifras no se introducen manualmente. Se generan ejecutando comandos predefinidos al cerrar cada tag o conjunto de prompts. El código generado no cuenta para las métricas de líneas o archivos, evitando así que la regeneración de contratos inflé falsamente la relación de calidad. La historia de tags se recorre sin revertir un árbol de trabajo, lo que permite regenerar la tabla en cualquier momento sin estado local.
Brilliantov también desglosa los costes por conjuntos de trabajo. Por ejemplo, la extracción de un servicio a la plataforma en la fase A requirió 7 iteraciones y 2 horas y 50 minutos de trabajo del ejecutor, frente a unas 1 hora y 30 minutos de tiempo calendario con dos ejecutores en paralelo. La cobertura total se sitúa en el 86,7%, pero el autor evita la cifra agregada y nombra los cinco paquetes con peor cobertura, tres de ellos al 0,0%, porque una media alta puede ocultar módulos sin pruebas.
El artículo no ofrece una herramienta descargable ni un benchmark universal. Es un cuaderno de campo sobre disciplina de medición. Para quien opera agentes de IA, el valor no está en replicar los números exactos, sino en adoptar la idea de que las métricas de calidad deben generarse automáticamente por tag y mantenerse en un ritmo que solo suba, exigiendo a los agentes que cada incremento de código venga acompañado de pruebas suficientes.
