---
term: 'Vibe Coding'
seoTitle: 'Vibe Coding: Definição, Origem, Riscos e Guardrails'
headline: 'O que é vibe coding?'
slug: vibe-coding
category: ai-modern-stack
shortDefinition: '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.'
relatedTerms:
  - no-ops-development
  - backend-boilerplate-code
  - api-key-security
  - access-control-lists-acl
contrastsWith:
  - ai-agent
aboutTerms:
  - 'Desenvolvimento Assistido por IA'
  - 'Builders Prompt-to-App'
  - 'Agentic Coding'
faq:
  - question: 'O que é vibe coding?'
    answer: 'É construir software descrevendo o que você quer a uma IA em linguagem natural e aceitando o código gerado praticamente sem revisão linha a linha — iterando ao rodar, testar e mandar novos prompts, em vez de editar. A parte de não revisar é o traço definidor, nas leituras mais estritas do termo.'
  - question: 'Quem criou o termo vibe coding?'
    answer: 'Andrej Karpathy, num post no X em fevereiro de 2025 — "fully give in to the vibes, embrace exponentials, and forget that the code even exists", ou seja, entregar-se às vibes e esquecer que o código existe. O Collins o elegeu Palavra do Ano de 2025, e os dicionários passaram a rastreá-lo como gíria semanas depois da cunhagem.'
  - question: 'Vibe coding é o mesmo que desenvolvimento assistido por IA?'
    answer: 'Não, e a distinção importa. No vibe coding você não revisa nem entende por completo o resultado. Na engenharia assistida por IA o humano mantém o controle arquitetural e revisa tudo — a regra de Simon Willison: se você revisou, testou e consegue explicar cada linha, isso não é vibe coding; é desenvolvimento de software.'
  - question: 'Vibe coding é programação de verdade?'
    answer: 'Ele produz software real e funcional — e não é engenharia. O que falta é accountability: revisão, entendimento e a capacidade de raciocinar sobre falhas. Para escopos descartáveis, tudo bem — esse era o enquadramento do próprio Karpathy; para qualquer coisa com usuários e dados, as partes que faltam são justamente as estruturais.'
  - question: 'Quem não sabe programar consegue fazer vibe coding?'
    answer: 'Sim — a maioria dos usuários de plataformas prompt-to-app não tem formação em programação, e essas pessoas realmente entregam ferramentas que funcionam. As paredes em que batem são previsíveis: autenticação, modelagem de dados, segurança e depuração — exatamente as partes em que não entender o código sai mais caro.'
  - question: 'Software feito com vibe coding é seguro para produção?'
    answer: 'Não sem revisão. Varreduras da indústria apontam falhas de segurança em cerca de 45% do código gerado por IA, e o histórico de incidentes é concreto: apps publicados com as regras de acesso do banco desabilitadas, autenticação quebrada deixando qualquer usuário ler dados alheios e segredos embutidos no código do cliente. O padrão em todos os casos: segurança de backend aceita sem revisão.'
  - question: 'Vibe coding vai substituir programadores?'
    answer: 'O consenso é que não — ele desloca o trabalho em vez de eliminá-lo: para especificação, revisão e arquitetura. Protótipos vibe-coded que dão certo costumam ser reconstruídos ou fortemente endurecidos por engenheiros antes de escalar, e o próprio criador do termo hoje distingue o vibe coding casual da "agentic engineering" séria.'
  - question: 'Quais são as boas práticas de vibe coding?'
    answer: 'Prompts pequenos e com escopo; uma tarefa por vez; checkpoints no controle de versão antes do "aceitar tudo"; testes como rede de segurança; revisão humana de tudo que toca autenticação, dados ou dinheiro; segredos fora dos prompts e do código do cliente; e um backend gerenciado e endurecido embaixo do frontend gerado.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Andrej Karpathy — o post original (fevereiro de 2025)'
    url: 'https://x.com/karpathy/status/1886192184808149383'
  - name: 'Not all AI-assisted programming is vibe coding — Simon Willison'
    url: 'https://simonwillison.net/2025/Mar/19/vibe-coding/'
  - name: 'Vibe coding — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Vibe_coding'
  - name: 'The (In)Security of Vibe-Coded Applications — arXiv'
    url: 'https://arxiv.org/abs/2506.23130'
