Uma suíte de testes verde não é uma revisão
Os testes cobrem os casos em que alguém pensou. Um agente que muda comportamento pode deixar todos os testes verdes, porque eles verificavam o comportamento antigo de forma frouxa ou porque nada cobria aquele caminho. Verde prova que a mudança roda, não que está correta.
O mesmo vale para um resumo arrumado: a descrição do que o agente fez é uma afirmação do mesmo sistema que fez a mudança. Leia o diff, não a nota de capa, e trate os testes como um sinal entre vários.
Comece num estado limpo e reversível
Antes do primeiro prompt: faça commit ou guarde o trabalho, crie um branch e saiba exatamente como voltar. Um agente com acesso ao terminal pode rodar migrações, reescrever configuração e apagar arquivos; um ponto de partida reversível transforma um acidente num incômodo.
Se a tarefa tocar em algo regulado ou confidencial, use uma cópia descartável do projeto e uma conversa sem segredos. Os termos e a documentação de dados do fornecedor decidem o que sai da sua máquina: leia-os em vez de supor a fronteira.
Leia o diff na ordem em que dói
Uma mudança gerada e grande é revisada melhor numa ordem deliberada do que de cima para baixo.
- Pontos de entrada: rotas, handlers, permissões e tudo que muda quem chega a quê.
- Dados: schema, migrações, serialização e consultas, principalmente o que apaga ou reescreve.
- Configuração: variáveis de ambiente, etapas de build, CI e ajustes de deploy.
- O resto: nomes, estrutura, duplicação e os retoques cosméticos que fazem o diff parecer maior.
Depois leia os testes adicionados e pergunte o que eles não cobrem. Um agente que escreveu código e teste pode registrar o mesmo mal-entendido duas vezes.
Dependências, segredos e as linhas que ninguém lê
Dependências novas são o risco mais silencioso de um patch gerado: um nome de pacote familiar, uma versão vinda do nada, um lockfile reescrito inteiro. Verifique o que foi adicionado, por quê, e se o projeto já tinha algo que bastasse.
Procure credenciais, tokens e URLs internas que não deveriam estar num commit, e confira que o logging não imprime agora dados de clientes. São as linhas que se passam batido — e justamente aquelas em que um agente não tem motivo para ser cuidadoso: ele otimiza para o pedido, não para o seu modelo de ameaça.
Quando jogar fora
Se o diff for maior que a tarefa, se você não conseguir explicar um bloco sem adivinhar, ou se a mudança resolve o sintoma em vez da causa, apague o branch. Recomeçar com um pedido mais estreito custa menos do que manter código que ninguém entende.
A mesma regra vale para o seu prompt: a lista de revisão do nosso guia do Manus e os conselhos de estrutura do nosso guia do Prompt Cowboy encurtam os dois o diff. Para o produto, comece pela nossa visão geral do Freebuff, e como tratamos links de indicação está na nossa divulgação de afiliados.
Perguntas frequentes
Devo deixar que ele execute comandos no meu terminal?+
O acesso ao terminal é o que torna um agente de código útil e arriscado, e é o fornecedor que define como as permissões funcionam. Comece numa cópia descartável ou num branch temporário, acompanhe as primeiras execuções e mantenha credenciais fora de alcance: um comando que só lê arquivos não é o mesmo pedido que um que faz deploy.
Um agente de código gratuito serve para trabalho de verdade?+
Para trabalho mecânico que você consegue revisar, sim. Gratuito é um modelo comercial, não uma garantia de qualidade: o fornecedor o financia com publicidade e pode mudar modelos, limites ou recursos. O que decide é se você consegue ler e testar o que ele produziu, não o preço.
Preciso declarar que o código foi escrito por um agente?+
Siga as regras do time, do repositório e da licença, e responda com honestidade se perguntarem. Profissionalmente, o que conta é que uma pessoa revisou a mudança e a assumiu; o risco é um patch gerado que ninguém leu, não a ferramenta que o escreveu.
Fontes e leituras complementares
Documentação oficial do fornecedor, revisada em 2026-10-26. Os termos mudam; confira a versão do seu país.