Time de desenvolvimento: agentes de IA revisam pull requests e triam issues do GitHub

Em um time de desenvolvimento, a revisão de código e a triagem de issues são duas tarefas que todo mundo acha úteis e para as quais ninguém encontra tempo de fazer a fundo. Uma pull request espera dois dias até uma pessoa livre lê-la, e os primeiros comentários costumam ser sobre o que uma leitura rápida teria visto: um teste ausente, uma branch larga demais, um segredo esquecido. Uma issue chega sem tipo nem prioridade, às vezes sem as informações para reproduzi-la, e espera que uma pessoa a qualifique. São tarefas de método, com critérios que o time sabe escrever, e combinam com os agentes de IA desde que os direitos deles sejam limitados.

A inspiração: uma primeira leitura antes das pessoas

O ponto de partida é um uso relatado por usuários do Hermes Agent, resumido em um cartão sobre o time de desenvolvimento: revisar as pull requests abertas e triar as novas issues. A ideia não é substituir o revisor humano, mas entregar a ele pull requests já lidas, com os pontos a verificar no topo da lista, e issues já qualificadas.

Mantemos dois papéis separados e um princípio de cautela: os agentes comentam e etiquetam, não decidem nada. A Atako aplica a ideia com dois agentes cujo acesso ao GitHub é deliberadamente restrito a ler, comentar e etiquetar.

O que os dois agentes fazem

O cenário implanta dois agentes, ambos conectados ao seu repositório do GitHub.

O revisor de PR lê as pull requests abertas. Para cada uma, percorre o título, a descrição, os arquivos alterados e os commits, abre os arquivos que importam e os compara com as convenções que você informou: testes, nomes, tamanho, mensagens de commit, áreas sensíveis. Procura riscos de erro, testes ausentes, mudanças que tocam autenticação, pagamento ou segredos e mudanças que nada explica. Deixa um único comentário por pull request: uma linha que resume a mudança, o que está bom e depois os pontos a verificar por ordem de importância, cada um ligado a um arquivo e, quando possível, a uma linha, e marcado como bloqueante ou como sugestão. Termina com o que não conseguiu verificar, por exemplo rodar os testes. Lembra do último commit lido e só comenta de novo quando chegam novos commits, com um acompanhamento curto.

O triador de issues cuida das novas issues. Verifica se as etiquetas de tipo (bug, funcionalidade, pergunta, documentação) e de prioridade (alta, média, baixa) existem e cria as que faltam. Para cada issue sem etiqueta, lê o texto e os comentários, procura issues parecidas, decide um tipo e uma prioridade segundo as suas regras, aplica as etiquetas e adiciona um comentário: o que entendeu, o motivo da prioridade, as prováveis duplicatas e o que falta para agir, por exemplo os passos para reproduzir ou a versão afetada. Quando o tipo ou a gravidade não estão claros, ele diz, escolhe a prioridade mais baixa e faz a pergunta.

Cada rodada termina com um resumo no chat que começa pelo que precisa logo de uma pessoa.

O que os agentes não fazem

Os limites fazem parte do desenho. Nenhum agente faz merge, aprova, pede formalmente alterações, fecha uma pull request, envia código ou cria uma branch. Essas ferramentas não são concedidas a eles: não é uma promessa feita em uma instrução, é uma capacidade que falta. O triador não fecha, não reabre, não trava e não exclui nenhuma issue e não altera nem o título, nem o responsável, nem o marco.

Os agentes não adivinham. O revisor cita o arquivo e a linha, sinaliza o que não conseguiu verificar e não inventa nenhuma função nem resultado de teste. Se encontra um segredo ou token commitado, diz onde parece estar, sem copiá-lo. O triador só cita como duplicatas issues que realmente encontrou pela busca. E a decisão continua humana a cada passo, que é o princípio de um desenho com validação humana.

Como configurar na Atako

A partir da página deste caso de uso, a implantação leva quatro passos.

1. Conecte o GitHub. Crie um token de permissões granulares limitado ao repositório, com acesso de leitura ao código e de leitura e escrita a issues e pull requests. A conexão é verificada antes de criar qualquer coisa.
2. Informe seu contexto. Dê o repositório na forma proprietário/nome, suas convenções de revisão se tiver e o que torna uma issue urgente para você. Sem elas, os agentes se apoiam em boas práticas gerais e na gravidade dos bugs.
3. Implante. Uma única ação cria os dois agentes e o projeto «Time de desenvolvimento». Os agentes são provisionados e recebem sozinhos as primeiras instruções.
4. Primeiros resultados, depois um ritmo regular. O revisor comenta as cinco pull requests mais recentes, o triador etiqueta as dez últimas issues sem etiqueta e cada um resume a sua rodada no chat. Depois o revisor agenda sozinho as rodadas dele às 9h e às 14h nos dias úteis, e o triador a dele às 9h30.

Se você ainda não tem conta, criá-la inicia o seu período de teste e o cenário é configurado logo em seguida. Se o seu administrador não permitiu que você crie agentes, a implantação avisa e para aí.

Onde ver os resultados

Os comentários de revisão são lidos no GitHub, em cada pull request, e as etiquetas e os comentários de triagem, em cada issue. O resumo de cada rodada é lido no chat de cada agente. No projeto Atako «Time de desenvolvimento» você encontra a página de funcionamento e o acompanhamento do trabalho, e no floor da Atako os dois agentes aparecem com a atividade atual.

Para ajustar o comportamento, escreva ao agente no chat dele, por exemplo «adicione às suas convenções que toda migração de banco de dados deve mencionar o plano de rollback». Ele guarda a instrução na memória para as rodadas seguintes.

Salvaguardas

O acesso é deliberadamente estreito. A conexão com o GitHub é concedida aos agentes com uma lista limitada de doze ferramentas: ler pull requests, arquivos e commits, ler e atualizar issues, gerenciar etiquetas, adicionar comentários. Um agente que vê uma lista curta de ferramentas as usa com mais confiabilidade do que um perdido em um catálogo de centenas e, sobretudo, o que não é concedido não pode acontecer, mesmo que um texto tente forçar. Os agentes tratam títulos, descrições, comentários e código como dados a analisar, nunca como instruções.

O token que você cria é a sua primeira salvaguarda: limitado a um repositório e a direitos precisos, ele restringe o dano possível, aconteça o que acontecer. É guardado criptografado, e você pode revogá-lo no GitHub ou remover o acesso dos agentes a qualquer momento.

A validação humana fica nos pontos de decisão. Você lê os comentários de revisão, decide o que corrigir, aprova e faz o merge você mesmo e fecha, atribui e planeja as issues.

O que esperar

Espere comentários úteis sobretudo em pull requests de tamanho razoável: diante de uma mudança muito grande, o revisor dirá isso e se concentrará nos arquivos mais sensíveis, em vez de fingir que leu tudo. Ele não consegue rodar seus testes e diz isso em cada comentário. O triador é tão preciso quanto suas regras de prioridade; sem elas, escolhe a cautela e faz perguntas. O valor vem da regularidade: cada pull request recebe uma primeira leitura em meio dia, cada issue chega qualificada e seus revisores humanos gastam o tempo com julgamento e não com detecção.