Vibe Coding para quem não é desenvolvedor: o que dá para construir com segurança em 2026

Quem não é desenvolvedor pode fazer muita coisa com vibe coding em 2026, até uma linha que dá para nomear. Abaixo dela ficam protótipos, landing pages, ferramentas internas e apps simples com login e banco de dados. Acima dela ficam lógica de pagamento personalizada, dados de saúde ou financeiros, apps compartilhados por várias empresas e qualquer coisa com tráfego sério. Esses casos ainda exigem um engenheiro.

O público já chegou. O Lovable diz que 80% de seus usuários se descrevem como não técnicos e que as pessoas o usam para ferramentas internas, CRMs e lojas, além de sites (The Next Web). As falhas vieram junto. Este ano, a UpGuard encontrou 16.326 bancos de dados no Supabase, o backend em que muitos desses apps rodam, com tabelas que qualquer pessoa na internet podia ler (UpGuard). A Veracode testou mais de 100 modelos de IA ao longo de quatro anos e calcula que a taxa média de aprovação em segurança do código escrito por IA é de 56%. Nas palavras da empresa: "It hasn't moved" ("não saiu do lugar") (Veracode).

Quase todo o estrago vem de um único erro que você consegue verificar sem ler código: um banco de dados que entrega linhas para quem pedir. Corrija isso, mantenha chaves secretas fora do navegador, e quase tudo o que um fundador, profissional de marketing ou analista quer construir está liberado.

Como é o vibe coding em 2026

Você descreve o que quer em linguagem natural, a ferramenta escreve o código, você clica pelo preview ao vivo e pede a próxima mudança. As ferramentas voltadas a quem não programa hoje vão bem além da interface. Elas criam também o banco de dados, o sistema de cadastro e a hospedagem, então um app com contas reais pode existir depois de uma tarde de prompts.

Leia o diagrama como um ciclo com uma saída. A saída é a parte que as pessoas pulam.

A seta tracejada sai do teste de propósito. Você não consegue julgar o código gerado lendo-o, mas consegue julgar o que ele faz: se uma segunda conta vê os registros da primeira, ou se uma página abre sem login. Quando um teste envolve dinheiro, dados privados de outras pessoas ou escala real, pare e chame alguém que leia código.

Muita coisa mudou este ano. O Lovable agora deixa uma única mensagem de build rodar por até 10 horas e ganhou um comando /goal que continua até a tarefa ser concluída, a um preço visivelmente maior (changelog do Lovable). O Replit lançou o Agent 4 com agentes paralelos, e sua IA agora roda em um Free Mode e nos modos pagos Power e Max. A Vercel reconstruiu o v0 em torno de branches e pull requests do GitHub, e o chefe de produto dela diz que 90% do trabalho real é alterar uma base de código existente. O Base44, da Wix, treinou o próprio modelo, o Base1, que seu fundador espera que acabe sendo mais rápido e barato para os clientes do que os modelos de fronteira.

O Google AI Studio agora percebe quando um app precisa de banco de dados ou login e, depois que você aprova, configura o Firebase para os dois. O builder anterior, o Firebase Studio, está sendo desativado, então qualquer tutorial baseado nele já está desatualizado.

A escada de risco: o que você pode construir sozinho

O risco sobe com duas coisas: de quem são os dados que o app guarda e se passa dinheiro por ele. Um protótipo cheio de registros inventados não vaza nada. Um app de cadastro com e-mails de desconhecidos pode vazar, e este ano muitos vazaram.

A escada ordena projetos comuns por esse risco. Os três degraus de baixo estão liberados para qualquer pessoa. O âmbar é onde aconteceu a maior parte dos vazamentos deste ano.

Protótipos clicáveis, landing pages com formulário de contato e ferramentas internas só para a equipe são o ponto ideal. Um protótipo responde "devemos construir isso?" antes de alguém abrir um ticket. Um tracker interno para o time de vendas ou de operações pode substituir uma planilha em que ninguém confia, e se ele estiver restrito ao workspace e com login, quem poderia fazer mau uso são seus colegas. Automações simples também ficam neste degrau, embora uma ferramenta de workflow como n8n ou Zapier muitas vezes resolva sem precisar construir um app (veja o ranking de automação de workflows).

Apps de clientes com contas são o degrau âmbar. As ferramentas conseguem construí-los sem problema. O problema é que uma única regra errada no banco expõe todos os usuários de uma vez, então construa e depois pague um engenheiro para revisar antes de pessoas reais se cadastrarem.

