Uma segunda opinião que ajuda

Uma revisão começa com a mudança que você quer avaliar e com o comportamento esperado. Informe entrada, resultado desejado, arquivos envolvidos e verificações já feitas. O revisor precisa saber o que pode ser considerado correto, não apenas receber um diretório enorme.

Uma segunda IA, como Codex, pode oferecer outra análise, mas não se torna automaticamente mais confiável. Trate suas sugestões como hipóteses que devem apontar um cenário concreto. O valor aparece quando a revisão encontra algo que pode ser demonstrado.

Em um projeto Git, o diff mostra o que mudou. Antes de revisar, confira a pasta atual e o estado do repositório. Separe arquivos próprios da mudança e materiais que não devem ser publicados. Uma revisão de alterações não versionadas pode incluir arquivos novos.

Com a CLI Codex instalada e autenticada, consulte a ajuda local e use uma revisão compatível com a versão disponível. O exemplo abaixo mostra a revisão de alterações não commitadas. Ela não substitui o teste da aplicação.

Solicite que cada achado descreva gatilho, efeito, localização e forma de reproduzir. Prefira “dois cliques enviam o mesmo pedido duas vezes” a “melhore a robustez”. O primeiro enunciado permite construir um teste; o segundo não define um comportamento.

Diferencie erro funcional, manutenção e preferência de estilo. Todos podem importar, mas não devem receber a mesma prioridade. Uma exportação que inclui registros de outro cliente exige uma resposta diferente de um nome de variável pouco claro.

Muitos erros aparecem na segunda execução. Se um pedido é reenviado depois de uma falha de conexão, a operação precisa saber se já foi processada. Uma chave de idempotência identifica a mesma intenção para evitar criar dois resultados.

Outro cenário é a interrupção no meio de uma atualização. Registrar metade de uma operação pode deixar os dados inconsistentes. Em exercícios, simule a falha entre os passos e observe o estado final. Não conclua que um fluxo é correto só porque funciona uma vez.

Quando uma correção falha repetidamente, registre o que já foi tentado e o resultado de cada tentativa. Reduza o problema até uma entrada pequena que ainda falhe. Entregue esse caso a uma nova revisão.

Trocar de modelo sem organizar as evidências pode apenas reiniciar o mesmo ciclo. A mudança mais importante é fornecer um experimento menor, uma hipótese por vez e uma condição clara de parada. Preserve o caso que falhava depois da correção.

Imagine um formulário fictício que acrescenta pedidos a uma lista. O mesmo identificador pode chegar duas vezes. Descreva como reproduzir a duplicação e proponha uma regra que preserve apenas um efeito para o mesmo pedido.

Não basta esconder a segunda linha na tela. A regra deve atuar no registro da operação. Explique também o que fazer quando o identificador é igual, mas o conteúdo mudou: isso exige tratar um conflito, e não descartar silenciosamente a informação.