Code review asistido: el robot que no debe aprobar solo

Llegas tarde al PR porque el build se tardó 18 minutos (otra vez). QA te anda correteando en Slack, y el founder ya quiere “deploy en corto” porque hay demo. Abres la pull request y ves 42 archivos tocados. Tu compa suelta: “pásalo por el bot, ese ya revisa todo”.

La tentación está bien real: que la IA apruebe y tú nomás pongas el ✅. Y ahí es donde nace el bug que se va a production un viernes a las 6:40 pm, justo cuando ya ibas rumbo a los tacos.

La IA puede ayudarte a revisar más rápido. Lo que no debe pasar es que se quede con el botón de Approve.

Qué vas a aprender

• Cómo armar un flujo de code review con IA que sí ahorre tiempo sin bajar calidad.
• Qué pedirle a la IA (prompts) para que encuentre riesgos de verdad: seguridad, performance, edge cases y deuda técnica.
• Cómo evitar el modo “robot buena onda” que te dice que todo está perfecto.
• Un checklist para que tu equipo diga: “sí usamos IA, pero con guardrails”.

Contexto práctico: por qué la IA ayuda… y por qué da cosa

Un buen review humano no es solo cazar bugs. Es entender intención, mantener coherencia del sistema, cuidar el roadmap y evitar que el código se convierta en un Jenga sostenido con fe.

La IA suele ser buena para:

• Leer mucho código rápido y resumir cambios.
• Detectar patrones repetidos (naming, consistencia, estilo).
• Sugerir pruebas faltantes y casos límite.
• Señalar smells y riesgos obvios (null checks, manejo de errores, logs peligrosos).

Y suele ser riesgosa para:

• Entender el contexto de negocio (“esto no puede cobrar dos veces”).
• Recordar incidentes pasados (“ya nos tronó este endpoint en quincena”).
• Decidir tradeoffs (“prefiero latencia vs costo de DB”).
• Evaluar seguridad con criterio completo si no le das contexto.

El peor combo: la IA escribió el cambio, la IA lo revisó, y tú lo mergeaste porque “se ve bien”. Eso no es pair programming: es autocomplacencia automatizada.

Decisión práctica: IA sí, pero como copiloto de revisión. El responsable sigue siendo humano.

Guía principal: un flujo de code review asistido que sí funciona

Este workflow lo he visto aguantar prisa, deuda técnica y equipos mixtos (juniors + seniors). O sea: chamba real con laptop ya medio cansada y deadlines que no perdonan.

1) Define el contrato del PR (si no, la IA adivina)

Antes de pedirle review a la IA, dale un “contrato” mínimo:

• ¿Qué problema resuelve?
• ¿Qué no resuelve (scope fuera)?
• ¿Qué riesgos hay?
• ¿Cómo se prueba?

Plantilla breve para el cuerpo del PR:

Problema:
- Usuarios reportan doble cargo cuando el webhook llega duplicado.

Cambio:
- Idempotency key por transactionId + source.

Fuera de scope:
- No se cambia el motor de pagos.

Riesgos:
- Colisiones de key si source es null.

Pruebas:
- Unit: PaymentService idempotency
- Integration: webhook duplicate delivery

Sí, son 3 minutos. Pero cuando estás al filo del deploy, esos 3 minutos te salvan de 30 de “¿por qué cambiaste esto?” en pleno incidente.

2) Pídele a la IA un resumen y un “mapa de impacto”

Primer prompt: no para criticar, sino para entender.

Prompt sugerido (copia/pega y ajusta):

Actúa como reviewer senior. Resume este PR en:
1) Qué cambia (lista corta)
2) Qué módulos/tables/endpoints impacta
3) Riesgos potenciales (máx 6)
4) Qué pruebas deberían existir

Contexto:
- Stack: Node/TS + Postgres
- Dominio: pagos, cuidado con doble cargo
- Prioridad: evitar regresiones

Diff:
[pega aquí el diff o los archivos relevantes]

