Prompts para Lovable: como pedir telas, correções e mudanças sem refazer o app inteiro

Fala aí, beleza? Se você cria app no Lovable sem ser dev, provavelmente já passou por isso: pede "melhora essa tela", o app volta diferente, alguma coisa quebra e lá vai você pedindo de novo 😛

E no Lovable esse vai e volta custa caro

Um único saldo de créditos paga a construção do app, o chat com o Lovable, a hospedagem e o backend integrado (Cloud), além dos recursos de IA do app publicado. Isso está na documentação de créditos e uso

Ou seja: cada pedido mal formulado sai do mesmo bolo que mantém teu app no ar

Neste guia eu trago modelos de prompt por etapa (primeiro pedido, nova tela, ajuste visual, bug e backend) e o fluxo de planejar antes de editar

O foco aqui é o Lovable e o momento de construir o app

Por que prompt vago no Lovable gera retrabalho?

Porque o Lovable executa o que entendeu, e um pedido vago deixa espaço demais pra ele adivinhar

As boas práticas oficiais são bem diretas nisso: pedir cinco coisas numa mensagem só aumenta a chance de um resultado parcial ou conflitante

O outro ponto é a especificidade

Em vez de "adicione um botão", o exemplo da própria documentação é algo como "um botão de CTA primário azul no canto superior direito da navegação, levando para /signup"

Se liga na diferença: o segundo pedido já diz o que é, onde fica, como parece e o que faz

Agora vem a parte que dói no bolso

No Build mode a cobrança varia conforme o trabalho realizado, e reverter para uma versão anterior não devolve os créditos gastos (as mensagens revertidas continuam contando)

Então um pedido errado sai caro duas vezes: você paga pra ele ser feito errado e paga de novo pra consertar

Antes de pedir: configure o Knowledge do projeto

O Knowledge é onde ficam as instruções que o Lovable segue em todo pedido, então vale escrever ali uma vez o que você ia repetir no chat toda hora

Pra abrir: clica no nome do projeto na barra superior e escolhe Settings, ou usa Cmd+. no Mac e Ctrl+. no Windows/Linux

Depois vai em Settings → Knowledge, dentro de Customization, conforme a página de configurações do projeto na documentação

Tem dois níveis aqui, e vale entender a diferença:

• Conhecimento do workspace: vale para todos os projetos daquele workspace (bom pra preferências gerais tuas)
• Conhecimento do projeto: vale só pra aquele app (produto, público, regras específicas)

A documentação recomenda descrever produto, público e preferências ali uma única vez

Modelo didático de texto para o Knowledge (é um ponto de partida, adapta pro teu caso):

Produto: app de agendamento para salões de beleza pequenos
Público: donos de salão sem conhecimento técnico, usando mais o celular
Idioma da interface: português do Brasil
Estilo: visual limpo, cores claras, botões grandes
Preferências: manter a navegação atual sempre que eu pedir uma tela nova
Regra geral: antes de mudar algo fora do que eu pedi, me pergunte

Erro comum: tratar o Knowledge como lixeira de ideias e jogar tudo ali

Como ele vale pra todo pedido, coloca só o que é verdade pro projeto inteiro

Modelos de prompt para Lovable por etapa

Todos os modelos abaixo seguem a estrutura que o guia oficial de prompting do Lovable recomenda: seções com rótulo Context, Task, Guidelines e Constraints

Se quiser mais ideias prontas depois, tem também uma lista de prompts Lovable para turbinar projetos aqui no blog

1. Primeiro pedido do app: comece no Plan mode

O primeiro pedido é o que define a base de tudo, então não manda direto pro Build

No Plan mode o Lovable não mexe no código e responde com perguntas de acompanhamento pra preencher as lacunas antes de escrever qualquer coisa

Modelo didático:

Context:
Quero um app de agendamento para salões de beleza pequenos
O público é dono de salão, sem conhecimento técnico, usando mais o celular

