🤖 AI

AI-Generated Code Is Not Reproducible (Yet): An Empirical Study of Dependency Gaps in LLM-Based Coding Agents

Este estudio empírico revela que el código generado por agentes de IA no es completamente reproducible en entornos limpios, ya que solo el 68,3% de los proyectos se ejecutan correctamente y presentan una expansión significativa de dependencias ocultas en comparación con las declaradas.

Autores originales: Bhanu Prakash Vangala, Ali Adibifar, Ashish Gehani, Tanu Malik

Publicado 2026-03-25

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Bhanu Prakash Vangala, Ali Adibifar, Ashish Gehani, Tanu Malik

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que le pides a un chef robot superinteligente (una Inteligencia Artificial) que te prepare una receta completa para un pastel. El robot te entrega:

La lista de ingredientes (el código).
Una nota que dice: "Necesitas harina y huevos" (las dependencias).
Instrucciones breves.

Tu expectativa es que, al llegar a tu cocina, solo tengas que comprar harina y huevos, mezclarlo todo y... ¡tada! Un pastel perfecto.

Pero, ¿qué pasa realmente?

Este estudio científico es como un grupo de inspectores de cocina que decidieron probar a tres de estos chefs robots (Claude, Gemini y Codex) con 300 recetas diferentes. Lo que descubrieron fue una sorpresa enorme: la mayoría de las recetas no funcionaban tal cual las entregaron.

Aquí te explico los hallazgos clave con analogías sencillas:

1. El problema de la "Lista de Ingredientes Incompleta"

Cuando el robot dice "necesitas solo harina y huevos", en realidad, para que el pastel funcione, necesitas 37 ingredientes.

La realidad: El robot olvidó mencionar el azúcar, la levadura, la mantequilla, la esencia de vainilla, y hasta el papel encerado.
El resultado: Llegas a tu cocina, compras lo que te dijo el robot, intentas hornear y... ¡bum! El pastel se deshace o no sube. Tienes que parar, buscar qué falta, comprarlo y volver a intentar.
En el estudio: Solo el 68% de los proyectos funcionaron "de caja" (sin que nadie tuviera que arreglar nada). El resto falló porque faltaban "ingredientes" (librerías de programación) que el robot no mencionó.

2. El "Efecto Hielo" (Dependencias Ocultas)

Imagina que el robot te dice que necesitas un solo bloque de hielo para enfriar tu bebida. Pero, al poner ese bloque en tu vaso, descubres que ese bloque de hielo arrastra consigo 12 cubitos más que no viste venir.

La analogía: En programación, instalar un paquete (como "harina") a veces descarga automáticamente otros 10 o 20 paquetes ocultos (como "azúcar" y "levadura") que el robot no supo explicar.
El dato impactante: En el lenguaje Java, por cada cosa que el robot dice que necesitas, en realidad se instalan 18 cosas. ¡Es una explosión de ingredientes ocultos! En Python, es un poco menos (12 veces más), y en JavaScript, el robot a veces incluso exagera y dice que necesitas más de lo que realmente se usa.

3. No todos los robots son iguales (Especialistas Ocultos)

El estudio descubrió que cada chef robot tiene sus "superpoderes" y sus "puntos débiles", aunque nadie se los había dicho:

Gemini: Es un genio absoluto cocinando recetas en Python (100% de éxito), pero cuando le pides una receta en Java (un tipo de cocina más compleja), falla casi todo el tiempo. Es como si fuera un chef experto en postres pero terrible en carnes.
Claude: Es el chef más equilibrado. Le va muy bien con Java (donde los otros fallan) y también con Python. Es el más confiable si quieres cocinar de todo.
Codex: Es bueno con Python, pero a veces escribe recetas tan desordenadas que ni siquiera se pueden leer (errores de sintaxis).

4. El verdadero culpable no son solo los ingredientes

El título del estudio habla de "huecos en las dependencias" (ingredientes faltantes), pero la investigación reveló algo más grave:

Solo el 10% de los fallos fue por ingredientes faltantes.
El 52% de los fallos fue porque el robot escribió la receta mal. Escribió "batir los huevos" en lugar de "batir la harina", o mezcló los pasos en el orden incorrecto.
La moraleja: El problema no es solo que olviden decirte qué comprar; es que a veces la receta en sí misma está mal hecha.

