Código generado por LLM en producción: resultados de un estudio con 12 proyectos

El grueso del debate sobre código generado por IA se centra en si funciona. Es la pregunta equivocada. La pregunta relevante para sistemas en producción es si funciona de forma fiable, si puede ser mantenido por ingenieros que no lo escribieron y si introduce defectos a un ritmo compatible con la entrega continua.

Nos propusimos responder con datos, no con opiniones.

Metodología

Analizamos 12 proyectos en producción entregados entre junio de 2025 y enero de 2026 con la metodología de desarrollo orquestado por IA de NOSOTA. Cada proyecto fue construido por entre uno y tres ingenieros sénior en rol de orquestadores, con agentes de IA generando la mayor parte del código productivo bajo briefs estructurados y revisión humana.

Los proyectos abarcan backends empresariales, aplicaciones móviles multiplataforma, portales web y sistemas con integración de ML. En conjunto suman más de 200.000 líneas de código, más de 1.400 pruebas automatizadas y más de 350 endpoints REST API. Cada métrica es trazable a través del historial de Git, los logs de CI/CD y los gestores de incidencias.

Medimos tres dimensiones: cobertura de pruebas (cobertura de líneas y ramas según CI), densidad de defectos (errores por cada mil líneas de código en los primeros 90 días tras el despliegue) y mantenibilidad (tiempo que necesita un ingeniero ajeno al proyecto para implementar un cambio no trivial).

Hallazgo 1: La cobertura de pruebas supera las referencias del sector

En los 12 proyectos, la mediana de cobertura de líneas fue del 78%, y tres proyectos superaron el 85%. La cobertura de ramas — una métrica más exigente — alcanzó una media del 64%. Como referencia, las encuestas del sector sitúan de forma consistente la cobertura media de líneas entre el 40% y el 60% en bases de código empresariales.

La explicación es estructural, no heroica. Los agentes de IA generan pruebas como parte de su salida estándar cuando reciben un brief con alcance bien definido. El costo de escribir un test se desploma cuando el agente lo produce junto con la implementación. Lo que resulta caro en flujos de trabajo convencionales — suites de pruebas exhaustivas — pasa a ser el resultado natural del desarrollo orquestado por IA.

El factor decisivo es la calidad del brief. Los proyectos en los que el orquestador especificó criterios de aceptación explícitos en cada brief alcanzaron entre 15 y 20 puntos porcentuales más de cobertura que aquellos donde los requisitos de pruebas quedaron implícitos.

Hallazgo 2: La densidad de defectos es menor, pero la disciplina de revisión es la clave

La mediana de densidad de defectos en los 12 proyectos fue de 0,8 errores por cada mil líneas de código en los primeros 90 días. La referencia del sector para equipos maduros suele situarse entre 1 y 5 errores por KLOC. Dos proyectos alcanzaron cero defectos en producción durante el periodo de medición.

El resultado no se debe a que la IA genere código perfecto — no lo hace. En nuestros datos, aproximadamente el 12% del código generado por IA requirió modificaciones durante la revisión humana antes de fusionarse. La baja tasa de defectos procede del proceso de revisión: cada línea de salida de la IA pasa por la evaluación de un ingeniero sénior antes de incorporarse al código base. La combinación de velocidad de generación de la IA y rigor de la revisión humana produce código que se escribe deprisa y se depura a conciencia.

Los proyectos en los que el orquestador omitió o aceleró la revisión — identificables por tiempos de revisión más cortos en los metadatos de Git — mostraron tasas de defectos entre 3 y 4 veces superiores. La metodología funciona cuando quien ocupa el puesto de revisor se toma en serio ese mandato.