La IA escribió el código. ¿Quién responde por el despliegue?

Un pull request puede llegar con implementación, pruebas y una explicación convincente en pocos minutos. Quien revisa recibe un problema menos cómodo. Tiene que averiguar si los cambios cumplen lo que necesita el producto, incluso cuando algo falla.

El volumen de código pendiente puede crecer sin que aumente la capacidad del equipo para entenderlo. Aprobar todo porque las pruebas pasan resulta tentador. También entrega la decisión a pruebas que quizá repiten la misma suposición equivocada del código.

GitHub documenta que la revisión de Copilot puede omitir problemas y proponer cambios innecesarios. La revisión humana sigue formando parte del proceso. Recomendamos organizarla alrededor del comportamiento que debe mantenerse después del despliegue.

Empieza por la regla que no puede romperse

Imagina una integración que recibe la confirmación de una inscripción y emite una entrada. El proveedor puede reenviar el mismo evento. La regla del producto exige una sola entrada por inscripción, incluso con entregas repetidas.

Una implementación puede consultar el evento, comprobar que no existe y guardar la entrada. Cada línea parece razonable. Sin embargo, dos solicitudes simultáneas pueden consultar antes de que cualquiera escriba.

La revisión debe preguntar dónde garantiza el sistema la unicidad. Una restricción en la base de datos puede proteger la escritura. Si el flujo también envía un correo, la transacción local no hace atómico ese envío externo. Hace falta registrar el trabajo pendiente y repetir la notificación sin crear otra entrada.

Es un ejemplo hipotético. La idea es buscar las decisiones que dependen del comportamiento del sistema completo. Una función legible no resuelve por sí sola la concurrencia.

Sigue el recorrido completo

Sigue el dato desde la entrada hasta el efecto final. En este ejemplo, lee cómo se verifica el origen del evento, cómo se identifica la inscripción y cómo se guarda la entrada. Después revisa la notificación.

Lee también los archivos existentes que llama el código nuevo. Una función llamada createTicket podría enviar correo internamente. Un manejador de errores podría convertir un fallo en una respuesta de éxito. Esos detalles cambian lo que ocurre cuando el proveedor reintenta.

Pide una explicación breve de cada dependencia nueva. Si una biblioteca solo sustituye una función disponible en el proyecto, retírala. Cada dependencia añadida seguirá necesitando atención después de cerrar el pull request.

Haz que las pruebas cuestionen la implementación

Escribe los resultados esperados sin copiar la estructura del código. Para esta integración, una revisión podría exigir:

Situación	Resultado esperado
El mismo evento llega dos veces	Una sola entrada
Dos entregas llegan a la vez	Se mantiene la regla de unicidad
La entrada se guardó y falló la notificación	Se puede retomar la notificación sin duplicar la entrada
El evento tiene un origen inválido	No se crea ninguna entrada

La prueba de concurrencia debe ejercitar la protección usada al escribir. Una base simulada que siempre devuelve la respuesta esperada puede ocultar el defecto que buscas.

Al corregir un error, comprueba que la prueba falla sin la corrección. Evita celebrar una prueba que nunca observó el problema.

Reduce el cambio hasta poder explicarlo

Cambiar el comportamiento, reorganizar carpetas y actualizar dependencias en la misma entrega encarece la revisión. Pide cambios separados cuando el trabajo sea independiente.

Antes de aprobar, la persona responsable debería poder describir el efecto para el usuario, el fallo más probable y cómo detectarlo después de publicar. No necesita memorizar cada línea. Necesita saber dónde mirar cuando llegue el primer reporte.

Anota los límites de la reversión. Revertir código no deshace automáticamente una migración destructiva ni recupera un correo enviado. Esas consecuencias pertenecen a la decisión de publicar.

La IA puede ayudar a investigar los cambios y proponer casos olvidados. Usa esa ayuda. La aprobación sigue exigiendo una modificación que alguien pueda explicar y mantener cuando deja de funcionar el caso ideal.