El Punto Ciego del Rendimiento: Los Agentes de IA Escriben Código Lento

El código pasó todas las pruebas. El linter estaba limpio. El verificador de tipos estaba satisfecho. La revisión de código lo aprobó. La función era 446 veces más lenta de lo necesario.¹

Codeflash, una herramienta de optimización del rendimiento de código, analizó dos pull requests generados completamente por Claude Code: 76.000 líneas entre un módulo de soporte del lenguaje Java y una integración con un framework de React.¹ Encontraron 118 funciones con problemas significativos de rendimiento. Las ralentizaciones iban de 3x a 446x. El peor caso: una función de extracción de tipos que reescaneaba un AST completo en cada llamada en lugar de almacenar en caché el recorrido. Comportamiento correcto. Rendimiento catastrófico.

El hallazgo no es una anomalía. SWE-fficiency, un benchmark de 498 tareas de optimización en repositorios como NumPy, Pandas y SciPy, encontró que los agentes de LLM con mejor rendimiento lograron menos de 0,15x la aceleración que un desarrollador experto logró en las mismas tareas.² Un estudio separado que evaluó Claude 3.5, OpenAI o1 y Llama 3.2 en 26 códigos de computación de alto rendimiento encontró que Claude 3.5 logró una aceleración de 1,02x en optimización serial (funcionalmente cero mejora) mientras producía código incorrecto en el 30% de los casos.³ El propio análisis de Codeflash de 100.000 funciones de código abierto encontró que el 90% de las optimizaciones sugeridas por IA son incorrectas o no proporcionan un beneficio medible, y entre las correctas, el 73% entregó ganancias por debajo del 5%.⁴

El rendimiento es la dimensión que las herramientas de codificación con IA no ven. Cada puerta de calidad estándar (linters, verificadores de tipos, suites de pruebas, revisión de código) valida la corrección. Ninguna valida la eficiencia. El resultado: un impuesto invisible sobre cada línea de código generado por IA que pasa todas las verificaciones y degrada cada sistema en el que entra.

TL;DR

Los agentes de IA escriben código correcto pero lento. Codeflash encontró 118 problemas de rendimiento en 76.000 líneas de salida de Claude Code, con ralentizaciones de 3x a 446x.¹ Los benchmarks académicos confirman el patrón: los LLMs logran menos de 0,15x la aceleración experta en tareas de optimización.² La causa es estructural: los datos de entrenamiento recompensan la corrección, y las puertas de calidad estándar no miden el rendimiento. Superar esto requiere infraestructura de rendimiento: benchmarks junto a pruebas unitarias, detección de patrones basada en AST en hooks, y perfilado como paso estándar del flujo de trabajo.

Conclusiones Clave

Para desarrolladores individuales. Agregue time o un perfilador al paso de verificación después de cada función generada por IA en una ruta crítica. La ralentización de 446x pasó todas las pruebas y todos los linters. La única puerta que la habría detectado es un benchmark. Trate “funciona” como necesario pero no suficiente. Pregunte “¿qué tan rápido funciona?” como seguimiento estándar.

Para líderes de equipo. La regresión de rendimiento es la forma invisible de la Meseta de Lo Suficientemente Bueno. El código generado por IA que pasa todas las pruebas funcionales crea una falsa sensación de completitud. Agregue benchmarks de rendimiento al CI junto a las pruebas unitarias. Los datos de Faros AI muestran que los equipos asistidos por IA completan un 21% más de tareas mientras generan un 9% más de errores.⁵ Los errores de rendimiento no se cuentan en ese 9% porque nadie los mide.

Para ingenieros de plataforma. Construya la puerta que falta. Los linters verifican el estilo. Los verificadores de tipos verifican contratos. Las suites de pruebas verifican el comportamiento. Nada verifica la complejidad algorítmica ni las características de tiempo de ejecución en el pipeline estándar de CI. La detección de patrones basada en AST (reglas de Semgrep, patrones de ast-grep, o hooks personalizados) puede detectar los antipatrones de rendimiento más comunes: recorridos redundantes, falta de memoización y copias innecesarias.

Cómo Se Ven 118 Errores

