← blog/lovable-fonte-de-verdadeEN
    // blog/lovable-fonte-de-verdade.md

    Por que não usamos o Lovable como fonte de verdade

    A IA gera o andaime em minutos. Mas quem é o dono do código depois? A resposta define seu fluxo inteiro.

    2026-05-11·7 min de leitura·build in public·POSTEP Digital

    Lovable = andaime · Git = casa · Uma fonte de verdade por projeto · Na segunda mão, escolha o git

    // 01

    O que o Lovable faz muito bem

    O Lovable transforma um prompt em um app React de verdade. Você descreve a tela, ele gera os componentes, sobe um preview ao vivo e empurra o código pra um repositório no GitHub. Em minutos você sai do zero pra uma interface funcionando — com Tailwind, shadcn/ui e tudo conectado.

    Pra prototipar, é difícil bater. A maior parte dos nossos dashboards e landings nasceu de um scaffold do Lovable. Ele resolve a página em branco, que é o problema mais caro no começo de qualquer projeto.

    O problema não é o que o Lovable gera. É o que acontece depois — quando o projeto cresce e o Lovable continua sendo o dono do código.

    // 02

    Fonte de verdade: quem é o dono do código

    Todo projeto tem uma fonte de verdade: o lugar canônico onde o código vive e a partir do qual tudo é construído. Pode ser o seu repositório git local. Pode ser o Lovable. O que não pode é ser os dois ao mesmo tempo.

    // dois modelos de quem manda no código
    Lovable como fonte
    ·edição pela UI do Lovable
    ·auto-commit no GitHub sem aviso
    ·preview ao vivo é a verdade
    ·ótimo enquanto UMA pessoa edita
    ·trava quando você precisa de pipeline
    Git local como fonte
    edição no editor + Claude Code
    commits explícitos, você revisa
    build determinístico do dist/
    deploy próprio (SFTP, CI, o que for)
    monorepo, branches, histórico real

    A pergunta não é “Lovable é bom?”. É “quem é o dono do código quando duas mãos diferentes mexem nele?”.

    // 03

    Dois escritores, uma branch

    O atrito apareceu no nosso site institucional. Ele é bilíngue — cada página tem a versão PT e a versão EN num arquivo espelho. Enquanto editávamos localmente via Claude Code, o Lovable também empurrava commits por conta própria, principalmente nos arquivos terminados em En.tsx.

    // o que acontecia no git
    você (local)
    edita BlogEn.tsx, commita, faz push
    Lovable (em paralelo)
    reescreve BlogEn.tsx e commita sozinho
    CONFLICT (add/add): BlogEn.tsx
    git checkout --ours + merge na unha

    Nenhuma ferramenta tava errada. O erro era ter duas fontes de verdade escrevendo na mesma branch sem se coordenar. Todo pull virava roleta.

    // 04

    A decisão: scaffold, não casa

    Resolvemos tratar o Lovable como o que ele é melhor: uma ferramenta de andaime. Ele te leva do nada até um app funcionando. Mas o lugar onde o código mora pra valer é o nosso git. Quando o projeto passa de protótipo a produto, a gente puxa pra local e desconecta o Lovable.

    gerar

    Lovable cria o scaffold a partir do prompt. Componentes, rotas, estilo base.

    puxar

    Clonamos o repo pra máquina. A partir daqui, git local é a fonte de verdade.

    construir

    Features, refactor e fixes acontecem no editor + Claude Code, com commits revisados.

    desconectar

    Lovable é desligado do repo. Sem auto-commit, sem branch fantasma, sem conflito.

    Foi exatamente isso que fizemos ao consolidar os projetos da agência num monorepo único: desconectamos o Lovable, e um git push passou a cobrir tudo. Os repositórios antigos do Lovable viraram arquivo — histórico preservado, mas read-only.

    // 05

    Quando o Lovable PODE ser a fonte

    Isso não é “Lovable nunca”. A regra é mais simples: uma fonte de verdade por projeto. O critério é quantas mãos editam o código.

    uma mão, sempre via Lovabledashboard que só uma pessoa ajusta pela UI, nunca no editor → Lovable como fonte é perfeito, deixa lá
    duas mãos, ou pipeline próprioqualquer edição local, deploy customizado, monorepo, code review → git é a fonte, desconecta o Lovable
    produto que vai escalarSaaS multi-tenant, billing, migrations → precisa de build determinístico e controle total → git, sem discussão

    O problema nunca foi a qualidade do código gerado. Foi a ambiguidade de quem manda. No segundo escritor, escolha o git.

    // 06

    A regra prática

    no início

    Use o Lovable sem culpa pra sair da página em branco. Scaffold em minutos é vantagem real, não atalho preguiçoso.

    ao virar projeto

    Decida a fonte de verdade ANTES de começar a editar localmente. Essa escolha define seu fluxo de commit, deploy e review.

    se for editar local

    Desconecte o Lovable do repo no mesmo dia. Não deixe dois escritores na mesma branch “só por enquanto” — o conflito vem.

    sempre

    Uma fonte de verdade por projeto. Documente qual é. Quem entra no projeto precisa saber onde o código mora de verdade.

    // regra principal

    Ferramenta de IA é ótima pra gerar. Péssima pra ser dona. Deixe o Lovable construir o andaime e deixe o git ser a casa. No dia em que a segunda mão tocar no código, a fonte de verdade é o seu repositório.

    escrito por
    POSTEP Digital
    ← ver todos os posts