Seu agente pode escrever, revisar e aprovar o próprio código?

# 4. Seu agente pode escrever, revisar e aprovar o próprio código? *Automatizar a revisão pode reduzir trabalho repetitivo. Entregar toda a aprovação ao mesmo processo exige outra conversa.* Imagine um fluxo em que um agente recebe uma tarefa, altera o código, executa os testes e informa que está tudo pronto. Em seguida, outro comando aprova a mudança e publica a nova versão. É um cenário atraente: menos espera, menos trabalho manual e mais entregas. Mas existe uma pergunta que precisa vir antes da velocidade: **qual parte desse processo consegue bloquear a mudança quando o agente está errado?** Em 1º de setembro de 2026, o GitHub anunciou, em prévia pública, a possibilidade de o Copilot code review aprovar pull requests. O recurso vem desativado por padrão e depende de configuração administrativa. O anúncio também diferencia a avaliação sobre estar pronto para aprovação da aprovação que efetivamente conta para a regra de revisão do repositório. [1] A novidade amplia as opções de automação. Não elimina a responsabilidade de desenhar o processo de entrega. ## Escrever, revisar e autorizar são responsabilidades diferentes Escrever código é propor uma solução. Revisar é examinar se ela atende ao objetivo e quais problemas pode introduzir. Autorizar a entrada em produção é aceitar o risco daquela mudança dentro de um contexto operacional. Nossa proposta na KeyCore é preservar essa separação, mesmo quando usamos IA em mais de uma etapa. Um agente pode ajudar a preparar a alteração. Outro pode apontar inconsistências. Testes podem verificar comportamentos esperados. Ainda assim, alguém precisa definir quais condições são suficientes para avançar e quais mudanças exigem avaliação humana. Não basta dar nomes diferentes aos agentes. Se eles compartilham as mesmas informações incompletas e podem alterar as próprias regras de aprovação, a independência existe mais no desenho do fluxo do que no controle real. ## O que a aprovação automática do Copilot muda Segundo o anúncio do GitHub, administradores podem controlar o recurso nos níveis de empresa, organização e repositório, inclusive limitando os caminhos de arquivos que o Copilot pode aprovar. Quando habilitada, a aprovação pode contar para a exigência de revisões do repositório. Novos commits após a aprovação exigem uma nova revisão, conforme o comportamento descrito para o recurso. [1] Isso abre espaço para um uso seletivo. Por exemplo, uma organização pode avaliar a aprovação automatizada em uma área de baixo impacto, mantendo outro tratamento para componentes sensíveis. Nossa recomendação é não transformar “o recurso existe” em “o recurso deve ser ativado em todo lugar”. A configuração precisa refletir a importância dos dados, a capacidade de recuperação e o impacto de um erro. ## A fronteira deve ser o risco, não apenas a extensão do arquivo Mudanças pequenas e bem delimitadas podem ser candidatas a maior automação. Ajustar uma mensagem de interface sem alterar comportamento é diferente de modificar uma regra de acesso. Mas o nome do arquivo não conta a história inteira. Uma documentação pode conter comandos usados no deploy. Um arquivo de teste pode ser alterado para deixar de verificar uma condição importante. Uma configuração curta pode mudar todo o comportamento de autenticação. Propomos olhar para três perguntas: o que a mudança pode afetar, como o erro seria percebido e quanto custaria voltar a um estado aceitável? Autenticação, pagamentos, isolamento entre clientes, permissões e alterações de banco merecem atenção especial na política de revisão. Não porque a IA seja incapaz de ajudar nessas áreas, mas porque a consequência de uma falha pode ser maior. ## O que deve continuar independente do agente No GitHub, regras de proteção de branches e rulesets podem exigir pull requests, verificações obrigatórias e aprovações antes da integração de uma mudança. A proteção depende de configuração, inclusive de quem pode contornar as regras. [2]; [3] Para um projeto com agentes, recomendamos três camadas de controle. **Regras fora do alcance da tarefa.** O agente que altera uma funcionalidade não deveria poder desativar a verificação que aprova essa funcionalidade. Mudanças na própria política de entrega precisam de revisão específica. **Evidências reproduzíveis.** Os resultados de testes devem estar associados à versão que será publicada. Um teste aprovado antes de uma alteração posterior não prova que o novo conteúdo está correto. **Responsáveis claros por áreas críticas.** O arquivo `CODEOWNERS` pode ajudar a definir revisores, mas sua existência sozinha não obriga a aprovação. A exigência de revisão dos responsáveis precisa estar habilitada nas regras aplicáveis. [2] A proteção não termina quando o agente escreve “todos os testes passaram”. O sistema de entrega precisa verificar as condições por conta própria. ## Um exemplo: a mudança simples que altera o acesso Considere um SaaS fictício usado por diferentes empresas. A tarefa parece pequena: facilitar a busca de clientes no painel. O agente melhora o componente de pesquisa, mas uma consulta deixa de aplicar corretamente o vínculo com a empresa autenticada. A interface continua funcionando. Um teste que verifica apenas se a busca retorna resultados também passa. O que falta não é mais confiança no agente, e sim um critério independente de isolamento: uma conta de teste da empresa A não pode receber registros da empresa B. Nesse cenário, nossa recomendação seria manter esse comportamento como requisito verificável, com dados sintéticos e avaliação humana para alterações na fronteira de acesso. O agente pode colaborar na solução sem ter autoridade para retirar a exigência. O exemplo é hipotético e ilustra por que aprovação técnica e responsabilidade sobre o risco precisam caminhar juntas. ## Publicar não é o mesmo que conseguir recuperar Depois da revisão, recomendamos validar a mudança em um ambiente apropriado antes de ampliar sua exposição. A estratégia pode variar conforme o produto: liberação para um grupo restrito, ativação gradual ou publicação acompanhada por indicadores definidos. Também é importante combinar previamente o que fazer se a mudança falhar. Reverter uma versão da aplicação pode ser simples; recuperar dados alterados pode exigir um plano diferente. Por isso, não tratamos “tem rollback” como uma resposta suficiente. O procedimento deve dizer o que será revertido, o que não será e quem pode interromper a liberação. A recuperação é parte do projeto da mudança, não uma tarefa para descobrir durante o incidente. ## Como nós, da KeyCore, equilibramos velocidade e responsabilidade Nossa visão para software e automação é reduzir o tempo gasto com repetição sem retirar clareza das decisões importantes. A IA pode preparar contexto para revisão, sugerir testes, identificar inconsistências e explicar alterações. Isso pode tornar o trabalho humano mais focado. O valor não precisa vir de remover todas as pessoas do processo. Antes de ampliar aprovações automáticas, recomendamos medir retrabalho, falhas após a publicação e tempo para recuperar o serviço, além da velocidade de entrega. Entregar mais mudanças só é uma vantagem quando a operação consegue absorvê-las com qualidade. **A pergunta não é apenas se o agente consegue aprovar código. É qual controle permanece confiável quando ele produz uma mudança errada.** **Continue a leitura:** [Red teaming de agentes precisa acompanhar cada deploy](/blog/red-teaming-agentes-cada-deploy). ## Fontes e referências **[1]** GitHub. *Copilot code review can now approve pull requests*. **[2]** GitHub Docs. *Managing a branch protection rule*. **[3]** GitHub Docs. *Available rules for rulesets*. *Referências consultadas em 8 de setembro de 2026.* [1]: https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests/ [2]: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule [3]: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets