A auditoria: aprovar o código do agente sem virar carimbo
O agente escreve código que passa em todo teste automático e mesmo assim pode estar fazendo a coisa errada. Esta aula te dá um checklist de auditoria de cinco itens pra quem aprova PR de agente em escala, e o princípio de que quem aprova é sempre quem responde.
Um agente abriu um PR pra corrigir um bug de paginação. Os testes passaram, o lint passou, o build passou, tudo verde. O revisor bateu o olho no resumo automático, achou razoável, clicou em approve em quinze segundos. Só depois, numa investigação de outro bug, alguém percebeu que o PR também tinha alterado um valor de cache padrão em um arquivo de configuração que não tinha nada a ver com paginação. Ninguém tinha notado, porque ninguém tinha lido o diff inteiro.
Um agente redige uma minuta de aditivo contratual, citando a cláusula original e a alteração proposta. O advogado aprova rápido porque o texto está bem escrito e formatado no padrão da banca, sem abrir o contrato original pra comparar linha por linha. Só quando o cliente pergunta por que uma cláusula de confidencialidade sumiu do aditivo é que alguém percebe que o agente reescreveu a seção inteira em vez de só inserir a alteração, e a cláusula que devia ter sido preservada não estava mais lá.
Um agente prepara o pacote de avaliação de desempenho de doze pessoas, com nota, justificativa e recomendação de aumento, a partir dos registros do ciclo. O gestor aprova o pacote inteiro numa tarde, porque a formatação está impecável e as justificativas soam plausíveis. Depois, uma pessoa contesta a nota: a justificativa citava um projeto que ela nunca tinha liderado, um dado que o agente puxou errado de outro colaborador com nome parecido, e que ninguém conferiu antes de aprovar o pacote inteiro de uma vez.
Um agente escreve o PRD de uma feature nova, com critério de sucesso, escopo e uma tabela de esforço estimado. O PM aprova o documento porque a estrutura está redonda e o critério parece razoável, sem checar a fonte de cada número. Só na reunião de planejamento alguém pergunta de onde veio a estimativa de esforço, e ninguém sabe responder: o agente extrapolou de uma feature "parecida" que na verdade era bem mais simples, e o time se compromete com um prazo que já nasceu furado.
Um agente monta a proposta comercial pra um cliente grande, com desconto, prazo e cláusula de reajuste, puxando do histórico de propostas anteriores. O gestor comercial aprova rápido, porque o formato é o de sempre e o desconto parece dentro da política. Só quando o cliente assina é que alguém percebe que a cláusula de reajuste anual tinha sido copiada de um contrato de outro segmento, com uma condição que a empresa nunca pratica com esse tipo de cliente, e agora está assinada.
Um agente ajusta o roteamento de um processo logístico depois de identificar um gargalo, e apresenta o novo fluxo com a métrica de SLA projetada. O gestor de operações aprova a mudança porque o número projetado é bom e o relatório está bem escrito, sem testar o fluxo novo numa amostra pequena antes. Na primeira semana em produção, o novo roteamento aumenta o custo por entrega em 15%, porque o agente tinha ignorado uma restrição de capacidade de um dos centros de distribuição que não estava documentada na base que ele usou.
Um agente prepara o relatório de aderência de controles pro comitê de risco, marcando a maioria dos itens como conformes. O responsável por compliance aprova o relatório inteiro porque o formato segue o padrão de sempre e nenhum item chamou atenção à primeira vista. Numa auditoria externa meses depois, descobre-se que um controle crítico tinha sido marcado como conforme com base numa evidência de um ciclo anterior, que o agente reusou porque "parecia atual", e ninguém conferiu a data antes de aprovar.
Um agente ajusta o fluxo de cadastro no protótipo do Figma depois de um teste de usabilidade, e apresenta o antes e depois com a métrica de conclusão projetada. O designer responsável aprova a mudança porque o mockup parece uma evolução óbvia, sem testar de novo com usuário real. Ao subir pra produção, a mudança resolve o problema que motivou o ajuste, mas introduz um novo: o campo que o agente moveu pra cima da tela quebra a ordem de tabulação pra quem navega só com teclado, um problema que só aparece numa auditoria de acessibilidade, semanas depois.
Um agente monta o relatório trimestral de posicionamento competitivo pro board, cruzando dado de mercado com o CRM interno. O documento sai formatado, com gráfico e fonte citada, e o executivo que revisa aprova em cinco minutos porque "os números batem com o que eu esperava". Só numa reunião de acompanhamento, um analista percebe que o gráfico de participação de mercado somava dois recortes de segmento diferentes, inflando o número em oito pontos, um erro que ninguém pegou porque ninguém abriu a planilha de origem antes de aprovar o slide que foi pro conselho.
Putz, deixa eu te contar uma cena que já deve ter acontecido no seu time. Um agente abre um PR, o pipeline inteiro fica verde, o resumo automático parece razoável, e o botão de aprovar está ali, pedindo um clique. Você clica. Passa pro próximo. No fim do dia você aprovou vinte PRs e não conseguiria recontar o que estava em nenhum deles. Essa aula é sobre o momento exato em que aprovar parou de ser revisão e virou carimbo.
A ideia central desta aula. Os portões automáticos que você viu na aula 6.1 já travam parte disso: teste, lint e build verdes garantem que o código faz o que os checks verificam. O que eles não garantem é que o código faz a coisa certa, que ficou dentro do escopo pedido, e que não abriu uma porta que ninguém pediu pra abrir. Por isso existe uma camada acima do portão automático: o julgamento de quem aprova. Esta aula te dá um checklist de cinco itens pra essa camada, e um princípio que não tem exceção: quem aprova o PR é quem responde pelo que ele quebra. O agente não assina nada. Você assina.
01"Passou nos testes" não é a mesma coisa que "está certo"
Vale entender a diferença de raiz, porque ela muda como você olha pro verde do pipeline. Um teste automatizado verifica uma coisa específica que alguém escreveu antes: essa função devolve esse valor, essa rota responde com esse código, essa tela renderiza sem quebrar. É uma pergunta fechada, e o teste responde sim ou não pra ela.
O problema é que um agente pode escrever um código que responde sim pra todas as perguntas fechadas que existem, e ainda assim estar errado de um jeito que ninguém pensou em testar. Ele resolve o bug pedido, mas também mexe num arquivo de configuração que não tinha nada a ver com o pedido. Ele corrige a mensagem de erro, mas também inverte a ordem de duas checagens de segurança. O teste que existia continua verde, porque ele nunca foi desenhado pra pegar esse tipo de desvio. O portão automático da aula 6.1 é real e funciona, só que ele só barra o que alguém já sabia que precisava barrar.
02Por que aprovar em escala vira carimbo
Aqui mora o risco que ninguém fala em voz alta. Quando o volume de PR de agente sobe, o revisor cansa. O padrão se repete: abre, olha o resumo, vê o verde, aprova. Na vigésima vez do dia, o cérebro já decidiu que "isso aqui sempre passou antes", e o clique em aprovar vira reflexo, não julgamento.
É exatamente o mecanismo do porém mortal que já apareceu nesta trilha: velocidade sem revisão vira dívida e incidente. Só que aqui ele tem uma cara específica, a do carimbo. Carimbo é quando a aprovação deixou de checar alguma coisa e passou a só confirmar que o processo foi seguido. E o pior é que carimbo se sente exatamente igual a revisão de verdade, por dentro. Ninguém percebe que virou carimbo até o incidente aparecer.
03O checklist de auditoria de cinco itens
Aqui está o centro da aula. Cinco perguntas, na ordem, antes de qualquer PR de agente sair aprovado com o seu nome. Pensa nelas como um funil: cada uma filtra um tipo de risco, e o que sobrevive às cinco é um PR que você pode defender de verdade.
A primeira: o diff bate com a intenção descrita no ticket? Leia o pedido original e leia o diff, e confira se um está contido no outro. Se o PR faz mais coisa do que o ticket pedia, essa sobra precisa ter uma explicação, não uma suposição.
A segunda: o raio de ação é o esperado? Olhe a lista de arquivos alterados antes de olhar o conteúdo. Um PR de "corrigir paginação" que também toca um arquivo de configuração de cache é exatamente o tipo de desvio que este item pega.
A terceira: o PR tocou segredo, permissão, credencial ou dado sensível? Essa pergunta sozinha já teria pego o exemplo de segurança do início da aula, onde a ordem de duas checagens de permissão foi invertida sem nenhum teste cobrir isso.
A quarta: o teste cobre o caso real ou só o caminho feliz? Pergunte o que aconteceria se o input fosse ruim, se o sistema estivesse sob carga, se a dependência mudasse de comportamento. Se a resposta é "não sei", o teste verde não prova nada além do caminho fácil.
A quinta, e a mais importante: você consegue defender esse PR numa reunião, linha por linha, se for questionado? Se a resposta for "não, foi o agente que fez", o PR não está pronto pra aprovação. Aprovação sem defesa possível é aprovação órfã.
Saiba mais: por que o item 5 (defesa) é o mais forte dos cinco
Os itens 1 a 4 são checagens objetivas, dá pra fazer em minutos e quase sempre pegam o desvio óbvio. O item 5 é diferente: ele é um teste de honestidade sobre você mesmo. Se você imaginar uma reunião difícil, com o seu nome no PR e alguém perguntando "por que essa linha 340 mudou o valor de timeout", e a única resposta que vem à cabeça é "não sei, o agente decidiu", isso é o sinal mais confiável de que a aprovação foi carimbo. Esse item funciona mesmo quando você não sabe exatamente o que procurar nos outros quatro, porque ele não depende de achar o erro, depende de você admitir a si mesmo que não olhou de verdade. É o item que sobrevive mesmo quando o seu conhecimento técnico específico daquele trecho é limitado, porque a pergunta não é "isso está certo", é "eu sei o suficiente pra dizer que está".
04A régua de três tempos: o agente propõe, o portão confere, a pessoa aprova
O checklist tem um princípio atrás dele, e é o que sustenta tudo. Pensa numa régua de três tempos que você nunca colapsa em um só.
O agente propõe. Ele é rápido e incansável, e o PR que ele entrega já vem com o rascunho pronto, muitas vezes bom. Use essa velocidade à vontade, é onde o agente brilha.
O portão automático confere. É o que você já viu na aula 6.1: teste, lint, build. Ele é objetivo e não aceita o que não passou, e faz isso sem cansar, sem pular linha, sem cara de sono na sexta às 18h.
E a pessoa aprova, de verdade. Esse é o passo que o checklist de cinco itens preenche. Aprovar de verdade não é o mesmo que clicar em "approve" depois de ver o ícone verde. É rodar as cinco perguntas e conseguir responder cada uma. Pular esse passo é exatamente o que faz um PR errado, com teste verde, quase virar incidente em produção.
05Quem aprova responde, sempre
Fecha o raciocínio com o ponto que não tem meio-termo. Quando um PR quebra alguma coisa em produção, ou planta uma dívida que só aparece meses depois, a pergunta que importa não é "quem escreveu essa linha". É "quem aprovou". E a resposta é sempre um nome humano.
"Foi o agente que fez" não existe como desculpa, do mesmo jeito que não existe no financeiro nem em nenhum outro lugar desta trilha. O agente não vai à reunião de post-mortem. O agente não perde a confiança do time. O agente não é quem explica pro cliente por que o sistema ficou fora do ar quarenta minutos. Quem aprovou aquele PR é quem carrega isso, porque aprovar é exatamente o ato de dizer "eu conferi, isso pode subir".
Isso não é desconfiança do agente, é higiene de quem opera em escala. O agente te devolve horas de trabalho mecânico. O checklist de cinco itens é o preço pequeno que protege esse ganho: minutos de auditoria contra um incidente que custa uma noite de trabalho, uma conversa difícil e um pedaço da confiança do time. Aprovar de verdade é o que transforma velocidade de agente em velocidade segura de usar.
Faça agora
Pegue um PR real de agente que você aprovaria hoje só porque os testes passaram, o seu a sua tarefa real ou outro PR recente da sua fila. Rode o checklist de cinco itens nele, escrevendo uma linha de resposta pra cada:
- O diff bate com a intenção descrita no ticket ou no pedido original?
- O raio de ação é o esperado, ou o PR tocou arquivo ou módulo fora do escopo?
- O PR tocou segredo, permissão, credencial ou dado sensível?
- O teste cobre o caso real (carga, input ruim, dependência mudando) ou só o caminho feliz?
- Você consegue defender esse PR numa reunião, linha por linha, se for questionado amanhã?
No fim, decida: você ainda aprovaria esse PR do jeito que estava, ou ele precisa de mais uma olhada antes? Se a resposta mudou depois do checklist, você acabou de sentir a diferença entre carimbo e auditoria.
Pratique
1. Um PR de agente passou em todos os testes automatizados, no lint e no build. O que isso garante?
2. Por que aprovar PR de agente em alto volume tende a virar carimbo?
3. Um PR de agente aprovado por você derruba um serviço em produção. Quem responde por isso?
Para o quadro
Sobre o verdepassou nos testes não é a mesma coisa que está certo.
Sobre o carimboo pior do carimbo é que ele se sente como revisão por dentro.
Sobre quem respondequem aprova responde pelo que quebra. Por isso a aprovação precisa ser julgamento, não clique.
Valeu pelo feedback. Isso ajuda a afiar a próxima aula.