Revê alterações de código feitas por IA antes de as aceitares
Verifica âmbito, diferenças, alterações preparadas, provas de teste e riscos em aberto no Mono Code com um modelo de revisão e comandos Git de leitura.
Revê o código que existe no repositório, não apenas o resumo do agente. Uma explicação convincente pode acompanhar uma correção incompleta, um teste que nunca correu ou alterações alheias à tarefa. Separa o comportamento pedido, as alterações reais e as provas antes de aceitar o resultado.
O Mono Code permite abrir ficheiros do projeto, trabalhar com agentes de programação e ver as alterações Git diretamente no editor. Este guia trata da revisão de uma pequena alteração já concluída; o guia de programação remota explica como se ligar. O repositório e os comandos ficam sempre no seu próprio computador, o anfitrião. O Mono ainda não está disponível; pode aderir à lista de espera.
1. Reformula a condição de aceitação
Usa um exemplo concreto: um formulário fictício aceita um título de tarefa composto apenas por espaços. A correção pedida deve rejeitá-lo sem prejudicar títulos normais. Antes de olhar para o patch, escreve o que tem de ser verdade:
- Títulos vazios ou só com espaços não podem ser enviados.
- Um título normal continua a ser enviado corretamente.
- O utilizador vê uma mensagem de validação útil.
- O restante comportamento do formulário respeita o âmbito acordado.
Mantém esta lista junto ao diff. Dá-te uma base para avaliar a alteração em vez de concordares com a explicação apresentada pelo agente. Se o pedido inicial era ambíguo, resolve o comportamento antes de aceitar uma implementação mais ampla.
2. Estabelece o estado do repositório
Confirma o anfitrião, a pasta do projeto e o ramo. Compara a lista de ficheiros alterados com o estado inicial registado antes do trabalho do agente. Alterações anteriores do utilizador não passam a pertencer ao agente por estarem no mesmo ficheiro.
Num terminal no anfitrião correto, estes comandos de leitura podem ajudar:
git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/fileSubstitui o caminho de exemplo. git diff mostra alterações não preparadas; --cached compara as alterações preparadas com o commit. Inspeciona separadamente ficheiros não acompanhados pelo Git. A documentação de Git diff explica estas comparações. Uma árvore de trabalho limpa não revela se o agente já fez um commit; consulta o histórico relevante se isso aconteceu.
3. Lê o patch e o código envolvente
No editor do Mono, a margem assinala as linhas adicionadas e modificadas, e tocar numa marca abre as diferenças dessa parte. É uma forma prática de ver uma alteração, não uma prova de que as reviu todas. Uma marca em falta ou desatualizada não significa que o ficheiro não mudou.
No exemplo do título, encontra a condição de validação e segue o que acontece depois. Verifica o valor normalizado? O erro é visível? O envio para? Inspeciona o código envolvente em vez de aceitar uma condição isolada sem quem a chama.
Verifica ficheiros novos, código eliminado, dependências e formatação fora do âmbito. Uma explicação curta não justifica uma grande diferença por explicar. Passa para o anfitrião ou um ecrã maior quando as linhas estão truncadas ou a alteração é demasiado larga para ler com confiança.
4. Liga os testes ao comportamento
Pede o comando realmente executado, o resultado e as verificações omitidas. «Os testes devem passar» é uma previsão, não um resultado observado. Uma bateria bem-sucedida também precisa de um caso relevante para o erro comunicado.
| Caso | Observação esperada |
|---|---|
| Título vazio | Envio interrompido com a mensagem prevista |
| Apenas espaços | Mesma rejeição, sem criar um elemento |
| Título normal | Envio continua a funcionar |
| Comportamento existente fora da alteração | Verificações relevantes continuam a passar |
Uma verificação manual pode servir para o feedback visível; um teste automatizado de regressão pode proteger a regra. Escolhe provas que demonstrem a alteração em vez de testes que repitam a implementação. Se o ambiente impedir os testes, regista essa limitação e decide onde fazer a verificação em falta.
5. Resolve problemas sem perder trabalho alheio
Dá feedback preciso: «O título só com espaços é rejeitado, mas a mensagem de erro não aparece» ou «Explica porque mudou o ficheiro de dependências nesta correção». Indica comportamento e ficheiro, em vez de dizer apenas «tenta outra vez».
Evita reposições ou restauros globais para retirar uma pequena alteração quando há outro trabalho presente. Pede uma correção dirigida e inspeciona o novo diff. Repete as verificações afetadas depois: um sucesso anterior não valida edições posteriores.
Autorizar um comando e aceitar código são decisões diferentes. Aprovar um comando de teste não autoriza commits, integração nem publicação. Consulta o guia de permissões para avaliar a operação em si.
6. Deixa uma passagem de trabalho verificável
Regista a conclusão numa nota curta:
Comportamento pedido: Rejeitar títulos de tarefas em branco.
Ficheiros revistos: Listar os caminhos reais.
Provas: Comandos, resultados e verificações manuais relevantes.
Questões abertas: Tudo o que ainda não foi verificado.
Próxima decisão: Aceitar, pedir correção ou adiar.Mantém explícitas as ações de commit e publicação. Para preservar a conversa, exporta-a para Markdown, mas conserva também os ficheiros reais do projeto. A transcrição regista a discussão; o repositório e as verificações comprovadas estabelecem o que mudou.
