Distingue uma falha de uma decisão por tomar
Uma falha tem um resultado esperado suficientemente claro para ser verificado. Uma decisão por tomar deixa várias respostas possíveis, e cada correção pode seguir uma delas. Se a equipa muda repetidamente a definição do comportamento certo, vale a pena suspender a implementação dessa parte e resolver primeiro a escolha pendente.
Já cheguei a abandonar uma versão de uma aplicação depois de a ideia mudar demasiado durante a construção. O projeto acumulou instruções contraditórias e a IA voltava a encontrar decisões antigas nos ficheiros. Recomeçar com o entendimento que tinha entretanto adquirido foi a escolha que fiz naquele caso concreto.
Essa experiência não transforma apagar trabalho numa regra de desenvolvimento. Mostra o custo de continuar a construir sobre decisões que já não correspondem ao que se pretende. Hoje, perante uma sequência de correções, procuro perceber se estamos a resolver defeitos identificáveis ou a mudar continuamente a própria definição do produto.
Imagina um protótipo para reservar salas de ensaio. Inicialmente, uma reserva ocupa uma sala durante uma hora; depois passa a depender de equipamentos partilhados e da presença de um técnico. Se estas condições forem acrescentadas sem rever a regra de disponibilidade, o calendário pode acumular exceções difíceis de explicar.
Quando corriges uma reserva e estragas outra, pergunta o que ambas têm em comum. Pode existir um defeito localizado, mas também pode faltar uma decisão sobre o que está realmente a ser reservado. Essa resposta orienta o trabalho seguinte de forma muito mais útil do que pedir outra correção genérica.
Para preparar o próximo passo, consulta Desenvolver aplicações com IA.
Procura contradições nas regras e nos documentos
Os sinais mais úteis aparecem quando diferentes partes do projeto defendem comportamentos incompatíveis. Compara os requisitos, os exemplos e o que a aplicação faz. Se a mesma situação recebe respostas diferentes conforme o documento consultado, define qual é a decisão válida antes de pedir à IA que continue a desenvolver.
No protótipo das salas, uma instrução pode dizer que o cliente escolhe livremente o horário, enquanto outra exige confirmação manual do técnico. Ambas podem fazer sentido em produtos distintos. Mantê-las sem explicar a relação entre elas obriga a aplicação a tentar cumprir duas promessas que a equipa ainda não conciliou.
Reúne as decisões relevantes num registo curto: o que está aceite, o que foi substituído e o que permanece em aberto. Uma decisão antiga pode continuar documentada como histórico, desde que deixe de parecer uma instrução atual. O importante é que quem trabalha consiga reconhecer a regra em vigor.
Também vale a pena distinguir o comportamento pretendido da solução técnica escolhida para o obter. Talvez precises de impedir reservas incompatíveis, mas isso não determina automaticamente a forma de organizar o calendário. Separar estas duas coisas permite rever a implementação sem voltar a discutir a necessidade que a motivou.
O exercício de planear uma aplicação antes de programar continua útil nesta fase, com uma vantagem: já tens exemplos concretos do que falhou. Usa-os para melhorar as perguntas do plano, em vez de escrever uma descrição mais extensa que mantém exatamente as mesmas ambiguidades da versão anterior.
Compara opções sobre a parte afetada
Antes de decidir recomeçar, compara o alcance de uma correção, de uma reformulação parcial e de uma nova versão. Para cada opção, identifica o que pode ser preservado e o que precisa de ser novamente validado. A escolha deve apoiar-se na causa do problema e nas dependências que realmente existem.
Se o calendário mostra a hora errada por uma transformação incorreta, pode bastar uma correção localizada. Se o conceito de disponibilidade mudou de sala para sala, equipamento e técnico em conjunto, talvez seja necessário rever essa parte de forma mais profunda. A dimensão visível do erro não determina a dimensão da solução.
Pede que a análise explique quais os dados, percursos e regras dependentes da parte a alterar. Um ecrã simples pode alimentar confirmação, cancelamento e gestão interna. Reconstruí-lo sem considerar essas ligações pode deixar o mesmo problema espalhado por outros pontos, com uma aparência nova mas uma lógica ainda incompleta.
Conta o esforço futuro de verificar cada opção, além do trabalho de construir. O que já gastaste ajuda a compreender o percurso, mas não demonstra que continuar nele seja a melhor decisão. Também não torna a reconstrução automaticamente vantajosa: perder comportamentos corretos pode criar uma nova lista de problemas.
Preserva a aprendizagem antes de mudar de direção
Um protótipo pode deixar de ser a base adequada e continuar a conter aprendizagem valiosa. Guarda os percursos demonstrados, os exemplos que revelaram falhas e as decisões entretanto esclarecidas. Preserva uma versão recuperável antes de uma reformulação, para poderes consultar e comparar o comportamento que já estava a funcionar.
No caso das salas, talvez o formulário de contacto esteja adequado e as mensagens sejam compreensíveis, apesar de a disponibilidade precisar de outra estrutura. Não há razão para tratar todas as partes como igualmente falhadas. Identifica o que pode ser reaproveitado e confirma a compatibilidade com as regras revistas.
Os testes que descobriram as contradições também devem acompanhar a mudança. Uma reserva que precisa do mesmo equipamento noutra sala passa a ser um caso concreto de validação. Se esse exemplo ficar apenas na conversa que levou à reformulação, podes terminar uma nova versão sem confirmar que resolveu a dificuldade original.
Ao preparar uma sessão de trabalho com Claude Code, esta informação merece mais atenção do que uma longa lista de tentativas. Entrega o estado aceite, as regras revistas e os casos a demonstrar. A história ajuda quando explica uma decisão, mas não deve esconder o pedido atual.
Retoma com uma hipótese que possas confirmar
A construção deve retomar quando existe uma explicação para a falha e um resultado que permite avaliar a mudança proposta. Escolhe um percurso representativo e implementa o necessário para o demonstrar. Só depois expande a solução, mantendo visíveis as decisões que ainda não foram tomadas para os restantes casos.
Para as reservas, podes começar por um pedido que envolva sala, equipamento e técnico, incluindo a tentativa de sobreposição que antes falhava. O objetivo é confirmar que a nova definição de disponibilidade produz a resposta esperada. Uma apresentação mais bonita do calendário não responde, por si só, a essa pergunta.
Regista também quem decide quando surge uma nova exceção. Voltar a discutir a mesma regra a cada pedido tem um custo semelhante ao de tomar repetidamente a mesma decisão na empresa. Tornar a escolha explícita permite concentrar a atenção nas situações que trazem informação verdadeiramente nova para o projeto.
Se a hipótese falhar, usa o resultado para rever a explicação, sem acrescentar imediatamente outra exceção à implementação. Parar a tempo mantém a aprendizagem disponível e limita o trabalho dependente de uma decisão frágil. O avanço que interessa é conseguir justificar o comportamento da próxima versão e demonstrá-lo nos casos relevantes.