Revisa el código generado por IA

Lee el requisito antes que el resumen

Empieza por el comportamiento solicitado y los criterios de aceptación. Después, inspecciona el diff real. El resumen del agente puede orientarte, pero puede omitir cambios o describir comprobaciones de forma incorrecta.

Confirma la rama y el commit que estás revisando. Busca cambios de configuración, dependencias, infraestructura y pruebas, además de código de aplicación. Una función pequeña a simple vista puede incluir un gran cambio en permisos o en el comportamiento de despliegue.

Revisa primero el comportamiento con consecuencias más importantes. El formato y los nombres importan, pero no deben distraerte de un límite de datos ausente.

Sigue la identidad hasta el recurso

Considera este endpoint ficticio e incompleto. El ejemplo ilustra un problema de revisión; no es código de producción.

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

La función obtiene un usuario autenticado. No muestra una decisión de autorización para la factura. Quien revise debe inspeccionar si otra capa aplica esa decisión. Que el valor user no se utilice es motivo para investigar, pero no demuestra por sí solo un defecto explotable.

Sigue la solicitud por el sistema real. Identifica al usuario y la organización a partir de información fiable. Comprueba cómo limita la consulta el acceso al registro solicitado. Inspecciona el comportamiento ante errores y las pruebas de solicitudes prohibidas.

No supongas que ocultar un botón protege la API. Se puede enviar una solicitud sin usar la interfaz. Tampoco supongas que un identificador de registro válido concede acceso.

Pregunta qué pruebas podrían rechazar el cambio

Una prueba que pasa puede usar un usuario administrador de prueba o simular la autorización. Comprueba si realmente ejercita el límite relevante. Cuando corresponda, añade un caso con otra organización y un recorrido de autorización real.

Para un cambio de interfaz, inspecciona el resultado renderizado. Comprueba el uso del teclado, los estados vacíos, la carga y los errores. Una comprobación de tipos no demuestra que un diálogo pueda usarse con teclado.

Para un cambio de dependencia, verifica por qué hace falta. Revisa la versión, la licencia y los hallazgos de seguridad. No aceptes una actualización ajena a la tarea solo porque el agente la haya generado durante el trabajo.

Mantén independiente la revisión

Un segundo modelo puede identificar problemas útiles. También puede repetir los supuestos de la implementación. Dale el requisito y el diff a quien revise. Evita decirle que el cambio ya es correcto.

Exige que los hallazgos identifiquen una vía concreta de fallo y el código pertinente. Trata las advertencias sin fundamento como preguntas que hay que investigar. Trata una aprobación rotunda como otra opinión hasta que las afirmaciones importantes tengan pruebas.

La revisión humana sigue siendo una decisión sobre responsabilidades. Quien revise debe comprender lo suficiente para explicar el comportamiento, los riesgos y la verificación del cambio. Si el diff es demasiado grande, reduce el alcance o divídelo en cambios que se puedan revisar.

Cierra la revisión sobre la versión final

Después de una corrección, vuelve a ejecutar las comprobaciones afectadas. Inspecciona si la corrección crea otro problema. Asegúrate de que la revisión exigida se aplique a la versión final conforme a la política del repositorio.

Expresa la decisión de aceptación en términos de comportamiento y pruebas. Registra cualquier limitación restante con una persona responsable y una siguiente acción. No conviertas una incidencia sin resolver en una afirmación de que todas las comprobaciones se han superado.

Usa el ejercicio de revisión de código para practicar cómo identificar la decisión que falta antes de examinar un cambio real.