O que é vibe coding?

Vibe coding é um fluxo de trabalho em que você constrói software escrevendo prompts para uma IA e aceitando o código gerado praticamente sem revisão. Andrej Karpathy cunhou o termo em fevereiro de 2025 — “fully give in to the vibes, embrace exponentials, and forget that the code even exists” (entregue-se às vibes e esqueça que o código existe) — descrevendo aceitar mudanças sem ler os diffs, colando erros de volta até funcionar, escopo que ele mesmo limitou a projetos descartáveis de fim de semana. Em um ano o termo virou atalho para qualquer programação com IA; este verbete mantém o sentido preciso, onde mora o julgamento de engenharia: o traço definidor não é usar IA — é não revisar o que a IA escreveu.

Principais pontos

O loop e a linha divisória

O fluxo é um loop curto: descreva → a IA gera → rode → cole os erros de volta → repita, tratando a base de código como problema da IA. Simon Willison traçou a linha que mantém o termo útil: se você revisou cada mudança, testou e consegue explicá-la, “isso não é vibe coding — é desenvolvimento de software”. Não é gatekeeping; é um rótulo de risco. O mesmo loop com revisão é engenharia assistida por IA, e o modo em que você está deveria ser uma decisão, não um acidente. Na prática:

// JavaScript — Cloud Code (cloud/main.js)
// The guardrail under a vibe-coded frontend: rules the AI can't skip
Parse.Cloud.beforeSave('Note', (req) => {
  // Whatever the generated client sends, ownership is enforced HERE
  if (!req.user) throw 'Sign in required';
  const acl = new Parse.ACL(req.user); // private by default
  req.object.setACL(acl);
});
// Client keys are publishable; the Master Key stays server-side.
// The vibe-coded UI can be rewritten nightly — these rules survive.

// Flutter / Dart — Back4app Flutter SDK
// The vibe-coded client can be sloppy — the backend isn't
final note = ParseObject('Note')..set('text', draft);
await note.save();
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.

// iOS / Swift — Back4app Swift SDK
// The vibe-coded client can be sloppy — the backend isn't
var note = Note()
note.text = draft
_ = try await note.save()
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.

// Android / Kotlin — Back4app Android SDK
// The vibe-coded client can be sloppy — the backend isn't
val note = ParseObject("Note")
note.put("text", draft)
note.save()
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.

Vibe coding vs. engenharia assistida por IA vs. desenvolvimento tradicional

O espectro, e a regra da graduação

O enquadramento que resolve a maioria das discussões sobre vibe coding: ele é um estágio, não uma identidade. Protótipos merecem as vibes — protótipos existem para isso. A regra que o histórico de incidentes ensina: código só se gradua entre estágios via revisão e testes. Vale notar que o próprio Karpathy seguiu adiante dentro do mesmo ano, distinguindo o vibe coding casual da “agentic engineering” para trabalho sério — o criador do termo concordando com seus críticos sobre o escopo.

O que quebra de verdade: o histórico de incidentes

A seção honesta que os explicadores de vendor suavizam. Varreduras da indústria apontam falhas das classes OWASP em cerca de 45% do código gerado por IA, e ferramentas independentes de revisão mediram no código de IA ~1,7× mais problemas graves do que em baselines escritos por humanos (o tratamento acadêmico chega a conclusões parecidas). Os incidentes nomeados compartilham uma mesma anatomia: em 2025, uma varredura de apps construídos num builder prompt-to-app popular encontrou 170 de 1.645 vazando dados de usuários — o stack gerado saía com a segurança em nível de linha do banco desabilitada (registrada como CVE); a camada de autenticação de uma plataforma prompt-to-app permitia a qualquer usuário entrar em qualquer app privado por um ID adivinhável; e um app de consumo viral foi violado quando seu banco de backend mobile sem proteção deixou qualquer usuário autenticado puxar IDs e mensagens privadas de outros usuários. Nenhum desses foi um ataque exótico. Todos eram o básico de backend — regras de acesso, autenticação, credenciais — gerados permissivos e aceitos sem revisão.

É no backend que morde

