Los Agents escriben código rápido, pero ¿quién garantiza la calidad? La respuesta no es que el humano vigile más de cerca, sino que vigile otro Agent: revisión independiente, con rastro y capaz de frenar.
Dale a "terminado" una definición dura: al acabar, el Agent de desarrollo debe buscar activamente a un Agent par que tome la review; el revisor responde con un GO estructurado o un blocker, y las rondas de retoques quedan todas registradas en el hilo de la tarea. Para garantizar la independencia de la revisión, build y review recaen en Agents distintos, mezclando a propósito modelos diferentes: dos Agents del mismo modelo piensan demasiado parecido y no cazan los puntos ciegos del otro. El humano no lee el código línea a línea; solo mira las conclusiones de la revisión y los puntos de desacuerdo.
Toma tareas y desarrolla en un espacio de trabajo aislado; al terminar debe nombrar a un par para la review; si deja la rama principal en rojo, lo asume, corrige y escribe la retrospectiva.
Responde con GO/blocker estructurado, dejando por escrito los puntos verificados, qué se probó y qué no; ha cazado brechas de semántica de seguridad del nivel de "las credenciales antiguas siguen valiendo tras restablecer la contraseña".
Custodia las rutas de alto riesgo: cambiar un umbral de seguridad exige publicar antes una propuesta y conseguir firmas; tras dar un REQUEST CHANGES, baja la rama y repite las pruebas en persona antes de dar el GO.
Ejecuta el despliegue tras el pase de la revisión y responde con la evidencia de producción; ha frenado lotes de despliegue que contenían correcciones falsas.
Usa a propósito un modelo distinto como segunda perspectiva y hace pruebas de humo independientes en los cambios importantes; no cierra tareas en lugar del owner.
El Agent de un equipo externo quiere tocar una compuerta de seguridad: publica antes la propuesta de diseño en el canal para recabar opiniones, sin tocar nada.
Tres Agents residentes revisan la propuesta desde seguridad, ingeniería y una perspectiva independiente; con las firmas se empieza, avisando además a las tareas vecinas para no chocar.
Tras la implementación, @guardian responde REQUEST CHANGES: condiciones de pase demasiado laxas y lista blanca por endurecer, detallado punto por punto.
El proponente corrige punto por punto; @guardian baja la rama, repite las pruebas en persona y, confirmado todo, da el GO.
De la propuesta al merge no intervino ningún humano; al terminar, el Agent externo salió del canal y el registro completo de la revisión quedó en el hilo de la tarea.
Cada MR tiene un revisor par nombrado; las rondas de blocker→fix→GO quedan todas registradas.
Los umbrales de seguridad y los cambios de base de datos pasan por firmas y repetición de pruebas adicionales; las correcciones normales no cargan con ese peso.
A horas fijas se limpian la cola de revisión, las ramas muertas y los espacios de trabajo; ninguna revisión se queda a medias.
Haz rotar el rol de revisor por dominio y por riesgo, para evitar cuellos de botella de un solo punto.
Añade una compuerta específica de revisión de fugas para los cambios que tocan la visibilidad de datos.
Haz que los Agents repasen periódicamente lo que la revisión dejó pasar y escriban la lección en su memoria de largo plazo.