# Optimizar el rendimiento del código con IA

URL: https://agentvera.dev/es/blog/optimize-code-performance-with-ai/ · Publicado: 2026-10-27

Optimiza el rendimiento del código con IA: perfila primero, dale al agente perfiles reales, arregla consultas N+1 y bundles, y demuestra cada mejora.

**En resumen:**

- Nunca pidas a un agente que «lo haga más rápido» sin datos. Perfila primero con Chrome DevTools, Lighthouse, node --cpu-prof, py-spy o cProfile, y dale al agente el perfil, no tu suposición.
- Escribe un benchmark o una medición repetible antes del cambio; es el paso de verificación. Un cambio que no mueve el número se revierte, por ingenioso que parezca.
- Las grandes mejoras habituales son aburridas: consultas N+1, índices que faltan, bundles demasiado grandes, trabajo repetido que se puede cachear. Los agentes los encuentran y arreglan bien cuando ven las pruebas.
- Protege las mejoras con guardas contra regresiones: aserciones sobre el número de consultas, presupuestos de tamaño de bundle y benchmarks en CI, para que el próximo cambio no deshaga el trabajo sin avisar.

**Para optimizar el rendimiento del código con IA, mide antes de escribir el prompt: perfila la ruta lenta, dale el perfil al agente, pide el cambio más pequeño que elimine el punto caliente y acéptalo solo cuando un benchmark muestre la diferencia.** Los agentes de programación como Claude Code, Codex y Gemini CLI son rápidos leyendo un flame graph, rastreando una función caliente hasta quienes la llaman y reescribiendo una consulta. Sin datos, hacen lo que haría cualquiera: adivinar. Y las optimizaciones adivinadas son las caras, porque hacen el código más difícil de leer sin hacerlo más rápido.

Esta guía cubre un flujo de trabajo que funciona en la práctica: definir el objetivo, perfilar, entregar las pruebas, cambiar una sola cosa, verificar con un benchmark y asegurar la mejora con una guarda contra regresiones. Por el camino trata los problemas que causan la mayoría de las ralentizaciones en apps reales: consultas N+1, tamaño del bundle y cachés que faltan.

## Empieza con un número, no con una sensación

«El dashboard va lento» no es una tarea. Conviértelo en algo que un agente pueda comprobar:

- **Qué** va lento: un endpoint, la carga de una página, un comando de CLI, un job por lotes.
- **Cuánto** tarda ahora, medido: la latencia p95 de un endpoint, el time to interactive de una página, el tiempo de ejecución de un script.
- **Qué significa «suficientemente rápido»**: un objetivo, como «menos de 300 ms en p95» o «la importación termina en menos de un minuto para 100.000 filas».
- **En qué condiciones**: tamaño de los datos, caché fría o caliente, build de producción o servidor de desarrollo.

Este último punto evita mucho trabajo desperdiciado. Una app de React en el servidor de desarrollo, un servicio de Node sin `NODE_ENV=production` o un job de Python sobre diez filas de datos de prueba mostrarán puntos calientes que no existen en producción. Mide lo que despliegas.

## Paso 1: perfila la ruta lenta

Elige el profiler que corresponda a dónde se va el tiempo.

### En el navegador

El panel **Performance** de Chrome DevTools graba una traza: tareas largas, scripting, layout, cascadas de red. **Lighthouse** da una puntuación de laboratorio con oportunidades concretas. La CLI de Lighthouse resulta práctica porque escribe un archivo que puedes pasarle a un agente:

```bash
npm install -g lighthouse
lighthouse https://localhost:3000/dashboard \
  --only-categories=performance \
  --output=json --output-path=./lighthouse.json
```

Si tu agente admite MCP, el servidor MCP de Chrome DevTools le permite iniciar una traza de rendimiento y leer los resultados por sí mismo:

```json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}
```

### En Node.js

Node tiene un profiler de muestreo integrado. `--cpu-prof` escribe un archivo `.cpuprofile` cuando el proceso termina, que puedes abrir en el panel Performance de DevTools o pasarle a un agente:

```bash
node --cpu-prof --cpu-prof-dir=./profiles server.js
# run the slow request a few times, then stop the server
```

El flag más antiguo `--prof` escribe un log de V8 que `node --prof-process` convierte en un informe de texto, muy fácil de leer para un agente:

```bash
NODE_ENV=production node --prof server.js
node --prof-process isolate-0x*-v8.log > processed.txt
```

Para problemas de memoria, `--heap-prof` escribe un `.heapprofile` de la misma forma.

### En Python

`py-spy` muestrea un proceso en ejecución sin cambiar tu código, lo que lo convierte en la opción segura para un servicio en vivo:

