Verificar dos líneas del agente me costaba una hora
El agente cierra una tarea de dos líneas. Verificar que no rompió nada me llevaba cerca de una hora.
Y no había ningún control de más. Los tests end-to-end los había agregado porque atajaron un bug real. La revisión de seguridad, porque atajó otro. Cada uno se había ganado su lugar, y justamente por eso ninguno se podía saltear.
Es una pendiente natural: agregás una verificación porque sirve; como sirve, no querés que se saltee; entonces la hacés obligatoria. Repetí eso cinco veces en tres meses y terminé con una hora de controles colgando de cada tarea, por chica que fuera.
Lo que lo destrabó no fue borrar chequeos ni acelerarlos. Fue cambiar la pregunta: no ¿este chequeo sirve? —todos servían— sino ¿qué decisión bloquea?. Algunos tienen que frenar la tarea. A otros les alcanza con frenar el deploy.
La parte cara era la revisión de interfaz
Dentro del control, la verificación más lenta era la revisión de interfaz asistida por modelo: un agente que abre el navegador, recorre la aplicación y evalúa si lo implementado se ve y se comporta como corresponde.
Es valiosa. Encuentra cosas que ningún test automatizado detecta. Y es carísima en tiempo, porque implica levantar el entorno, navegar, esperar cada pantalla y razonar sobre lo que ve.
Correr eso en cada tarea era el equivalente a pedirle a un diseñador que revise la aplicación completa cada vez que alguien cambia una línea de código.
La pregunta correcta no es si el chequeo sirve
El cambio de pregunta reordenó todo, y la razón es económica antes que conceptual: no es lo mismo un control que impide cerrar una tarea que uno que impide desplegar a producción. Tienen costos de espera completamente distintos. El primero se paga decenas de veces por semana; el segundo, una vez por release. Mezclarlos es lo que hace que un equipo termine desactivando los dos.
De ahí salieron los dos niveles.
Nivel 1: lo que bloquea cada tarea
Rápido, determinista y por tarea. Tres cosas: la suite completa del backend, los tests end-to-end propios de esa tarea corriendo sin interfaz gráfica, y una traza de seguridad.
Lo importante es el "propios de esa tarea". No la suite end-to-end completa: solo las pruebas que corresponden a lo que se acaba de tocar. Eso es lo que baja el tiempo de una hora a minutos.
Nivel 2: lo que bloquea el deploy
Lento, costoso y en lote. Ahí se fueron la suite end-to-end completa y la revisión de interfaz con modelo, que se ejecuta sobre las tareas que el nivel 1 no llegó a cubrir.
Ese lote corre en dos momentos: antes de desplegar, de forma bloqueante, y además todas las noches como red de seguridad. Si algo falla, no traba el trabajo del día — traba la salida a producción, que es donde ese control realmente importa.
En la pantalla la división se hizo visible con dos columnas separadas, una por nivel, cada una con su propio estado. Que se vea importa: si un control no bloquea, tiene que quedar clarísimo que su resultado sigue existiendo y que alguien lo va a mirar.
La parte delicada: cambiar algo de lo que depende todo
Esta es la parte que más me costó y de la que menos se escribe.
El control de calidad es una pieza de la que cuelga todo el sistema. Los pasos de cierre se niegan a marcar una tarea como terminada si el control no aprobó. Y esa aprobación, tal como estaba escrita, exigía explícitamente el resultado de la revisión de interfaz.
O sea: si yo hacía lo intuitivo —sacar la revisión de interfaz del control por tarea— el sistema entero dejaba de poder cerrar tareas. No una parte: todas. Cada cierre habría empezado a fallar buscando un dato que ya nadie producía.
Por eso el plan tiene una regla escrita en mayúsculas: si dejás de producir la señal antes de dejar de exigirla, se rompen todos los cierres.
El orden de implementación quedó fijado en cinco etapas, y la primera es la contraintuitiva:
- Primero, desacoplar el requisito. Que la aprobación deje de exigir la revisión de interfaz. Es un cambio compatible hacia atrás: si la señal está, se ignora; si no está, ya no bloquea. En este punto el sistema sigue funcionando exactamente igual que antes.
- Después, agregar los chequeos nuevos del nivel 1, que es puramente aditivo.
- Recién al final, que la habilidad deje de producir la señal por tarea. Ahora es seguro, porque hace dos pasos que nadie la exige.
- Las columnas de la pantalla y el corredor de lotes, que son net-new y no tocan el camino existente.
Es la clase de secuencia que parece burocrática cuando la escribís y te salva el día que la ejecutás. Si hubiera empezado por el paso obvio —sacar la revisión de interfaz— habría roto el cierre de tareas en todos los proyectos gestionados al mismo tiempo.
Un detalle que evitó bastante dolor
Cada chequeo nuevo lee la configuración del proyecto y se auto-omite cuando el proyecto no declara lo que necesita.
Hay proyectos gestionados que no tienen tests end-to-end. Si el control los exigiera, esos proyectos quedarían trabados para siempre por un requisito que no aplica. La regla que quedó es: el control no puede exigir lo que el proyecto no declara tener.
Suena obvio escrito así, pero es el tipo de cosa que descubrís cuando el mismo mecanismo corre sobre proyectos con formas distintas.
El resultado y lo que siguió
El objetivo declarado en el plan era bajar el control por tarea de aproximadamente una hora a minutos, en todos los proyectos a la vez. Eso se consiguió.
Y con el sistema corriendo por fin rápido, quedó expuesto un problema que la lentitud había estado tapando: cada vez que reiniciaba el servidor, perdía el plan de trabajo completo. De eso trata la próxima entrega.