Os dois degraus de cima são dos engenheiros. Pagamentos vêm primeiro. Um botão de compra que abre o checkout hospedado do Stripe é aceitável, porque os dados do cartão vão direto para o Stripe e nunca passam pelo seu app. O próprio guia de segurança do Stripe alerta que uma empresa que recebe dados de cartão diretamente pode ter de cumprir mais de 300 controles de segurança do PCI DSS. Cobrança por uso e apps em que várias empresas compartilham o mesmo banco dependem de lógica de autorização, exatamente onde pesquisadores continuam encontrando apps feitos com IA quebrados.

Dados regulados são o outro caso. O FAQ corporativo do Lovable diz que a empresa não assina business associate agreements, não é compatível com a HIPAA e pede que os usuários não enviem informações de saúde protegidas. Dados de saúde, financeiros e de crianças trazem obrigações legais que nenhum scan pré-publicação consegue cobrir.

As ferramentas que importam hoje e como cada uma cobra

Cinco builders cobrem a maior parte do que este leitor precisa, e eles diferem menos no que conseguem fazer do que na forma de cobrar e na facilidade de sair. O Bolt e o v0 ficam ao lado de Lovable, Replit e Base44. Os preços são dos planos pagos de entrada, conforme a página de preços de cada fornecedor.

Para a maioria de quem não programa, o Lovable é o padrão sensato. Ele publica exemplos de custo por mensagem, faz scan de problemas de segurança a cada publicação e sincroniza o código com o GitHub em qualquer plano, inclusive o gratuito. O Base44 serve para quem não quer ver código nunca, com uma ressalva tratada na seção de transferência mais abaixo. O Replit faz sentido se você quer um único workspace para apps, slides e dashboards de dados, e o Free Mode é a forma mais tranquila de começar. O Bolt combina com quem constrói em rajadas, já que os tokens pagos não usados acumulam por um mês. O v0 é a escolha quando sua empresa já faz deploy na Vercel e engenheiros vão assumir o projeto.

Duas opções no-code mais antigas ainda cobrem terreno parecido com editores visuais: o Bubble cria apps web e mobile, e o Glide transforma planilhas em apps. O ranking ao vivo abaixo mostra como a categoria mais ampla está hoje, e nosso guia de AI app builders aprofunda uma dúzia deles.

O ranking inclui também builders voltados a desenvolvedores, então use-o para descobrir ferramentas e a tabela para planejar o orçamento.

Por que os créditos acabam mais rápido do que você planejou

Todas essas ferramentas agora cobram pelo trabalho que a IA faz, não pela mensagem que você envia. Isso é justo para pequenos ajustes e caro para pedidos vagos.

O Lovable publica os exemplos mais claros. "Make the button gray" custou 0,50 crédito, "Add authentication" 1,20 e "Build a landing page with images" 2,00, enquanto uma mensagem em plan mode custa 1 crédito (Lovable). Como uma mensagem de build agora pode rodar por horas, o Lovable pausa para confirmar quando uma única mensagem passa de 20 créditos, um padrão que você pode aumentar ou desativar. Recargas no Pro custam US$ 15 por 50 créditos, ou seja, US$ 0,30 por crédito contra US$ 0,25 dentro do plano de 100 créditos.

As outras funcionam do mesmo jeito, com nomes diferentes. A central de ajuda do Bolt diz que a maior parte do uso de tokens vem de ler e sincronizar os arquivos do projeto, então o mesmo prompt custa mais à medida que o app cresce. O v0 conta o histórico do chat e os arquivos de código como tokens de entrada. O Base44 diz que não há custo fixo por mensagem e coloca mudanças típicas entre cerca de 0,5 e 4 créditos. O Free Mode do Replit não custa nada dentro de uma cota, mas os modos Power e Max consomem créditos mensais, e os pacotes extras de crédito expiram seis meses após a compra.

A escada de preços do Lovable mostra o que isso significa para o orçamento.

Quase não há desconto por volume. Todo plano até 800 créditos sai a US$ 0,25 por crédito, e o de 2.000 créditos ainda custa US$ 0,24. Dobrar o quanto você usa de prompts dobra a conta, então a alavanca que importa são as mensagens desperdiçadas.

