Andrej Karpathy cunhou o termo vibe coding para descrever um jeito solto de programar com IA — “para projetos descartáveis de fim de semana”. A palavra-chave era descartável. O mercado ignorou essa parte.
O que sobrou foi a promessa: descreva em linguagem natural, a IA gera, funciona no navegador, sobe. Domingo à noite, café frio, deploy feito. E aí mora o problema — porque funcionar no demo e aguentar produção são duas coisas diferentes, e a distância entre elas é exatamente o que o vibe coding esconde.
O que é vibe coding
Vibe coding é desenvolvimento assistido por IA em que você descreve o objetivo em linguagem natural e um modelo (LLM) gera o código. Seu papel muda de escrever linha por linha para orientar, testar e refinar o que a IA produz — de forma conversacional.
O termo é de Andrej Karpathy, início de 2025 (Wikipedia). A intenção original era clara: fluxo divertido para throwaway weekend projects. Protótipo. Descartável. Não produto para cliente pagante.
No-code vs vibe coding
Não é a mesma coisa, e a diferença importa para o risco:
- No-code monta a aplicação numa interface visual. Você não vê o código, não versiona, não audita. O teto é a plataforma.
- Vibe coding gera código-fonte real. Você pode ler, colocar no Git, testar e endurecer — ou ignorar tudo isso e subir cru.
O código que você não revisou continua sendo seu. Mais poder que no-code vem com mais responsabilidade, não menos.
O “descartável” era o produto, não o defeito
Vibe coding não é uma ferramenta de produção com bug. É uma ferramenta de exploração funcionando exatamente como projetada. O erro não está no método — está em subir o resultado sem o trabalho que separa protótipo de produto.
Quando você faz um protótipo para validar uma hipótese, código feio é ótimo: rápido, jogável, sem cerimônia. O problema começa no momento em que esse mesmo código toca dado de cliente, processa pagamento ou integra sistema legado — e ninguém trocou o motor.
Os números que não aparecem no demo
Não é FUD, é auditoria. Levantamentos de 2025-2026 sobre código gerado por IA mostram um padrão consistente:
| Sinal | Frequência | O que é |
|---|---|---|
| Vulnerabilidade OWASP Top-10 | 38%–45% do código IA | ≥1 falha clássica (injeção, XSS, auth) |
| Segredo / chave de API exposta | 58% das apps auditadas | Credencial hardcoded no código-fonte |
| SQL injection | 34% | Query por concatenação de string, não parametrizada |
| XSS / input sem sanitização | Padrão, não exceção | Entrada de usuário renderizada sem escape |
Vale nomear o framework: quase metade do código gerado por IA ainda cai no OWASP Top-10 — a mesma lista de falhas que a indústria conhece há uma década, só que produzida mais rápido e em escala maior. Um benchmark acadêmico recente (Is Vibe Coding Safe?, arXiv 2512.03262) chega à mesma conclusão: promissor para democratizar software, arriscado sem gestão de segurança.
O detalhe cruel: nada disso quebra o demo. O segredo hardcoded funciona. O SQL concatenado retorna os dados certos na sua máquina. O XSS só dispara quando existe um usuário mal-intencionado. A falha aparece com tráfego real, dado que você não previu ou alguém procurando brecha — ou seja, exatamente em produção.
Um exemplo concreto
Você sobe um “app besta” de fim de semana: uma landing com formulário que grava lead num banco. A IA colou a chave do banco direto no código e o repositório foi para o GitHub público — porque era só um teste. Semanas depois, um scanner automático varre o GitHub, acha a credencial e entra no banco. Só que essa chave é a mesma que você reusou no projeto sério, porque era mais prático. Agora o “app besta” virou porta de entrada para o sistema que importa: credencial reutilizada, pivoting para outros ambientes, e um vazamento que começou num protótipo que “não tinha nada de importante”.
Nenhum passo dessa cadeia exigiu um atacante sofisticado. Exigiu só um segredo no lugar errado e a suposição de que projeto pequeno não é alvo. Projeto pequeno é o alvo mais fácil — justamente porque ninguém o trata como produção.
A conta maior não é a segurança. É a dívida.
Todo mundo fala de CVE. Poucos falam do custo que dói mais no dia a dia: manutenibilidade.
Repositório levantado num fim de semana costuma ficar de pé com fita adesiva, esperança e alucinação do modelo. Três meses depois, o bug aparece em produção e ninguém no time sabe explicar por que o código faz o que faz. Corrigir vira reescrever do zero.
Shadow IT, dono e trilha de auditoria
No ambiente corporativo o risco muda de nome. Código gerado sem revisão vira shadow IT — sistema em produção que a área de tecnologia não conhece, não monitora e não consegue auditar. A Gartner já apontava o uso de tecnologia não autorizada como vetor crescente de incidente. Sem dono definido, sem documentação e sem trilha de auditoria, o primeiro incidente não tem nem por onde começar a investigação.
Propriedade intelectual e licença de dependência
Código gerado puxa dependências que a IA escolheu por você. Alguma pode ter licença incompatível com uso comercial; outra pode estar desatualizada e carregar CVE conhecido. Quem responde pela licença e pela cadeia de dependência é a empresa que subiu — não o modelo que gerou.
LGPD e dado sensível
No Brasil isso não é opcional. Se o app toca dado pessoal, a LGPD (Lei 13.709/2018) se aplica igual, tenha o código sido escrito à mão ou gerado por IA. Vibe coding facilita dois erros de compliance:
- Dado vazando para processamento externo sem base legal nem consentimento claro.
- Ausência de controle de acesso e registro — quem viu o quê, quando, com qual finalidade.
Protótipo com PII sem esses controles não é “beta”. É produção com outro nome — e com exposição regulatória. A arquitetura segura de dados sensíveis precisa existir antes do primeiro cadastro real, não depois da notificação da ANPD.
Sinais de que o protótipo já virou produto
O perigo raramente é uma decisão consciente de “vou para produção”. É um deslize gradual: o protótipo ganha um usuário real, depois dois, depois um pagamento. Ninguém apertou o botão “isto agora é sério” — mas ele ficou sério. Sinais de que a linha já foi cruzada:
- Alguém que não é você depende do app para trabalhar, comprar ou decidir.
- Existe dado real — nome, e-mail, telefone, pagamento — no banco.
- Cair custa dinheiro ou reputação, não só o seu domingo.
- Você tem medo de mexer no código porque não sabe o que quebra.
- Existe um cliente esperando suporte quando algo falha.
Se qualquer um desses é verdade, o “projeto de fim de semana” já é produção — e merece o rigor de produção, mesmo que o código não tenha mudado uma linha desde o commit de sábado.
O teste de domingo à noite
Antes de clicar em deploy, responda honestamente. Se falhar em qualquer uma, ainda é protótipo:
- Segredos: alguma chave, token ou senha está no código ou no histórico do Git?
- Autenticação: quem pode ver o quê? A regra roda no servidor ou só no client?
- Dados: tem PII? Está protegido? Tem backup e você sabe restaurar?
- Validação: o servidor confia no que o front manda, ou revalida?
- Injeção: as queries são parametrizadas? A entrada de usuário é sanitizada antes de renderizar?
- Testes: os fluxos que geram receita têm ao menos smoke test?
- Manutenção: você consegue explicar o código inteiro para outra pessoa amanhã?
- Rollback: deu ruim às 2h da manhã, qual é o plano?
Isso não é burocracia. É a fronteira entre “subi meu projeto” e “publiquei um incidente futuro”. O checklist completo de go-live e o guia de testes antes do go-live aprofundam cada item.
Isso não é “pare de usar IA”
Pelo contrário. IA para gerar código é aceleração real — quando existe uma pessoa técnica no loop. Vale inclusive separar as ferramentas por perfil:
- Times técnicos: Cursor, Claude Code, GitHub Copilot — mantêm o controle do código, ideais para acelerar quem já sabe revisar.
- Times sem perfil técnico: Lovable, Bolt.new, Replit — ótimos para protótipo visual, exigem endurecimento antes de cobrar cliente.
O padrão saudável, em qualquer um dos dois, é o mesmo:
- Vibe coding para explorar — protótipo, spike, validação de UX. Solte a mão.
- Revisão humana antes de cobrar — segredos, auth, validação server-side, dependências, licença.
- Endurecimento para produção — testes dos fluxos críticos, arquitetura segura de dados, rollback e monitoramento.
É o mesmo caminho que recomendamos para protótipos de Lovable e no-code: a ferramenta acelera a fase certa; ela não substitui o ownership de produto. Vale lembrar que rodar IA em produção tem custo próprio, e que agentes de IA fazem sentido em contextos específicos — não em todo lugar.
Quanto custa endurecer depois
A objeção comum é “não tenho orçamento para fazer certo agora”. A conta real é o contrário: fazer certo depois custa mais que fazer no meio.
Um endurecimento tem faixas bem diferentes:
- Conserto rápido — tirar segredo do código, rodar env corretamente, ligar controle de acesso básico, escrever smoke test dos fluxos que geram receita. Dias, não meses.
- Refactor médio — mover regra de negócio do client para o servidor, arrumar autenticação, isolar multi-tenant, revisar dependência com licença ou CVE problemático.
- Reescrita — quando o protótipo é tão acoplado e sem teste que consertar sai mais caro que refazer com cabeça de produção.
O custo de cada faixa cresce com o tempo que o código passou em produção acumulando dependência e dado. E nenhuma dessas faixas se compara ao custo de um vazamento: notificação à ANPD, perda de confiança do cliente e o trabalho emergencial de conter o dano com o sistema no ar. Endurecer antes é a opção barata — ela só não parece, porque o custo do “depois” é invisível até o incidente. Um discovery técnico curto coloca número nessas faixas antes de você orçar no escuro.
O ponto
Você pode vibe-codar um projeto de fim de semana. Deve, até — é ótimo para aprender e validar. O que você não pode é confundir o protótipo com o produto e subir para cliente pagante sem o trabalho no meio.
“Quase pronto” não é “pronto”. “Funciona aqui” não é “aguenta produção”. E o código que a IA escreveu em dois minutos pode custar duas semanas de rescue depois — ou um vazamento que custa muito mais.
Se você tem um protótipo vibe-coded que virou negócio de verdade, a hora de endurecer é antes do primeiro cliente, não depois do primeiro incidente. É exatamente o trabalho de levar um MVP do zero à produção com responsabilidade — e onde a engenharia da Pixelize entra.
Perguntas frequentes
Vibe coding serve para produção?
Serve para protótipo, spike e validação. Para produção com cliente, dado real ou pagamento, precisa de revisão humana: segredos, auth, validação server-side e testes. “Funciona no demo” ≠ “pronto”.
Qual a diferença entre no-code e vibe coding?
No-code monta na interface visual e esconde o código. Vibe coding gera código-fonte real — você pode ler, versionar e endurecer. Mais poder, mais responsabilidade: o código que você não revisou é seu mesmo assim.
Vibe coding é seguro?
O método é seguro; o output nem sempre. 38% a 45% do código IA cai no OWASP Top-10 — injeção, XSS, segredo exposto, auth quebrada. Com revisão humana antes do deploy, o risco cai ao nível de código escrito à mão.
Por que projeto de fim de semana é arriscado se está funcionando?
Porque “funcionar” esconde o que quebra depois: segredo hardcoded, SQL por concatenação, auth frágil, código que ninguém explica. O custo aparece no incidente e na manutenção, não no deploy.
Vibe coding vai substituir desenvolvedores?
Substitui o boilerplate e a exploração, não o julgamento de engenharia. Alguém decide arquitetura, revisa segurança, garante LGPD e mantém em produção. A IA acelera quem sabe o que faz; não sabe o que você não pediu.
Como transformar um protótipo em produto?
Discovery técnico: audite segredos e dependências, mova regra para o servidor, teste os fluxos que geram receita, defina rollback e monitore. Endurecer é mais barato que um breach.