Como Evoluir um App Criado com IA Sem Quebrá-lo

Para evoluir um app criado com IA sem quebrá-lo, mude uma coisa por prompt, confira no preview e salve um checkpoint antes de seguir adiante. Descreva o que você vê, em vez do que você acha que o código faz, planeje as mudanças grandes antes de construí-las e, quando uma mudança der errado, volte para a última versão boa em vez de pedir à IA para consertar a própria correção.

A primeira versão de um app costuma ficar pronta em minutos. A parte difícil é a quinquagésima mudança, quando cada novo prompt arrisca quebrar algo que já funcionava. Este guia é o ciclo que evita isso.

O ciclo de evolução

1. Escolha uma mudança. Uma funcionalidade, um bug, uma página.
2. Descreva-a em termos do que o usuário vê e faz.
3. Para mudanças grandes, planeje primeiro. Peça um plano, leia e só então construa.
4. Confira o resultado no preview — a mudança e os fluxos próximos a ela.
5. Salve um checkpoint ou commit.
6. Repita.

Cada passo existe para manter as mudanças pequenas e reversíveis.

Passo 1: Mantenha uma lista curta

Antes de pedir, escreva o que você quer mudar, em ordem de importância. Isso evita mandar um parágrafo com dez desejos em uma única mensagem e dá um jeito de dizer "agora não" para as ideias que surgem no meio do caminho.

Se uma mudança é grande, divida-a. "Adicionar contas de equipe" vira: criar equipes, convidar um membro, alternar entre equipes, limitar os dados à equipe atual. Cada uma é um prompt próprio. Escrever histórias de usuário é um bom jeito de fazer essa divisão.

Passo 2: Descreva o que você vê

A IA não enxerga a sua tela a menos que você conte. Aponte coisas específicas e diga o que deveria acontecer:

Na página de preços, no celular, o botão do cartão Pro está cortado na borda direita. Mantenha o layout de desktop igual; em telas abaixo de 640px, empilhe os cartões e deixe os botões com largura total.

Compare com "a página de preços está ruim no celular". O primeiro pedido pode ser feito e conferido de uma vez; o segundo convida um redesenho que você não pediu.

Capturas de tela ajudam. Se o seu construtor aceitar imagens, anexe uma e marque o problema.

Passo 3: Planeje antes das mudanças grandes

Para qualquer coisa que toque várias partes do app — um novo modelo de dados, pagamentos, papéis de usuário —, peça um plano antes de qualquer código ser alterado:

Não mude o código ainda. Quero que os usuários pertençam a equipes e vejam apenas os projetos da sua equipe. Planeje a mudança: quais tabelas, páginas e rotas de API mudam, o que acontece com os dados dos usuários existentes e em que ordem você construiria.

Leia o plano. Se estiver errado, corrigir um plano custa muito menos do que desfazer uma construção.

Passo 4: Diga o que não pode mudar

As ferramentas de IA às vezes "arrumam" coisas que você não pediu. Proteja o que funciona:

Adicione um filtro de data na tabela de pedidos. Não mude as colunas da tabela, o estilo nem o botão de exportação.

Para regras que valem em todo lugar — cores da marca, tom de voz, "nunca apague dados sem confirmação" —, coloque-as em um arquivo de notas ou em uma configuração de conhecimento do projeto que a IA lê sempre, em vez de repeti-las.

Passo 5: Confira mais do que a mudança

Depois de cada prompt, teste:

• A mudança em si. Faz o que você pediu, no desktop e no celular?
• Os vizinhos. Coisas na mesma página e fluxos que usam os mesmos dados.
• O caminho crítico. Cadastro, login, a ação principal, pagamento. Uma passada de trinta segundos após cada mudança grande pega a maioria das quebras cedo.

Se algo estiver errado, relate com precisão — veja como escrever um bom relatório de bug.

Passo 6: Volte atrás em vez de empilhar

Quando uma mudança quebra algo e a primeira correção não funciona, pare. Cada "correção" extra é construída sobre um estado quebrado, e os problemas se acumulam.

Em vez disso:

1. Volte para a última versão que funcionava (um checkpoint ou commit do Git).
2. Descubra o que estava pouco claro no prompt.
3. Tente de novo com um pedido menor ou mais claro.

Essa mudança quebrou o salvamento de rascunhos. Eu voltei atrás. Desta vez: adicione apenas o indicador de salvamento automático, como texto no cabeçalho. Não mude como os rascunhos são salvos.

Passo 7: Saiba quando reconstruir é o certo

Reconstruir do zero descarta muitos detalhes que já funcionam. Só vale a pena quando:

• A ideia do produto mudou por completo.
• A estrutura por baixo não suporta o que você precisa agora — por exemplo, foi feita como um site estático e agora precisa de contas e banco de dados.
• O projeto ainda está perto do zero.

Ao reconstruir, liste o que manter: nome, cores, textos, as partes que os usuários gostavam.

Exemplos de prompts

Antes de continuarmos, resuma como o app funciona hoje: páginas, dados que ele guarda e o que você acha frágil.

Quero adicionar agendamentos recorrentes. Qual é a menor versão que seria útil? Sugira três mudanças separadas que possamos fazer uma de cada vez.

Revise as últimas três mudanças e veja se alguma pode ter quebrado o fluxo de checkout. Ainda não edite nada.

Erros comuns

• Dez pedidos em um prompt. Alguns ficam prontos, outros pela metade, e você não consegue saber quais.
• Feedback vago. "Está quebrado" ou "melhore isso" gera palpites.
• Nunca conferir os vizinhos. Uma mudança em um componente compartilhado quebra três outras páginas.
• Corrigir correções. Quatro prompts deep em um bug? Volte atrás.
• Repetir o contexto toda vez em vez de manter as regras permanentes nas notas do projeto.
• Reconstruir quando travado. A maioria dos momentos de "começar de novo" é, na verdade, "voltar dois passos".

Checklist

• Um objetivo por prompt.
• Eu descrevo o que vejo e o que deveria acontecer.
• Mudanças grandes ganham um plano antes de qualquer código.
• Eu digo o que não pode mudar.
• Depois de cada mudança, testo a mudança, os vizinhos e o caminho crítico.
• Salvo um checkpoint ou commit após cada mudança que funciona.
• Quando uma correção falha, volto atrás em vez de empilhar correções.
• As regras permanentes ficam nas notas do projeto que a IA lê sempre.

Evoluindo na Mythex

A Mythex é construída em torno desse ciclo:

• Modos Plan, Build e Ask. Plan discute a abordagem antes de editar; Ask responde sem mudar o código; Build faz a mudança. Veja Chat.
• Checkpoints. Após cada turno bem-sucedido, a Mythex salva um checkpoint do git; Revert to this point (voltar a este ponto) desfaz. Você também pode editar uma mensagem anterior e usar Discard & resend (descartar e reenviar) para testar outro prompt a partir daquele ponto. Veja Evoluir sem reconstruir.
• Knowledge. Em Configurações do projeto → Knowledge ficam as notas permanentes que o agente segue em cada mensagem.
• /test faz o agente clicar pelo preview como um usuário faria, depois de uma mudança grande.

Pedidos menores também gastam menos créditos. Para escrever os próprios prompts, veja como escrever prompts para construtores de apps com IA; quando algo quebrar de fato, veja como depurar um app criado com IA.

Perguntas