A maior parte do desperdício vem dos loops de correção: a IA quebra uma coisa, a correção quebra outra, e cada rodada é cobrada. Planejar antes ajuda, já que uma mensagem em plan mode no Lovable custa um crédito fixo e o Bolt diz que o plan mode usa menos tokens porque não altera nada. Botões também ajudam: o Bolt observa que publicar ou restaurar uma versão por botão não custa nada, enquanto pedir isso à IA gasta tokens. Quando uma sessão desanda, volte a um checkpoint em vez de tentar sair dela na base do prompt.

Coloque seus próprios hábitos no estimador abaixo. Ele usa os custos de exemplo do Lovable, então trate o resultado como uma faixa de orçamento, não como uma cotação.

Nos valores padrão, você precisa de cerca de 162 créditos por mês, o que o plano de US$ 50 cobre. Se o retrabalho chegar a 60%, até o caminho mais barato, o plano de US$ 25 mais recargas, sobe para US$ 70. Defina também um teto: a recarga automática do Lovable aceita um limite mensal de gasto em vez de "No limit", e o Replit permite limitar o gasto além dos créditos incluídos. Se o preço por créditos ainda parece escorregadio, nosso explicativo sobre modelos de preço de ferramentas de IA detalha créditos, assentos e tokens.

O histórico de incidentes aponta para um único erro

Coloque os relatórios de incidentes deste ano lado a lado e a mesma falha aparece o tempo todo. Não é hacking sofisticado. É um banco de dados que responde a qualquer um que pergunte.

O estudo da UpGuard encontrou cerca de 300 mil domínios com sinais de uso do Supabase e 16.326 bancos de dados expondo tabelas legíveis, mais da metade com indícios de dados pessoais (UpGuard). A explicação é específica: tabelas criadas pela API, que é como os agentes de código conversam com o Supabase, não vêm com row-level security ativado por padrão. O responsável de segurança do Supabase disse ao TechCrunch que os projetos são seguros por padrão e que a segurança é uma responsabilidade compartilhada.

O Moltbook, uma rede social para agentes de IA cujo fundador disse que "didn't write a single line of code" ("não escreveu uma única linha de código"), foi ao ar com a chave do Supabase na página e sem políticas de row-level security. Pesquisadores da Wiz chegaram a 1,5 milhão de tokens de API, 35 mil endereços de e-mail e milhares de mensagens privadas antes de a equipe corrigir o problema, poucas horas depois de ser avisada (Wiz).

Um app hospedado no Lovable expôs 18.697 registros de usuários, milhares deles de contas de estudantes, segundo o pesquisador Taimur Khan. Ele encontrou a verificação de acesso escrita de trás para frente: "The guard blocks the people it should allow and allows the people it should block" ("O guarda bloqueia quem deveria deixar entrar e deixa entrar quem deveria bloquear") (The Register). O Lovable afirmou que oferece um scan de segurança gratuito antes da publicação, que agir sobre ele cabe ao usuário, e que o banco vulnerável não era hospedado pelo Lovable e o projeto continha código que o Lovable não havia gerado.

As plataformas também escorregam. Mais adiante no ano, um pesquisador mostrou que uma conta gratuita do Lovable conseguia puxar código-fonte, credenciais de banco de dados e históricos de chat com IA de projetos públicos de outras pessoas. O Lovable primeiro chamou o comportamento de intencional e por design. Depois admitiu que apontar para uma documentação pouco clara não era suficiente, disse "We'll do better" ("Vamos fazer melhor") e afirmou ter corrigido sua API para que os chats de projetos públicos não possam ser acessados (The Register). A empresa de segurança RedAccess contou cerca de 380 mil apps acessíveis publicamente criados em Lovable, Base44, Replit e Netlify, e cerca de 5 mil deles expunham dados sensíveis. O CEO do Replit respondeu que apps públicos serem acessíveis é comportamento esperado e que a privacidade é uma configuração de um clique.

A pesquisa diz a mesma coisa pelo outro lado. O teste de longa duração da Veracode mostra o quanto modelos mais inteligentes ajudaram pouco.

Mesmo o melhor modelo da rodada 2026 da Veracode falha em quase uma tarefa de segurança a cada três, e os modelos feitos para programar não se saem melhor que os de uso geral. Um estudo separado da startup Tenzai construiu 15 apps com cinco agentes de código e encontrou 69 vulnerabilidades. As piores envolviam autorização e lógica de negócio, e bugs clássicos de injeção nem apareceram. Isso bate com os incidentes. A IA escreve código que funciona, mas não pergunta quem deveria poder usá-lo, a menos que você diga.

Row-level security em português claro