```bash
py-spy top --pid 12345                    # live view, like top
py-spy record -o profile.svg --pid 12345  # flame graph
py-spy record -o profile.svg -- python import_job.py
```

Para un script que puedes lanzar tú mismo, `cProfile` de la biblioteca estándar da recuentos de llamadas exactos:

```bash
python -m cProfile -s cumtime import_job.py | head -40
```

A octubre de 2026, Python 3.15 incluye además un paquete `profiling` con un profiler estadístico (`python -m profiling.sampling`) y mantiene `cProfile` como alias de su profiler de trazado; en versiones anteriores, `cProfile` y py-spy son las herramientas a usar.

### En la base de datos

Para el tiempo de las consultas, la base de datos ya conoce la respuesta: el log de consultas lentas, `pg_stat_statements` en PostgreSQL y `EXPLAIN ANALYZE` para una consulta concreta. [Escribir SQL con IA](/es/blog/write-sql-with-ai/ "Escribir SQL con IA") explica cómo leer planes de consulta y elegir índices con un agente, así que esta guía no lo repite.

## Paso 2: dale las pruebas al agente

Ahora el agente tiene algo real con lo que trabajar. Entrégale el perfil y el contexto, y pide análisis antes que código:

```text
El endpoint /api/orders tarda unos 1,8 s en p95 en producción; el objetivo
es 300 ms. Adjunto: processed.txt de node --prof-process para 50 peticiones,
y el log de consultas lentas del mismo periodo.
No cambies código todavía. Enumera los tres principales puntos calientes,
con la prueba del perfil para cada uno (función, tiempo propio o total,
número de llamadas), la causa probable en nuestro código (archivo y línea)
y un arreglo propuesto. Ordénalos por impacto esperado.
```

Algunos hábitos hacen que este paso funcione:

- **Dale la salida en bruto, no tu resumen.** Tu resumen ya contiene tu suposición.
- **Pide pruebas para cada afirmación.** «Esta función es lenta» debe venir con un número del perfil.
- **Mantén al agente en la ruta caliente.** El código que consume el 2 % del tiempo no merece una reescritura, por feo que sea.

Si el agente dice algo como «el perfil no muestra claramente el cuello de botella», créetelo y captura un perfil mejor con más carga o con el build de producción. Es un resultado mucho mejor que una suposición segura de sí misma.

## Paso 3: escribe el benchmark antes del arreglo

El benchmark es tu paso de verificación. Escríbelo, ejecútalo sobre el código actual y guarda la referencia antes de cambiar nada.

Para un comando o un script, `hyperfine` lo ejecuta muchas veces e informa de la media y la dispersión:

```bash
hyperfine --warmup 3 'node scripts/build-report.js'
```

Para una función, usa el soporte de benchmarks de tu stack: `go test -bench=. -benchmem` en Go, `pytest-benchmark` en Python, el soporte de bench de tu runner de tests de JavaScript. Para un endpoint, una prueba de carga corta con un número fijo de peticiones contra un build de producción.

Después dile la regla al agente:

```text
Aquí tienes el benchmark y su resultado de referencia. Haz un cambio cada
vez. Después de cada cambio, ejecuta los tests y el benchmark tres veces e
informa del antes y el después. Si un cambio no mejora el resultado más allá
del ruido, reviértelo y dímelo, aunque creas que debería ayudar.
```

Dos detalles importan. Compara en la misma máquina con los mismos datos, porque los portátiles reducen su frecuencia y las cachés se calientan. Y mantén los tests ejecutándose junto al benchmark: una función más rápida que devuelve la respuesta equivocada es un bug. Si el código que optimizas no tiene tests, añádelos primero; [escribir tests unitarios con IA](/es/blog/write-unit-tests-with-ai/ "Escribir tests unitarios con IA") muestra cómo obtener tests útiles de un agente.

## Dónde se suele ir el tiempo

En apps reales, un pequeño conjunto de problemas explica la mayoría de las ralentizaciones. Estos son los que hay que revisar primero.

### Consultas N+1

El clásico: cargas una lista y luego ejecutas una consulta extra por cada elemento dentro de un bucle o una plantilla. Parece ir bien con diez filas en desarrollo y se viene abajo con dos mil en producción. El arreglo es cargar los datos relacionados en una o dos consultas, con la herramienta que ofrece tu ORM:

| Stack | Carga anticipada |
| --- | --- |
| Django | `select_related` (joins), `prefetch_related` (consulta aparte) |
| Rails | `includes`, y la gema Bullet para detectar N+1 en desarrollo |
| SQLAlchemy | `selectinload`, `joinedload` |
| Prisma | `include` |