El análisis de Codeflash de dos PRs de Claude Code proporciona el conjunto de datos públicos más granular sobre problemas de rendimiento en código generado por IA.¹ Los dos PRs sumaron 76.000 líneas: 52.000 para soporte del lenguaje Java y 24.000 para soporte de React. Ambos eran funcionales. Ambos pasaron sus suites de pruebas. Ambos contenían código que se degradaría bajo carga real.

Las causas raíz se agrupan en cuatro categorías:

Algoritmos ineficientes. La categoría dominante. Una función que convertía offsets de bytes a posiciones de línea usaba escaneo O(n) en lugar de búsqueda binaria O(log n) con una tabla de búsqueda precalculada. El código era legible. Los nombres de variables eran descriptivos. La lógica era correcta. La clase de complejidad era incorrecta.

Computación redundante. Funciones que re-analizaban, re-recorrían o recalculaban valores que podrían almacenarse en caché. El buscador de funciones auxiliares re-analizaba el mismo archivo fuente en cada llamada. Un decorador de memoización habría reducido la sobrecarga de 74x a cero después de la primera invocación.

Falta de caché y memoización. Estrechamente relacionado con la computación redundante pero distinto en que los datos estaban disponibles en un alcance más amplio. El extractor de definiciones de tipos recorría el AST completo cada vez en lugar de construir un índice en el primer acceso. El patrón: el agente escribe cada función de forma aislada sin considerar cómo se llamará en un bucle.

Estructuras de datos subóptimas. Escaneos de listas donde conjuntos o diccionarios proporcionarían búsqueda O(1). El verificador de exports iteraba a través de una lista para verificar pertenencia. Una conversión a conjunto habría eliminado la sobrecarga de 9x por completo.

Por Qué los Agentes Producen Código Lento

El punto ciego del rendimiento no es un error en ningún modelo particular. La causa es estructural, y opera en tres niveles: datos de entrenamiento, criterios de evaluación y suposiciones del flujo de trabajo.

Los Datos de Entrenamiento Recompensan la Legibilidad

Los LLMs aprenden de la distribución de código en sus datos de entrenamiento. La implementación más común de cualquier algoritmo es la ingenua. El código de tutoriales prioriza la claridad. Las respuestas de Stack Overflow priorizan la corrección. El código de código abierto contiene versiones optimizadas para rendimiento, pero están superadas en número por implementaciones directas por órdenes de magnitud.

El patrón se extiende más allá del rendimiento. Stanford encontró que los desarrolladores asistidos por IA escribieron código inseguro con más frecuencia en cuatro de cinco tareas de seguridad, y esos mismos desarrolladores tenían más probabilidades de creer que su código era seguro.⁸ La brecha de confianza se aplica igualmente al rendimiento: el código se ve limpio, se lee bien y produce una salida correcta, por lo que el desarrollador confía en él. Los investigadores de SWE-fficiency encontraron que los agentes tienen dificultades para localizar oportunidades de optimización y razonar sobre la ejecución a través de funciones.² Los LLMs hacen ediciones pequeñas y específicas de la entrada en lugar de mejoras algorítmicas. Cuando se les pide optimizar, el modelo recurre a la transformación correcta más cercana (agregar un caché, hacer inline de una función) en lugar de reconsiderar el enfoque algorítmico. El resultado es micro-optimización superpuesta sobre estructuras fundamentalmente ineficientes.

Ninguna Puerta de Evaluación Mide el Rendimiento

Las puertas de calidad estándar validan lo que están diseñadas para validar:

Cada puerta que la industria ha estandarizado opera sobre la corrección. Las pruebas de rendimiento existen (perfiladores, frameworks de benchmarking, herramientas de pruebas de carga), pero ocupan un flujo de trabajo separado que la mayoría de los equipos no integran en su pipeline de CI y que los agentes de IA nunca invocan por iniciativa propia.

El vacío de verificación que explica el muro del 10% de productividad se extiende más allá de la corrección funcional. El vacío no es solo “¿funciona el código?” sino “¿tiene buen rendimiento el código?”, y ninguna puerta estándar hace la segunda pregunta.

Los Agentes Escriben Funciones, No Sistemas