Cómo usar la salida:

• Si el “mapa de impacto” no coincide con tu intención, ya tienes un problema de comunicación o diseño.
• Si te marca “riesgo: race condition”, conviértelo en acción: prueba, lock, transacción o idempotencia bien hecha.

3) Haz que revise por categorías (no “revísalo a ver qué”)

La IA mejora cuando le pides revisar con lentes específicos.

Lente A: Correctitud y edge cases

Revisa el diff buscando bugs lógicos, edge cases y manejo de errores.
No me des consejos genéricos. Para cada hallazgo:
- Archivo y línea aproximada
- Por qué falla
- Ejemplo de caso que lo rompe
- Fix sugerido (con snippet)

Lente B: Seguridad (lo que sí pasa en la vida real)

En LatAm el tráfico no siempre es “bonito”. Hay bots, scraping, requests raras, y proveedores que a veces mandan payloads medio chuecos.

Revisa el diff por riesgos de seguridad:
- Inyección (SQL/NoSQL), SSRF, path traversal
- Exposición de PII en logs
- Autorización/autenticación faltante
- Validación de input

Dame hallazgos accionables con severidad (alta/media/baja).

Lente C: Performance y costo

Porque el bug no siempre es un crash; a veces es una factura de infraestructura que te cae cuando menos.

Revisa el diff por performance:
- Consultas N+1
- Falta de índices probables
- Loops sobre listas grandes
- Cache mal usado
- Timeouts/retries

Si propones optimización, di el tradeoff.

4) Obliga a la IA a señalar lo que falta: pruebas, logs, métricas

Un PR sin pruebas claras es un boleto a incidentes. Y sí: a veces no hay tiempo. Pero mínimo deja el rastro y el plan.

Dime qué pruebas faltan para cubrir los cambios.
Divide en:
- Unit tests
- Integration tests
- E2E (si aplica)
Incluye 3 casos concretos por tipo.

Si tu equipo rota guardias/soporte, pide observabilidad desde el review:

Sugiere logs/metrics que me ayuden a detectar regresiones en producción.
Evita loggear PII.

5) Convierte hallazgos del bot en comentarios humanos

Si copias y pegas lo que dijo la IA tal cual, el review se siente plástico y el autor no aprende. Además, cuando el comentario está mal, se nota que nadie lo pensó.

Transforma “hallazgo IA” en comentario que suena a humano con contexto:

• Pregunta concreta: “¿Qué pasa si llega el webhook dos veces con distinto timestamp?”
• Impacto: “Esto podría volver a cobrar si la idempotency key no incluye source.”
• Propuesta: “Sugiero key = provider + transactionId y un test de duplicados.”

Y si toca algo crítico (pagos/auth/data), ponte firme:

• “Esto no lo puedo aprobar sin test de idempotencia. Prefiero invertir 1 hora ahorita que 6 horas en rollback en production.”

6) Regla de oro: la IA no aprueba, solo recomienda

Política simple para evitar tragedias:

• La IA puede comentar.
• La IA puede sugerir cambios.
• La IA puede generar tests.
• La IA no hace approve final.

Si quieres formalizarlo para tu equipo:

• “Todo PR requiere al menos 1 aprobación humana, y 2 si toca auth/pagos/infra.”
• “Si el PR fue generado mayormente con IA, requiere pruebas extra o revisión más profunda (los errores suelen ser sutiles).”

7) Flujo recomendado (rápido) para equipos con prisa

Cuando hay demo, soporte o el sprint ya se quemó:

1. Autor llena la plantilla del PR (contrato).
2. IA hace resumen + riesgos.
3. Autor corrige lo obvio antes de pedir review humano.
4. Reviewer humano revisa diseño + riesgos de negocio.
5. IA revisa por lentes (seguridad/perf/pruebas).
6. Reviewer humano decide approve / request changes.

El orden importa: la IA te quita paja, tú haces el juicio.

