Código generado en producción sin revisión

El código generado llega a producción sin que nadie lo lea por caminos conocidos: una regla de fusión automática pensada para cambios triviales, una aprobación en tres minutos sin un comentario, o un agente que puede declarar trivial su propio cambio. En los casos públicos de este tipo se repite el cuadro: el código compilaba, las pruebas pasaban y nadie había mirado qué hacía fuera de lo que las pruebas comprobaban.

Las pruebas verifican lo que alguien pensó verificar. Un cambio que deja sin un dato a otro servicio, que vive en otro repositorio, no rompe ninguna prueba del repositorio donde se hizo. Y si el mismo agente escribió el código y sus pruebas, las dos cosas comparten los mismos supuestos.

La revisión de una persona no es un trámite: es la parte del proceso que puede preguntar quién más usa esto, qué pasa si sale mal y cómo se vuelve atrás.

Toda regla de fusión automática tiene una condición. La pregunta de auditoría no es si la condición es razonable, sino quién la controla. Si la condición es una etiqueta que puede poner el propio autor, y el autor es un agente, el agente decide si su cambio pasa por una persona o no.

Es un caso de separación de funciones, igual que en cualquier otro proceso: quien hace el cambio no puede ser quien decide que no hace falta revisarlo.

Además de la etiqueta, la regla tenía un tope de líneas. Un tope de líneas solo protege si cuenta lo que importa. Si el conteo deja fuera carpetas enteras (las migraciones de base de datos, la configuración, la infraestructura), un cambio de pocas líneas de código puede llevar dentro un cambio de esquema que borra datos al desplegarse.

Una migración que elimina una columna es una acción irreversible, igual que una purga: la diferencia es que no la ejecuta un agente con una herramienta, sino el proceso de despliegue, y por eso nadie la mira como una acción.

La línea de tiempo de un incidente de despliegue tiene hitos fijos: la fusión, la aplicación en producción, el primer síntoma, la primera alerta, la identificación del cambio causante y la vuelta a la normalidad. Cada hito sale de un registro distinto, y conviene anotar de cuál.

La duración del impacto se mide desde que el cambio se aplica en producción hasta que el servicio vuelve a funcionar, no desde que alguien abre un ticket. La diferencia entre las dos cifras es, justamente, el tiempo en que nadie sabía.

Un control para el código generado tiene que cerrar el camino por el que entró este cambio, no el que entró la vez anterior. Aquí el camino tuvo tres tramos: el agente marcó su propio cambio, la regla no contó la migración y la etapa de respaldo previo dependía de otra etiqueta que nadie puso.

Lo que no cierra el camino: pedirle al agente que se explique (sigue decidiendo él), mover el tope de líneas (la migración sigue sin contar) o escribir una prueba para esta tabla concreta (protege esta columna y deja abierta la próxima).