Calidad del código generado por LLM: un estudio práctico de 12 proyectos

La mayor parte del debate sobre el código generado por IA gira en torno a si funciona. Es la pregunta equivocada. Lo que importa en los sistemas de producción es si funciona de forma fiable, si pueden mantenerlo ingenieros que no lo escribieron y si introduce defectos a un ritmo compatible con la entrega continua.

Nos propusimos responder a estas preguntas 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 lo construyeron entre uno y tres ingenieros sénior en el papel de orquestadores, mientras los agentes de IA generaban la mayor parte del código de producción a partir de encargos estructurados y bajo revisión humana.

Los proyectos abarcan backends empresariales, aplicaciones móviles multiplataforma, portales web y sistemas con aprendizaje automático integrado. En conjunto suman más de 200.000 líneas de código, más de 1400 pruebas automatizadas y más de 350 puntos de conexión de API REST. Cada métrica puede rastrearse en el historial de Git, los registros de CI/CD y los gestores de incidencias.

Medimos tres dimensiones: cobertura de pruebas (cobertura de líneas y de ramas según la 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).

Conclusión 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 reiterada 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 habitual de su trabajo cuando reciben un encargo bien acotado. El coste de escribir una prueba se reduce casi a cero cuando el agente lo produce junto con la implementación. Lo que resulta caro en los flujos de trabajo convencionales, los conjuntos de pruebas exhaustivos, pasa a ser el resultado natural del desarrollo orquestado por IA.

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

Conclusión 2: la densidad de defectos es menor, y la causa es la disciplina de revisión

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, porque no lo hace. En nuestros datos, aproximadamente el 12 % del código generado por IA requirió modificaciones durante la revisión humana antes de integrarse. La baja tasa de defectos procede del proceso de revisión: cada línea producida por la IA pasa por la evaluación de un ingeniero sénior antes de incorporarse a la base de código. La combinación de la velocidad de generación de la IA y el rigor de la revisión humana da como resultado un código que se escribe deprisa y se examina a conciencia.

Los proyectos en los que el orquestador omitió o precipitó la revisión (identificables por unos 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 la persona que supervisa el proceso se toma en serio su función de revisión.

Conclusión 3: la documentación permite que otros mantengan el código

La mantenibilidad es la dimensión por la que los clientes preguntan menos y la que pagan durante más tiempo. Un sistema es mantenible cuando un ingeniero que no lo construyó puede entenderlo con rapidez y modificarlo con seguridad.

En el desarrollo orquestado por IA, la documentación no es un añadido de última hora, sino un subproducto del método. Todos los proyectos de la muestra se entregaron con las especificaciones que guiaron a los agentes de IA, registros de decisiones de arquitectura, documentación de la API y código comentado para explicar la intención, no la sintaxis. La misma revisión que busca defectos en el trabajo de la IA comprueba también que el código se explique por sí mismo.

Esto tiene dos consecuencias prácticas. En primer lugar, el cliente no queda atado a un proveedor: el conocimiento del sistema reside en el repositorio, no en la cabeza de quienes lo construyeron. En segundo lugar, el desarrollo puede pasar de un equipo a otro (ingenieros propios, otro proveedor o nuevas incorporaciones) con una curva de aprendizaje mínima, porque el nuevo equipo parte de las mismas especificaciones y decisiones que el original.