7 regras para prompts no Lovable que não quebram o projeto

Tenho usado o Lovable para construir o lowcode.ai inteiro: o blog, o painel, a rotina que monta as imagens do Instagram e o conector que deixa o Claude agendar posts. Nos últimos dias de ajustes, os mesmos erros de pedido apareceram várias vezes, e cada um custou uma mensagem extra e créditos do plano. Este texto reúne sete regras que passei a seguir. Cada uma vem com uma situação real do projeto e um prompt que você pode adaptar.

As regras valem para qualquer projeto no Lovable com banco no Supabase, e rendem mais conforme o app cresce. Num site de uma página, um prompt vago costuma funcionar. Num projeto com funções agendadas, rotas protegidas e dados em produção, ele altera coisas que você só percebe dias depois.

Regra 1: peça para ler o código antes de opinar

Quando um post do blog não saiu junto com o do Instagram, minha primeira reação foi montar hipóteses sobre a causa. A resposta útil veio de pedir que lessem o projeto e dissessem como o fluxo era montado. A geração do blog roda numa função separada, disparada pela função do Instagram, e depende de uma opção ligada no painel. A busca ficou reduzida a dois lugares: a opção e os logs da função.

O Lovable tem o modo plano, em que o agente discute e planeja sem editar código. É o modo certo para perguntas de diagnóstico, porque o pior resultado possível é uma resposta errada, sem nenhum arquivo alterado.

Antes de alterar qualquer coisa, leia o código que gera o post do blog junto com o post do Instagram. Me diga por quais arquivos o fluxo passa, onde ele pode falhar sem avisar e o que eu preciso conferir no painel. Não edite nada nesta mensagem.

Para o lado da investigação, o texto Como debugar um app que a IA escreveu e você não entende complementa esta regra.

Regra 2: um objetivo por mensagem e um critério que o agente consiga testar

Cada mensagem consome créditos, então uma mensagem que precisa ser refeita custa duas vezes. O critério de aceite evita a refação. Em vez de pedir "melhore o prompt das capas", peço que o agente mostre o prompt final que a função monta para duas categorias e liste os arquivos alterados. Na última rodada, o agente escreveu um pequeno script de verificação, comparou as cópias do texto e devolveu o resultado impresso. Eu li o prompt antes de qualquer imagem ser gerada.

Misturar pedidos produz o efeito oposto. Se uma única mensagem troca o logo, muda o prompt de imagem e mexe no calendário, você não sabe qual das três mudanças causou o problema que aparecer.

Objetivo: trocar o logo usado nas imagens do Instagram.
Ao terminar: gere uma capa e um slide de exemplo, confira o contraste sobre fundo claro e escuro e liste os arquivos alterados.

Regra 3: cole o texto exato quando o texto importa e cite os arquivos

"Deixe as capas mais impactantes" gera um texto diferente a cada tentativa. Quando o que muda é um trecho de prompt, uma constante ou uma mensagem de erro, escrevo o texto e peço a substituição literal, citando o arquivo. No caso das capas do blog, o texto novo ficou idêntico em duas cópias do projeto, e o agente confirmou a igualdade num teste.

A mesma lógica vale para nomes. Dizer "o arquivo que desenha a capa" obriga o agente a procurar. Dizer src/lib/instagramCoverServer.ts leva direto ao ponto. Se você não sabe o nome, peça primeiro que ele liste os candidatos (regra 1) e só depois mande a alteração.

Troque o valor de DEFAULT_BLOG_IMAGE_STYLE em supabase/functions/_shared/blog-automation-defaults.ts e em src/lib/blogAutomationDefaults.ts por este texto, sem alterar mais nada:
"Editorial cover photograph for a tech news site, 16:9 landscape..."

Regra 4: diga o que não pode mudar

O logo novo existia no projeto com mais de um nome de arquivo, e a barra de navegação do site usa outro arquivo. Pedi a troca somente nas imagens do Instagram e deixei três proibições na mensagem: não mexer no logo do site, não apagar os arquivos antigos e não mexer no banco. Sem essas frases, um agente bem-intencionado pode "limpar" arquivos que parecem sobrando ou trocar um arquivo compartilhado e mudar o cabeçalho do site inteiro.

As proibições valem também para dados. "Não mexa no banco" é uma linha curta e evita migrations que ninguém pediu.

Use esse arquivo só nas imagens do Instagram. Não mexa no logo do site (Navbar, Footer), não apague os arquivos de logo antigos e não altere o banco de dados.

Regra 5: antes de trocar um padrão, peça a lista de todos os lugares onde ele aparece