Apps construídos assim costumam falar com o banco direto do navegador, usando uma chave que é pública por design. O que impede um desconhecido de usar essa chave para ler tudo é o row-level security: regras dentro do banco que decidem, linha por linha, quem pode ler ou alterar o quê. O backend integrado do Lovable e o banco do Bolt usam essas regras do Postgres, o mesmo modelo do Supabase.

A documentação do Supabase é direta. Uma tabela em um schema exposto sem RLS "is readable and writable by any role with a grant on it" ("pode ser lida e escrita por qualquer role com permissão sobre ela") (Supabase). Quando ele está ativado, a chave pública não enxerga nada até que uma policy permita. Uma policy é curta. Esta, do tipo que seu builder deveria escrever para uma tabela de pedidos, permite que cada usuário logado leia apenas as próprias linhas:

create policy "Users read their own orders"
on orders for select
to authenticated
using ( (select auth.uid()) = user_id );

Você não precisa escrevê-la. Mas precisa confirmar que existe uma para cada tabela. A chave secreta, ou "service role", ignora essas regras por completo, então nunca pode ficar em código de navegador. E qualquer coisa no seu front end, inclusive uma checagem como "este usuário é admin?", pode ser editada por quem está usando, e é por isso que a documentação do Lovable diz que código de frontend nunca deve tomar decisões de segurança.

Um processo de construção seguro, passo a passo

Esta ordem mantém os erros baratos: dados falsos até o último passo, pessoas reais só no final.

1. 1Escreva uma especificação de uma página antes do primeiro prompt. Diga quem usa o app, liste as cinco ou seis telas, detalhe o que cada tipo de usuário pode ver e alterar e nomeie o que está fora do escopo. Cole no plan mode e peça à ferramenta que procure furos nela.
2. 2Faça o protótipo com dados falsos. Construa telas e fluxos com registros inventados, mantenha o projeto privado e mostre para as pessoas que vão usá-lo. Mude de direção agora, enquanto uma mudança custa uma mensagem.
3. 3Descreva o modelo de dados em palavras simples. Liste cada tipo de registro (clientes, pedidos, notas) e de quem ele é, depois peça à ferramenta que crie as tabelas e explique, tabela por tabela, quem pode ler e alterar linhas. Se alguma resposta for "qualquer um", corrija antes de avançar.
4. 4Adicione cadastro e permissões no mesmo passo e depois leia as regras de volta. O Base44, por exemplo, aceita regras escritas como frases, como "Only the person who submitted an order should be able to see it" ("Só a pessoa que fez um pedido deve poder vê-lo").
5. 5Teste com duas contas e dados falsos. Cadastre-se como Alice e como Bob. Como Bob, tente abrir os registros da Alice, edite o número do registro na barra de endereço e use o app sem estar logado. Tudo o que o Bob alcançar e não deveria é um bug, independentemente de como o código seja.
6. 6Rode a checagem de segurança. Use o scan integrado, corrija todo achado crítico e depois siga o checklist da próxima seção. A auditoria completa do Bolt não gasta tokens quando executada pelo menu Publish. Se o app guarda dados pessoais de clientes, é aqui que um engenheiro o revisa.
7. 7Lance pequeno, com limites. Convide primeiro um punhado de usuários reais, defina limites de gasto, confirme que backups e rollback funcionam e apague as contas falsas.

Não sabe em que degrau sua ideia está? A árvore abaixo dá uma resposta em três perguntas ou menos.

Se a árvore mandar você para um engenheiro, o protótipo não foi em vão. Um mock-up funcional mais uma especificação é o briefing mais claro que um desenvolvedor pode receber.

O checklist de segurança antes do lançamento

Rode isto antes que qualquer pessoa fora das suas contas de teste receba um link. Nada aqui exige que você leia código. Cada item é uma configuração para olhar, um scan para rodar ou um teste para fazer.

Dois itens fazem a maior parte do trabalho. O row-level security em toda tabela se confere na visão de banco de dados ou de segurança do seu builder, e o Bolt sinaliza regras "always true", ou seja, que deixam todo mundo entrar. O teste com segunda conta pega o que os scanners deixam passar, como a verificação de acesso invertida no app do Lovable citado acima.

O resto é rápido. O Bolt ativa a proteção contra senhas vazadas por padrão, e o scan pré-publicação do Lovable avisa quando ela está desligada. No Lovable, tudo que tem o prefixo VITE_ acaba no navegador, então uma chave secreta nunca pode levá-lo.