Task:
Monte um plano para a primeira versão com três telas:
/ (página inicial), /agenda (lista de horários do dia) e /novo-agendamento (formulário)

Guidelines:
Interface em português do Brasil
Visual limpo e botões grandes para uso no celular

Constraints:
Não inclua login, pagamento nem notificações nesta versão
Me faça as perguntas que precisar antes de propor o plano

Erro comum deste passo: empilhar login, pagamento, painel admin e notificações no primeiro pedido

É exatamente o caso das cinco coisas numa mensagem que a documentação avisa que tende a dar resultado parcial ou conflitante

Como conferir: responde as perguntas de acompanhamento e lê o plano antes de aprovar (falo mais disso lá embaixo)

2. Nova tela: cite a rota e o comportamento esperado

Pra tela nova, a regra é dizer a página exata e o que ela precisa fazer

Modelo didático:

Context:
O app já tem as telas / e /agenda funcionando

Task:
Crie a tela /clientes com a lista de clientes cadastrados
Cada item mostra nome e telefone
Ao clicar num cliente, abre /clientes/detalhe com os dados dele

Guidelines:
Use o mesmo estilo visual da tela /agenda

Constraints:
Não altere as telas / e /agenda
Não mude a navegação, só adicione o link para /clientes

Erro comum deste passo: pedir "uma tela de clientes" sem rota nem comportamento

Aí o Lovable escolhe onde colocar, como navegar e o que mostrar, e você paga pra desfazer o que ele escolheu

Como conferir: abre a rota /clientes no app, clica num item e vê se cai em /clientes/detalhe

E confere no History se apareceu a versão nova

3. Ajuste visual pontual: Visual Edits primeiro

Trocar texto, cor, imagem ou mexer no layout de forma pontual? Usa o Visual Edits

Segundo a documentação de design do Lovable, ele é um editor visual sem código pra essas mudanças rápidas e é gratuito, sem gastar créditos, dentro do limite diário de edições

Prompt só entra quando o ajuste visual envolve lógica, tipo "esse botão só aparece se…"

Modelo didático pra esse caso:

Context:
Na tela /agenda existe o botão "Cancelar horário"

Task:
Mostre esse botão só nos horários que ainda não passaram
Nos horários passados, mostre o texto "Concluído" em cinza no lugar do botão

Constraints:
Não altere o layout da lista nem as outras telas

Erro comum deste passo: gastar prompt pra trocar a cor de um botão quando o Visual Edits resolveria sem crédito

Ah, e se teu fluxo começa com um design feito fora do Lovable, a lógica de pedir mudança em cima de algo pronto é parecida com a de abrir um design no Claude: você parte do que existe e pede só o delta

Como conferir: olha a tela /agenda com um horário passado e um futuro

4. Correção de bug a partir da mensagem de erro

Quando aparece um erro, o Lovable mostra o botão ‘Try to fix’

O fluxo rápido que a documentação de depuração recomenda é usar ele uma ou duas vezes: o Lovable lê os logs, encontra o problema e tenta corrigir

Se liga no limite: a conta tem 10 correções gratuitas, compartilhadas entre o ‘Try to fix’ de erros de build e as correções da tela Security, em todos os workspaces e projetos

Cada uma volta a ficar disponível 24 horas depois de usada

Depois das 10, o ‘Try to fix’ continua funcionando, mas conta como uso normal de build e consome créditos

Não resolveu em uma ou duas tentativas? Aí para de clicar e escreve um prompt focado, colando o erro e anexando captura de tela (a documentação recomenda screenshot principalmente pra bug e problema de UX)

Modelo didático:

Context:
Na tela /novo-agendamento, ao clicar em "Salvar", aparece este erro:
Mensagem de erro: (cole o texto exatamente como aparece)
Anexei uma captura de tela do momento do erro

Task:
Encontre a causa desse erro e corrija só o salvamento do agendamento

