Começa por dizer o que significa concluído
Um trabalho está concluído quando cumpre o objetivo acordado e passa as verificações necessárias para a sua utilização. Escreve essas condições antes de pedir melhorias adicionais. Se ninguém consegue explicar o que falta, a próxima revisão pode estar a procurar uma preferência nova em vez de resolver um problema existente.
Imagina que pedes um formulário para recolher pedidos de orçamento. O pedido deve esclarecer que informação é obrigatória, quem recebe o pedido e o que a pessoa vê depois de o enviar. Se estas decisões não estão tomadas, cada versão pode parecer incompleta por razões diferentes, mesmo quando executa aquilo que foi solicitado.
A reflexão sobre planear uma aplicação antes de começar a programar é relevante precisamente aqui. Quanto mais claro for o comportamento esperado, mais concreta pode ser a verificação. Dizer que o formulário deve impedir um envio sem contacto dá um critério observável; pedir que fique mais profissional deixa várias interpretações em aberto.
Os critérios também precisam de limites. Uma primeira ferramenta interna pode estar concluída para uma tarefa definida, ainda que existam funcionalidades desejáveis para o futuro. Regista essas possibilidades separadamente para que a avaliação da entrega atual não se transforme continuamente numa nova especificação.
Para preparar o próximo passo, consulta Desenvolver aplicações com IA.
Distingue correções de mudanças de preferência
Uma correção resolve uma diferença entre o resultado e o critério acordado. Uma mudança de preferência altera esse critério ou acrescenta uma escolha que ainda não tinha sido feita. Ambas podem ser legítimas, mas exigem decisões diferentes sobre prioridade, esforço e necessidade de voltar a verificar partes do trabalho.
Se o formulário perde a mensagem quando ocorre um erro, há um comportamento concreto a corrigir. Se decides trocar a ordem das perguntas porque agora queres começar pelo serviço pretendido, estás a rever o desenho da interação. Apresentar tudo como um defeito da IA dificulta perceber o que falhou e o que mudou no pedido.
Antes de enviar feedback, escreve o resultado observado, o resultado esperado e a razão da diferença. Se não consegues identificar um comportamento incorreto, formula a alteração como uma opção de melhoria. Essa distinção permite decidir se merece entrar agora ou ficar para uma revisão futura sem desvalorizar a preferência.
Também ajuda a evitar instruções contraditórias. Uma versão pode ter sido simplificada porque pediste menos informação, enquanto a revisão seguinte exige explicações que removeste. Mantém uma referência atual das decisões aceites para que o trabalho seja avaliado contra o mesmo objetivo, em vez de depender da memória de uma conversa longa.
Dá uma pergunta concreta a cada revisão
Uma revisão útil procura uma classe de problemas e apresenta evidência do que encontrou. Pede que sejam verificadas condições específicas, indicando o material de referência e o tipo de resultado esperado. A instrução revê tudo pode servir como início de exploração, mas precisa de se transformar num conjunto de verificações explicáveis.
Num texto comercial, uma passagem pode conferir nomes, condições e correspondência com a oferta aprovada. Noutra tarefa, pode ser necessário confirmar se os cálculos usam os dados certos. A escolha das verificações depende do efeito de um erro e não do número de revisões que dá uma sensação de segurança.
Pede ao assistente que distinga problemas demonstrados de sugestões. Uma sugestão de estilo pode melhorar a leitura, mas não tem a mesma urgência de uma condição comercial errada. Quando recebes uma lista indiferenciada de alterações, acabas a decidir novamente sobre tudo, mesmo sobre o que já tinha sido aprovado.
A revisão precisa ainda de consultar algo além da própria resposta quando a tarefa exige confirmação factual. Pedir ao modelo que releia uma afirmação não fornece, por si só, a informação necessária para a verificar. Mostra a fonte, o exemplo esperado ou o teste que permite comparar a resposta com a realidade do trabalho.
Conta também o trabalho de comparar versões
O custo de revisão inclui o tempo da ferramenta, a leitura humana, a comparação entre versões e as verificações desencadeadas por novas alterações. Regista esse esforço no processo completo. Uma pequena melhoria pode justificar outra passagem, mas essa decisão deve considerar o que ganhas e o que precisas de voltar a conferir.
Numa proposta, alterar um parágrafo pode exigir verificar novamente o âmbito, os valores e a coerência com outras secções. Num projeto de software, uma mudança pode afetar comportamentos ligados à parte editada. Por isso, uma revisão que reescreve tudo torna mais difícil perceber se apenas corrigiu o problema identificado.
Pede alterações delimitadas e uma explicação curta do que mudou. Preserva uma versão anterior recuperável para comparar os resultados quando necessário. A pessoa responsável deve conseguir identificar se a nova versão resolveu a falha sem introduzir mudanças adicionais que não tinham sido pedidas nem avaliadas.
A escolha do modelo para a tarefa também entra nesta conta. Configurações mais exigentes podem fazer sentido em trabalho difícil, mas não transformam todas as passagens adicionais em verificações úteis. O benefício precisa de aparecer nos problemas encontrados e resolvidos, e não apenas numa resposta mais longa ou demorada.
Fecha a revisão com uma decisão verificável
Depois de corrigir os problemas identificados, executa as verificações necessárias e compara o resultado com os critérios iniciais. Se foram cumpridos, fecha essa entrega e regista as melhorias opcionais para outra ocasião. Reabre o trabalho quando surge nova evidência, uma falha relevante ou uma alteração explícita ao que deve ser entregue.
Os princípios de testar uma automação antes de a entregar à equipa ajudam a tornar esse fecho concreto. Uma entrega precisa de evidência de funcionamento nos casos acordados, incluindo exceções pertinentes. Repetir uma avaliação já satisfeita sem alteração ou dúvida nova pode consumir atenção que faria falta noutro ponto.
Há situações em que vale a pena insistir ou pedir uma revisão independente. Uma falha recorrente, uma alteração com consequências importantes ou resultados contraditórios justificam aprofundar a análise. Nesse caso, explica qual é a incerteza restante e que tipo de verificação pode resolvê-la, em vez de reiniciar indiscriminadamente todas as etapas.
No exemplo do formulário, o fecho pode reunir o comportamento acordado, os casos verificados e as limitações conhecidas. A preferência por outra ordem de perguntas fica registada como possível evolução se não for necessária à entrega atual. O trabalho avança quando a equipa sabe por que aceita aquela versão e o que, concretamente, faria voltar a abri-la.