Como rever alterações de código sugeridas pela IA
Para rever alterações de código sugeridas pela IA, compara o pedido com os ficheiros alterados, testa o comportamento esperado e procura efeitos nos percursos relacionados. Regista a versão que verificaste e as limitações encontradas. Este guia usa uma pequena alteração num formulário para mostrar como transformar uma revisão vaga numa decisão fundamentada.
Por onde começar a revisão de uma alteração?
Começa por escrever o comportamento que a alteração deve produzir e o problema que resolve. Depois identifica a versão anterior e a proposta que vais rever. Esta referência permite comparar resultados e perceber se o agente resolveu o pedido, acrescentou trabalho desnecessário ou deixou alguma condição importante por tratar.
Vamos usar um exemplo fictício: um formulário aceita pedidos de contacto, mas não explica ao visitante que o envio está em curso. A alteração pedida é mostrar esse estado e evitar novos cliques enquanto o pedido está pendente. O destino dos dados e os campos do formulário continuam a fazer parte do percurso existente.
Escreve um critério observável: ao enviar dados válidos, aparece uma indicação de processamento; durante o pedido, o botão não inicia outro envio; no fim, o visitante recebe uma resposta coerente. Acrescenta o caso de falha: deve ser possível perceber o problema e tentar novamente nas condições definidas.
Se o pedido inicial for demasiado grande, começa por dividir o protótipo em tarefas pequenas de implementação. Uma revisão funciona melhor quando consegues relacionar cada mudança com um resultado concreto, sem ter de avaliar simultaneamente um novo formulário, uma base de dados e um sistema de contas.
Como descobrir exatamente o que a IA alterou?
Consulta a lista completa de ficheiros modificados e compara o conteúdo anterior com o novo. Pede uma explicação da função de cada mudança, mas confirma-a na comparação efetiva. Inclui ficheiros novos, configurações e dependências na revisão, porque uma alteração visível pequena pode envolver outros elementos do projeto.
Num projeto com Git, git diff mostra alterações ainda não preparadas para o próximo commit, enquanto git diff --cached mostra as que já estão nessa preparação. A comparação depende dos pontos escolhidos; nenhum destes comandos isolados deve ser confundido com um inventário universal do trabalho. A documentação de git diff descreve essas diferenças.
Podes usar uma interface gráfica para fazer a mesma leitura. Se trabalhas com uma pull request no GitHub, o separador Files changed permite percorrer as diferenças e comentar linhas específicas. A documentação de revisão de alterações no GitHub explica esse percurso.
No exemplo, espera encontrar uma relação clara entre os ficheiros alterados e o estado do formulário. Se aparecer uma nova biblioteca, pede o motivo e a alternativa considerada. Se surgirem mudanças no checkout ou nos acessos dos utilizadores, confirma a ligação ao pedido antes de as integrar.
Que explicação deves pedir ao agente?
Pede uma explicação organizada pelo efeito da alteração: o problema anterior, a solução proposta, os casos tratados e a validação realizada. Exige referências aos ficheiros relevantes e separação entre testes executados e verificações apenas sugeridas. Assim, consegues usar o resumo como orientação para a tua própria revisão.
Um pedido útil seria: «Explica o que mudou no percurso de envio do formulário. Indica onde começa e termina o estado de processamento, como é tratada uma falha e que testes executaste. Associa cada conclusão ao código ou à evidência disponível. Identifica o que ainda não conseguiste verificar.»
Confere as respostas com o trabalho entregue. Se o agente disser que o botão volta a ficar disponível após um erro, procura o caminho que repõe esse estado e experimenta-o. Uma explicação plausível pode omitir uma condição que o código também omitiu.
Quando não compreenderes uma parte, pede uma descrição com um exemplo de entrada e saída. «O visitante clica, a rede demora e depois falha: o que vê em cada momento?» Esta pergunta ajuda a ligar a implementação ao uso real. Guarda as decisões relevantes nas instruções do projeto quando forem reutilizáveis.
Como escolher testes que dizem alguma coisa útil?
Escolhe testes que possam distinguir a versão correta de uma versão com o problema original. Parte dos critérios de aceitação e acrescenta as condições que mudam o resultado. Para uma alteração de interface, combina verificações automáticas relevantes com observação do percurso no navegador, incluindo o estado de erro.
| Caso do formulário fictício | Resultado esperado | Evidência a procurar |
|---|---|---|
| Envio válido com resposta demorada | Estado de processamento visível | Observação durante a espera |
| Segundo clique durante o pedido | Sem novo envio iniciado pelo botão | Contagem dos pedidos no teste |
| Resposta de sucesso | Confirmação coerente com o resultado | Resposta recebida e estado da interface |
| Falha de rede simulada | Erro compreensível e recuperação possível | Mensagem e nova tentativa controlada |
| Dados obrigatórios em falta | Validação mantém o comportamento acordado | Nenhum pedido indevido neste caso |
Este conjunto é uma proposta para o exercício, não um teste já executado numa aplicação real. Adapta os resultados ao contrato do teu formulário. Se uma falha puder acontecer depois de o servidor guardar o pedido, a estratégia de repetição também precisa de considerar esse cenário.
A Anthropic recomenda dar ao Claude Code formas de verificar o trabalho, como testes, compilação e comparação visual. Usa esses mecanismos com critérios concretos, em vez de pedir apenas «confirma que está tudo bem». A orientação está nas boas práticas do Claude Code.
O que fazer quando todos os testes passam?
Confirma o que os testes realmente cobrem antes de concluir que a alteração está pronta. Um resultado positivo é evidência sobre os casos executados, no ambiente usado e naquela versão. Revê se esses casos representam o pedido e se alguma parte importante ficou substituída por uma simulação demasiado simplificada.
No formulário, um teste pode verificar apenas que o texto «A enviar» existe no código. Isso não demonstra que aparece no momento certo nem que desaparece depois de uma falha. Prefere observar a sequência de estados e a interação que desencadeia cada um deles.
Verifica também os comandos executados e o resultado final. «Testes preparados» e «testes passaram» descrevem estados diferentes. Se faltou uma configuração e a execução foi interrompida, regista essa limitação. Não transformes a ausência de um resultado numa aprovação por inferência.
Quando houver testes anteriores, percebe se a alteração os removeu ou tornou menos exigentes. Uma expectativa deve mudar quando o comportamento pretendido muda, com justificação. Alterar a expectativa só para fazer desaparecer uma falha pode esconder o problema que a revisão deveria encontrar.
Como procurar efeitos noutras partes da aplicação?
Segue as relações diretas da alteração e testa os percursos que partilham o código modificado. Se o formulário usa um botão comum a várias páginas, verifica onde esse componente é reutilizado. A extensão da revisão deve acompanhar o impacto provável da mudança, em vez de depender apenas do número de linhas.
No exemplo, um novo estado de carregamento num componente partilhado pode afetar o contraste, o tamanho ou a possibilidade de clicar noutros botões. Abre uma página que use o mesmo componente sem envio de formulário. Confirma que a utilização anterior continua a fazer sentido.
Observa o percurso em telemóvel e com teclado quando a alteração mexer na interação. O visitante consegue chegar ao botão, perceber o estado e recuperar de um erro? Um teste de lógica não responde sozinho a perguntas sobre legibilidade, foco ou mensagens que ficam fora da área visível.
Mantém a revisão focada. Não precisas de redesenhar toda a aplicação porque encontraste uma preferência estética noutra página. Regista essa observação separadamente e corrige, nesta entrega, o que impede o comportamento pedido ou introduz um problema relevante nos percursos afetados.
Que alterações exigem uma revisão técnica mais profunda?
Identifica se a mudança toca em permissões, dados persistentes, pagamentos, segredos ou comunicação com serviços externos. Nesses casos, a revisão precisa de cobrir as decisões tomadas pelo servidor e as consequências de entradas inesperadas. Se não consegues avaliar essa parte, envolve alguém com competência técnica para o âmbito concreto.
Desativar o botão do nosso exemplo melhora a interação, mas não prova que o servidor impede pedidos duplicados vindos por outros caminhos. Se evitar duplicação for um requisito do sistema inteiro, tens de rever também a forma como o servidor reconhece e trata repetições.
Numa aplicação com contas, confirma os limites de acesso em ambiente autorizado e com utilizadores de teste. Uma mudança que permite abrir um registo pelo identificador deve respeitar quem pode consultá-lo. O facto de o botão estar escondido para uma conta não demonstra, por si só, essa proteção.
Procura ainda configurações ou valores privados que tenham entrado nos ficheiros preparados para partilha. Faz esta verificação sem copiar segredos para relatórios ou conversas. A profundidade necessária depende do projeto; uma revisão de um formulário não deve ser apresentada como auditoria completa de segurança da aplicação.
Como dar feedback que ajude a corrigir o problema?
Descreve a condição que provoca a falha, o resultado observado e o comportamento esperado. Junta a versão e o ambiente em que testaste, com evidência suficiente para repetir o caso. Este formato permite ao agente investigar uma causa concreta e evita correções baseadas numa impressão geral sobre a página.
Em vez de «o formulário continua mal», escreve: «Na versão de teste atual, simulei uma resposta de erro após clicar em Enviar. A mensagem aparece, mas o botão mantém o estado de processamento. Esperava conseguir tentar novamente depois de o pedido terminar com erro.»
Pede uma correção delimitada e a repetição dos casos afetados. Se o problema era repor o estado depois de uma falha, volta a verificar esse caminho e o caminho de sucesso. Confirma também que a correção não passou a aceitar cliques adicionais enquanto o primeiro pedido ainda decorre.
Mantém as observações ligadas a ficheiros ou comportamentos identificáveis. Se a solução proposta exigir mudar o objetivo, decide essa alteração explicitamente. O guia para começar um projeto com Claude Code sem perder o controlo ajuda-te a manter contexto e critérios ao longo destas iterações.
Como distinguir revisão local, integração e publicação?
Regista em que fase está a alteração e qual a versão correspondente. Uma mudança pode estar validada no computador, guardada no repositório ou publicada num ambiente de teste. A confirmação no endereço final é outra verificação, necessária quando a entrega inclui colocar o comportamento novo à disposição dos utilizadores.
Num processo com Git, um commit identifica um estado do código. O envio desse commit para um repositório remoto pode desencadear uma publicação se existir essa integração, mas isso depende da configuração do projeto. Confirma o resultado do serviço de alojamento e a versão efetivamente disponibilizada.
Se a publicação fizer parte do trabalho autorizado, prepara a entrega e verifica-a nesse âmbito. Se o exercício for apenas local, regista esse limite. A revisão não deve confundir uma aprovação da implementação com decisões sobre ambientes ou serviços que ficaram fora do pedido.
Depois de publicar, repete o percurso essencial no endereço correto com dados de teste apropriados. Configurações de ambiente e serviços externos podem diferir da máquina local. Associa a verificação à versão publicada e evita atribuir à entrega nova um resultado observado numa pré-visualização antiga.
O que deve ficar registado no fim da revisão?
Guarda uma nota curta com o problema resolvido, a versão revista, os testes realizados, os resultados e as limitações que continuam relevantes. Inclui uma decisão clara sobre a entrega e o motivo. Esse registo permite retomar o projeto sem depender da memória da conversa com o agente.
Para o exercício, a nota poderia começar assim: «O formulário mostra o envio em curso e recupera após erro. Foram verificados os cinco casos definidos, na versão identificada. A prevenção de duplicados no servidor ficou fora desta alteração e continua a precisar de avaliação se for um requisito.»
Se algum teste não passou, a nota deve dizer o que falta corrigir e como repetir o problema. Se passou com uma limitação, explica o efeito dessa limitação na decisão. Evita expressões como «cem por cento seguro» ou «sem qualquer erro», que excedem a evidência disponível.
Guarda também uma forma de recuperar a versão anterior quando a alteração o justificar. Repor código pode não reverter mudanças em dados ou ações já enviadas para outros serviços. No nosso exemplo, mantém a revisão proporcional ao formulário e documenta qualquer efeito adicional que tenha surgido durante o trabalho.
Como podes aprender isto no Laboratório da IA?
No Laboratório da IA, podes desenvolver projetos com agentes e aprender a avaliar o que eles entregam. Leva uma alteração pequena, o comportamento esperado e a evidência dos testes às aulas e aos Zooms semanais. Essa preparação torna a discussão concreta e ajuda-te a melhorar a próxima decisão do projeto.
Podes começar pelo exercício deste guia numa aplicação de teste. Define os estados do formulário, pede a implementação e conduz a revisão com os casos preparados. O objetivo é conseguires explicar por que aceitas a alteração, que resultados observaste e quais os limites dessa conclusão.
Referências
As referências seguintes documentam a comparação de alterações no Git, o percurso de revisão no GitHub e mecanismos de verificação no Claude Code. Foram consultadas em 14 de outubro de 2026. O formulário e os resultados esperados apresentados neste artigo são um exercício editorial, sem alegação de testes numa aplicação real.
Aprende a construir isto no Lab.
Trabalha o processo com aulas, materiais e acompanhamento. Leva o que estás a construir e esclarece as dúvidas da tua implementação.
- Relacionar cada alteração com o comportamento pedido.
- Testar casos de sucesso, falha e efeitos nos percursos relacionados.
- Rever projetos com agentes nas aulas e Zooms semanais do Laboratório.
Aulas semanais para aprender e aplicar. Zooms de acompanhamento semanais para esclarecer dúvidas. Replay e materiais para retomar o trabalho ao teu ritmo.
Entrar no Laboratório da IA