Un equipo de Avito lleva al código el flujo de trabajo de sus agentes de IA con dos puntos de aprobación

Le pides a un agente que primero obtenga la aprobación del plan, después escriba el código y lo pruebe en un entorno de pruebas. Una hora más tarde entrega un PR terminado, pero se ha saltado la aprobación y, en lugar de los resultados de las pruebas, ofrece una explicación convincente de por qué todo debería funcionar. Puedes añadir otra advertencia a AGENTS.md. Eso no garantiza que se cumpla.

Valeri Pochtariov, del equipo Checks de Avito, dedicado a la lucha contra el fraude, describió otro enfoque: trasladar los requisitos verificables de las instrucciones a scripts y hooks. Estos determinan en qué fase se encuentra la tarea, si se permiten cambios y si el resultado puede enviarse a revisión. La configuración se llama af-checks-context; su autor está extendiendo ahora su uso personal al equipo.

Cómo un requisito se convierte en un bloqueo

La base del sistema es un repositorio git independiente con el contexto del equipo: especificaciones, planes, conocimientos y una descripción del proceso. Los repositorios de los servicios se encuentran junto a él. La sesión del agente comienza con el contexto del equipo para que una tarea que abarque varios servicios no quede reducida al contenido de un único proyecto.

A continuación se sigue una secuencia de fases: tarea, plan, aprobación, implementación, pruebas en un entorno independiente, aprobación del resultado y envío del PR a revisión. Un script calcula la fase de la tarea a partir de los artefactos existentes. El modelo no puede limitarse a declarar que ya se ha completado una fase obligatoria.

Supongamos que el agente modifica una comprobación de acceso. Hasta que se aprueba el plan, un hook bloquea los cambios de código en el directorio de trabajo de la tarea. Una persona confirma el plan en un mensaje independiente que incluye la clave de la tarea. El hook crea una marca de corta duración que un comando utiliza para registrar la aprobación. El agente tiene prohibido crear esa marca por su cuenta.

Tras la implementación se exige un informe del entorno de pruebas. Se comprueba que incluya el veredicto pass y el hash del commit probado. Si el agente introduce otro cambio después de una ejecución satisfactoria, el informe anterior deja de validar la versión actual. Incluso un cambio pequeño requiere pruebas actualizadas de su verificación.

Dónde fallaron las primeras restricciones

La parte más útil del artículo es la descripción de las comprobaciones que fallaron. Una primera barrera aceptaba cualquier campo de aprobación que no estuviera vacío: incluso el valor false pasaba. Otra solo comprobaba que existiera la ruta del informe, por lo que hasta un directorio con el nombre adecuado le servía. Formalmente, la fase quedaba completada; en la práctica, no había pruebas.

Surgió otro problema con un bot que distinguía entre cambios en el proceso y cambios de contenido ordinarios. Leía la lista de rutas protegidas del propio PR que estaba comprobando. Un cambio podía eliminar su propio directorio de la lista y entrar en una categoría que permitía la fusión sin intervención humana. La solución: tomar las reglas de la rama de destino y considerar siempre que una modificación de la propia configuración es un cambio en el proceso.

La verificación por otro agente tampoco garantiza que el resultado sea correcto. En una ocasión, el agente revisor encontró una contradicción entre la especificación y un servicio adyacente. Su copia local estaba 36 commits por detrás; el comportamiento necesario ya existía. Ahora, estos hallazgos se contrastan primero con origin actualizado. Separar los roles es útil, pero sigue siendo necesario comprobar que los datos de partida estén al día.

Qué incorporar a tu propio proceso

Puedes empezar por una transición que falle con frecuencia en tu flujo de trabajo. Por ejemplo, impedir el envío de un PR a revisión si no existe un informe satisfactorio para el commit actual. Después, prueba la propia barrera: ¿qué ocurre si el informe está vacío, el tipo de archivo es incorrecto, hay un nuevo commit o falla la carga del script de comprobación?

El control tiene un coste de mantenimiento. El hook de inicio del autor tardaba entre 14,6 y 18 segundos en ejecutarse, con un tiempo límite de 15 segundos, lo que a veces impedía que el contexto llegara al agente sin que se notificara el fallo. Las casillas de control administrativo cambiaban el hash del plan y provocaban nuevas solicitudes de aprobación. Hubo que simplificar el sistema, separar las comprobaciones rápidas de las lentas y excluir las líneas administrativas del cálculo de la versión del plan.

Todavía es pronto para evaluar la magnitud del efecto: el fragmento proporcionado se interrumpe en una tabla con mediciones personales del autor y no ofrece una visión completa de la productividad del equipo. Pero la técnica de ingeniería ya está clara. Para cada acción obligatoria, hay que definir un resultado verificable y bloquear la transición si falta. Después, hay que asegurarse de que el agente no pueda reescribir los criterios con los que se acepta su trabajo.