GitHub e agentes de IA
No GitHub está tudo o que foi feito, e nada disso está escrito para quem pergunta quando é que fica pronto. O agente lê o repositório e passa-o para frases que você pode dizer a um cliente ou à direcção: o que saiu, o que está encravado e aquilo por que lhe vão perguntar primeiro.
O que um agente faz no GitHub
- Reúne o que saiu mesmo esta semana: pull requests integrados, issues fechadas, etiquetas de versão colocadas.
- Mostra os pull requests que estão sem revisão há mais tempo do que o prazo que você definiu.
- Mantém a ligação entre a pergunta do cliente e a issue que está por trás: onde vai e o que lá aconteceu por último.
- Prepara um rascunho das notas de versão a partir dos commits e das etiquetas reais, separando o que o utilizador vai notar do que só a equipa nota.
- Traz-lhe as issues abertas por gente de fora da equipa, em vez de as deixar paradas sem ninguém as ler.
Processos que arrancam sozinhos
Um playbook não é um botão — é um processo com uma condição que o faz arrancar. No GitHub, essa condição vem quase sempre do próprio repositório: um pull request sem revisão, uma etiqueta de versão colocada, uma issue aberta por alguém de fora.
Um pull request fica sem revisão
Um pull request está aberto há mais tempo do que o prazo que você definiu e continua sem revisão
- Separar a espera a sério dos rascunhos e daqueles que não têm revisor atribuído
- Explicar num parágrafo, sem código, o que muda e a quem toca
- Lembrar o revisor atribuído onde ele lê mesmo as mensagens
- Pôr-lhe à frente aquele que está a atrasar a entrega há mais tempo
Uma versão, contada por palavras
É colocada uma etiqueta de versão no repositório
- Reunir os commits e as issues fechadas entre a etiqueta anterior e esta
- Separar o que o cliente vai notar do que só a equipa nota
- Entregar-lhe o rascunho das notas de versão — a redacção e as promessas continuam a ser suas
- Assinalar os pontos que precisam da resposta de um programador e não de um palpite
Chega alguma coisa de fora
Uma issue é aberta por alguém que não é da sua equipa
- Verificar se aquilo repete algo que já está aberto
- Montar uma ficha curta: quem escreveu, o que pede, o que é que isso afecta
- Entregá-la a si — não atribui responsável nem promete data
Onde o agente pára
- Não escreve, não revê nem integra código: isso é decisão da engenharia e responsabilidade dela.
- Conta o que o repositório mostra e não tira nem qualidade nem esforço do número de commits.
- Não mexe em acessos, segredos nem na protecção de ramos — nada disso se configura por conversa.
- Quando é que uma coisa fica pronta dizem-no as pessoas que a estão a fazer, e não um agente a extrapolar um gráfico de commits.
FAQ
É preciso saber ler código para acompanhar isto?
Não. O agente descreve as alterações pelo resultado: o que passou a funcionar, o que foi corrigido, a quem é que toca. A ligação para o pull request ou para a issue original fica ao lado, para quando você a quiser pôr à frente de um programador.
O agente vai alterar alguma coisa no repositório?
Por omissão só lê. Se você autorizar, deixa um comentário ou uma etiqueta — nunca código, ramos ou histórico. Rever e integrar continua a ser da equipa.
Isto não acaba por ser vigiar os programadores?
De propósito não fazemos relatórios do género «quem fez mais commits»: esse número não diz nada sobre o trabalho e qualquer equipa aprende a alimentá-lo num mês. O agente mostra o estado do trabalho, não uma classificação de pessoas.
O que é preciso para ligar um repositório privado?
O acesso de leitura é dado pela dona do repositório ou por um administrador da organização: é decisão deles, não nossa. A partir daí a configuração é uma conversa: você indica os repositórios e os prazos a partir dos quais uma coisa conta como encravada.
Onde isto aparece
Casos em que ver o que a parte técnica está mesmo a fazer é parte do processo.