La causa más profunda es arquitectónica. Un agente de IA genera código una función, un archivo, una tarea a la vez. El alcance de cada generación es el requisito inmediato. Los problemas de rendimiento emergen en los límites: cuando una función escrita para invocación única se llama en un bucle, cuando un parser escrito para entradas pequeñas recibe archivos grandes, cuando una búsqueda escrita para corrección se ejecuta en cada solicitud.

El modo de fallo de Visión de Túnel de la taxonomía de fallos de agentes describe este patrón a nivel funcional: el agente perfecciona un componente sin verificar los puntos de integración. El punto ciego del rendimiento es la Visión de Túnel aplicada a las características de tiempo de ejecución. La función es perfecta de forma aislada. El sistema se degrada porque las características de rendimiento de la función nunca se evaluaron en contexto.

El Impuesto Invisible

El punto ciego del rendimiento sería un problema menor si el código generado por IA fuera una fracción pequeña de los sistemas en producción. Las cifras actuales lo convierten en un riesgo sistémico.

DX mide el código creado por IA en un 26,9% del código fusionado en producción, y sigue en aumento.⁶ Faros AI (un proveedor de analítica DevOps) encontró que los equipos asistidos por IA fusionan PRs un 154% más grandes que las líneas base pre-IA, completan un 21% más de tareas y generan un 9% más de errores por desarrollador.⁵ La cifra del 9% cuenta defectos funcionales. Las regresiones de rendimiento están completamente ausentes de la métrica porque la mayoría de los equipos no tienen una línea base de rendimiento contra la cual medir regresiones.

La matemática de la acumulación importa. El ensayo controlado aleatorizado de METR encontró que los desarrolladores experimentados tardaron un 19% más con herramientas de IA, pero creían que la IA los aceleró en un 20%.⁹ Si los propios desarrolladores no pueden evaluar con precisión el impacto, la deuda de rendimiento se acumula sin ser detectada. Con el 26,9% del código fusionado portando deuda potencial de rendimiento y la organización sin ninguna puerta de rendimiento, la deuda se acumula con cada sprint. El informe DORA 2025 encontró que la adopción de IA se correlaciona con un aumento de la inestabilidad en las entregas incluso cuando la productividad mejoró.⁷ El informe no atribuye la inestabilidad al rendimiento específicamente, pero el mecanismo encaja: más código, fusionado más rápido, con características de rendimiento que nunca se midieron.

El 52% de los líderes de ingeniería encuestados por Codeflash reportaron que el aumento del uso de IA genera problemas de rendimiento en sus bases de código.⁴ El número es autorreportado y proviene de un proveedor (Codeflash vende herramientas de optimización de rendimiento), pero la dirección es consistente con todos los conjuntos de datos independientes. Más código generado por IA, fusionado con puertas de calidad estándar, produce sistemas que funcionan correctamente y se ejecutan lentamente.

El muro del 10% de productividad tiene una dimensión de rendimiento que los datos originales no revelan. Si la IA acelera la generación de código en un 10% pero el código generado porta deuda de rendimiento que surge semanas o meses después como incidentes en producción, la ganancia neta de productividad se reduce aún más. El muro no es solo “la IA no hace más rápidos a los desarrolladores”. El muro incluye “la IA hace el código más lento de maneras que nadie mide”.

Cómo Se Ve la Detección

La detección de rendimiento para código generado por IA requiere infraestructura que la mayoría de las organizaciones no tienen. Las herramientas existen. La integración no.

Puertas de Benchmark en CI

La solución más directa: hacer benchmark de las rutas críticas y fallar el build en caso de regresiones. Existen frameworks para cada lenguaje principal: pytest-benchmark para Python, JMH para Java, criterion para Rust, benchmark.js para JavaScript. El desafío no es el tooling sino la práctica. Los benchmarks requieren líneas base, y las líneas base requieren que alguien escriba el benchmark inicial antes de que el código generado por IA pueda mostrar regresiones.

La implementación mínima viable: identifique las 10-20 funciones en la ruta crítica, escriba benchmarks para ellas y agréguelos al CI. Los 118 errores que Codeflash encontró estaban concentrados en parsers y funciones de recorrido de AST: el núcleo computacional, no el código de conexión. Los problemas de rendimiento se agrupan en los mismos lugares cada vez.

