Como e por que vibe coding funciona (e onde ele te custa caro)

Num artigo anterior, eu falei que uma LLM "preenche gaps" — toma decisões técnicas de implementação por você quando o prompt não especifica. Quem tem expertise guia essas decisões e consegue resultados muito bons. Mas e quem não tem?

Afinal, o público-alvo de ferramentas de vibe coding (como a Lovable, onde "o código não importa") é não-programadores, que provavelmente não fazem ideia se React é de comer ou de passar no cabelo. (E que fique claro desde já: eu acho ótimo/incrível que isso seja possível!)

Uma hipótese plausível é que os engenheiros da Lovable, por exemplo, hardcodaram (fixaram) em uma espécie de "master prompt" várias dessas decisões técnicas, para que o usuário não precise tomar.

Aqui está um suposto master prompt da Lovable.

A legitimidade desse repositório não é confirmada, então, encare com um pé atrás. Mas o conteúdo é consistente com o comportamento observável da ferramenta. Por isso, para o restante do texto, vou usar como premissa que é legítimo. Sendo assim, isso reforça minha hipótese.

Então, olhando esse prompt com cuidado, dá pra ver o tamanho do que foi decidido por você:

• Frontend: só React + Vite + Tailwind + TypeScript. O prompt diz explicitamente que "it is not possible for Lovable to support other frameworks like Angular, Vue, Svelte, Next.js, native mobile apps, etc.". Se, por exemplo, você precisa migrar pra mobile nativo, o código gerado pela Lovable não serve.

• Backend: a Lovable não roda código de servidor. Nada de Python, Node.js, Ruby. A única opção é a integração nativa com Supabase. Isso significa que quando você pede "quero login com Google", a Lovable resolve via Supabase — e funciona! Mas e se o requisito evoluir pra uma API customizada? Integração com um sistema legado? Processamento pesado no servidor? Você está vendor-locked em Supabase sem nem saber o que isso significa.

• Usuário: o prompt assume explicitamente que "most lovable users are non-technical" e instrui a IA a nunca pedir que o usuário edite arquivos manualmente. Isso funciona enquanto tudo vai bem. Quando algo quebra de forma não-trivial, o usuário não tem vocabulário nem contexto pra diagnosticar — e a IA fica tentando resolver sozinha num ciclo de tentativa e erro.

Ou seja, o tradeoff é muito maior do que parece. Não são só "algumas decisões técnicas". É a stack inteira, o backend inteiro, e a premissa de que você não precisa (nem deve) entender o que está acontecendo por baixo.

Sei que existe a possibilidade de você baixar todo o código do projeto feito na Lovable e modificar você mesmo. Mas daí você já parte de um código legado escrito pela IA — e sabe-se lá a quantidade de débito técnico e caos que você vai encontrar.

Por isso que, hoje, acredito que, para desenvolvedores, ferramentas de desenvolvimento assistido por IA (Claude Code) e não de vibe coding (Lovable) são melhores opções para ganho de produtividade no médio e longo prazo. Nessas ferramentas a IA escreve o código por você mas, sabendo usar bem a ferramenta, você mantém controle sobre todas as decisões técnicas e qualidade do código. (Escrevi mais sobre isso em outro artigo.)

Não estou dizendo que vibe coding não tem valor. Eu acho uma ótima opção pra prototipar e validar ideias rapidamente; e pode ser feito sem envolver o time técnico! Pode inclusive ser usado para colocar soluções em produção (por que não?), dependendo do que você precisa resolver.

Agora, se mal usado, vibe coding vai apenas deslocar a complexidade para um ponto onde ela fica mais cara.

Desenvolvimento assistido por IA ainda é um assunto novo. Cada desenvolvedor e equipe tem suas próprias práticas e workflows com essas ferramentas, e acredito que ainda vai demorar um tempo para termos um consenso solidificado do que funciona melhor.

Esse artigo foi originalmente postado no Linkedin: https://www.linkedin.com/pulse/como-e-por-que-vibe-coding-funciona-onde-ele-te-custa-marco-souza-y7umf/