Guidelines:
Antes de corrigir, explique em poucas linhas qual é a causa

Constraints:
Não altere outras telas
Não mude o visual do formulário

Erro comum deste passo: ficar no loop de ‘Try to fix’ sem parar pra entender o erro

Além de queimar as correções gratuitas, depois delas cada clique vira consumo de crédito

Como conferir: repete exatamente a ação que dava erro (no exemplo, salvar um agendamento) e vê se passa

5. Integração com backend: planeje antes de conectar

Backend é onde um pedido mal pensado mais bagunça o app, então essa etapa começa no Plan mode, sempre

O passo a passo de conexão e configuração do Cloud não entra aqui de propósito: segue a documentação oficial do Lovable pra isso, porque é ali que fica atualizado

O que dá pra fazer com segurança é usar o Plan mode pra decidir o que vai ser salvo, por quem e onde, antes de qualquer código

Modelo didático:

Context:
Hoje os agendamentos do app ficam só na tela e somem quando a página recarrega

Task:
Monte um plano para salvar os agendamentos de forma permanente
Liste quais dados precisam ser guardados e quais telas mudam

Guidelines:
Explique o plano em linguagem simples, sou iniciante

Constraints:
Não altere o visual das telas
Não implemente nada ainda, quero só o plano

Erro comum deste passo: misturar a integração com ajuste visual e tela nova no mesmo pedido

Um assunto por prompt, lembra?

Como conferir: lê o plano, ajusta o que precisar e só depois aprova

Como pedir uma mudança cirúrgica sem o Lovable reescrever o app

A mudança cirúrgica sai de três coisas juntas: um assunto por prompt, a página exata e uma Constraint dizendo o que NÃO pode ser tocado

O próprio guia oficial dá o exemplo de restrição: "não altere o código da página de login"

Modelo didático de prompt cirúrgico:

Context:
Na tela /agenda, a data aparece no formato 2026-10-16

Task:
Mostre a data no formato dia/mês/ano, só nessa tela

Constraints:
Não altere o código da página de login
Não altere nenhuma outra tela
Não mude o layout da lista

Depois de mandar, confere no painel History

Segundo a documentação de histórico, cada mudança feita pelo Lovable cria uma versão automaticamente

O passo a passo pra checar:

1. Abre o painel History pelo botão History na barra superior do editor ou pelo menu ao lado do campo de mensagem
2. Abre a versão nova em modo de visualização e confere se só o que você pediu mudou
3. Se ficou bom, usa ‘Back to latest’ pra voltar pra versão mais recente
4. Se ficou ruim, restaura a versão anterior

Tome cuidado com dois erros aqui:

• Achar que reverter devolve créditos: não devolve, as mensagens revertidas continuam contando
• Deixar pra restaurar muito tempo depois: versões muito antigas podem ser abertas e visualizadas, mas não restauradas, e aparece a mensagem ‘Cannot revert this far back in history’

Então se algo saiu errado, resolve logo, não espera acumular 20 mudanças por cima haha

Plan mode, Chat mode ou Build mode: quando usar cada um?

Resposta curta: Chat pra perguntar, Plan pra decidir, Build pra executar

Os três modos ficam no seletor do chat do projeto, dá pra trocar entre eles a qualquer momento e a conversa continua nos três

Chat mode: pra entender sem mexer em nada

O Chat mode lê o código, os arquivos e os dados do projeto aberto, responde perguntas e nunca altera nada no código nem nos dados

É o modo pra perguntar "por que essa tela faz isso?" ou "onde fica tal coisa?"

Na cobrança, uma mensagem é cobrada conforme o trabalho necessário, normalmente uma fração de crédito

E aqui entra a ordem de consumo dentro daquele saldo de créditos: nos workspaces Free, Pro e Business tem uma cota diária de chat, que é usada primeiro, depois os créditos diários de build e só por último os créditos gerais, sempre pelo mesmo preço por mensagem