5. ¿Por qué importa esto? (El costo oculto)

Si un científico o un programador usa a estos robots para hacer su trabajo, se encuentra con un problema:

El mito: "La IA me ahorrará tiempo".
La realidad: Tienes que pasar 15 minutos (en promedio) arreglando cada receta que falla. Si la IA te da 100 recetas y 30 fallan, has perdido 7 horas y media de tu vida arreglando errores que la IA debería haber evitado.

Conclusión: ¿Estamos listos para confiar en ellos?

El estudio concluye que, por ahora, la IA es como un asistente de escritura muy rápido, pero que no sabe cocinar. Puede escribir la lista de ingredientes, pero no entiende cómo funciona la cocina completa.

Para que la IA sea realmente útil y confiable, necesita aprender a:

Escribir recetas que no tengan errores de lógica.
Entender que un ingrediente simple arrastra consigo una cadena gigante de otros ingredientes ocultos.
Probar su propia receta en una cocina limpia antes de entregártela.

En resumen: La IA genera código que parece completo, pero a menudo es como un castillo de naipes: se ve bonito, pero si intentas usarlo sin arreglarlo primero, se cae. La comunidad científica y los desarrolladores deben exigir que la IA no solo "escriba código", sino que garantice que ese código funcione de verdad en cualquier lugar.

Resumen Técnico: Estudio Empírico sobre la Reproducibilidad del Código Generado por LLM

1. Planteamiento del Problema

La aparición de Modelos de Lenguaje Grande (LLM) como agentes de codificación promete acelerar el desarrollo de software. Sin embargo, existe una crisis de reproducibilidad en la investigación computacional que se está trasladando a estas herramientas.

El núcleo del problema: Aunque los LLMs generan proyectos completos con especificaciones de dependencias (ej. requirements.txt), el código resultante a menudo no se puede ejecutar en un entorno limpio utilizando únicamente las dependencias declaradas por el modelo.
La brecha actual: Los benchmarks existentes (como HumanEval o MBPP) evalúan la corrección funcional asumiendo que los entornos ya son reproducibles. Esto ignora un fallo crítico: el código no puede ser "correcto" si no se puede ejecutar sin intervención manual adicional.
La pregunta de investigación: ¿Puede un desarrollador tomar un proyecto generado por un LLM, instalar solo las dependencias especificadas en un entorno limpio y ejecutarlo exitosamente?

2. Metodología

Los autores realizaron un estudio sistemático y empírico para cuantificar la "Fiabilidad Ejecutable" (Executable Reliability).

Agentes Evaluados: Se probaron tres agentes de codificación LLM de última generación:
- Claude Code (Opus 4.1)
- OpenAI Codex (0.52.0)
- Gemini Code (2.5 Pro)
Dataset: Se generaron 300 proyectos completos a partir de 100 prompts estandarizados. Los prompts solicitaban explícitamente código reproducible con especificaciones completas de dependencias.
Distribución de Lenguajes:
- Python: 40 prompts (120 proyectos).
- JavaScript: 35 prompts (105 proyectos).
- Java: 25 prompts (75 proyectos).
Entorno de Prueba: Se utilizaron instancias AWS EC2 (Ubuntu 22.04) con un entorno "limpio" reseteado entre pruebas, conteniendo solo 91 paquetes base del sistema.
Protocolo de Evaluación:
1. Se intenta ejecutar el código usando exclusivamente las dependencias declaradas por el LLM.
2. Si falla, se aplica un protocolo de resolución iterativa (Algoritmo 1) para diagnosticar si el fallo se debe a dependencias faltantes, errores de sintaxis o lógica.
3. Métrica principal: Solo se cuenta como "éxito" la ejecución exitosa sin ninguna intervención manual (depuración o adición de paquetes).

3. Marco Conceptual: Análisis de Dependencias de Tres Capas

El estudio introduce un marco innovador para entender las fallas de reproducibilidad, diferenciando tres capas de dependencias:

Dependencias Reclamadas ( $D_c$ ): Lo que el LLM especifica explícitamente en los archivos de configuración.
Dependencias Funcionales ( $D_w$ ): Lo que realmente se necesita tras depurar (incluye las reclamadas más las faltantes descubiertas por errores de importación).
Dependencias de Tiempo de Ejecución ( $D_r$ ): El cierre transitivo completo de paquetes que se cargan realmente al ejecutar el código.

Métricas Clave:

Brecha de Completitud ( $\Delta_{completeness}$ ): Diferencia entre $D_w$ y $D_c$ (paquetes olvidados por el LLM).
Multiplicador de Tiempo de Ejecución ( $\rho_{runtime}$ ): La relación entre $D_r$ y $D_c$ , revelando la complejidad oculta (dependencias transitivas no declaradas).

4. Resultados Principales

Tasa General de Reproducibilidad: Solo el 68.3% de los proyectos (205 de 300) se ejecutaron correctamente "out-of-the-box". El 31.7% restante falló inmediatamente.
Variación por Lenguaje:
- Python: 89.2% de éxito (el más reproducible debido a su gestión simple de dependencias).
- JavaScript: 61.9% de éxito.
- Java: 44.0% de éxito (el más problemático debido a la complejidad de Maven y dependencias transitivas).
Explosión de Dependencias Ocultas:
- Existe una brecha masiva entre lo declarado y lo real. El multiplicador promedio de tiempo de ejecución es de 13.5x.
- Ejemplo: Un proyecto de Python que reclama 3 paquetes requiere en realidad un promedio de 37 paquetes en tiempo de ejecución.
- En Java, este multiplicador alcanza 18.4x, mientras que en JavaScript es sorprendentemente bajo (1.0x), sugiriendo que los LLMs a veces sobre-especifican dependencias en JS o que el análisis de npm captura solo dependencias directas.
Especialización Oculta de Agentes:
- Gemini: Logró un 100% de éxito en Python, pero solo un 28% en Java.
- Claude: Mostró el mejor rendimiento en Java (80%), superando significativamente a sus competidores en este lenguaje.
- Codex: Fuerte en Python (87.5%) pero débil en Java (24%).
Causas de Fallo: Contrario a la intuición inicial, la mayoría de los fallos (52.6%) no se debieron a dependencias faltantes, sino a errores de generación de código (sintaxis incorrecta, rutas de archivos erróneas, variables no inicializadas). Las dependencias faltantes solo representaron el 10.5% de los fallos.

5. Contribuciones Clave

Definición de "Fiabilidad Ejecutable": Una nueva métrica que mide la probabilidad de que un proyecto se ejecute en un entorno limpio usando solo lo proporcionado por la IA.
Marco de Tres Capas: Una metodología para cuantificar la brecha entre lo que la IA dice que necesita y lo que realmente necesita el entorno de ejecución.
Evidencia Empírica de la Crisis: Demostración de que la "compleción automática" de código no equivale a la generación de software listo para producción, revelando costos ocultos de depuración (promedio de 15 minutos por proyecto fallido).
Análisis de Especialización: Revelación de que los modelos tienen sesgos fuertes hacia ciertos lenguajes y ecosistemas, lo cual no está documentado en sus especificaciones comerciales.

6. Significado e Implicaciones

Para la Ciencia Computacional: El uso de LLMs para generar scripts de investigación introduce un riesgo de irreproducibilidad. Los investigadores deben publicar no solo el código, sino el cierre completo de dependencias (archivos .lock), ya que las declaraciones originales de la IA son insuficientes.
Para el Desarrollo de Software: Existe una "deuda técnica oculta". Las organizaciones no pueden asumir un rendimiento uniforme de los agentes de IA; deben seleccionar herramientas basadas en su pila tecnológica específica (ej. usar Claude para Java, Gemini para Python).
Para la Investigación de IA: Los benchmarks actuales son insuficientes. Se necesitan nuevas evaluaciones que prioricen la reproducibilidad y la corrección del contexto de ejecución, no solo la lógica algorítmica.
Conclusión Final: Los LLMs actuales actúan como "autocompletado sofisticado" pero no como "socios de desarrollo" completos. Para que el código generado por IA sea verdaderamente útil, los modelos deben aprender a especificar entornos de ejecución completos y probar su propio código en entornos limpios antes de entregarlo.