Scans têm limites, e os fornecedores admitem isso. A documentação do Lovable diz que suas ferramentas "cannot guarantee complete security" ("não podem garantir segurança completa") e sugere uma revisão profissional para apps que lidam com dados sensíveis. A documentação do Base44 é mais curta: você é responsável pelas configurações de segurança do seu app.

Passando o projeto para um desenvolvedor

Um app vibe-coded que funciona vai precisar de um engenheiro mais cedo ou mais tarde, para revisá-lo ou assumi-lo. Planeje a transferência desde o primeiro dia.

Conecte um repositório do GitHub cedo. A sincronização bidirecional do Lovable funciona em todos os planos, e um desenvolvedor pode clonar o repositório e continuar no próprio editor. A sincronização bidirecional do Base44 começa no plano Builder. No v0, um repositório conectado vira a fonte da verdade, e o v0 envia suas mudanças para uma branch de trabalho em vez de direto na branch de origem. O Bolt também sincroniza commits com o GitHub.

Saiba o que o código deixa para trás. A documentação do Lovable diz que nem a sincronização com o Git nem o download do código incluem os dados dentro do seu banco, e o guia de hospedagem em outro lugar manda você mover os arquivos de armazenamento manualmente. O Base44 diz que nada fica preso à plataforma e que a sincronização com o GitHub exporta o código-fonte completo. A documentação para desenvolvedores também descreve um SDK que os projetos exportados usam para acessar os serviços do próprio Base44 para dados e funções de backend. Nossa leitura, não uma afirmação do Base44: sair totalmente do Base44 pode significar substituir essa camada.

Dê ao desenvolvedor um pacote de transferência curto:

• A especificação, com cada tela e quem pode usá-la.
• Acesso ao repositório e ao projeto no builder.
• Uma lista em português claro de cada tabela e de quem deve poder ler e alterá-la.
• As integrações que você adicionou e os nomes dos segredos que elas usam, nunca os valores em si por chat ou e-mail.
• Bugs conhecidos, gambiarras estranhas que você pediu via prompt e quanto o projeto custou em créditos até agora.

Peça uma revisão de segurança antes de novas funcionalidades: regras de acesso, funções do lado do servidor e onde ficam os segredos. A maioria dos desenvolvedores vai abrir o repositório em uma ferramenta de código como o Cursor ou o Claude Code. Nosso guia de assistentes de código e o artigo assistentes de código de IA vs. construtores de agentes explicam como essas ferramentas diferem dos app builders, e o ranking de assistentes de código de IA mostra como o setor está posicionado.

Perguntas frequentes

Sou dono do código que uma ferramenta de vibe coding escreve?

Lovable, Base44, Bolt e v0 sincronizam o código com um repositório do GitHub sob seu controle, no caso do Base44 a partir do plano Builder. Ser dono do código, porém, não é o mesmo que ser dono do app em funcionamento. Seus dados, arquivos armazenados e serviços de backend podem continuar na plataforma até que alguém os migre.

Qual ferramenta de vibe coding é a mais barata para começar?

As cinco têm plano gratuito. O Lovable dá aos usuários gratuitos 5 créditos de build por dia, com teto de 30 por mês, e o Free Mode do Replit roda nos planos individuais gratuito e pagos, com limites definidos pelo plano. Entre os planos pagos, o Starter do Base44 custa US$ 16 por mês com cobrança anual e o Replit Core, US$ 20 por mês.

Posso receber pagamentos em um app vibe-coded?

Sim, por meio de checkout hospedado. A integração do Lovable com o Stripe abre o Stripe Checkout e guarda sua chave secreta como segredo de backend, não no código do app. Teste primeiro com chaves de sandbox e o cartão de teste do Stripe. Cobrança por uso, repasses a outros usuários e cobrança para contas multiempresa são território de engenheiro.

A IA consegue checar a segurança do próprio código?

Em parte. Os scans integrados pegam problemas comuns, como regras de acesso ausentes, chaves expostas e pacotes vulneráveis. Mas os fornecedores dizem que os scans não garantem segurança, e o app que vazou 18.697 registros estava numa plataforma que oferece scan gratuito antes de publicar. Trate o scan como piso, não como aprovação final.

O que aconteceu com o Firebase Studio?

O Google está desativando. Ele não cria mais novos workspaces, será encerrado em 2027, e o Google diz que os usuários podem migrar os workspaces existentes para o Google AI Studio ou o Antigravity. Serviços do Firebase, como Firestore e Authentication, continuam como antes.