Essa cota diária pertence ao workspace, renova todo dia às 00:00 UTC e não acumula

Detalhe importante: esse preço do chat, incluindo a cota diária gratuita, é um modelo temporário que vale até 31 de outubro de 2026, segundo o anúncio do Lovable

Plan mode: pra decidir antes de construir

O Plan mode serve pra investigar e planejar sem mexer no código: pensar uma funcionalidade maior, depurar um problema com segurança ou comparar abordagens

Cada mensagem custa 1 crédito, mais o custo da pesquisa feita por subagentes durante o planejamento

O massa aqui é a tela do plano: você edita o plano direto em markdown (acrescenta restrições, tira etapas, reescreve trechos) e depois aprova

Ao aprovar, o Lovable muda pro Build mode e implementa seguindo estritamente o plano aprovado

E a versão aprovada mais recente fica salva em .lovable/plan.md

Build mode: pra executar o que já está decidido

No Build mode, o Lovable implementa e verifica as mudanças direto no projeto

A cobrança é conforme o trabalho realizado, e muitos pedidos custam menos de 1 crédito

Os planos Free, Pro e Business incluem 5 créditos diários de build, que renovam às 00:00 UTC e não acumulam Se liga no detalhe do Free: lá esses créditos diários têm um teto de 30 por mês, então eles não somam 5 em todos os dias do mês, o teto mensal chega antes

Modelo de prompt pra revisar o plano antes de aprovar

Antes de clicar em aprovar, vale uma rodada de revisão no próprio Plan mode

Modelo didático:

Context:
Este é o plano que você propôs para a tela /clientes

Task:
Revise o plano e me diga quais etapas mexem em telas que já existem

Guidelines:
Responda em lista curta, em linguagem simples

Constraints:
Não implemente nada
Se alguma etapa alterar /agenda ou a página de login, marque como risco

Depois disso, edita o plano em markdown, tira o que for risco e só então aprova

Estratégia para não gastar créditos à toa no Lovable

Esse assunto eu já tratei num vídeo, e a ideia central dele casa direitinho com o fluxo deste guia

No vídeo eu mostro que o problema mais comum é ficar debatendo repetidamente com a IA sem encontrar solução, gastando crédito em cada tentativa

Isso é o loop de Build que a gente viu nos passos de bug e de mudança cirúrgica

A minha recomendação lá é usar o modo chat em vez de tentar resolver direto no código

No vídeo eu explico que, nesse modo, a IA pensa e analisa o projeto antes de aplicar a solução, em vez de tentar resolver "na marra"

E é por isso que eu falo que essa estratégia faz você economizar crédito

Trazendo pro guia: primeiro conversa (Chat mode) ou planeja (Plan mode), depois edita (Build mode)

Hoje o Lovable separa Chat mode e Plan mode, e os preços, cotas e regras de cobrança que valem são os da documentação que citei acima

Próximo passo: monte seu primeiro pedido no Plan mode

Bora pra prática? Faz esse roteiro uma vez e você já sente a diferença 🙂

1. Abre as configurações do projeto (Cmd+. ou Ctrl+.), vai em Settings → Knowledge e preenche produto, público e preferências
2. Troca pro Plan mode no seletor do chat e manda o modelo de primeiro pedido, adaptado pro teu app
3. Responde as perguntas de acompanhamento
4. Na tela do plano, edita o markdown e acrescenta pelo menos uma restrição tua (tipo "não altere a página de login")
5. Aprova e deixa o Lovable implementar no Build mode
6. Abre o History e confere a versão nova em modo de visualização

Se tudo bateu com o plano, você tem o fluxo na mão pra todo pedido daqui pra frente

E se quiser mais ideias prontas pra lapidar teus pedidos, aquela lista de prompts Lovable que linkei lá em cima é o próximo degrau

Até o próximo post! 😀

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.