Anatomia técnica de projetos Lovable: o que encontramos ao abrir o capô do vibe coding

O vibe coding democratizou a criação de software. Ferramentas como o Lovable permitem que em poucos minutos você tenha uma aplicação React funcionando, com autenticação, banco de dados e deploy — tudo a partir de prompts em linguagem natural.

A SoftDesign já publicou sobre como usar o Lovable para acelerar o backlog da TI, e os cenários de prototipação e discovery são realmente transformadores.

Mas o que acontece quando você decide que aquele protótipo vai virar produto?

Como Lead Software Engineer, fiz algo que raramente aparece nos artigos sobre vibe coding: abri o código-fonte. Auditei dois projetos reais construídos com Lovable — aplicações corporativas com dezenas de telas, formulários complexos, integrações com Supabase e APIs externas.

O que encontrei conta uma história que todo gestor de TI precisa ouvir antes de decidir colocar código gerado por IA em produção sem supervisão profissional.

O que é vibe coding e como funciona na prática

O conceito de vibe coding ganhou espaço como uma abordagem inovadora no desenvolvimento de software, fortemente impulsionada pela evolução de ferramentas com Inteligência Artificial.

Em essência, vibe coding é o ato de programar em fluxo com a IA — traduzindo intenções, ideias e comandos em linguagem natural para gerar código funcional de forma colaborativa, rápida e intuitiva.

Na prática, o fluxo de trabalho com vibe coding segue a seguinte lógica:

• Seleção de ferramenta: a escolha da ferramenta de IA é o ponto de partida.
• Geração de código: por meio de um prompt claro, a IA gera o código-fonte necessário.
• Validação e otimização: o código gerado é analisado e testado para garantir a qualidade e a estrutura. Nessa fase, a coleta de feedback é essencial para iterar e refinar o produto.
• Implementação: por fim, a versão final é publicada.

De acordo com o Gartner, até 2028, 40% dos novos softwares de produção nas empresas serão desenvolvidos com técnicas e ferramentas de vibe coding.

Embora promissor, esse modelo ainda apresenta limitações, o que reforça a importância de uma adoção responsável e apoiada por especialistas. Veja o motivo a seguir.

O experimento: auditoria técnica de projetos reais de vibe coding

Recentemente, analisei dois projetos React 18 + Vite + TypeScript + Tailwind CSS construídos no Lovable, ambos com ambição de ir para produção.

Um deles passou por seis fases de iteração na plataforma. O outro integrava Supabase e uma API REST externa simultaneamente.

A auditoria cobriu dez categorias:

1. Fundamentos de engenharia;
2. Arquitetura;
3. Dependências;
4. Qualidade de código;
5. Testes;
6. Performance;
7. Segurança;
8. DevOps;
9. Acessibilidade;
10. Padrões específicos do Lovable.

O resultado: ambos os projetos ficaram entre 2.0 e 2.5 em uma escala de 5.0. Não apenas em uma ou duas categorias, mas na média geral.

Os padrões de problema se repetiram de forma quase idêntica em ambos os projetos, o que sugere que não se tratam de incidentes isolados, mas de características sistêmicas da ferramenta.

Vamos a eles.

1. TypeScript está lá, mas não está funcionando

O TypeScript é uma das decisões técnicas mais inteligentes da stack do Lovable. A tipagem estática evita categorias inteiras de bugs em runtime, documenta contratos entre componentes e dá confiança para refatorar.

O problema é que, em ambos os projetos, o TypeScript estava efetivamente desabilitado:

{ 
  "strict": false, 
  "noImplicitAny": false, 
  "strictNullChecks": false, 
  "noUnusedLocals": false, 
  "noUnusedParameters": false 
} 

Ou seja: a linguagem aceita any em qualquer lugar, não avisa sobre variáveis null, e ignora código morto. Encontrei 99 ocorrências de any em um projeto e 68 no outro.

Exemplos como (inspection as any).name revelam que, quando a IA muda a estrutura de dados entre iterações, em vez de atualizar os tipos, ela simplesmente contorna o compilador com um cast.

• Por que isso importa: com strict: false, o TypeScript vira um transpilador sofisticado de JavaScript. Você paga o custo de sintaxe de tipos sem ganhar a proteção que eles oferecem. Logo, erros que seriam detectados em tempo de compilação — como acessar uma propriedade que não existe — viram crashes silenciosos em produção.

2. Testes: a rede de segurança que não existe

Ao analisar os projetos de vibe coding, a cobertura de testes foi um dos achados mais alarmantes. Os números falam por si:

Mas o mais grave não é a quantidade, é que os testes não rodam. Em um dos projetos, o Jest estava na versão 30 com ts-jest na versão 29 (incompatíveis entre si).  

Além disso, a configuração usava moduleNameMapping quando a propriedade correta é moduleNameMapper. Um typo que faz os aliases de import falharem silenciosamente. 

Em outras palavras: existe uma infraestrutura elaborada de testes — factories, handlers de mock para requisições HTTP, test-utils —, mas ela nunca foi executada com sucesso.

