"\"Parece uma pintura com 3 estilos diferentes\": por que o app gerado fica remendado e o que fazer antes do remendo 4"

"Eu simplesmente não consigo, parece que fica algo remendado, como se fosse uma pintura com 3 estilos diferentes."

E logo depois, na mesma conversa num fórum brasileiro:

"As vezes eu também penso que o problema sou."

Já expliquei aqui de onde vêm os três estilos: cada conversa com a IA começa do zero, e as regras que moram só na sua cabeça não chegam na próxima. O conserto pra isso é um arquivo de regras que ela lê sempre, e se você ainda não tem, o lugar de pôr fica aqui.

Só que esse arquivo tem um limite que ninguém fala. Ele impede o quarto estilo. Ele não apaga os três que já estão na parede.

Não, o problema não é você

Repare no que a pessoa do fórum fez: ela olhou o próprio app e viu que estava remendado. Isso não é sinal de incompetência. É olho. Muita gente com app remendado não enxerga.

A causa é mais simples. Quando você pede "uma tela de agendamento", a IA cria uma. Não tem nada no pedido que diga "igual à de clientes", então ela inventa um jeito: outro botão, outra mensagem de erro, outro formato de data. A documentação do Claude Code, a ferramenta de programar da Anthropic, dá um exemplo desse problema na própria página de boas práticas. O pedido ruim é "adicione um widget de calendário". O bom é "veja como os widgets que já existem foram feitos na página inicial, use aquele como exemplo e siga o padrão".

Leia de novo: o fabricante precisa ensinar a dizer "siga o que já existe". Porque, se ninguém disser, a IA não segue.

E o Lovable, um dos geradores que mais aparecem nos relatos de quem não programa, oferece em todos os planos pagos um recurso chamado design systems: um projeto que serve, nas palavras da documentação, de "fonte da verdade" pros componentes e estilos, definidos uma vez. Ótimo que exista. Mas diz muito: consistência é um recurso que você precisa ligar e alimentar, não algo que vem de fábrica.

O inimigo não é a IA. É o conselho que vem depois

Quando o app fica remendado, os dois conselhos que mais aparecem são: "refaz do zero" ou "aprende a programar e faz direito". Nenhum dos dois diz o que é "direito". Um joga fora o que funciona (e é o conselho mais caro que existe), o outro te manda embora.

Na mesma conversa do fórum, alguém respondeu melhor: "Você terá de abrir, revisar, criticar... É quase uma troca." É isso. Só que ninguém diz o que abrir, nem o que criticar. Então, aqui vai.

Antes do remendo 4: inventário e tela-modelo

Vinte minutos, sem mexer em nada do código.

1. Peça o inventário. No modo que conversa sem alterar código (no Lovable, o Plan mode):

"Sem alterar nada, faça um inventário do app. Para cada item abaixo, diga quantos jeitos diferentes existem e em quais telas aparece cada jeito: botão principal; mensagem de erro; mensagem de sucesso; formato de data; formato de dinheiro; formulário de cadastro; jeito de confirmar antes de apagar."

O exemplo de resposta é inventado, mas o formato costuma ser assim: "datas: 3 jeitos. dd/mm/aaaa em Clientes, 2026-10-20 em Agendamentos, '20 de out.' no Painel". Aí está a sua pintura, item por item.

2. Escolha a tela-modelo. Abra o app e ache a tela que você mais gosta, a que parece "o meu app". Essa vira a referência. Normalmente é a mais antiga, a que você conferiu com mais calma.

3. Decida cada item. Você, não a IA. Pra cada linha do inventário, escreva qual jeito ganha. Quase sempre é o da tela-modelo. Isso é decisão de dono: a IA vai sugerir o mais "moderno", e você quer o que o seu cliente já conhece.

4. Escreva a regra por exemplo, não por descrição. No seu arquivo de regras, em vez de descrever o botão ("azul, arredondado, com sombra"), aponte pra tela:

PADRÃO DO APP
- Todo formulário segue a tela Clientes.
- Data sempre como em Clientes: 20/10/2026.
- Dinheiro sempre como em Clientes: R$ 1.234,56.
- Antes de criar um jeito novo de qualquer coisa
  desta lista, me pergunte.

A última linha é a que mais segura. Ela transforma "a IA inventou" em "a IA perguntou".

5. Unifique um item por pedido. Não peça "padronize o app inteiro". Peça "deixe todas as datas no formato da tela Clientes, sem mudar mais nada". Uma mudança por vez, e depois de cada uma, o teste de 5 cliques, porque mexer em formato de data em sete telas é exatamente o tipo de pedido que quebra outra coisa.

Sete itens, sete pedidos, uma semana leve. No fim, a parede tem um estilo, e o arquivo de regras impede que volte a ter três.

O que isso não resolve

O inventário pega o que aparece na tela. A bagunça que não aparece, três jeitos diferentes de guardar o mesmo dado no banco, por exemplo, é mais funda e mais perigosa, porque não dá pra ver olhando. Essa pede outro tipo de conferência, a das peças que se puxam por dentro.

Era uma parede de várias

Remendo é sintoma de app vivo: o primeiro mês foi fácil porque tudo era novo, e o segundo é onde a manutenção aparece. Unificar o visual é uma parede. Do lado dela estão o dado velho que não encaixa na regra nova, o serviço externo que muda sem avisar e o backup que nunca foi restaurado. Cada uma tem o seu jeito de resolver, e a ordem entre elas é o que faz o app ficar de pé no mês seis.

A pessoa do fórum achou que o problema era ela. O problema era não ter ninguém dizendo "começa pelo inventário".

Fontes

• Relatos "parece uma pintura com 3 estilos diferentes", "as vezes eu também penso que o problema sou" e "você terá de abrir, revisar, criticar", TabNews (registrados na pesquisa do blog, pesquisa/03-swipe-file-verbatim.md; relatos, não estatística)
• Claude Code Docs, "Best practices for Claude Code" (seção "Reference existing patterns": apontar um exemplo que já existe e pedir pra seguir o padrão): https://code.claude.com/docs/en/best-practices
• Lovable Docs, "Design systems" (disponível nos planos pagos; projeto que serve de "source of truth" pra componentes e estilos): https://docs.lovable.dev/features/design-systems