Releia a lista de incidentes e o padrão se nomeia sozinho: o perigo não é a IA escrever uma UI desajeitada — um botão quebrado se resolve com um refresh. O perigo se concentra onde os dados vivem: autenticação, regras de acesso, chaves de API coladas no código do cliente, rate limits ausentes. Código não revisado é mais perigoso exatamente onde a revisão mais importa — e essa é a resposta arquitetural: faça da parte vibe-coded a parte de baixo risco. Um frontend gerado sobre um backend gerenciado inverte o risco: a plataforma fornece autenticação endurecida, ACLs negadas por padrão impostas no servidor, chaves de cliente publicáveis com os segredos reais guardados em outro lugar e funções server-side para a lógica que não deve viver em código de cliente gerado. A IA pode reescrever a UI toda noite; ela não consegue desabilitar regras que não controla.

O checklist de guardrails

1. Revise tudo que toca autenticação, dados ou dinheiro — o portão de graduação, inegociável.
2. Faça checkpoint no controle de versão antes do “aceitar tudo” — undo barato para sugestões caras.
3. Mantenha segredos fora dos prompts e do código do cliente — trate ambos como públicos.
4. Regras de acesso negadas por padrão — o app gerado recebe as permissões que você escolheu, não as permissivas que ele sugeriu.
5. Validação server-side para cada invariante — hooks que o cliente não consegue pular.
6. Testes antes de confiança — o único feedback honesto do loop além de “parece que roda”.
7. Escopos pequenos, uma tarefa por prompt — diffs do tamanho de uma revisão continuam revisáveis.
8. Limite o gasto — chaves de API com cotas; loops de agente já queimaram orçamentos reais.
9. Isole os experimentos — app separado, chaves separadas, dados descartáveis.
10. Saiba em qual modo você está — vibe ou engenharia, escolhido de propósito.

Casos de uso comuns

• Protótipos e MVPs — o caso de uso fundador: testar a ideia neste fim de semana, não neste trimestre.
• Ferramentas pessoais e internas — audiência pequena, usuários conhecidos, raio de explosão baixo.
• Hackathons e demos — velocidade é a rubrica inteira.
• Aprender construindo — o loop como tutor, com a ressalva de que código não lido ensina menos.
• Iteração de UI sobre um backend estável — a arquitetura de risco invertido: vibes em cima, contratos embaixo.

Você deveria usar vibe coding? Matriz de decisão

Limitações e trade-offs

• Depurar código não lido é arqueologia. Quando o loop trava, alguém finalmente precisa ler tudo de uma vez — a revisão que você pulou, com juros.
• A dívida de compreensão se acumula. Cada mudança aceita sem leitura alarga o vão entre o que o app faz e o que alguém consegue explicar; o vão é o risco.
• Os defaults da IA são permissivos. Configurações geradas privilegiam “funciona” sobre “é seguro” — regras de acesso abertas, chaves embutidas — e o usuário que mais precisa perceber é o menos equipado para isso.
• O termo está derivando. “Vibe coding” cada vez mais significa qualquer programação com IA, o que contrabandeia práticas de nível protótipo para conversas de produção; a precisão sobre o modo em que você está é a defesa.
• A atrofia de habilidade é real, mas mal enquadrada. A habilidade que importa migra de escrever código para especificar, revisar e julgar código — a atrofia só acontece se a revisão também for pulada.

Vibe coding no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. A dupla é a arquitetura de risco invertido posta em prática: aponte o frontend gerado para um backend em que as partes estruturais já foram projetadas por engenheiros — cadastro, sessões e login social vindos da plataforma; ACLs e permissões de classe impostas no servidor em cada requisição, negadas por padrão; chaves de cliente publicáveis com a master key guardada no servidor; e o guard de beforeSave das abas de código como o padrão para cada invariante que o cliente escrito pela IA não pode ter a confiança de manter. A superfície vibe-coded continua sendo o que Karpathy quis que fosse — rápida, divertida, descartável — enquanto as partes que acabam em relatórios de incidente vêm de uma plataforma: revisadas uma vez, impostas sempre.