Cómo revisar código después de Cursor, Claude Code y Codex

Un agente de programación reduce el tiempo que va de la tarea al diff, pero no asume la responsabilidad de la publicación. El código escrito por IA no es peligroso porque tenga una categoría especial de errores de máquina. Produce errores corrientes con rapidez, en varios archivos y con explicaciones convincentes. Por eso, la revisión debe empezar por los límites del cambio y por señales reproducibles, no por otro chatbot.

Explica por qué cada archivo modificado pertenece al diff

Pide al agente un resumen breve y compáralo después con el diff real. Elimina formateos incidentales, actualizaciones de lockfile sin explicación, código de depuración y cambios en módulos vecinos que la tarea no necesita. Divide un diff grande cuando sea posible: el esquema de datos, el servidor, la interfaz y las pruebas son más fáciles de razonar como unidades lógicas separadas.

Localiza la nueva fuente de la verdad. ¿Dónde vive ahora el estado, quién llama a la función y qué rutas antiguas permanecen? Un agente a menudo añade una capa nueva sin eliminar ni actualizar la anterior. Buscar el nombre, la ruta y el tipo puede revelar dos implementaciones en competencia.

Deja que el compilador y las pruebas hablen antes que un revisor de IA

Ejecuta el formateo, el linting, la comprobación de tipos, las pruebas unitarias y las pruebas de integración con los mismos comandos que CI. Si el proyecto carece de estas comprobaciones, eso es un riesgo aparte, no una razón para sustituirlas por un modelo. Una herramienta determinista repite una regla exactamente; un revisor de IA estima problemas probables y puede pasar por alto algo simple.

Una prueba nueva debería fallar contra el código anterior y pasar después de la corrección. Una prueba que está en verde en ambas versiones quizá no demuestre nada. Reproduce el fallo original para una corrección de bug; para una funcionalidad, cubre el camino principal, los límites y el fallo de una dependencia.

Playwright valida un recorrido de usuario, no la elegancia de la implementación

Añade o actualiza una prueba de navegador para un flujo web crítico. Los proyectos de Playwright ejecutan distintos navegadores y entornos, mientras que trace viewer conserva los pasos, el estado del DOM, la actividad de red y las capturas de pantalla para el diagnóstico en CI. Codegen es un borrador útil, pero los localizadores y las expectativas deben reescribirse alrededor de comportamientos estables y visibles para el usuario.

No cubras cada setter con E2E. Bloquea el recorrido cuyo fallo resulta costoso: inicio de sesión, pago, creación de objetos, publicación o permisos de rol. Las pruebas de API y unitarias pueden cubrir las ramas más baratas.

Las migraciones y el trabajo en segundo plano necesitan ensayar la reversión

Cuando un diff cambia el esquema, inspecciona las filas existentes, los valores nulos, los índices, los bloqueos y el tiempo de ejecución. Ejecuta la migración contra una copia con volumen realista. Decide si el código nuevo funciona con el esquema antiguo durante un despliegue progresivo y si la aplicación puede revertirse después de la migración.

Para colas y webhooks, prueba reintentos, orden, tiempos de espera y finalización parcial. Los agentes escriben con facilidad un camino feliz en el que un evento llega una sola vez. Producción tiende a probar lo contrario.

Los permisos y las rutas de datos importan más que las líneas de aspecto sospechoso

Rastrea la entrada no confiable hasta la base de datos, el sistema de archivos, la shell, el HTML y las solicitudes salientes. Verifica la autorización en el servidor en lugar de confiar en un botón oculto. Los secretos no deben entrar en un bundle de cliente, logs, una respuesta de error ni en el contexto de un modelo.

Inspecciona las dependencias y el código generado. Una biblioteca nueva amplía la superficie de cadena de suministro y el tamaño del bundle; un paquete parecido puede ser un error tipográfico. Para datos personales, comprueba la minimización, la retención y si los registros se envían a un modelo sin autorización.

Una segunda IA funciona mejor como oponente con instrucciones estrictas

Después de las comprobaciones convencionales, entrega el diff a un agente revisor distinto. Define una tarea precisa: encontrar violaciones de invariantes, pruebas faltantes, incompatibilidad de API, condiciones de carrera o saltos de autorización. Exige un archivo, una línea y un escenario de fallo. “Revisa este código” produce una gran cantidad de ruido estilístico.

No aceptes un hallazgo sin reproducirlo. Un modelo puede inventar un contrato o no ver una regla del proyecto. Los productos relevantes aparecen en la colección de revisión de código con IA de AIDive, con productos centrados en la ejecución en la colección de pruebas con IA.

La revisión de la publicación termina con observación después del despliegue

Antes de fusionar, verifica la descripción del PR, la incidencia enlazada, la documentación, las flags, las métricas y el plan de reversión. Después de la publicación, observa algo más que los errores del servidor: conversión de pasos, latencia, profundidad de cola, tasas de rechazo e invariantes de negocio. Una reversión rápida es más valiosa que un largo debate con un agente durante un incidente.

La secuencia breve es: entender el diff, reducirlo, ejecutar comprobaciones deterministas, reproducir el recorrido crítico, inspeccionar por separado los datos y el acceso, usar IA como segundo revisor y publicar con observación. La velocidad de generación solo importa cuando el equipo conserva la capacidad de demostrar la corrección.