É scaffolding gerado pela IA para parecer que o projeto tem testes, quando na prática não tem nenhum funcional.

• Por que isso importa: sem testes, qualquer mudança no código é uma aposta. Refatorar um componente, atualizar uma dependência ou corrigir um bug pode quebrar funcionalidades em produção sem que ninguém saiba até o usuário reclamar.

3. Segurança: os riscos que a IA não vê 

Se a seção anterior preocupa, esta deveria tirar o sono de qualquer gestor de TI. 

Configuração de produção com dados fictícios 

Em um dos projetos, a configuração do ambiente de produção estava com useMockData: true. Isso significa que, ao fazer deploy, a aplicação apresentaria dados falsos — nomes de usuários inventados, projetos fictícios, métricas fabricadas — como se fossem dados reais.  

O ServiceFactory, que decide se usa serviços reais ou mockados, segue cegamente essa flag. Em produção. 

Autenticação fake 

No mesmo projeto, o AuthService.login() importava a função authenticateUser de um arquivo chamado mockUsers.ts.

A “autenticação” validava credenciais contra dados hardcoded em um array JavaScript. Ou seja, qualquer pessoa com acesso ao código-fonte saberia exatamente quais são os usuários e senhas válidos. 

Credenciais no código-fonte 

No outro projeto, a URL e a chave pública do Supabase estavam hardcoded diretamente no código TypeScript, apesar de existir um .env com as mesmas variáveis.

Para piorar, o .env não estava no .gitignore — o que significa que credenciais são commitadas no repositório e ficam no histórico do Git permanentemente. 

Bug em controle de acesso 

Uma vulnerabilidade funcional chamou atenção: o sistema de permissões mapeava as roles viewer, inspector e admin em uma hierarquia numérica.

Porém, a role technician — que existia nos tipos TypeScript e que era atribuída a usuários — não foi incluída nesse mapeamento. Como technician não estava no mapa, o sistema retornava um nível indefinido, e ao comparar com o nível mínimo exigido, a verificação sempre falhava (em JavaScript, undefined < 1 resulta em false).  

Na prática, todos os usuários com role technician eram bloqueados de todas as rotas protegidas, sem mensagem de erro clara. Um bug funcional que afetava usabilidade e que passou despercebido justamente porque não há testes. 

• Por que isso importa: a IA gera código para o “caminho feliz”. Não pensa em modelos de ameaça, não questiona se credenciais deveriam estar em variáveis de ambiente, e não verifica se o mapeamento de permissões está completo. Segurança é uma preocupação sistêmica que exige raciocínio adversarial — exatamente o oposto de como uma LLM opera. 

4. Over-engineering: complexidade sem contrapartida

Este é talvez o padrão mais curioso do Lovable. Ao receber prompts que pedem “arquitetura robusta” ou “boas práticas”, a IA responde gerando abstrações enterprise-grade que seriam sofisticadas demais até para projetos com equipes grandes.

Em um dos projetos de vibe coding, que opera 100% com dados mockados e ainda não se conectou a um backend real, encontrei:

• ServiceFactory com singleton pattern;
• Repository Pattern com BaseRepository genérico;
• CacheManager com expiração automática e remoção de entradas;
• PerformanceMonitor (343 linhas) com métricas de performance do navegador;
• AnalyticsService (440 linhas) com tracking de eventos;
• AdvancedErrorHandler (524 linhas) com error boundary customizado;
• DeveloperExperience (513 linhas) com debug tools;
• WebSocketService (278 linhas) para realtime;
• SecurityService (336 linhas) com sanitização XSS.

São aproximadamente 3.500 linhas de código de infraestrutura que não entregam valor ao usuário final. Enquanto isso, os sete arquivos de teste do projeto mal funcionam.

No outro projeto, o sistema de erros definia 12 classes de erro customizadas (ValidationError, NotFoundError, DatabaseError, AuthenticationError, etc.) — mas o ErrorBoundary que deveria capturá-los nunca foi montado em nenhum componente.

717 linhas de infraestrutura de erros que ninguém usa.

• Por que isso importa: over-engineering gerado por IA é pior do que over-engineering humano, porque não existe intenção por trás. Um desenvolvedor sênior cria abstrações quando há necessidade real — múltiplos backends, alta concorrência, escalabilidade iminente. A IA cria abstrações porque foi treinada em repositórios que as têm, sem avaliar se fazem sentido no contexto atual. O resultado é um codebase que parece maduro na superfície, mas que esconde fragilidade fundamental sob camadas de complexidade.

5. O legado instantâneo: quando cada prompt é uma camada arqueológica

O Lovable encoraja iteração rápida: escreva um prompt, veja o resultado, peça ajustes. Isso é excelente para convergir a uma UI desejada. Mas cada iteração adiciona código sem necessariamente limpar o que veio antes.

Um dos projetos tinha seis arquivos README de fases distintas (PHASE-2 até PHASE-6, mais um README-LAYERED-ARCHITECTURE). Cada fase adicionou serviços, hooks, componentes e abstrações — sem que as fases anteriores fossem refatoradas.

