Principais conclusões
- Escrever código não é mais a parte lenta. Em 31 dias nosso repositório principal mesclou 473 solicitações de pull request. 130 delas precisaram que alguém voltasse e mesclasse o main no branch, 239 commits de mesclagem no total, e 238 deles foram feitos por uma pessoa.
- Os PRs que precisavam disso levaram uma mediana de 44 horas desde abertura até mesclagem. Os que não precisavam levaram 2. Dos 60 PRs que permaneceram abertos por mais de três dias, 51 precisaram de pelo menos uma mesclagem do main.
- babysit-pr divide o trabalho em um rótulo:
LGTM, “looks good to me”, que o autor adiciona quando o trabalho está pronto. Antes disso, uma habilidade mantém o agente na PR até que CI esteja verde e cada bot de revisão tenha respondido. Depois disso, um fluxo de trabalho do GitHub Actions mantém a PR mesclável até que uma pessoa a mescle, e adicionaRTM, “ready to merge”, assim que alguém que não seja o autor aprova. - O fluxo de trabalho nunca mescla, nunca fecha e nunca altera uma linha que o autor escreveu. Um conflito que não consegue resolver em torno do código do autor volta para o autor como
REWORK. - A habilidade é pública, licenciada com MIT: babysit-pr-skill no GitHub , com o script observador e o design do fluxo de trabalho. O fluxo de trabalho em si ainda está em execução seca no nosso repositório, e explico abaixo por quê.
Por que solicitações de pull request concluídas ficam obsoletas?
Escrever o código deixou de ser a parte lenta. Com o padrão arquiteto e agentes fazendo a maioria da digitação, nosso repositório leva cerca de 13 commits por dia para o main. Isso é bom para envio e ruim para cada solicitação de pull request aberta, porque cada um desses commits pode colocar uma PR em conflito ou deixar seu CI vermelho.
Puxei os últimos 31 dias de PRs mescladas para ver para onde o tempo foi.
O 44 contra 2 é uma correlação, não uma causa. Um PR que permanece aberto por mais tempo dá ao main mais tempo para se mover sob ele, então é mais provável que precise de uma mesclagem. Mas as mesclagens em si são trabalho real que alguém fez 239 vezes em um mês. Cinco pessoas fizeram 238 delas manualmente. Um PR precisou de oito mesclagens do main durante os sete dias que esteve aberto.
A aprovação em si foi rápida. Assim que um PR recebeu sua primeira aprovação, o tempo mediano para mesclagem foi zero horas. A espera aconteceu antes disso: o autor terminou, depois a PR ficou sentada até um revisor chegar até ela, e enquanto ficava, o main se moveu. Começamos a rotular PRs concluídas como LGTM em 20 de outubro. Os 20 que mesclaram desde então esperaram uma mediana de 38 horas entre LGTM e mesclagem, e um em cada quatro esperou mais de 78.
Essa é a lacuna para a qual isso é. Ninguém é descuidado aqui. O autor acha que está pronto, o revisor ainda não a abriu, e o branch apodrece enquanto isso.
Pronto para expandir seu negócio?
Comece seu teste gratuito hoje e veja resultados em dias.
Por que não fechar solicitações de pull request obsoletas com actions/stale?
A resposta usual para solicitações de pull request obsoletas é actions/stale : uma ação do GitHub que adiciona um rótulo obsoleto a problemas e solicitações de pull request após um número definido de dias de inatividade, e as fecha automaticamente alguns dias depois a menos que alguém comente ou faça push.
Isso se encaixa em uma solicitação de pull request que ninguém está trabalhando. Não faz nada para aqueles que tínhamos. Os nossos eram trabalho concluído que ficou obsoleto enquanto esperavam por um revisor, porque o main se moveu sob eles. Fechá-los joga o trabalho fora, e um rótulo obsoleto diz ao autor o que ele já sabe. O que o PR precisa é que alguém mescle o main, re-execute o trabalho CI vermelho e o mantenha verde até que uma pessoa aprove. Então, em vez de fechar solicitações de pull request obsoletas, mantemos elas mesclável.
Como babysit-pr mantém solicitações de pull request mesclável
A divisão segue quem está esperando. Antes de LGTM o autor ainda está no PR, geralmente uma sessão de agente, e a habilidade mantém essa sessão fazendo trabalho útil em vez de declarar vitória quando o código compila. Após LGTM o autor avançou, então o trabalho vai para algo que não precisa deles: um fluxo de trabalho que executa se alguém estiver olhando ou não.
LGTM significa “looks good to me”. Na maioria das equipes um revisor diz sobre o código de outra pessoa. Aqui o autor coloca em seu próprio PR como um rótulo que significa “Estou pronto, nada mais para eu fazer”. É a palavra de uma pessoa: o agente adiciona apenas quando foi instruído a entregar a PR. Esse rótulo é o opt-in para tudo depois disso, e é a coisa que torna um desenvolvedor confortável permitindo que um bot faça push em seu branch.
Junte-se à nossa newsletter
Receba gratuitamente as últimas dicas, tendências e ofertas.
Antes de LGTM: uma habilidade do Claude Code leva o PR para pronto
A habilidade começou como a habilidade babysit-pr no tstack
de Theo Browne. Mantive seu observador e suas regras principais e mudiei onde para.
Um observador por solicitação de pull request
pr-wait sonda uma solicitação de pull request e imprime uma linha por evento real: uma verificação falhou, todas as verificações terminaram, alguém comentou ou revisou, o main se moveu em arquivos que esse PR toca, o branch ficou para trás ou em conflito, a PR mesclou. No Claude Code ele executa sob a ferramenta Monitor, então cada linha ativa o agente uma vez. Um evento que não precisa de ação termina o turno sem uma mensagem. “Ainda esperando” não é notícia, e um agente que diz isso cinquenta vezes preenche seu próprio contexto com nada.
Classifique o trabalho CI vermelho antes de tocar código
Existem quatro tipos de vermelho, e apenas um é uma correção de código:
- O PR quebrou. Corrija com a menor mudança.
- O executor apresentou falha. Re-execute os trabalhos falhados uma vez. Uma segunda falha na mesma head não é uma falha.
- O main está vermelho. Não corrija o main no branch de recurso de alguém. Relate e aguarde.
- Uma verificação de processo está vermelha, por exemplo, o PR não liga um problema aprovado. Isso é um passo para uma pessoa.
Agentes deixados sozinhos tratam todos os quatro como o primeiro, e a PR cresce uma solução alternativa para um teste que está quebrado no main.
Prove uma descoberta de revisão antes de corrigi-la
Uma descoberta de revisão que o agente aceita recebe um teste falhando primeiro, depois a correção. Uma descoberta que ele descarta recebe uma razão escrita. Esta é a mesma regra da nossa habilidade de revisão comprovada, e é o que impede que bots de revisão direcionem uma PR por volume.
Mantenha a PR do tamanho de seu objetivo
Loops de revisão crescem uma PR um conserto barato por vez: uma proteção para um caso extremo que ninguém acerta, um teste para comportamento que não mudou, um shim de compatibilidade. A habilidade corrige bugs reais no caso pretendido e declina o resto por escrito. Os que valem a pena se tornam problemas.
Pronto é uma lista de verificação
Cada trabalho CI de gating verde no head atual, cada bot de revisão concluído neste head, nada aguardando em um humano, nenhuma thread não resolvida, nenhum conflito. Quando isso se mantém, o agente a relata e para de observar.
Após LGTM: um fluxo de trabalho do GitHub Actions resolve conflitos de mesclagem
O fluxo de trabalho tem dois trabalhos.
O portão decide o que cada PR precisa
O portão é barato: sem agente, sem checkout do código PR. Ele executa em cada push para main, cada conclusão de CI, cada rótulo e revisão, e a cada 30 minutos, e uma consulta GraphQL fornece cada PR aberta LGTM. Para cada um uma função pura decide o que fazer. Adicione RTM se for aprovado por alguém que não seja o autor, verde e sem conflito. Deixe em paz se uma revisão está executando. Re-execute CI vermelho uma vez. Envie um conflito, ou CI que ainda está vermelho após sua re-execução, para o corretor.
O agente corretor mescla o main
O corretor é um trabalho de agente para uma PR em uma head. Ele mescla o main no branch sem fazer commit, dá ao agente os arquivos conflitados e os logs falhados, e deixa editar apenas os arquivos conflitados e os arquivos que a PR já altera. Depois faz uma pergunta.
Essa PR pode se integrar sem alterar uma linha que o autor escreveu?
Se sim, o veredito é MODERNIZE. O agente resolve o conflito em torno das linhas do autor, um validador verifica o resultado, e o fluxo de trabalho empurra um commit de mesclagem normal. Se não, porque o main deletou a função que a PR edita ou o código da própria PR falha em CI, o veredito é REWORK. Nada é empurrado, LGTM é removido, e o autor recebe um comentário com a menor reescrita. Se o main já faz o que a PR faz, o veredito é CLOSE, e uma pessoa a fecha.
O validador mantém cada linha que o autor escreveu
O validador é o que mantém a regra. Ele rejeita qualquer mesclagem que descarte uma linha que a PR adicionou, ou uma linha que o main adicionou a um arquivo conflitado. Ele rejeita edições fora dos arquivos permitidos, marcadores de conflito restantes e mudanças em arquivos CI ou segurança. Um agente que tenta “corrigir” o código do autor termina com um rótulo pedindo um humano, nunca com um push. O fluxo de trabalho empurra sem força, e apenas se o branch não se moveu desde o início da tentativa. Uma tentativa por head e base, duas por head, três comentários por PR por dia.
Ele nunca mescla
RTM, “ready to merge”, é a declaração do portão de que uma PR tem tudo que precisa: o LGTM do autor, uma aprovação de alguém mais, CI verde e nenhum conflito. Uma pessoa faz a mesclagem. Isso manteve o design pequeno, e manteve o argumento sobre se um bot deve mesclar fora da revisão.
O que muda para o autor, o revisor e quem mescla
O autor diz pronto uma vez. Ele não volta três dias depois para mesclar o main e esperar por CI novamente, e uma PR de um agente não apodrece porque a sessão que a abriu terminou.
O revisor abre uma PR que está verde e mesclável no main de hoje, então sua aprovação é o último passo e não o início de outra rodada.
Quem mescla trabalha de uma lista. RTM permanece uma vez que o portão a adiciona, e se o main quebrar a PR depois disso, o fluxo de trabalho a corrige e o rótulo permanece.
E o autor mantém o controle de seu código. O pior que o bot pode fazer a um branch é adicionar um commit de mesclagem que um validador verificou linha por linha.
Por que nosso antigo resolvedor de conflito de mesclagem nunca foi executado
Tínhamos um resolvedor de conflito antes deste. Um detector encontrou PRs conflitadas e comentou sobre elas, e o resolvedor executou quando alguém adicionou um rótulo pedindo. No mesmo período o detector executou cerca de 2.500 vezes. O resolvedor executou zero vezes.
Não acho que alguém foi preguiçoso. Um desenvolvedor que considera uma PR concluída não volta a ela para pressionar um botão. Automação que aguarda ser solicitada não será solicitada. É por isso que esta começa com LGTM, o momento em que o autor diz que está pronto, e faz o resto sem eles.
O que ainda não está funcionando?
Duas coisas, e prefiro dizê-las aqui do que você as descobrir.
O fluxo de trabalho está em execução seca
Seu portão apenas registra o que faria até que uma variável de repositório diga o contrário. Antes de ir até lá, uma revisão que apenas mantém descobertas que consegue provar com um teste falhando encontrou onze bugs. Alguns valem a pena saber se você construir o seu. A busca de rótulo do GitHub atrasa, então uma PR que retorna pode ter perdido o rótulo segundos atrás, e a decisão deve verificar rótulos em tempo real. Um marcador “esta head já teve sua re-execução” escrito antes da chamada de re-execução suceder deixa uma chamada de API falhada usar a única tentativa da head. E um cheque “não perca nenhuma linha” que não segue renomações vê cada linha de um arquivo renomeado como perdido.
Os corredores de agentes estavam inativos
Desde 19 de outubro cada trabalho destinado aos nossos corredores de agentes falhou em obter uma máquina: 406 cancelados, 24 ainda enfileirados quando verifiquei. O portão executa em outro lugar e está bom, mas o corretor precisa de um corredor de agente, e um morto parece exatamente como um dia tranquilo. Nada falhou com força. Trabalhos enfileirados e depois foram cancelados. Se você construir isso, alerte sobre execuções de corretor que ficam enfileiradas.
Então os números acima são a imagem anterior. Agora temos 27 PRs abertas LGTM, 7 delas com CI vermelho e nenhuma com RTM. Esses são os números que isso deveria mudar, e reportarei o que fez.
Como instalar a habilidade babysit-pr
github.com/LivinTribunal/babysit-pr-skill tem:
SKILL.md, a habilidade, com uma breve seção “configure uma vez” para seus fluxos de trabalho CI, bots de revisão e verificações de processo.scripts/pr-wait, o observador. Precisa de Python e umghautenticado.docs/after-lgtm.md, o design do fluxo de trabalho apósLGTM: os rótulos, o portão, o corretor, a regra de que nunca altera as linhas do autor, e os onze bugs.
O fluxo de trabalho é um design em vez de um arquivo para copiar, porque o nosso executa contra rótulos, corredores e CI de uma empresa. Construa o seu a partir do doc, envie no modo somente log, leia um dia de suas decisões, depois ative.
Ele se emparelha com o padrão arquiteto , que decide quem escreve o código, e grain , que decide como o código se parece. babysit-pr é o que acontece depois que um deles abre a solicitação de pull request. Se você está sintonizando o agente em si, o teste A/B CLAUDE.md e o limite de contexto que reduziu o uso de tokens em 17% cobrem as instruções e o custo.
