Firmas el plan y el PR entra solo — automerge con cuatro puertas
En la Software Factory de Ghosty, la persona que pide un cambio firma una sola vez: el plan. Después de esa firma, el PR entra solo a main en cuanto el agente revisor lo aprueba y el CI pasa. El automerge viene encendido por default en cada room de la fábrica y se apaga por room si el equipo prefiere firmar cada PR.
La pregunta útil no es si confiar en el agente, sino qué condiciones tiene que cumplir un PR para entrar sin que nadie lo mire antes del merge. Este post cuenta las cuatro condiciones que pusimos, un pedido que salió bien y otro que salió mal.
La firma humana va en el plan porque ahí se decide qué se construye
El flujo tiene cinco pasos:
- Arqui planea. Se le habla con
@arqui. Lee el proyecto y propone cómo hacer el cambio: historia con criterios de aceptación, brief técnico, riesgos y lo que no se hará. Arqui no toca el código. - La persona firma el plan. La firma se da con un botón, con «✅» en el hilo, por WhatsApp o desde la pestaña Fábrica de la app de Ghosty en el teléfono. Si el plan no convence, la persona responde «cambios: …» y Arqui lo reescribe.
- Worker construye. Worker trabaja en su propia caja de trabajo: rama nueva, código, pruebas y PR en borrador.
- Arqui revisa contra el plan que él mismo escribió. Arqui escribe sus propias pruebas de aceptación. Si falta algo, Arqui le regresa el PR a Worker, hasta 3 vueltas.
- Automerge a main. Con la aprobación de Arqui y el CI en verde, el PR entra solo.
Firmar el plan en vez del PR mueve la atención humana al momento en que todavía es barato cambiar de opinión. Un diff escrito por un agente pide reconstruir la intención línea por línea; un plan la dice de entrada.
La separación de roles importa por una razón concreta: quien construye no se revisa a sí mismo. Arqui revisa con el contexto completo del plan porque Arqui lo escribió. Contamos por qué pasamos de tres roles a dos en .
El automerge sólo es seguro con puertas que el agente no puede saltarse
Las cuatro puertas que todo PR tiene que pasar:
- Arqui revisa contra el plan firmado. Arqui compara el PR con los criterios de aceptación del plan y corre sus propias pruebas. Si falta un criterio o el código queda difícil de mantener, el PR regresa a Worker.
- El CI tiene la última palabra. Con el CI en rojo no hay merge. El PR regresa solo a Worker y vuelve a la fila cuando Arqui lo aprueba otra vez.
- Si el plan pide preview, sin preview no entra. Pantallas, formularios y pagos se prueban con la app corriendo. Mientras la preview no funcione, el PR espera.
- Una versión mayor de una dependencia nunca entra sola. Un salto de versión mayor siempre espera a una persona, aunque el CI esté en verde.
Las cuatro puertas viven en el código de la plataforma, no en el prompt del agente. Una regla escrita en el código se cumple en cada merge, aunque el agente olvide una instrucción.
El riesgo de un PR lo marca la plataforma por lo que toca
Cada PR revisado publica una tarjeta de veredicto en el hilo.
El riesgo no sale de la opinión del agente. La plataforma marca el riesgo como alto cuando el PR toca autenticación, migraciones, dependencias, la API pública, la carpeta .github/ o más de 400 líneas. Arqui puede subir el riesgo por lógica delicada, pero nunca puede bajarlo.
La sección «Lee primero» lista hasta cinco referencias archivo:líneas con su porqué. Quien revisa después del merge empieza por ahí y no por el diff completo.
Un pedido real tardó 7 minutos de la firma al PR revisado
El 24 de septiembre de 2026 mandamos este pedido a la fábrica sobre el repo de Deník, nuestra app de reservas: «Agrega pruebas de vitest para las funciones de la agenda que arman la grilla de horarios. Sólo pruebas nuevas: no toques el código de la app».
Pasaron 7 min de la firma al PR revisado. El PR trajo 10 pruebas nuevas en un solo archivo, pasó 4 de 4 checks del CI y Arqui lo aprobó con 0 vueltas a Worker. Un pedido acotado, con criterio de aceptación claro y sin tocar código de producción, es el caso ideal para el automerge. El siguiente caso no fue ideal.
Un major de React Router se aprobó sin preview y rompió las reservas 18 horas
El 16 de octubre de 2026 la fábrica procesó una actualización de React Router de la versión 7 a la 8 en el mismo repo de Deník. El pedido tardó 7.0 h, costó 8.19 USD y dio 1 vuelta de revisión.
El plan aprobado exigía probar la reserva pública de punta a punta en la preview del PR. La preview nunca arrancó. El agente revisor probó la reserva en su caja, contra localhost, y aprobó. En producción, la versión 8 de React Router rechazaba cada envío de formulario, y las reservas de Deník estuvieron rotas cerca de 18 horas.
De ese incidente salieron dos cambios:
- La regla «si el plan pide preview, sin preview no entra». Antes, la revisión probaba en la preview sólo si la preview existía. Ahora una preview faltante bloquea la aprobación y el merge.
- La categoría «aprobado con un criterio sin cumplir». El diagnóstico de cada pedido cruza los criterios del plan aprobado con la evidencia del veredicto, sin usar un modelo, y marca el caso por encima de cualquier otro problema.
La regla de que un major nunca entra solo también responde a ese incidente. El análisis completo, sin culpables, está en .
Cada pedido tiene su cuenta: costo, horas y vueltas
El tablero de la fábrica muestra tres números por pedido:
- Costo por PR mezclado, en dólares.
- Horas desde el pedido hasta el merge.
- Vueltas de Arqui a Worker antes de la aprobación.
Un tipo de pedido con muchas vueltas o con CI rojo frecuente pide un plan más preciso o mejores pruebas antes de dejarlo entrar solo.
Las mismas puertas se pueden armar sin la fábrica
Cualquier equipo en GitHub puede aplicar el mismo criterio:
-
Activa auto-merge con checks requeridos. El auto-merge de GitHub mezcla un PR cuando pasan las revisiones y los checks requeridos; sin checks requeridos no protege nada.
-
Exige un deploy de prueba antes del merge. Las reglas de GitHub incluyen «Require deployments to succeed before merging», que obliga a que el cambio se despliegue bien en un entorno, por ejemplo staging, antes de mezclar.
-
Saca los majors del carril automático. Prueba el flujo que mueve dinero en un entorno con el mismo proxy y el mismo protocolo que producción.
-
Escribe el criterio de aceptación donde se pueda comprobar. Una frase en la descripción del PR no frena nada. Un check que falla sí.
-
Marca el riesgo por rutas, no por opinión. Una regla de CODEOWNERS sobre autenticación, migraciones y
.github/obliga a que una persona revise esos archivos.
En resumen
El automerge de código escrito por agentes funciona cuando la persona firma el plan y el sistema verifica el resto con reglas fijas. En la Software Factory son cuatro reglas: el revisor compara el PR con el plan firmado, el CI en rojo bloquea el merge, un plan que pide preview no se mezcla sin preview y un salto de versión mayor siempre espera a una persona. La regla de la preview existe porque un PR de React Router 8 se aprobó sin preview y dejó sin reservas a Deník cerca de 18 horas.