Encontrar y corregir problemas de rendimiento con agentes de IA

Dale datos de profiling en lugar de dejarlo adivinar, hipótesis antes de arreglar, y mide siempre antes y después; si no, el agente solo "optimiza" eliminando comportamiento.

Sin datos de medición no hay hallazgo

Un agente al que solo le dicen "la app va lenta" adivina igual que al depurar sin un stacktrace. Dale salidas reales de profiling: mediciones de tiempo, una exportación de flamegraph, logs de consultas a base de datos con sus tiempos de ejecución. Las cifras concretas muestran dónde se pierde realmente el tiempo, no dónde se "siente" que se pierde.

Hipótesis antes de arreglar

Igual que al depurar: primero haz que nombre las posibles causas, ordenadas por el impacto que se sospecha, y después prueba una de forma deliberada. Una optimización sin una hipótesis previa a menudo acierta en el sitio equivocado: rápida de hacer, pero inútil.

Medir antes y después

Cada optimización necesita un benchmark antes y después, en las mismas condiciones. Sin una cifra de comparación no sabes si un cambio realmente sirvió de algo, solo que se siente más rápido.

Microoptimización frente a optimización de arquitectura

Los cambios pequeños (un bucle, una consulta) se implementan rápido, pero a menudo aportan poco. La mayor ganancia suele estar en decisiones de arquitectura: un problema de consultas N+1, un recálculo innecesario, la falta de caché. Un agente debería nombrar ambas categorías, y decirte cuál tendría mayor impacto.

La trampa: optimizar eliminando comportamiento

Un agente puede hacer las cosas "más rápidas" simplemente recortando trabajo: saltándose una validación, sirviendo una caché con datos obsoletos en lugar de frescos, o codificando un resultado a fuego. Eso se ve bien en el benchmark, pero es un bug de corrección. Después de cada cambio de rendimiento, comprueba si el resultado sigue siendo correcto, no solo si es más rápido.

EJEMPLO

Prompt: "Aquí tienes la exportación de profiling de /api/search (adjunta). Nombra las tres causas más probables de la latencia de 800 ms, ordenadas por el impacto que se sospecha. No cambies nada todavía. Después, mide antes/después con el mismo comando de benchmark y ejecuta la suite de tests existente."

🛠️ EJERCICIO — PRUÉBALO TÚ

Toma una función deliberadamente lenta (por ejemplo, un bucle anidado o una consulta N+1) y haz que un agente la optimice de forma sistemática.

Mide el tiempo de ejecución actual con un comando de benchmark fijo y anota la cifra.
Haz que el agente primero nombre la causa más probable, sin cambiar nada.
Después, deja que optimice, ejecuta de nuevo el mismo benchmark y corre los tests existentes antes de aceptar la corrección.

✅ AUTOEVALUACIÓN

☐ ¿Ha bajado el tiempo de ejecución de forma demostrable (cifra frente a cifra), no solo en sensación?
☐ ¿Siguen en verde todos los tests existentes?
☐ ¿Eliminó o debilitó el agente algún comportamiento para parecer más rápido?

QUIZ RÁPIDO

¿Qué trampa deberías vigilar especialmente en la optimización de rendimiento asistida por IA?