Agentes escrevem o diff; quem registra o motivo da mudança? · Centelha

Um agente altera a validação de um formulário. O CI fica verde, o diff parece pequeno e o PR está pronto para revisão. Só que a regra mudou: um campo antes opcional passou a ser obrigatório. Isso era parte do pedido ou o agente tomou a decisão por conta própria?

Dá para inspecionar o código e descobrir o que mudou. Descobrir por que mudou costuma exigir outra coisa: o ticket, o critério de aceite, uma decisão anotada em algum lugar. Quando o patch nasce de uma sessão longa, pedir ao revisor que leia a conversa inteira para encontrar essas pistas não escala nem numa equipe pequena.

A Entire lançou um forge com Trails, uma proposta que reúne histórico de sessões e avaliações ligadas aos pushes para dar contexto à colaboração entre agentes e pessoas. A empresa argumenta que esse formato pode substituir o PR tradicional. É uma proposta de produto; não é demonstração de que times, em geral, já trocaram seus PRs ou passaram a revisar melhor.

Um preprint recente sobre possíveis substitutos do pull request ajuda a separar as perguntas. No conjunto de documentos públicos examinado pelos autores, o PR aparece como lugar de integração, revisão, justificativa da mudança e participação de colaboradores externos. Muitas propostas preservam o PR e mudam o que é registrado dentro ou ao redor dele. O estudo descreve esse recorte, não mede a eficácia de um formato novo nem representa todos os times.

Para quem já trabalha com PR, eu começaria por um experimento menor: melhorar a informação que chega ao revisor sem trocar de plataforma.

Um recibo curto, junto da mudança

Pode ser um comentário no PR, uma seção do template ou um campo no artefato de revisão que o time usa hoje. A ideia é deixar cinco respostas fáceis de encontrar:

Qual ticket ou pedido originou a alteração? Que comportamento deve existir depois dela?
Quais fluxos e arquivos mudaram? Se o escopo cresceu, por quê?
O que foi verificado, com qual resultado? O que ainda não foi testado?
Que alternativa relevante foi descartada e por qual motivo?
Quem confere a lacuna e assume a aprovação?

Não precisa colar um histórico de prompts. Aponte para o ticket, o diff e os resultados dos testes já existentes. Se um teste não rodou, escreva "não executado" e explique o motivo, em vez de deixar o campo em branco ou chamar o trabalho de concluído.

Imagine o formulário do início. Num caso hipotético, os testes de envio válido e de mensagem de erro passam, mas ninguém confere se o valor continua lá depois de recarregar a página. O recibo registraria essa pendência. O revisor verificaria se tornar o campo obrigatório era mesmo o critério de aceite, compararia a implementação com o comportamento esperado e pediria a checagem de persistência antes de aprovar. Não executei esses testes; o exemplo mostra como tornar visível uma lacuna que o selo verde do CI, sozinho, não esclarece.

O resumo também precisa de revisão

O próprio agente pode preencher um primeiro recibo. Eu não aceitaria esse texto como única versão dos fatos: ele pode omitir uma hipótese errada ou declarar como verificado um fluxo que não testou. Quem revisa precisa conseguir confrontá-lo com o ticket, o diff e o resultado dos testes. Se a regra de negócio não estava clara no pedido, o caminho é perguntar a quem definiu a tarefa, não pedir ao modelo uma justificativa mais convincente.

Guardar a sessão completa pode ajudar a recuperar a origem de uma decisão ou investigar um incidente. Mas ela tem custo de leitura e pode conter dados que não deveriam circular no PR. Se for mantê-la, controle acesso e retenção; não despeje tokens, credenciais ou dados de usuários numa trilha compartilhada. Para a revisão cotidiana, o recibo com referências verificáveis tende a ser uma entrada mais manejável.

Eu testaria esse formato em alguns PRs feitos com agentes. Observe quanto tempo a revisão leva, quais perguntas se repetem e quantas mudanças voltam por falta de contexto. Se o recibo só acrescentar texto sem ajudar ninguém a decidir, ajuste-o. O objetivo não é defender o PR para sempre: é permitir que outra pessoa entenda a mudança e tenha condições reais de aprová-la.

Fontes para aprofundar

Anúncio do forge e dos Trails da Entire — proposta da empresa para registrar sessões e avaliações junto do fluxo de mudanças.
What Will Replace Pull Requests? — preprint que examina funções do PR e alternativas discutidas em documentos públicos; não é uma medição de ganho de produtividade.