Los agentes hacen bien este arreglo una vez que saben dónde ocurre. Activa el log de consultas, abre la página lenta una vez y dale el log al agente: un patrón de consulta repetido con distintos IDs es la huella. Luego pide el arreglo y un test que verifique el número de consultas de esa página, para que el problema no pueda volver sin que nadie se entere.

### Tamaño del bundle

En el rendimiento del front-end, el JavaScript que envías suele ser la palanca más grande. Mide primero qué hay en el bundle con `source-map-explorer` o `webpack-bundle-analyzer` (o el analizador de tu bundler), y luego busca las causas habituales:

- una librería grande importada para una sola función,
- un set de iconos completo o un paquete de locales entero arrastrado por un único import,
- componentes pesados cargados en el primer pintado que podrían cargarse en diferido,
- la misma dependencia empaquetada dos veces en versiones distintas.

Dale al agente la salida del analizador y pide cambios ordenados por bytes ahorrados. Después compara el resultado del build antes y después, igual que comparas un benchmark.

### Trabajo repetido y caché

Una caché es la respuesta correcta cuando el mismo resultado costoso se calcula una y otra vez con las mismas entradas. Es la respuesta equivocada cuando el cálculo simplemente podría abaratarse, o cuando nadie ha decidido qué pasa cuando cambian los datos. Antes de aceptar una caché de un agente, pregúntale:

```text
Para esta caché: ¿cuál es la clave, qué la invalida, cuánta antigüedad de
los datos aceptamos como máximo, cuánta memoria puede usar y qué pasa en un
arranque en frío? Muéstrame la tasa de aciertos medida o el perfil que la
justifica.
```

Si las respuestas son vagas, la caché acabará convertida en un informe de bug. A menudo el mejor arreglo está antes en la cadena: un índice que falta, una consulta que trae todas las columnas, un bucle que recalcula el mismo valor en cada iteración.

### Problemas algorítmicos

A veces el perfil muestra una sola función con un número enorme de llamadas: un bucle anidado sobre dos listas, un `.find()` dentro de un `.map()`, una ordenación dentro de un bucle. Sustituir una búsqueda lineal por un `Map` o un `Set` es un arreglo clásico de agente, y el benchmark te dice al instante si ha importado.

## Evita la optimización prematura y especulativa

A los agentes les encanta optimizar. Pídele a uno que «mejore el rendimiento» de un archivo y memoizará componentes, reescribirá bucles y añadirá cachés por todas partes. La mayoría de esos cambios no mueven nada medible y hacen que el código sea más difícil de cambiar. Reglas que vale la pena dejar claras en las instrucciones de tu proyecto:

```markdown
## Trabajo de rendimiento
- Ninguna optimización sin un perfil o benchmark que muestre el problema.
- Un cambio por commit, con los números de antes/después en el mensaje.
- La legibilidad gana a las micro-optimizaciones fuera de las rutas calientes medidas.
- No añadas cachés, workers ni dependencias nuevas sin preguntar.
```

Lo mismo vale para las sugerencias del propio agente durante un trabajo que no tiene relación. Si propone «ya que estaba, también he optimizado…», pide los números o pídele que lo revierta. Cuando algo se rompe después de una optimización, [depurar código con IA](/es/blog/debug-code-with-ai/ "Depurar código con IA") explica cómo acotarlo sin adivinar.

## Paso 4: protege la mejora

El rendimiento se degrada en silencio, un cambio razonable tras otro. Convierte cada arreglo en una comprobación que falle de forma ruidosa:

- **Tests de número de consultas.** Verifica que la página de pedidos ejecuta como máximo un número fijo de consultas. La mayoría de los frameworks tienen un helper para esto, como `assertNumQueries` en Django.
- **Presupuestos de bundle.** Herramientas como `size-limit` hacen fallar el build cuando un bundle crece por encima de un tamaño fijado.
- **Lighthouse en CI.** Ejecuta la CLI de Lighthouse contra un build de preview y falla por debajo de un umbral de puntuación en las páginas que importan.
- **Benchmarks frente a una referencia.** Guarda la referencia y compara; en Go, `benchstat` compara dos ejecuciones de benchmark y te dice si la diferencia es significativa.

Los agentes escriben bien estas guardas, y vale la pena pedir una en la misma tarea que el arreglo: «arregla el N+1 y añade un test que lo habría detectado».

## Cómo hacerlo en AgentVera

AgentVera es una app de escritorio que ejecuta CLIs de agentes de programación como Claude Code, Codex y Gemini CLI uno al lado de otro. Varias de sus funciones encajan con este ciclo:

- **Un navegador que el agente puede controlar.** El [navegador del agente](/es/features/agent-browser/ "Navegador del agente") es un perfil de Chrome independiente que los agentes usan a través de Playwright MCP, con DevTools y la consola integrados, así que el agente puede abrir la página lenta por sí mismo y tú puedes observarlo.
- **Envía las pruebas con un atajo.** [Enviar al agente](/es/features/send-to-agent/ "Enviar al agente") (⌘⇧L) envía a un agente la salida de la terminal, una selección del editor, un diff o la consola del navegador. La salida del profiler en la terminal llega al agente sin copiar y pegar; una salida muy larga se corta a los 12.000 caracteres, así que envía la parte superior del informe o guárdalo en un archivo.
- **Planes de consulta junto al código.** El [gestor de bases de datos](/es/features/database-manager/ "Gestor de bases de datos") (Pro) abre PostgreSQL, MySQL y SQLite con un editor SQL que muestra planes EXPLAIN, y los agentes pueden consultar la base de datos a través de su herramienta integrada.
- **Benchmarks como criterios de aceptación.** Escribe «los tests pasan y el benchmark es al menos un 30 % más rápido que la referencia» en tu mensaje, y [Verify](/es/features/verify/ "Verify") lo comprueba al final del turno con un verificador que ejecuta comandos pero no puede editar archivos.
- **Deshaz una optimización que no compensó.** Los [checkpoints](/es/features/checkpoints-and-replay/ "Checkpoints y repetición") guardan una instantánea de cada turno, así que revertir un experimento es un clic.
- **Prueba dos enfoques a la vez.** En la cuadrícula del [workspace](/es/features/workspace/ "Workspace"), ejecuta dos agentes en worktrees separados, por ejemplo uno con la caché y otro con la consulta, y quédate con el que tenga mejores números.

## Para terminar

Optimizar el rendimiento del código con IA es la misma disciplina que optimizar sin ella, solo que más rápida: un objetivo claro, un perfil, las pruebas entregadas, un cambio cada vez, un benchmark como prueba y una guarda para conservar la mejora. El agente hace la lectura y la reescritura; los números deciden. Si tu ralentización llegó con una actualización de dependencias, el flujo de [actualizar dependencias con IA](/es/blog/upgrade-dependencies-with-ai/ "Actualizar dependencias con IA") te ayuda a aislar qué paquete la causó.

Para probar este flujo en tu propio proyecto, [descarga AgentVera](/es/download/ "Descargar AgentVera").

## Preguntas frecuentes

**¿Puede un agente de IA encontrar problemas de rendimiento leyendo el código?** Puede señalar sospechosos probables, como una consulta dentro de un bucle, pero no puede saber cuál importa con tus datos y tu tráfico. Dale un perfil, un log de consultas lentas o una traza, y podrá centrarse en el código que de verdad consume el tiempo.

**¿Qué profiler debo usar?** Para el navegador, el panel Performance de Chrome DevTools y Lighthouse. Para Node.js, node --cpu-prof, que escribe un .cpuprofile que puedes abrir en DevTools. Para Python, py-spy para procesos en ejecución y cProfile para un script que puedas lanzar tú mismo.

**¿Cómo sé si la optimización ha funcionado?** Mide lo mismo antes y después, varias ejecuciones cada vez, en la misma máquina. Una herramienta de benchmark como hyperfine para comandos, o el soporte de benchmarks de tu framework de tests, hace las ejecuciones repetidas por ti. Si la diferencia está dentro del ruido, no ha funcionado.

**¿Por qué los agentes sugieren optimizaciones que no ayudan?** Sin mediciones, un modelo recurre a consejos generales: memoiza esto, usa un bucle más rápido, añade una caché. Esos cambios añaden complejidad y a menudo no mueven nada. Pide la prueba detrás de cada sugerencia y rechaza todo lo que no esté ligado a un punto caliente medido.

**¿Cómo evito que el rendimiento vuelva a empeorar?** Convierte cada arreglo en una comprobación: un test que verifique el número de consultas de una página, un presupuesto de tamaño de bundle en CI o un benchmark comparado con una referencia. La comprobación falla antes de que la regresión llegue a los usuarios.

---

**Sobre AgentVera.** AgentVera es una app de escritorio para macOS, Windows y Linux, desarrollada por Solviera Teknoloji. Ejecuta 18 agentes de programación con IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) en paralelo, por proyecto, en terminales reales con las instalaciones y sesiones de CLI del propio usuario. El plan gratuito tiene agentes ilimitados. Descargar: https://agentvera.dev/es/download/ · Precios: https://agentvera.dev/es/pricing/