cta:
  title: 'Vibe no frontend. Não no backend.'
  text: 'Aponte seu app gerado por IA para o Back4app e as partes estruturais chegam endurecidas: autenticação, ACLs, rate limits e lógica server-side que o código gerado não consegue desabilitar — a superfície vibe-coded segue sendo a de baixo risco.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-24'
translationKey: 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](https://x.com/karpathy/status/1886192184808149383) 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

| Pergunta | Resposta |
| --- | --- |
| A definição | Prompt → gerar → rodar → novo prompt — sem ler o código |
| A origem | Karpathy, fev/2025 · Palavra do Ano do Collins em 2025 |
| A linha | Revisado, testado, entendido = engenharia assistida por IA, não vibe coding |
| O histórico | ~45% do código de IA tem falhas de segurança; houve incidentes reais |
| A regra | Vibe na superfície de baixo risco; nunca em auth, dados ou dinheiro |

## 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](https://simonwillison.net/2025/Mar/19/vibe-coding/) 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:**

```javascript
// 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
// 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.
```

**Swift:**

```swift
// 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.
```

**Kotlin:**

```kotlin
// 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

| | Vibe coding | Engenharia assistida por IA | Tradicional |
| --- | --- | --- | --- |
| Quem escreve o código | A IA | A IA + o humano | O humano |
| Revisão | Pulada — essa é a definição | Cada mudança | Cada mudança |
| O humano é dono de | O prompt e a vibe | Arquitetura, correção | Tudo |
| Velocidade | A mais rápida | Rápida | Baseline |
| Encaixe | Descartáveis, protótipos | Produtos reais | Produtos reais |
| Modo de falha | Código publicado que ninguém entende | Erros em escala de IA, pegos por humanos | Erros em escala humana |

## O espectro, e a regra da graduação

```mermaid
flowchart LR
  accTitle: O espectro do vibe coding até a produção
  accDescr: O software percorre um espectro que vai do protótipo vibe-coded descartável, passando pelo desenvolvimento assistido por IA com revisão, até a engenharia de produção. O código só se gradua de um estágio para o próximo por meio de revisão humana e testes, e o modo de falha é pular a graduação publicando um protótipo direto para os usuários.
  V["Protótipo vibe-coded<br/>sem revisão, rápido, descartável"] -->|"graduação: revisão<br/>+ testes + hardening"| A["Desenvolvimento assistido por IA<br/>o humano é dono da correção"]
  A -->|"mesmo portão, régua mais alta"| P["Engenharia de produção<br/>accountability + operação"]
  V -.->|"o modo de falha:<br/>publicar como está"| X["Incidente"]
```

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](https://arxiv.org/abs/2506.23130) 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](/glossary/pt/autenticacao-vs-autorizacao/), [regras de acesso](/glossary/pt/listas-de-controle-de-acesso-acl/), [chaves de API](/glossary/pt/seguranca-de-chaves-de-api/) coladas no código do cliente, [rate limits](/glossary/pt/rate-limiting-de-api/) 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](/glossary/pt/cloud-code-funcoes-serverless/) 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](/glossary/pt/gatilhos-de-banco-de-dados/).
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](/glossary/pt/api/) embaixo.

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

| O que você está construindo | Veredito |
| --- | --- |
| Descartável de fim de semana, demo, experimento | Vibe à vontade — esse é o habitat |
| Ferramenta interna, real mas pequena | Vibe, depois revise os caminhos de dados |
| Qualquer coisa com contas de usuário | O backend vem de uma plataforma endurecida, não do prompt |
| Qualquer coisa lidando com pagamentos ou PII | Revisão completa — agora isso é engenharia |
| O produto de verdade de uma startup | Assistido por IA com ownership; protótipos se graduam, nunca são publicados como estão |
| O frontend sobre um backend gerenciado | O ponto ideal — velocidade onde é seguro |

## 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](/glossary/pt/oauth-2-login-social/) vindos da plataforma; [ACLs e permissões de classe](/glossary/pt/listas-de-controle-de-acesso-acl/) impostas no servidor em cada requisição, negadas por padrão; chaves de cliente publicáveis com a [master key guardada no servidor](/glossary/pt/seguranca-de-chaves-de-api/); 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.