Como escrever prompts para AI App Builders (com exemplos de antes e depois)

Observe duas pessoas usando o mesmo AI app builder por uma hora. Uma tem um app funcionando; a outra tem uma bagunça e a opinião de que "codar com IA é superestimado". A ferramenta era idêntica. Os prompts, não.

Escrever prompts para um app builder é uma habilidade diferente de conversar com um chatbot. Você não está fazendo perguntas — está dando ordens de serviço a um agente que vai tomar dezenas de decisões com base no que você disse e no que deixou de dizer. Aqui está o que realmente funciona, com exemplos de antes e depois ao longo do texto.

O primeiro prompt: antecipe decisões, pule a implementação

Seu prompt de abertura define a fundação do projeto. O agente preenche cada lacuna que você deixa com um palpite, e embora bons agentes chutem com sensatez, todo palpite é um cara ou coroa quanto a acertar a sua intenção.

Antes:

Faça um app de fitness para mim.

Depois:

Construa um rastreador de treinos para quem faz musculação. Dados: treinos têm uma data; cada treino tem registros com nome do exercício, séries, repetições e carga. Telas: (1) registro de hoje com entrada rápida, (2) histórico agrupado por semana, (3) gráfico de progresso por exercício. Um usuário só, sem necessidade de login. Design escuro e minimalista.

A versão "depois" decide o público, o modelo de dados, as telas, o escopo de autenticação e a direção visual — as cinco decisões caras de mudar depois. Note o que ela não inclui: nada de stack de tecnologia, nada de escolha de banco de dados, nada de bibliotecas de componentes. Uma boa plataforma toma essas decisões melhor do que um prompt tomaria, e entulhar seu briefing com termos técnicos meio entendidos atrapalha ativamente ("use MongoDB" quando a plataforma é construída em torno de Postgres só cria atrito).

Uma estrutura que funciona consistentemente:

1. O que é, em uma frase, com o público.
2. Os dados, como substantivos e campos simples.
3. As telas, numeradas.
4. Exclusões explícitas — "sem login", "sem pagamentos". Exclusões evitam escopo que o agente inventaria de forma prestativa.

Prompts de iteração: uma mudança, ancorada a um lugar

Depois do primeiro build, seus prompts mudam de natureza: de arquitetura para cirurgia. Duas regras fazem a maior parte do trabalho.

Uma mudança por mensagem. Pedidos empacotados falham em bloco — quando uma das cinco mudanças sai errada, você fica re-prompteando em volta das outras quatro.

Ancore cada mudança a um local.

Antes:

As datas estão estranhas.

Depois:

Na página de histórico, os cabeçalhos de semana mostram "Semana 32". Mostre um intervalo de datas no lugar, como "4 ago – 10 ago".

Nomeie a tela, cite o texto errado, descreva o texto certo. O agente encontra o ponto exato em vez de caçar — menos palpites errados, menos créditos.

Descreva resultados, não implementações

Você vai sentir a tentação de falar como um desenvolvedor. Resista, a menos que você seja um.

Antes:

Adicione um useEffect que refaz o fetch ao montar e memoize a renderização da lista.

Depois:

Quando eu volto para o dashboard depois de adicionar uma despesa, o total ainda mostra o número antigo até eu atualizar a página. Ele deveria estar atualizado.

A primeira versão compromete o agente com o seu diagnóstico, que pode estar errado. A segunda entrega o defeito real — a coisa da qual você tem certeza — e deixa o agente encontrar a causa. Descreva sintomas com a confiança de um usuário; deixe os diagnósticos para quem consegue ler o código.

Use referências — elas vencem adjetivos

"Moderno e limpo" não significa nada; todo design desde 2010 se descreve assim. Referências carregam ordens de magnitude mais informação:

Faça a seção de preços parecer com a página de preços do Linear: bastante espaço em branco, bordas finas, uma cor de destaque.

Melhor ainda, anexe uma captura de tela — de um app que você gosta, de um rascunho à mão, do layout quebrado exato que você está descrevendo. Plataformas que aceitam anexos de imagem (a Massvai aceita) resolvem ambiguidade visual a partir de uma imagem muito mais rápido do que a partir de prosa. Uma captura de tela do bug com uma legenda de uma linha é o formato de prompt de maior valor que existe.

Quando dá errado: pare de cavar

O erro de prompt mais caro não é um prompt ruim — é a quarta tentativa consecutiva de remendar uma direção fundamentalmente errada.

Se duas tentativas da mesma correção não funcionaram, mude de estratégia:

• Reverta. Restaure o checkpoint anterior à bagunça (a Massvai fotografa cada geração) e reaborde com uma descrição diferente. Voltar atrás parece uma derrota; costuma ser o caminho mais rápido para frente.
• Afaste o zoom. Em vez de re-descrever a correção, descreva o objetivo: "Esqueça as instruções anteriores sobre o dropdown de filtro. É isto que eu quero permitir que os usuários façam: …" Agentes lidam melhor com objetivos frescos do que com instruções de remendo acumuladas.

Uma cola rápida

Nada disso é exótico. É a mesma clareza que você deveria a um prestador de serviço humano — só que este prestador lê com atenção, nunca se irrita com detalhes e começa a trabalhar em segundos. Entregue a ele um briefing à altura.