Como Iterar uma App Criada com IA Sem a Estragar

Para iterar uma app criada com IA sem a estragar, mude uma coisa de cada vez, verifique-a na pré-visualização e guarde um ponto de controlo antes de avançar. Descreva o que vê em vez do que acha que o código faz, planeie as alterações grandes antes de as construir e, quando uma alteração correr mal, volte à última versão boa em vez de pedir à IA que corrija a sua própria correção.

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

O ciclo de iteração

1. Escolha uma alteração. Uma funcionalidade, um erro, uma página.
2. Descreva-a em termos do que o utilizador vê e faz.
3. Nas alterações grandes, planeie primeiro. Peça um plano, leia-o e só depois construa.
4. Verifique o resultado na pré-visualização — a alteração e os fluxos à volta dela.
5. Guarde um ponto de controlo ou um commit.
6. Repita.

Cada passo existe para manter as alterações pequenas e reversíveis.

Passo 1: Mantenha uma lista curta

Antes de dar instruções, escreva o que quer mudar, por ordem de importância. Isto impede-o de enviar um parágrafo com dez desejos numa só mensagem, e dá-lhe forma de dizer "agora não" às ideias que surgem a meio.

Se uma alteração for grande, divida-a. "Adicionar contas de equipa" passa a ser: criar equipas, convidar um membro, alternar entre equipas, limitar os dados à equipa atual. Cada uma é um prompt próprio. Escrever histórias de utilizador é uma boa forma de fazer isto.

Passo 2: Descreva o que vê

A IA não consegue ver o seu ecrã, a não ser que lho diga. Aponte coisas específicas e diga o que deve acontecer:

Na página de preços, num telemóvel, o botão do cartão Pro fica cortado na borda direita. Mantenha o layout de computador igual; em ecrãs abaixo de 640 px, empilhe os cartões e faça os botões ocupar toda a largura.

Compare isto com "a página de preços tem mau aspeto no telemóvel". A primeira pode ser feita e verificada de uma vez; a segunda convida a um redesenho que não pediu.

As capturas de ecrã ajudam. Se o seu construtor aceitar imagens, anexe uma e assinale o problema.

Passo 3: Planeie antes das grandes alterações

Para qualquer coisa que toque em várias partes da app — um novo modelo de dados, pagamentos, perfis de utilizador — peça um plano antes de qualquer código ser alterado:

Ainda não altere o código. Quero que os utilizadores pertençam a equipas e vejam apenas os projetos da sua equipa. Planeie a alteração: que tabelas, páginas e rotas da API mudam, o que acontece aos dados dos utilizadores existentes e por que ordem a construiria.

Leia o plano. Se estiver errado, corrigir um plano é muito mais barato do que desfazer uma construção.

Passo 4: Diga o que não pode mudar

As ferramentas de IA às vezes "arrumam" coisas sobre as quais não perguntou. Proteja o que funciona:

Acrescente um filtro de data na tabela de encomendas. Não altere as colunas da tabela, o estilo nem o botão de exportação.

Para regras que se aplicam em todo o lado — cores da marca, tom de voz, "nunca apagar dados sem confirmação" — coloque-as num ficheiro de notas do projeto ou numa definição de conhecimento que a IA lê sempre, em vez de as repetir.

Passo 5: Verifique mais do que a alteração

Depois de cada prompt, teste:

• A própria alteração. Faz o que pediu, em computador e em telemóvel?
• Os vizinhos. As coisas na mesma página e os fluxos que usam os mesmos dados.
• O caminho crítico. Registo, início de sessão, a ação principal, pagamento. Uma verificação de trinta segundos depois de cada alteração grande apanha a maioria das quebras logo no início.

Se algo não estiver bem, descreva-o com precisão — veja como escrever um bom relatório de erro.

Passo 6: Volte atrás em vez de acumular

Quando uma alteração parte algo e a primeira correção não resolve, pare. Cada "correção" extra assenta num estado partido, e os problemas acumulam-se.

Em vez disso:

1. Volte à última versão que funcionava (um ponto de controlo ou um commit do Git).
2. Perceba o que estava pouco claro no prompt.
3. Tente de novo com um pedido mais pequeno ou mais claro.

Essa alteração partiu a gravação de rascunhos. Já voltei atrás. Desta vez: acrescente apenas o indicador de gravação automática, como texto no cabeçalho. Não altere a forma como os rascunhos são guardados.

Passo 7: Saiba quando a recriação é a opção certa

Recriar do zero deita fora muitos detalhes que já funcionavam. Só compensa quando:

• A ideia do produto mudou por completo.
• A estrutura subjacente não suporta o que agora precisa — por exemplo, foi construída como site estático e agora precisa de contas e de uma base de dados.
• O projeto ainda está quase vazio.

Quando recriar, liste o que deve manter: nome, cores, texto, as partes de que os utilizadores gostavam.

Exemplos de prompts

Antes de continuarmos, resuma como a app funciona atualmente: páginas, dados que guarda e tudo o que considera frágil.

Quero acrescentar marcações recorrentes. Qual é a versão mais pequena que seria útil? Sugira-a como três alterações separadas que possamos fazer uma de cada vez.

Reveja as últimas três alterações e diga se alguma pode ter partido o fluxo de finalização de compra. Ainda não edite.

Erros comuns

• Dez pedidos num só prompt. Alguns ficam feitos, outros a meio, e não se percebe quais.
• Feedback vago. "Está partido" ou "melhore isto" produz adivinhações.
• Nunca verificar os vizinhos. Uma alteração num componente partilhado parte três outras páginas.
• Corrigir correções. Quatro prompts depois de um erro, volte atrás.
• Repetir o contexto sempre em vez de guardar as regras permanentes nas notas do projeto.
• Recriar quando está bloqueado. A maioria dos momentos de "recomeçar do zero" são, na verdade, "voltar dois passos atrás".

Lista de verificação

• Um objetivo por prompt.
• Descrevo o que vejo e o que deve acontecer.
• As grandes alterações têm um plano antes de qualquer código.
• Digo o que não pode mudar.
• Depois de cada alteração, testo-a, os vizinhos e o caminho crítico.
• Guardo um ponto de controlo ou um commit após cada alteração que funciona.
• Quando uma correção falha, volto atrás em vez de acumular correções.
• As regras permanentes estão nas notas do projeto que a IA lê sempre.

Iterar na Mythex

A Mythex assenta neste ciclo:

• Modos Plan, Build e Ask. Plan discute a abordagem antes de editar; Ask responde sem alterar o código; Build faz a alteração. Veja Chat.
• Pontos de controlo. Depois de cada turno bem-sucedido, a Mythex guarda um ponto de controlo do Git; Reverter para este ponto volta atrás. Também pode editar uma mensagem anterior e usar Descartar e reenviar para tentar outro prompt a partir desse ponto. Veja Iterar sem recriar.
• Conhecimento. Definições do projeto → Conhecimento guarda notas permanentes que o agente segue em cada mensagem.
• /test pede ao agente que clique na pré-visualização como um utilizador faria, depois de uma alteração grande.

Pedidos mais pequenos também gastam menos créditos. Para escrever os próprios prompts, veja como escrever prompts para construtores de apps com IA; quando algo partir, veja como depurar uma app criada com IA.

Perguntas