Testing y Code Review con Agentes de IA

Tu agente de IA escribió 200 líneas de código en 3 minutos. Ahora qué. Si haces merge sin revisar, estás apostando. Si revisas línea por línea, perdiste la ventaja de velocidad. El code review con agentes necesita una estrategia diferente — no más relajada, sino más inteligente.

La paradoja del review

La IA es rápida generando código. Tan rápida que crea un cuello de botella nuevo: el review. Antes el bottleneck era escribir código. Ahora es validarlo.

No puedes saltarte el review — el código generado tiene errores sutiles, patrones inconsistentes y decisiones que ningún agente puede tomar por ti. Pero tampoco puedes revisar todo al mismo nivel de detalle que antes. Necesitas un sistema que filtre lo obvio y te deje enfocarte en lo que importa.

Mi checklist de review

Después de meses revisando código generado por agentes, estos son los cinco puntos que siempre verifico. No es una revisión exhaustiva — es un filtro rápido que atrapa el 80% de los problemas.

1async function deleteUsers(data: any) {
2  const res = await fetch("/api/users", {
3    method: "DELETE",
4    body: JSON.stringify(data),
5  });
6  console.log(res);
7  return res.json();
8}

Vamos uno por uno:

¿Cumple la intención? El error más común no es que el código falle — es que hace algo diferente a lo que pediste. El agente interpretó tu prompt de una forma, tú querías otra cosa. Este es el check más importante y el que solo un humano puede hacer.

¿Tipos correctos? Los agentes adoran el any. También omiten null checks, ignoran errores de API y asumen que los datos siempre llegan en el formato esperado. Una revisión rápida de los tipos atrapa problemas que después son bugs en producción.

¿Sigue los patrones del codebase? El agente puede generar código funcional que no se parece en nada al resto de tu proyecto. Usa console.log en vez de tu logger, crea utils duplicados, ignora convenciones de naming. Código que funciona pero que nadie reconoce como suyo.

¿Inputs validados? Cualquier dato que viene de fuera — usuario, API, query params — necesita validación. Los agentes tienden a confiar en que los datos siempre son correctos. En producción, nunca lo son.

¿Casos edge cubiertos? Datos vacíos, errores de red, timeouts, arrays con un solo elemento, strings con caracteres especiales. Los agentes cubren el happy path. Los edge cases son tu responsabilidad.

Agentes revisando agentes

La idea suena recursiva, pero funciona: usar un agente de code review como primer filtro antes de que tú mires el código. No reemplaza tu revisión — la hace más corta.

Lo que hago: después de que el agente genera código, le pido que lo revise contra un set de reglas. El CLAUDE.md del proyecto ya tiene las convenciones. El agente compara el output contra esas convenciones y señala inconsistencias.

El humano revisa la revisión. Suena redundante, pero el tiempo total es menor que revisar todo el código directamente. El agente atrapa los problemas mecánicos. Tú te enfocas en los problemas de diseño.

Cuándo la revisión automática acierta

Los agentes son buenos detectando cosas que los humanos pasamos por alto por tedio:

• Patrones rotos en muchos archivos — Si renombraste una convención y tres archivos no se actualizaron, el agente lo encuentra.
• Imports no usados — Tú los ignoras, el agente los lista todos.
• Naming inconsistente — getUserData en un archivo, fetchUserInfo en otro. El agente detecta la divergencia.
• Código duplicado — Dos utils que hacen lo mismo con nombres diferentes. El agente compara y señala.

Este tipo de revisión es tedioso para humanos y trivial para agentes. Delegarlo tiene sentido.

Cuándo la revisión automática falla

Los agentes no pueden validar:

• Lógica de negocio — ¿Este cálculo de precio incluye impuestos? ¿El descuento se aplica antes o después del shipping? Solo alguien que entiende el dominio puede verificar esto.
• Decisiones de UX — ¿Este loading state comunica bien lo que pasa? ¿El error message ayuda al usuario a resolver el problema? Juicio humano.
• ¿Es el enfoque correcto? — El código puede estar perfecto y ser la solución equivocada. El agente no sabe si deberías haber usado un webhook en vez de polling, o si esa feature debería existir en primer lugar.
• Contexto de equipo — Acuerdos no documentados, decisiones históricas, razones por las que algo se hizo de cierta forma. Si no está en el codebase, el agente no lo sabe.

Un workflow que funciona

Mi flujo actual:

1. Escribir con agente — Prompt claro, spec definida, contexto del codebase disponible
2. Auto-review — El agente revisa su propio output contra las convenciones del proyecto
3. Fix automático — Los problemas mecánicos (imports, formatting, tipos) se corrigen antes de que yo los vea
4. Review humano — Yo reviso intención, lógica de negocio, edge cases y decisiones de arquitectura
5. Ship — Con confianza, porque los dos niveles de review ya pasaron

El review humano es más corto porque las cosas obvias ya están resueltas. No gasto tiempo señalando console.log o tipos any — eso ya se atrapó. Mi atención va a las preguntas que solo yo puedo responder.

Conclusión

El objetivo no es cero review humano. Es que el tiempo de review humano cuente. Cada minuto que pasas verificando un import no usado es un minuto que no pasas evaluando si la arquitectura escala o si la feature resuelve el problema correcto.

Los agentes son buenos atrapando errores mecánicos. Los humanos somos buenos evaluando intención, contexto y consecuencias. Un buen workflow de review usa cada uno para lo que es mejor.

Este es el noveno artículo de la serie. El primero fue sobre las herramientas que uso. El segundo sobre por qué fallan y cómo arreglarlo. El anterior sobre planificación antes de codear con SDD. Este cierra el bucle — el código ya está generado, ahora hay que asegurar que merece llegar a producción.