Claude Code no dia a dia: alterações que se conseguem rever
Defina contexto, limites e validação para uma tarefa real com Claude Code, da investigação inicial ao diff e aos testes.
“Melhore este projeto” deixa quase tudo em aberto. O agente tem de adivinhar prioridade, comportamento esperado e âmbito. Um pedido útil começa por descrever o problema, a reprodução e o resultado que será aceite.
Imagine um formulário que perde os dados quando o servidor devolve erro. Neste exemplo hipotético, o objetivo é conservar o preenchimento e explicar a falha, sem mudar a biblioteca nem redesenhar a aplicação.
Defina o ponto de partida antes de editar
Confirme pasta, branch e alterações existentes. Registe os comandos que funcionam no projeto. Separe credenciais e dados reais dos materiais de teste. Forneça contexto suficiente para investigar sem acessos desnecessários.
A documentação do Claude Code apresenta o modo de planeamento para ler e propor antes de editar, com claude --permission-mode plan.
Peça um diagnóstico com ficheiros relevantes e uma hipótese verificável. Se não explica a reprodução, prossiga a investigação. Um plano convincente deve corresponder ao código encontrado.
Estabeleça fronteiras claras
Indique o comportamento a preservar e os módulos relevantes. Para o formulário, peça que se mantenham os valores após falha, se apresente o erro e seja possível repetir. Inclua um caso de sucesso para não corrigir um estado prejudicando outro.
Defina as ações externas excluídas. Executar testes locais é diferente de enviar mensagens, alterar uma base partilhada ou publicar uma versão. As permissões devem acompanhar as necessidades concretas.
Reveja alteração e evidência
Leia o diff à procura de mudanças alheias, código duplicado e tratamentos de erro que apenas escondem a falha. Peça a saída dos testes relevantes e confirme os casos executados.
No exemplo, envie com falha simulada, confirme que os campos permanecem e repita com sucesso. Um teste unitário verifica uma função; navegar mostra como uma pessoa percebe o resultado. Use ambos quando cobrem riscos diferentes.
Deixe uma passagem de trabalho compreensível
Registe problema corrigido, comportamento final, comandos e pendências. Se uma integração não estava disponível, identifique a parte não validada. A ausência de erros no terminal não comprova que todo o percurso funciona.
O ganho útil surge quando a alteração chega à revisão com contexto e evidência. Quanto menos o próximo programador tiver de reconstruir, mais fácil será manter o resultado.
Continue em quando dividir trabalho entre agentes.
Sobre o autor
Tiago F SantiagoComentários
Ainda sem comentários
Partilhe uma dúvida ou experiência relacionada com o artigo.
Artigos relacionados
