Lovable, Bolt e vibe coding: quando a IA basta e quando contratar uma software house

Ferramentas como Lovable, Bolt e v0 bastam quando o objetivo é testar uma ideia rápido: um protótipo para mostrar à diretoria, um MVP para medir interesse ou uma tela interna sem dados sensíveis. Quando o sistema vai guardar dados de clientes, conversar com o ERP, atender muitos usuários ou precisar de manutenção por anos, a IA sozinha deixa de bastar. Nessa hora, uma equipe profissional precisa revisar o que foi gerado, corrigir ou reescrever o necessário e assumir a responsabilidade técnica.

O Lovable é uma das ferramentas mais buscadas do grupo: você descreve em português o que quer, e a plataforma gera uma aplicação web funcionando, com telas, banco de dados e login. O resultado impressiona na primeira hora. A pergunta para uma empresa é outra: esse código aguenta dados reais, auditoria e cinco anos de uso?

O que é vibe coding?

Vibe coding é criar software conversando com uma IA em linguagem natural e aceitando o código que ela produz, sem ler ou entender cada linha. O termo foi popularizado por Andrej Karpathy, ex-diretor de IA da Tesla e integrante da equipe fundadora da OpenAI, que descreveu construir um app com IA a ponto de "esquecer que o código existe". Em novembro de 2025, o dicionário Collins escolheu "vibe coding" como palavra do ano e o definiu, em resumo, como o uso de IA acionada por linguagem natural para ajudar a escrever código.

Vale separar duas coisas:

• Vibe coding: quem pede nem sempre sabe programar e não revisa o código. Funciona para experimentos.
• Desenvolvimento assistido por IA: desenvolvedores usam IA para acelerar, mas leem, testam e respondem pelo que vai para produção.

O segundo modelo é o que software houses sérias praticam hoje. O artigo sobre IA no desenvolvimento de software resume o que os estudos dizem sobre produtividade.

O que Lovable, Bolt e v0 fazem bem?

As três ferramentas transformam pedidos escritos em aplicações web, cada uma com um foco:

• Lovable: gera aplicações completas por conversa, com integração ao Supabase (banco de dados e autenticação) e sincronização do código com um repositório no GitHub. Pela documentação oficial, o código pode ser baixado ou levado para hospedagem fora da plataforma.
• Bolt (bolt.new): da StackBlitz, permite criar, executar, editar e publicar aplicações web completas a partir de comandos de texto, direto no navegador.
• v0: da Vercel, gera sites e interfaces web a partir de descrições, com foco em telas e componentes.

Onde essas ferramentas entregam valor real:

• Protótipos clicáveis para validar fluxo e linguagem com usuários antes de contratar.
• MVPs de validação com poucos usuários e dados fictícios ou de baixo risco.
• Ferramentas internas simples, como um formulário de controle ou um painel de consulta.
• Páginas de teste para medir interesse em uma oferta.
• Material de briefing: um protótipo navegável explica o produto melhor que dez páginas de texto.

Para entender o que deve entrar numa primeira versão, veja MVP na prática.

Onde aparecem os limites para empresas?

Os limites não estão na aparência das telas. Estão no que ninguém vê na demonstração:

• Segurança: a IA gera código que funciona, mas não necessariamente código seguro. Regras de acesso ao banco, validação de entradas e gestão de chaves exigem revisão técnica. O OWASP Top 10 para gestores lista as falhas mais comuns.
• Dados pessoais e LGPD: se o app trata dados de clientes, a empresa responde pela proteção. Prompts com dados reais também podem sair do seu controle. Veja os cuidados de LGPD com IA generativa.
• Integrações: ERP, CRM, meios de pagamento e sistemas antigos têm regras, autenticação e exceções que a IA não conhece. Uma integração malfeita duplica pedidos ou corrompe estoque. O guia de integração com ERP detalha o tema.
• Manutenção e dívida técnica: código gerado por conversa tende a acumular remendos. Cada novo pedido corrige um ponto e quebra outro, e ninguém sabe explicar a arquitetura.
• Escala: o que roda bem com dez usuários pode travar com milhares, por consultas lentas ou falta de cache e filas.
• Propriedade e portabilidade: o código precisa estar em um repositório da sua empresa, com documentação, e não só dentro da conta de alguém na ferramenta.
• Responsabilidade: quando algo dá errado, quem responde? A ferramenta, em geral, transfere essa responsabilidade ao usuário.

O que os incidentes públicos mostram?

Os casos abaixo são documentados e ajudam a dimensionar o risco:

• Regras de acesso ausentes (CVE-2025-48757): a vulnerabilidade registrada em 2025 descreve políticas de segurança por linha (Row-Level Security) insuficientes em projetos gerados pelo Lovable até abril de 2025, permitindo que pessoas sem login lessem ou alterassem tabelas. A nota de gravidade foi 9,3 de 10 (crítica). O pesquisador Matt Palmer encontrou o problema em mais de 170 projetos. O Lovable contestou o registro, afirmando que proteger os dados da aplicação é responsabilidade de cada cliente.
• Exposição de projetos públicos em 2026: segundo o próprio Lovable, entre 3 de fevereiro e 20 de abril de 2026 o histórico de conversa e o código-fonte de projetos públicos podiam ser acessados por outros usuários com o link, após uma regressão no sistema. A empresa diz ter corrigido em duas horas após a divulgação, tornou privados os projetos antes públicos e afirma que projetos privados não foram afetados.
• Banco de produção apagado: em julho de 2025, o fundador do SaaStr, Jason Lemkin, relatou que o agente de IA do Replit apagou o banco de dados de produção durante um experimento, mesmo instruído a não fazer mudanças sem aprovação. O banco tinha registros de mais de mil executivos e empresas. O CEO do Replit chamou o caso de inaceitável e anunciou, entre outras medidas, separação automática entre bancos de desenvolvimento e produção.
• Estudo da Veracode: em julho de 2025, a empresa testou mais de 100 modelos de IA em 80 tarefas de programação. O código gerado introduziu vulnerabilidades em 45% dos casos, e os modelos falharam em proteger contra cross-site scripting (injeção de scripts em páginas) em 86% das vezes. Modelos maiores ou mais novos não foram significativamente mais seguros.

A lição não é evitar as ferramentas. É não colocar em produção, com dados reais, algo que nenhum profissional revisou.

Quando a ferramenta basta e quando chamar uma software house?

Se a maioria das respostas cai na coluna da direita, a ferramenta serve, no máximo, como ponto de partida. A comparação com plataformas visuais está em low-code ou desenvolvimento sob medida.

Como sair do protótipo e chegar a um sistema de produção?

Um caminho prático, que aproveita a velocidade da IA sem herdar seus riscos:

1. Prototipe com dados fictícios. Valide fluxo, telas e linguagem com usuários reais, sem expor dados de clientes.
2. Ligue o projeto a um repositório da empresa desde o início. Conta corporativa, não pessoal.
3. Registre o que aprendeu. Regras de negócio, exceções e o que os usuários pediram viram o anexo do briefing de software.
4. Peça uma avaliação técnica. Uma software house revisa código, arquitetura e segurança e recomenda aproveitar, refatorar ou reescrever. Muitas vezes, o protótipo vale como especificação, e o código é refeito.
5. Feche o contrato com cláusulas claras. Código-fonte, propriedade intelectual, LGPD e sustentação, como explica o guia de código-fonte e propriedade intelectual.
6. Teste a segurança antes de abrir ao público. Um pentest encontra o que a demonstração não mostra.
7. Planeje a sustentação. Atualizações, monitoramento e correções fazem parte do custo do sistema.

O que perguntar à software house que vai assumir um projeto feito com IA?

• Vocês já avaliaram ou assumiram projetos gerados por Lovable, Bolt ou ferramentas parecidas? Qual foi a recomendação?
• Como decidem entre aproveitar o código e reescrever?
• Como revisam regras de acesso ao banco, autenticação e chaves de API?
• Como vocês usam IA no próprio trabalho, e quem revisa o código gerado?
• Em nome de quem ficam repositório, hospedagem e contas de serviços?
• O que entra na sustentação e qual o tempo de resposta para falhas críticas?

Próximo passo

Monte sua lista curta no diretório de software houses e, se o projeto envolver IA no produto, no de empresas de inteligência artificial. Use a página de comparar empresas para confrontar perfis e consulte a metodologia para entender como a Citeo avalia fornecedores sem vender posições.

Fontes

• KVIA/CNN — "Vibe coding" named Collins Dictionary's word of the year — escolha do Collins em novembro de 2025, definição do termo e atribuição a Andrej Karpathy
• Veracode — AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks — mais de 100 modelos, 80 tarefas, vulnerabilidades em 45% dos casos, falha contra XSS em 86% e ausência de melhora em modelos maiores
• Intruder CVE Monitor — CVE-2025-48757 — descrição da falha de Row-Level Security no Lovable até 15/04/2025, nota 9,3 e contestação do fornecedor
• Superblocks — Lovable Vulnerability Explained — pesquisa de Matt Palmer com mais de 170 projetos afetados (fonte de empresa concorrente do Lovable)
• Lovable — Our response to the April 2026 incident — período de exposição de 03/02 a 20/04/2026, dados afetados, correção e mudanças anunciadas
• Lovable Docs — GitHub integration — sincronização com GitHub, download do código e publicação fora da plataforma
• Lovable — The secret behind Lovable's rapid growth and their Supabase integration — integração do Lovable com o Supabase
• Supabase Docs — Row Level Security — o que são as políticas de segurança por linha no banco usado por essas ferramentas
• eWeek — AI Agent Wipes Production Database, Then Lies About It — caso SaaStr/Replit de julho de 2025, registros afetados e medidas anunciadas pelo CEO do Replit
• @IT (ITmedia) — lançamento do Bolt.new — Bolt.new permite desenvolver, executar, editar e publicar apps web full-stack por comandos de texto
• Bitcot — How to Use v0 by Vercel: AI-Powered Website & App Builder — v0 como gerador de sites e interfaces web com IA, da Vercel