O azul das capas do blog estava escrito em mais de um lugar: na automação de notícias, no conector que agenda posts e na geração manual, com o prompt padrão do painel. Na primeira rodada corrigi dois caminhos. O terceiro só apareceu quando abri a tela de configuração e li "vibrant colors blue teal" no template. Custou uma segunda rodada.

A busca do agente tinha seguido o nome de uma função, e o caminho manual usa outra. Peça a busca pelo conceito, não pelo nome.

Antes de mudar, procure no projeto inteiro (código do site e funções) tudo que monta um prompt de imagem de capa, mesmo com outro nome de função ou com o texto repetido em outro arquivo. Liste os caminhos encontrados antes de alterar qualquer um.

Regra 6: dados em produção ficam com você

Dois episódios mostram o limite. No primeiro, o conector que agenda posts gravou um valor que a tabela rejeitou por uma regra de validação do banco, uma constraint. A correção foi uma migration, que li antes de aplicar. No segundo, precisei refazer as imagens dos carrosséis já agendados depois da troca do logo. Em vez de pedir ao agente que mexesse nos dados, recebi o SQL pronto, com um filtro restrito a posts agendados no futuro, li linha por linha e rodei eu mesmo no editor SQL do Supabase.

O padrão é este: o agente propõe, você lê, você executa. Um UPDATE sem WHERE é o acidente clássico, e ler o filtro leva poucos segundos. Antes de qualquer app ir ao ar, passe também pelo checklist de segurança do Lovable com Supabase.

Não altere dados. Escreva o SQL que marca para nova montagem apenas os posts com status agendado e data futura, explique cada condição do WHERE e me mostre antes de eu executar.

Regra 7: código salvo ainda não é código publicado

Terminada a troca do logo, o agente avisou que faltava publicar. A rotina que renderiza as imagens do Instagram roda no site publicado, então o código novo só passa a valer depois da publicação. A ordem importa: se você marca posts para refazer a montagem antes de publicar, o agendador usa o código antigo e consome a marcação. Primeiro publique, depois mexa nos dados. Para entender por que essa rotina fica no servidor e não no navegador, leia Navegador ou servidor: onde gerar as imagens da sua automação.

O teste final é olhar o resultado. Abro uma imagem renderizada e confiro se o logo é o novo. O status "pronta" diz que a montagem terminou, e não diz que o resultado está certo.

Ao terminar, me diga se a mudança precisa de publicação para valer, quais partes rodam no ambiente publicado e qual a ordem segura entre publicar e alterar dados.

Um modelo que junta as sete regras

Quando a mudança é maior que um ajuste, uso este esqueleto. Preencho só os campos que se aplicam e apago o resto.

Objetivo: [uma frase com o resultado esperado].
Antes de editar: leia [arquivos] e liste todos os lugares onde [padrão] aparece.
Texto exato: [cole aqui o trecho que deve entrar, se houver].
Não mexer: [site, banco, arquivos antigos].
Dados: não altere o banco; se precisar de SQL, me mostre antes.
Ao terminar: mostre [resultado verificável], liste os arquivos alterados e diga se precisa publicar.

O esqueleto parece longo para uma mudança de cor. Para mudanças pequenas, as linhas "Objetivo" e "Não mexer" já bastam. Ele existe para os pedidos que tocam em mais de um arquivo ou em dados.

Erros comuns ao aplicar as regras

O primeiro é transformar o modelo num texto de duas páginas. Prompt longo esconde a instrução principal, e o agente tende a obedecer mais ao que aparece no começo e no fim. Mantenha cada campo em uma ou duas linhas.

O segundo é aceitar "feito" sem evidência. A resposta do agente descreve o que ele pretendia fazer. O critério de aceite da regra 2 existe para trocar a descrição por uma prova: um teste impresso, uma lista de arquivos, uma imagem de amostra.

O terceiro é deixar a decisão só na conversa. Nas últimas rodadas, o agente registrou cada regra nova no AGENTS.md e no roadmap.md do projeto, e isso evita repetir a mesma instrução depois. Peça o registro sempre que uma decisão for valer daqui para frente.

O que fazer agora

1. Escolha uma mudança pendente no seu projeto e escreva-a como um único objetivo, com um critério de aceite que o agente consiga mostrar.
2. Use o modo plano para pedir a lista de arquivos e de lugares envolvidos, sem editar nada.
3. Cole o texto exato que deve entrar e cite os arquivos pelo nome.
4. Escreva as proibições: o que não muda, o que não se apaga e que o banco fica de fora.
5. Se houver dados a alterar, peça o SQL, leia o filtro e rode você mesmo.
6. Publique, abra uma amostra visual do resultado e só então dê a mudança por concluída.
7. Para ver essas regras dentro de uma automação completa, leia Carrossel automático no Instagram com Claude, GPT-Image e Make.