Análisis de Codeflash: 118 Errores de Rendimiento Encontrados en Dos PRs Escritos con Claude Code

Análisis de Rendimiento del Código Generado por IA

Codeflash utilizó su propia herramienta de optimización para analizar dos solicitudes de extracción escritas con Claude Code. Las características analizadas fueron el soporte del lenguaje Java (52.000 líneas entre analizadores sintácticos, extractores de contexto, instrumentación, ejecutores de pruebas y transformadores de aserciones) y el soporte del framework React (24.000 líneas cubriendo descubrimiento de componentes, perfilado, evaluación comparativa y reemplazo de código).

Hallazgos Clave

Solo en estas dos solicitudes de extracción, Codeflash identificó 118 funciones con un rendimiento significativamente peor del necesario. Estos no eran casos extremos — eran funciones en la ruta crítica de su optimizador, ejecutándose en cada trabajo de optimización para cada usuario.

Patrones de Ineficiencia

• Algoritmos catastróficamente ineficientes: Una función de extracción de tipos en el módulo de contexto de Java era 446 veces más lenta de lo necesario, implementada con escaneo de cadenas ingenuo en lugar de extracción basada en tree-sitter. Un buscador de funciones auxiliares era 74 veces más lento por razones similares.
• Cómputo redundante: Las funciones volvían a analizar datos ya analizados, volvían a recorrer árboles ya recorridos, reconstruían cadenas carácter por carácter. Un constructor de llamadas de destino de aserción era 19 veces más lento debido a recalcular conversiones de bytes fuente en cada invocación en lugar de usar caché. Una utilidad de inserción de importaciones en la solicitud de extracción de React era 36 veces más lenta debido a recorridos de árbol redundantes.
• Falta de caché: Funciones llamadas repetidamente con las mismas entradas calculaban resultados desde cero cada vez. Un extractor de definiciones de tipos en la solicitud de extracción de React era 16 veces más lento sin memorizar resultados intermedios, y un verificador de exportaciones era 9 veces más lento por la misma razón.
• Estructuras de datos subóptimas: Listas donde deberían haber conjuntos, búsquedas lineales donde funcionarían búsquedas hash, concatenación de cadenas en bucles en lugar de uniones. Un analizador de equilibrio de llaves era 3 veces más lento debido a elecciones ineficientes de estructuras de datos.

Ejemplo Concreto: Mejora de Rendimiento de 19x

Claude Code escribió esta función para convertir desplazamientos de bytes a posiciones de caracteres:

# Llamada para cada nodo AST encontrado en el archivo
start_char = len(content_bytes[:start_byte].decode("utf8"))
end_char = len(content_bytes[:end_byte].decode("utf8"))

Codeflash la reemplazó con:

# Construye una tabla de búsqueda una vez, luego búsqueda binaria para cada nodo
from bisect import bisect_right
cum_bytes = [0]
for ch in source.decode("utf8"):
    cum_bytes.append(cum_bytes[-1] + len(ch.encode("utf8")))
start_char = bisect_right(cum_bytes, start_byte) - 1
end_char = bisect_right(cum_bytes, end_byte) - 1

El código original decodifica todo el prefijo de bytes desde el principio del archivo en cada llamada — O(n) por búsqueda. Para un archivo con cientos de nodos AST, esto significa volver a decodificar los mismos bytes cientos de veces. La versión optimizada construye una tabla de búsqueda una vez y usa búsqueda binaria — O(n) una vez, luego O(log n) por búsqueda.

El artículo enfatiza que esto no se trata de si usar agentes de codificación con IA (ellos recomiendan usarlos), sino de lo que sucede con el código después de hacerlo. Estos problemas de rendimiento representan una nueva categoría de deuda técnica que los agentes de IA introducen sistemáticamente al enfocarse en la corrección y legibilidad sobre la optimización del rendimiento.