Revisão e testes de código
Agentes de programação podem produzir muito código, o que também significa que podem gerar dívida técnica. Avançar rápido é ótimo, mas é importante manter um padrão de qualidade alto. Seus critérios para o que é mergeado devem ser os mesmos, independentemente de o código ter sido escrito manualmente ou por um agente.
Código gerado por IA pode parecer correto, mas conter erros sutis. Ele pode seguir padrões existentes, compilar e passar nos testes que você escreveu, mas ainda deixar de considerar casos de borda, ter problemas de segurança ou duplicar lógica que já existe em outra parte da sua base de código.
É por isso que a revisão de código é tão importante. Você precisa estabelecer os processos certos para garantir uma base de código de alta qualidade e detectar issues antes que cheguem à produção. Como engenheiro, é sua responsabilidade investir para que a revisão de código seja bem-sucedida.
Autoavaliação
Revise seu código antes de pedir que outras pessoas o analisem.
Acompanhe o trabalho do agente. A visualização de diff mostra as alterações conforme elas acontecem. Se perceber que o agente está indo na direção errada, clique em Stop ou pressione Cmd Shift BackspaceCtrl Shift Backspace para cancelar e redirecioná-lo. Não é preciso esperar até que ele termine. Para mudanças de rumo maiores, reverta as alterações e refine seu plano antes de executá-lo novamente, como vimos em desenvolvimento de funcionalidades.
Peça ao agente para revisar todas as alterações de uma vez. Marque @Branch no prompt para fornecer ao agente o diff completo do branch atual. Diga algo como "revise as alterações deste branch" ou "em que estou trabalhando agora?" para dar ao agente um contexto mais amplo e detectar issues em vários arquivos.
Por exemplo, você pode pedir ao agente que revise o próprio trabalho:
Prepare-se para a revisão por pares
Os agentes podem produzir muitas alterações de código de uma só vez. Isso pode resultar em um único commit grande, com centenas de linhas alteradas. É difícil para qualquer pessoa revisar.
Recomendamos usar commits pequenos e semânticos, com descrições claras. Cada commit representa uma alteração lógica. Um revisor humano pode percorrer o histórico de commits em vez de analisar um bloco enorme de alterações de código.
Esse tipo de organização de commits é tedioso quando feito manualmente, mas os agentes lidam bem com isso. Por exemplo:
- Desenvolva a funcionalidade livremente. Não se preocupe com a organização dos commits enquanto estiver iterando.
- Quando tudo estiver funcionando, peça ao agente para reorganizar o histórico de commits em partes fáceis de revisar.
- O agente volta para
main, lê todas as alterações e planeja uma sequência lógica para criar commits limpos com mensagens descritivas. - Ele valida se o diff final corresponde ao original, garantindo que nenhuma das suas alterações seja perdida.
Use este prompt para criar uma skill, para que qualquer pessoa da sua equipe possa executar /rework-commits após concluir uma funcionalidade:
Create a skill file at .cursor/skills/rework-commits/SKILL.md with this content: # Split branch into reviewable commits Rework a branch into a sequence of small, semantic commits for review. ## Important - Prepend `GIT_EDITOR=true` to all git commands you run, especially ones looking at diffs, so you avoid getting blocked ## Instructions 1. **Check for uncommitted changes**: Abort if there are any. 2. **Check rebase status**: Verify the branch is rebased on top of `main`. Abort if not. 3. **Save recovery point**: Tell the user the current commit hash in case we need to `git reset --hard` to it later. 4. **Save the original diff**: Save the full git diff to `/tmp/original-diff.patch` before making changes. 5. **Reset to main**: Run `git reset main` to unstage all changes. 6. **Plan the commits**: Read through ALL changes carefully. Plan a logical breakdown into small, sequential, semantic commits. Write a TODO for each in `/tmp/split-todos.md`. Order: database/schema changes first, backend second, frontend last. 7. **Create the commits**: Work through the TODOs one by one. Write excellent commit descriptions for human reviewers. 8. **Validate**: Compare the current diff against `/tmp/original-diff.patch` to ensure no changes were lost or altered. 9. **Cleanup**: Delete temporary files once validation passes. ## Notes - If validation fails, tell the user and provide the original commit hash for recovery - Each commit should be self-contained and represent a logical unit of work - Commit messages should explain the "why" behind the changes
Try in Cherri CodeRevisão do agente
Depois que o agente concluir uma tarefa, clique em Revisar e em Encontrar issues para executar uma revisão de código dedicada. O agente analisa as edições propostas linha por linha e sinaliza possíveis problemas.
Para revisar todas as alterações locais, abra a aba Controle de versão e execute a Revisão do agente para compará-las com sua branch principal. Isso detecta issues em todo o conjunto de alterações.
Isso é semelhante a pedir manualmente que o agente revise suas alterações. Elaboramos cuidadosamente um prompt para tornar esse processo eficaz.
Bugbot para pull requests
O Bugbot integra-se ao seu provedor de controle de versão para revisar pull requests automaticamente. É uma das várias ferramentas que fornecem feedback diretamente no PR.
O Bugbot revisa PRs quando você faz push. Ele lê todo o contexto da sua alteração, incluindo como o código modificado se conecta ao restante da sua base de código, e procura bugs que poderiam chegar à produção. Diferentemente dos linters, que detectam problemas de formatação, o Bugbot encontra erros de lógica, como exceções de ponteiro nulo, condições de corrida, falta de tratamento de erros e problemas de segurança.
Quando o Bugbot encontra um issue, também pode propor uma correção. Com o autofix habilitado, você pode fazer commit da correção diretamente em um comentário no pull request.
Você também pode personalizar o Bugbot fornecendo regras adicionais, sobre as quais falaremos mais na próxima seção, sobre personalização de agentes.
Objetivos verificáveis
Para ajudar a garantir que seu código esteja correto, dê ao agente sinais claros para validar o próprio trabalho:
- Testes detectam regressões de comportamento
- Verificação de tipos detecta erros estruturais
- Linting detecta violações de estilo e padrões
Quanto mais dessas verificações você tiver implementado, mais confiança terá para delegar trabalho aos agentes. Recomendamos usar linguagens tipadas, com cobertura de testes e regras de linting, junto com seu agente.
Qual combinação oferece a melhor rede de segurança para código gerado por IA?
Deixe os agentes escreverem seus testes
No passado, alcançar uma boa cobertura de testes exigia muito esforço. A maioria das equipes só adicionava testes depois que algo quebrava ou adotava processos rigorosos para garantir determinado percentual de cobertura.
Com agentes, escrever testes se torna muito mais fácil. Você pode pedir ao agente para escrever testes e depois verificar se eles estão corretos. O agente também pode executar testes manuais por você usando o navegador, verificando estados ou fluxos da UI que, de outra forma, você teria de conferir manualmente.
Isso é importante porque testes de alta qualidade dão mais confiança para deixar o agente trabalhar de forma autônoma e fazer alterações sem introduzir regressões.
Bons prompts para gerar testes:
- "Planeje como obter cobertura e2e para nosso fluxo de checkout. Quais cenários devemos testar?"
- "Configure testes de integração para a API de pagamentos. Use nossa infraestrutura de testes existente em
src/__tests__/." - "Quais casos de borda não são cobertos pelos nossos testes atuais da funcionalidade de desconto?"
- "Escreva testes de regressão para o bug que corrigimos em
PaymentService.ts."
O agente também pode ajudar você a configurar a infraestrutura de testes do zero. Se você não tiver o Playwright configurado para uma aplicação web, pode pedir ao agente que configure o projeto, escreva a configuração e crie seu primeiro teste.
Agentes em nuvem
Até agora, você trabalhou com agentes executados localmente no Editor. Os agentes em nuvem são executados em sandboxes remotos, o que significa que você pode fechar o laptop e conferir os resultados mais tarde.
Veja como eles funcionam:
- Descreva a tarefa e forneça o contexto relevante
- O agente clona seu repositório e cria uma branch
- Ele trabalha de forma independente e abre uma pull request ao terminar
- Você recebe uma notificação quando ele conclui a tarefa (via Slack, e-mail ou pela interface web)
- Revise as alterações e faça o merge quando estiver tudo pronto
Os agentes em nuvem são ideais para tarefas que você colocaria em uma lista de pendências: correções de bugs que surgiram enquanto trabalhava em outra coisa, cobertura de testes para código existente, atualizações da documentação ou refatorações.
Testes em escala com agentes em nuvem
Um padrão eficiente é usar agentes em nuvem para testar muitas variações em paralelo. Você pode iniciar vários agentes em nuvem para testar diferentes casos de borda, condições de erro e combinações de entrada em todo o app.
Por exemplo, suponha que você tenha adicionado uma funcionalidade de código de desconto. Você pode iniciar agentes em nuvem para testar todos os tipos de desconto, tentar entradas inválidas, testar combinações como o empilhamento de descontos e verificar o comportamento nos valores-limite de casos de borda.
Cada agente em nuvem cria uma branch com seus casos de teste e resultados. Em seguida, você pode consolidar as falhas em casos de teste locais reproduzíveis e corrigi-las antes de fazer o merge.
Acelere seus ciclos de feedback
À medida que você começa a trabalhar com mais agentes de programação, o gargalo passa a ser a parte mais lenta do sistema. Muitas vezes, é preciso esperar a suíte de testes terminar, executar verificações de tipo e linting em toda a base de código ou concluir outras etapas do pipeline de CI.
Cada conversa com um agente tem esses custos. Se seus testes levam 10 minutos para serem executados e você inicia 10 agentes em paralelo, são quase duas horas de espera. Se os testes ficarem 50% mais rápidos, você economizará quase uma hora a cada vez.
Essas melhorias geram ganhos em cada sessão, branch e agente. Veja alguns exemplos de alterações de alto impacto:
- Acelerar sua suíte de testes
- Reduzir sua árvore de dependências
- Otimizar seu pipeline de CI
- Acelerar sua verificação de tipo
- Reduzir o tempo de build
São tarefas que as equipes podem deixar em segundo plano, mas, quando os agentes executam esses comandos dezenas de vezes por dia, a economia se acumula. Investir uma hora para acelerar os testes pode economizar centenas de horas ao longo do tempo.
E o melhor é que os agentes podem fazer esse trabalho por você. Você pode pedir a um agente que analise o desempenho dos testes e encontre os mais lentos para corrigir. Também pode pedir que ele audite suas dependências e remova o que não é usado. São tarefas bem delimitadas, com saída clara e verificável — exatamente o tipo de trabalho em que os agentes se saem melhor.
Padrão comum de falha
Testes aprovados não garantem que o código funcione corretamente. É possível que os testes estejam verificando o comportamento errado. O agente pode ter escrito um código que funciona nos casos mais comuns, mas não considera todos os casos de borda.
É importante que você entenda as alterações no código. Se a alteração for grande demais para revisar com tranquilidade, considere dividi-la em partes menores, mais fáceis de revisar, tanto para você quanto para os agentes.
Próximos passos
Agora você sabe como lançar novas funcionalidades, depurar problemas e revisar código para garantir a qualidade. Por fim, personalize os agentes para sua base de código e torne seu fluxo de trabalho mais rápido.