Conclusiones clave
- Escribir código ya no es la parte lenta. En 31 días nuestro repositorio principal fusionó 473 solicitudes de cambios. 130 de ellas necesitaron que alguien volviera y fusionara main en la rama, 239 commits de fusión en total, y 238 de esos fueron hechos por una persona.
- Las PRs que lo necesitaban tomaron una mediana de 44 horas desde la apertura hasta la fusión. Las que no lo necesitaban tomaron 2. De las 60 PRs que se mantuvieron abiertas más de tres días, 51 necesitaban al menos una fusión de main.
- babysit-pr divide el trabajo en una etiqueta:
LGTM, «looks good to me» (se ve bien), que el autor añade cuando el trabajo está hecho. Antes de ello, una habilidad mantiene el agente en la PR hasta que CI esté verde y cada bot de revisión sea respondido. Después de ello, un flujo de trabajo de GitHub Actions mantiene la PR fusionable hasta que una persona la fusione, y añadeRTM, «ready to merge» (listo para fusionar), una vez que alguien diferente al autor la aprueba. - El flujo de trabajo nunca fusiona, nunca cierra, y nunca cambia una línea que el autor escribió. Un conflicto que no puede resolver alrededor del código del autor vuelve al autor como
REWORK. - La habilidad es pública, con licencia MIT: babysit-pr-skill en GitHub , con el script del observador y el diseño del flujo de trabajo. El flujo de trabajo en sí aún está en ejecución de prueba en nuestro repositorio, y explico por qué debajo.
¿Por qué las solicitudes de cambios terminadas se vuelven obsoletas?
Escribir el código dejó de ser la parte lenta. Con el patrón de arquitecto y agentes haciendo la mayoría de la escritura, nuestro repositorio toma aproximadamente 13 commits al día en main. Eso es bueno para el envío y malo para cada solicitud de cambios abierta, porque cada uno de esos commits puede poner una PR en conflicto o poner su CI en rojo.
Extraje los últimos 31 días de PRs fusionadas para ver dónde se fue el tiempo.
El 44 contra 2 es una correlación, no una causa. Una PR que se mantiene abierta más tiempo da a main más tiempo para moverse bajo ella, por lo que es más probable que necesite una fusión. Pero las fusiones en sí son trabajo real que alguien hizo 239 veces en un mes. Cinco personas hicieron 238 de ellas a mano. Una PR necesitó ocho fusiones de main durante los siete días que estuvo abierta.
La aprobación en sí fue rápida. Una vez que una PR obtuvo su primera aprobación, la mediana de tiempo hasta la fusión fue cero horas. La espera sucedió antes de eso: el autor terminó, luego la PR se quedó hasta que un revisor llegó a ella, y mientras se quedaba, main se movió. Comenzamos a etiquetar las PRs terminadas como LGTM el 20 de octubre. Las 20 que se fusionaron desde entonces esperaron una mediana de 38 horas entre LGTM y fusión, y una de cada cuatro esperó más de 78.
Ese es el vacío para el que es esto. Nadie es descuidado aquí. El autor cree que está hecho, el revisor aún no la ha abierto, y la rama se pudre entre ellas.
¿Listo para hacer crecer tu negocio?
Comienza tu prueba gratuita hoy y ve resultados en días.
¿Por qué no cerrar solicitudes de cambios obsoletas con actions/stale?
La respuesta habitual a las solicitudes de cambios obsoletas es actions/stale : una GitHub Action que añade una etiqueta obsoleta a problemas y solicitudes de cambios después de un número establecido de días de inactividad, y los cierra automáticamente algunos días después a menos que alguien comente o haga push.
Eso se ajusta a una solicitud de cambios en la que nadie está trabajando. No hace nada en las que teníamos. Las nuestras eran trabajo terminado que se volvió obsoleto mientras esperaban a un revisor, porque main se movió bajo ellas. Cerrarlas tira el trabajo, y una etiqueta obsoleta le dice al autor lo que ya sabe. Lo que la PR necesita es que alguien fusione main, vuelva a ejecutar el trabajo de CI rojo y lo mantenga verde hasta que una persona lo apruebe. Entonces, en lugar de cerrar solicitudes de cambios obsoletas, las mantenemos fusionables.
Cómo babysit-pr mantiene las solicitudes de cambios fusionables
La división sigue a quién está esperando. Antes de LGTM el autor aún está en la PR, generalmente una sesión de agente, y la habilidad mantiene esa sesión haciendo trabajo útil en lugar de declarar victoria cuando el código se compila. Después de LGTM el autor se ha movido, así que el trabajo va a algo que no los necesita: un flujo de trabajo que se ejecuta independientemente de si alguien está mirando.
LGTM significa «looks good to me» (se ve bien). En la mayoría de los equipos un revisor lo dice sobre el código de otro. Aquí el autor lo pone en su propia PR como una etiqueta que significa «He terminado, no queda nada para mí». Es la palabra de una persona: el agente solo lo añade cuando se le dijo que entregara la PR. Esa etiqueta es el consentimiento para todo lo que viene después, y es lo que hace que un desarrollador se sienta cómodo permitiendo que un bot haga push a su rama.
Únete a nuestro boletín
Obtén los últimos consejos, tendencias y ofertas gratis.
Antes de LGTM: una habilidad de Claude Code lleva la PR a lista
La habilidad comenzó como la habilidad babysit-pr en tstack
de Theo Browne. Mantuve su observador y sus reglas principales y cambié dónde se detiene.
Un observador por solicitud de cambios
pr-wait controla una solicitud de cambios y imprime una línea por evento real: una verificación falló, todas las verificaciones finalizaron, alguien comentó o revisó, main se movió bajo archivos que esta PR toca, la rama se quedó atrás o en conflicto, la PR se fusionó. En Claude Code se ejecuta bajo la herramienta Monitor, por lo que cada línea despierta el agente una vez. Un evento que no necesita acción termina el turno sin un mensaje. «Todavía esperando» no es noticia, y un agente que lo dice cincuenta veces llena su propio contexto con nada.
Ordena el trabajo de CI rojo antes de tocar código
Hay cuatro tipos de rojo, y solo uno es una corrección de código:
- La PR lo rompió. Corrígelo con el cambio más pequeño.
- El runner se inestabilizó. Vuelve a ejecutar los trabajos fallidos una vez. Un segundo fallo en la misma cabeza no es una inestabilidad.
- Main está rojo. No corrijas main en la rama de característica de alguien. Informalo y espera.
- Una verificación de proceso está roja, por ejemplo la PR no vincula un problema aprobado. Ese es un paso para una persona.
Los agentes dejados solos tratan a los cuatro como el primero, y la PR crece una solución alternativa para una prueba que está rota en main.
Demuestra un hallazgo de revisión antes de corregirlo
Un hallazgo de revisión que el agente acepta obtiene una prueba fallida primero, luego la corrección. Un hallazgo que rechaza obtiene una razón escrita. Esta es la misma regla que nuestra habilidad de revisión probada, y es lo que detiene a los bots de revisión de dirigir una PR por volumen.
Mantén la PR del tamaño de su objetivo
Los bucles de revisión crecen una PR una corrección barata a la vez: una protección para un caso extremo que nadie alcanza, una prueba para un comportamiento que no cambió, un shimcompatibilidad. La habilidad corrige errores reales en el caso previsto y rechaza el resto por escrito. Los que valen la pena se convierten en problemas.
Listo es una lista de verificación
Cada trabajo de CI de puerta verde en la cabeza actual, cada bot de revisión terminado en esta cabeza, nada esperando una persona, sin hilo sin resolver, sin conflicto. Cuando eso se mantiene el agente lo informa y deja de observar.
Después de LGTM: un flujo de trabajo de GitHub Actions resuelve conflictos de fusión
El flujo de trabajo tiene dos trabajos.
La puerta decide lo que cada PR necesita
La puerta es barata: sin agente, sin extracción de código de PR. Se ejecuta en cada push a main, cada finalización de CI, cada etiqueta y revisión, y cada 30 minutos, y una consulta GraphQL le da cada PR LGTM abierta. Para cada una una función pura decide qué hacer. Añade RTM si está aprobada por alguien diferente del autor, verde, y sin conflictos. Déjala sola si una revisión se está ejecutando. Vuelve a ejecutar CI rojo una vez. Envía un conflicto, o CI que aún está rojo después de su re-ejecución, al fijador.
El agente fijador fusiona main
El fijador es un trabajo de agente para una PR en una cabeza. Fusiona main en la rama sin confirmar, le da al agente los archivos conflictivos y los registros de fallo, y le permite editar solo los archivos conflictivos y los archivos que la PR ya cambia. Luego hace una pregunta.
¿Puede esta PR aterrizar sin cambiar una línea que su autor escribió?
Si es así, el veredicto es MODERNIZE. El agente resuelve el conflicto alrededor de las líneas del autor, un validador verifica el resultado, y el flujo de trabajo empuja un commit de fusión normal. Si no, porque main eliminó la función que la PR edita o el propio código de la PR falla CI, el veredicto es REWORK. Nada se empieza, LGTM se quita, y el autor obtiene un comentario con la reescritura más pequeña. Si main ya hace lo que la PR hace, el veredicto es CLOSE, y una persona la cierra.
El validador mantiene cada línea que el autor escribió
El validador es lo que hace que la regla se mantenga. Rechaza cualquier fusión que elimine una línea que la PR añadió, o una línea que main añadió a un archivo conflictivo. Rechaza ediciones fuera de los archivos permitidos, marcadores de conflicto restantes, y cambios a archivos de CI o seguridad. Un agente que intenta «corregir» el código del autor termina con una etiqueta pidiendo una persona, nunca con un empuje. El flujo de trabajo empuja sin fuerza, y solo si la rama no se ha movido desde que el intento comenzó. Un intento por cabeza y base, dos por cabeza, tres comentarios por PR por día.
Nunca fusiona
RTM, «ready to merge» (listo para fusionar), es la declaración de la puerta de que una PR tiene todo lo que necesita: la LGTM del autor, una aprobación de alguien más, CI verde y sin conflicto. Una persona hace la fusión. Eso mantuvo el diseño pequeño, y mantuvo el argumento sobre si un bot debería fusionar fuera de la revisión.
¿Qué cambia para el autor, el revisor y quien fusiona?
El autor dice terminado una vez. No vuelven tres días después para fusionar main y esperar CI de nuevo, y la PR de un agente no se pudre porque la sesión que la abrió terminó.
El revisor abre una PR que está verde y fusionable en main de hoy, así que su aprobación es el último paso y no el inicio de otra ronda.
Quien fusiona trabaja desde una lista. RTM se mantiene una vez que la puerta lo añade, y si main rompe la PR después, el flujo de trabajo la corrige y la etiqueta se mantiene.
Y el autor mantiene el control de su código. Lo peor que el bot puede hacer a una rama es añadir un commit de fusión que un validador ha verificado línea por línea.
¿Por qué nuestro antiguo resolutor de conflictos de fusión nunca se ejecutó?
Teníamos un resolutor de conflictos antes de este. Un detector encontró PRs conflictivas y comentó en ellas, y el resolutor se ejecutó cuando alguien añadió una etiqueta pidiéndolo. En el mismo período el detector se ejecutó alrededor de 2,500 veces. El resolutor se ejecutó cero veces.
No creo que nadie fuera perezoso. Un desarrollador que considera una PR terminada no vuelve a ella para presionar un botón. La automatización que espera a ser pedida no será pedida. Por eso este comienza con LGTM, el momento en que el autor dice que está terminado, y hace el resto sin ellos.
¿Qué no funciona aún?
Dos cosas, y prefiero decirlas aquí que tengas que encontrarlas.
El flujo de trabajo está en ejecución de prueba
Su puerta solo registra lo que haría hasta que una variable de repositorio diga lo contrario. Antes de que llegara tan lejos, una revisión que solo mantiene hallazgos que puede probar con una prueba fallida encontró once errores en ella. Algunos valen la pena saber si construyes el tuyo. La búsqueda de etiquetas de GitHub se retrasa, por lo que una PR que devuelve puede haber perdido la etiqueta segundos hace, y la decisión debe verificar etiquetas en vivo. Un marcador «esta cabeza ya tuvo su re-ejecución» escrito antes de que la llamada de re-ejecución tenga éxito permite a un fracaso de API fallo use el único reintento de la cabeza. Y una verificación «no pierde ninguna línea» que no sigue cambios de nombre ve cada línea de un archivo renombrado como perdida.
Los corredores de agentes estaban caídos
Desde el 19 de octubre cada trabajo dirigido a nuestros corredores de agentes ha fracasado en obtener una máquina: 406 cancelados, 24 aún en cola cuando revisé. La puerta se ejecuta en otro lugar y está bien, pero el fijador necesita un corredor de agentes, y uno muerto se parece exactamente a un día tranquilo. Nada fracasó ruidosamente. Los trabajos se pusieron en cola y luego se cancelaron. Si construyes esto, alerta en ejecuciones de fijador que se sientan en cola.
Entonces los números anteriores son la imagen anterior. Ahora tenemos 27 LGTM PRs abiertas, 7 de ellas con CI rojo y ninguna con RTM. Esos son los números que esto debería cambiar, e informaré sobre lo que hizo.
Cómo instalar la habilidad babysit-pr
github.com/LivinTribunal/babysit-pr-skill tiene:
SKILL.md, la habilidad, con una breve sección «configura una vez» para tus flujos de trabajo de CI, bots de revisión y verificaciones de proceso.scripts/pr-wait, el observador. Necesita Python y unghautenticado.docs/after-lgtm.md, el diseño del flujo de trabajo después deLGTM: las etiquetas, la puerta, el fijador, la regla de que nunca cambia las líneas del autor, y los once errores.
El flujo de trabajo es un diseño en lugar de un archivo para copiar, porque el nuestro se ejecuta contra las etiquetas, corredores y CI de una empresa. Construye el tuyo desde el doc, envíalo en modo solo log, lee un día de sus decisiones, luego actívalo.
Se empareja con el patrón de arquitecto , que decide quién escribe el código, y grain , que decide cómo se ve el código. babysit-pr es lo que sucede después de que cualquiera de ellos abre la solicitud de cambios. Si estás ajustando el agente en sí, la prueba A/B de CLAUDE.md y el límite de contexto que redujo el uso de tokens en un 17% cubren las instrucciones y el costo.