Detección de Patrones Basada en AST

El análisis estático puede detectar los patrones más flagrantes sin ejecutar el código. Semgrep y ast-grep admiten reglas personalizadas que detectan:

• List comprehensions o bucles dentro de otros bucles donde la colección interna no cambia (candidato a caché)
• Verificaciones .index() o in contra listas que podrían ser conjuntos
• E/S de archivos o llamadas de red dentro de bucles sin agrupamiento
• Llamadas repetidas a funciones con los mismos argumentos (candidato a memoización)

Estas reglas no reemplazan el perfilado. Detectan los patrones que representan la mayoría de los 118 errores: computación redundante, falta de caché, estructuras de datos incorrectas.

Conciencia de Rendimiento Basada en Hooks

Para los usuarios de Claude Code, un hook PreToolUse puede inyectar conciencia de rendimiento en el flujo de trabajo del agente. El enfoque es paralelo al patrón de puerta de evidencia usado para la corrección:

check_performance_patterns() {
    local file_path="$1"
    local ext="${file_path##*.}"

    case "$ext" in
        py)
            # Detect nested loops with repeated computation
            if grep -Pn 'for .+ in .+:\n.*for .+ in .+:' "$file_path" 2>/dev/null; then
                echo "WARNING: Nested loops detected in $file_path"
                echo "Verify inner loop does not recompute invariant values."
            fi
            # Detect list membership checks that should be sets
            if grep -n '\bin\b.*\[' "$file_path" 2>/dev/null | grep -v '#'; then
                echo "WARNING: List membership check in $file_path"
                echo "Consider converting to a set for O(1) lookup."
            fi
            ;;
        js|ts)
            # Detect Array.includes or indexOf in loops
            if grep -n '\.includes\|\.indexOf' "$file_path" 2>/dev/null; then
                echo "NOTE: Array search detected in $file_path"
                echo "If called in a loop, consider a Set or Map."
            fi
            ;;
    esac
}

El hook no es un perfilador. Genera conciencia. El objetivo es el mismo que el de cualquier otra puerta de calidad: hacer visible lo invisible para que el desarrollador (o el agente en una iteración posterior) pueda abordarlo antes de que el código se despliegue.

La Infraestructura que Falta

El patrón en cada punto de datos es el mismo que explica el muro del 10% de productividad y los siete modos de fallo: la IA amplifica cualquier infraestructura que exista, incluida la ausencia de infraestructura.

Las organizaciones con benchmarks de rendimiento en CI detectarán las regresiones de rendimiento generadas por IA de la misma manera que detectan las generadas por humanos. Las organizaciones sin ellos acumularán deuda de rendimiento de forma invisible. El hallazgo de “amplificador” de DORA se aplica directamente: la IA no crea el punto ciego del rendimiento. La IA lo escala.⁷

Tres inversiones mínimas cierran la brecha:

1. Haga benchmark de las rutas críticas antes de que la IA genere código alrededor de ellas. El benchmark es la línea base. Sin él, ninguna regresión es detectable. Identifique las 10-20 funciones que representan la mayor parte del tiempo de cómputo y escriba benchmarks para ellas primero.

2. Agregue linting de rendimiento basado en AST al pipeline de CI. Reglas de Semgrep o ast-grep que marquen los cuatro antipatrones dominantes (computación redundante, falta de caché, estructuras de datos incorrectas, complejidad innecesaria). Las reglas son ligeras y componibles con los pasos de linting existentes.

3. Inyecte conciencia de rendimiento en los flujos de trabajo de los agentes. Para Claude Code: un hook que marque patrones relevantes de rendimiento en archivos modificados. Para otras herramientas: un prompt que incluya “verificar complejidad algorítmica” como instrucción estándar. El objetivo no es la optimización automatizada sino la conciencia: hacer emerger la pregunta “¿es esto suficientemente rápido?” en un flujo de trabajo que actualmente no la formula.

El punto ciego no es la IA. El punto ciego es la ausencia de infraestructura de rendimiento. Cada puerta de calidad estándar que la industria ha construido valida la corrección. Ninguna valida la eficiencia. La brecha existía antes de la IA. La IA la convirtió en un problema del 26,9% del código en producción.

Fuentes