O resultado é o que chamo de legado instantâneo: código que tem cara de herança de três anos, mas que foi gerado em semanas.

Sinais práticos desse padrão:

• Código comentado extensivo: 42 linhas comentadas em um AuthContext, 51 em uma página — resquícios de iterações anteriores que nunca foram limpos.
• Interfaces duplicadas: o mesmo tipo Inspection definido em três arquivos diferentes com campos potencialmente divergentes.
• as any para contornar mudanças: quando a IA muda a estrutura de dados entre prompts, ela usa type assertions para silenciar o compilador em vez de atualizar todos os consumidores.
• Dois sistemas de backend coexistindo: um projeto de vibe coding usava Supabase para registro de usuários e uma API REST separada para login — dois sistemas de autenticação sem fronteira clara sobre qual é a fonte de verdade.
• Dependências acumuladas: Leaflet E Mapbox no mesmo projeto para funcionalidades de mapa (~240KB extras no bundle).

6. O que mais encontramos: padrões recorrentes 

Além dos grandes temas acima, alguns achados se repetiram em ambos os projetos com consistência quase mecânica: 

A repetição desses padrões é o dado mais relevante para gestores. Não estamos falando de projetos feitos por desenvolvedores descuidados — estamos falando de características da ferramenta. 

O que isso significa para o seu próximo projeto 

Nada do que apresentei aqui é uma condenação ao vibe coding. O Lovable, por exemplo, é uma ferramenta genuinamente impressionante para prototipação, discovery e aceleração de front-end. 

Mas existe uma distância real entre um protótipo funcional e um produto de produção. E essa distância não se resolve com mais prompts. Ela se resolve com engenharia. 

O que um engenheiro ou equipe de engenharia faz depois que o Lovable gera o código é o que separa um MVP descartável de um produto sustentável: 

1. Ativar o TypeScript de verdade: habilitar strict: true, resolver os erros que aparecerem, substituir any por tipos reais. Isso é trabalho humano que exige compreender o domínio de negócio. 
2. Construir a rede de segurança: escrever testes que validem comportamento (não implementação), configurar o pipeline de testes, garantir que eles rodam — e que alguém olha quando falham. 
3. Revisar segurança com raciocínio adversarial: perguntar “o que acontece se…” para cada endpoint, cada formulário, cada política de acesso. A IA não faz isso espontaneamente. 
4. Simplificar a arquitetura: remover abstrações que não entregam valor, consolidar serviços duplicados, escolher um package manager, uma biblioteca de mapas, um sistema de autenticação. 
5. Implantar CI/CD: lint, type-check, testes e build automatizados em cada commit. Sem isso, a qualidade é uma questão de sorte. 
6. Refatorar continuamente: a cada feature gerada por IA, um profissional revisa, limpa resíduos de iterações anteriores e mantém a coerência do codebase. Sem refatoração contínua, o legado instantâneo se acumula até que o projeto se torne mais caro de manter do que reescrever. 

A regra prática 

Uma regra que tenho aplicado nos projetos que acompanho: para cada hora de vibe coding, reserve ao menos uma hora de revisão e refatoração por um profissional.

Nos dois projetos auditados, a refatoração para um nível mínimo de produção exigiu mais horas do que a geração original. 

Não é overhead — é hedge contra dívida técnica. É o que garante que a velocidade do prompt de hoje não se transforme no bloqueio técnico do trimestre que vem.

Conclusão: velocidade é vantagem, mas só com maturidade técnica 

Atualmente, estamos em um momento extraordinário para o desenvolvimento de software.  

A capacidade de converter uma ideia em um protótipo funcional em minutos é real e transformadora. Mas a engenharia de software existe por motivos que uma LLM não resolve sozinha: confiabilidade, segurança, manutenibilidade, escalabilidade. 

O vibe coding é um acelerador poderoso. Mas um acelerador sem freios e sem direção é um risco, não uma vantagem. 

Os dados das auditorias que compartilhei aqui não são exceções — são padrões. E padrões exigem respostas sistemáticas: processos de revisão, profissionais qualificados e uma cultura que valorize a engenharia tanto quanto valoriza a velocidade. 

O futuro do desenvolvimento é, sim, AI-Assisted. Mas “assisted” é a palavra-chave. A Inteligência Artificial gera o código; a inteligência humana garante que ele funcione, que seja seguro, e que possa evoluir.  

E essa é uma capacidade que toda organização séria precisa construir — ou contratar.

Perguntas frequentes sobre vibe coding

Por fim, confira respostas para dúvidas sobre o assunto.

Leia também:

• Lovable: como aplicar o conceito de vibe coding para acelerar o backlog da TI
• AI Strategy: como sair do hype e estruturar iniciativas que realmente geram resultado
• Do AI Assisted ao Agentic Workflow: como integrar IA no SDLC em 2026
• Human in the Loop: o modelo que equilibra automação, governança e precisão em IA
• Valor da IA nos negócios: como sair do hype e medir resultados