Screenshots sugeridos

• Captura de un PR con plantilla (Problema/Cambio/Riesgos/Pruebas).
• Captura de comentarios de la IA separados por categorías (Correctitud/Seguridad/Performance).
• Captura de un test agregado por recomendación de la IA (ej. caso de duplicado).
• Captura de un ejemplo de “Approve” bloqueado por falta de pruebas (mensaje claro).

Errores comunes + solución (los que sí pasan)

1) “La IA dijo que estaba bien, entonces merge”

Qué pasa: te confías, se cuela un edge case, y el incidente llega en hora pico (tipo quincena, cuando pagos se ponen intensos).

Solución: policy explícita: IA no aprueba. Checklist humano obligatorio.

2) Prompt vago = review vago

Qué pasa: “revísalo” produce cosas tipo “considera mejorar la legibilidad”. Gracias, robot.

Solución: prompts por lentes + pedir evidencia (archivo/línea/caso que rompe).

3) Meterle todo el repo y filtrar cero

Qué pasa: la IA se pierde, alucina contexto o te avienta puro ruido.

Solución: pásale lo relevante: diff, archivos tocados y contexto del PR. Si es enorme, divídelo por módulos.

4) Revisar estilo antes que riesgos

Qué pasa: se va el tiempo en naming y lint, y nadie ve que falta una validación o que hay doble escritura.

Solución: orden: correctitud → seguridad → pruebas → performance → estilo.

5) No proteger datos sensibles al usar herramientas externas

Qué pasa: pegas logs con PII, keys, tokens o info del cliente. Luego toca dar explicaciones en retro y apagar fuegos.

Solución:

• Redacta PII (emails, teléfonos, CURP si aplica).
• Nunca pegues secrets.
• Si tu empresa lo requiere, usa herramientas con entorno privado o modelos on-prem.

Checklist final (para que el robot no te gane)

• El PR tiene “contrato”: problema, cambio, fuera de scope, riesgos, cómo probar.
• La IA entregó resumen + mapa de impacto y sí coincide con la intención.
• La IA revisó por lentes: correctitud, seguridad, performance.
• Se agregaron o ajustaron pruebas clave (mínimo 1 caso de borde).
• Los comentarios que se dejaron son humanos: claros, con impacto y propuesta.
• Hay mínimo 1 aprobación humana (2 si es crítico: auth/pagos/infra).
• No se compartió PII/secrets con herramientas externas.
• Si hay riesgo, hay plan: feature flag, rollback, monitoreo.

FAQ

1) ¿Qué tanto le puedo confiar a la IA en code review?

Como copiloto para detectar cosas obvias y ordenar el review, bastante. Para decidir si se aprueba, poco: esa decisión carga contexto de negocio y responsabilidad.

2) ¿Qué le doy a la IA: el diff o el archivo completo?

Arranca con el diff y los archivos tocados. Si detecta un riesgo que depende de otra parte del sistema, ahí sí súmale el archivo relacionado.

3) ¿Cómo evito que la IA invente cosas?

Pídele evidencia: archivo/línea, ejemplo que rompe y snippet de fix. Y delimita contexto (stack, objetivo, límites del PR).

4) ¿Sirve para juniors o los vuelve dependientes?

Sirve si se usa como herramienta de aprendizaje: que el junior compare recomendaciones con tests y documentación. Se vuelve dependencia si la IA “aprueba” y nadie entiende por qué.

5) ¿Qué políticas mínimas pondrías en un equipo chico?

• IA no aprueba.
• PR template obligatorio.
• 1 aprobación humana siempre.
• 2 aprobaciones en código crítico.
• Tests obligatorios o explicación explícita de por qué no (y ticket para pagarlo).

Siguiente episodio

Cuando el bot ya revisa, el siguiente paso natural es: “¿y si también escribe las pruebas?”

En el próximo armamos un workflow para generar tests con IA sin caer en tests de mentiritas que pasan pero no protegen nada.