Vibecoding Essencial
Um checklist para usar IA no fluxo de código de forma produtiva e responsável: você continua sendo o autor e o revisor. Cada tópico em poucas linhas, com as armadilhas. Se algo soar novo, o ponteiro → aprofunde em… indica a apostila completa.
O formato "Essencial"
Densa, sem rodeios, feita para ser varrida.
- Leia rápido. Se você já faz isso, siga. Se travou, é sinal de estudar.
- → aprofunde em…: Vibecoding (completa), Aceleração de Código com IA, Criação de Agentes de IA, Segurança de Aplicações de IA, Testing & Automação, DevTools & Debug.
- Caixas ⚠️: o que mais gera bug e retrabalho — não pule.
- Auto-checagem ao fim de cada seção; checklist final para marcar.
O que é (e o que não é)
Fluxo assistido por IA para quem já programa. Você especifica, a IA rascunha, você revisa e é responsável. → aprofunde em Vibecoding
| É | Não é |
|---|---|
| Delegar a digitação e o boilerplate; iterar rápido sobre um rascunho | Aceitar código que você não entende ("se roda, tá bom") |
| Usar a IA como par que sugere e explica | Deixar a IA decidir arquitetura, dependências e segurança sozinha |
| Manter revisão, testes e code review normais | Pular a revisão porque "foi a IA que escreveu" |
| Aprender uma API nova mais rápido | Terceirizar o entendimento do problema |
Regra de ouro: se aparece o seu nome no git blame, você é o autor — inclusive do bug.
✔️ Auto-checagem
Qual a diferença entre "vibecoding" e "não olhar o código"? De quem é a responsabilidade pelo código gerado? O que a IA não deve decidir sozinha?
As ferramentas e os modos
Escolha o modo pela tarefa. → aprofunde em Aceleração de Código com IA
| Modo | Exemplos | Bom para |
|---|---|---|
| Autocomplete inline | Copilot, Supermaven, Cursor Tab | completar a linha/bloco que você já sabe escrever; menos digitação |
| Chat na IDE | Copilot Chat, Cursor, Continue, Cline | "explique isto", "gere este teste", edições pontuais com contexto do arquivo |
| Agente | Claude Code, Cursor Agent, Aider | tarefas multi-arquivo: refactor, feature pequena, migração — com você aprovando os diffs |
| Chat web | Claude, ChatGPT | desenhar solução, comparar abordagens, rubber-duck; sem acesso ao repo |
Quanto maior a tarefa, mais você precisa quebrar em passos pequenos e revisar cada um. Agente não é "faça a feature toda"; é "faça este passo, eu confiro, próximo".
✔️ Auto-checagem
Quando autocomplete vs chat vs agente? Por que quebrar tarefas grandes em passos? O que o chat web não tem que a IDE tem?
Contexto é tudo
O modelo só sabe o que você dá. Contexto ruim = resposta ruim. → aprofunde em Criação de Agentes de IA (RAG, janela)
- Dê o alvo: arquivos/funções relevantes, a seleção exata, exemplos de código parecido no repo ("faça no estilo de
X"). - Regras do projeto versionadas:
CLAUDE.md/.cursorrules/.github/copilot-instructions.md— convenções, stack, o que evitar, comandos de build/test. - @-mentions de arquivos, símbolos, docs, erros do terminal — em vez de descrever de memória.
- Não despeje o repo inteiro: contexto demais dilui o que importa e custa tokens; foco > volume.
- Sessão longa "apodrece": em conversas enormes o modelo perde o fio — reinicie com um resumo do estado.
- Pedir uma edição sem abrir/mencionar o arquivo → a IA inventa a estrutura.
- Não ter regras do projeto → cada geração usa um estilo diferente.
- Confiar que o modelo "lembra" de 30 mensagens atrás.
✔️ Auto-checagem
Onde vivem as regras do projeto para a IA? Por que não colar o repo inteiro? O que fazer quando a sessão fica longa e confusa?
O loop e o prompt
Especificar → gerar → revisar → testar → iterar. → aprofunde em Vibecoding · Aceleração de Código com IA
Um bom pedido tem
OBJETIVO o que a mudança deve alcançar (comportamento, não "mexa no arquivo X") RESTRIÇÕES stack, padrões, o que NÃO fazer, dependências permitidas CONTEXTO arquivos/exemplos relevantes; o teste que deve passar FORMATO "me dê um diff pequeno", "primeiro só o plano", "sem comentários óbvios"
- Peça o plano antes do código em tarefas não triviais; aprove o plano, depois gere.
- Diffs pequenos e revisáveis > um despejo de 400 linhas.
- Itere com feedback específico: "isto quebra o caso vazio", "use o padrão de erro do repo", não "está errado".
- TDD funciona bem: descreva/escreva o teste, peça a implementação, rode.
✔️ Auto-checagem
Quais os 4 elementos de um bom pedido? Por que pedir o plano antes? Por que diffs pequenos? Como dar feedback útil numa iteração?
Revisão obrigatória
Código gerado entra pelo mesmo portão de qualidade do código humano — não por um mais frouxo. → aprofunde em Testing & Automação · DevTools & Debug
- Leia cada linha. Se não entende, não commita — peça explicação ou reescreva.
- Rode e teste — a IA alucina comportamento. "Compila" ≠ "correto".
- Code review normal no PR; marque no PR o que foi assistido se o time pede.
- Cheque: casos de borda, tratamento de erro, nomes/idioma do repo, duplicação, performance óbvia, testes de verdade (não tautológicos — → Testing, mutation testing).
- Desconfie de "cobertura" gerada: testes que só reafirmam a implementação não protegem.
- Aceitar 300 linhas de uma vez sem ler.
- Confiar num teste gerado que "passa" mas não verifica nada.
- Mergear código que você não saberia manter/depurar sozinho.
✔️ Auto-checagem
O que você faz antes de commitar código gerado? Por que "compila" não basta? Como um teste gerado pode enganar?
Armadilhas de qualidade
Os erros típicos do código de IA que você tem que caçar na revisão.
| Armadilha | Como pegar |
|---|---|
| API/pacote alucinado (função ou lib que não existe — slopsquatting) | conferir na doc oficial; instalar só de lockfile revisado; desconfiar de pacote recém-criado |
| Over-engineering (abstração/config para um problema que você não tem) | "faça a versão mais simples que resolve"; cortar o que não é usado |
| Copiar o padrão errado do repo (um arquivo antigo/ruim como exemplo) | apontar explicitamente o arquivo bom como referência |
| "Funciona mas não é idiomático" | comparar com como o time faz; linter/formatter |
| Duplicação (reimplementa algo que já existe no projeto) | buscar antes; pedir "reuse o que já existe em utils/" |
Comentário-ruído (// incrementa i) | pedir "sem comentários óbvios" |
| Confiança falsa (a resposta parece certa e não é) | a explicação eloquente não é evidência — teste |
✔️ Auto-checagem
O que é slopsquatting e como se proteger? Por que a IA tende a over-engineer? Como evitar que ela copie o padrão errado do repo?
Segurança
A IA pode gerar código inseguro e você pode vazar dado no prompt. → aprofunde em Segurança de Aplicações de IA
- Não cole no prompt: segredos, chaves, tokens,
.env, PII, dado de cliente, código proprietário sem autorização. Verifique a política de retenção/treino da ferramenta. - Código gerado pode ter falha clássica: SQL injection (concatenar em vez de parametrizar), XSS (
innerHTMLcom input),eval, path traversal, autorização ausente (BOLA), CORS*, criptografia fraca. → OWASP no material de Segurança de IA e de API Design. - Prompt injection: um arquivo, issue, dependência ou README que a IA lê pode conter instruções maliciosas — trate conteúdo de terceiros como não confiável; revise ações do agente (rodar comandos, editar CI, adicionar deps).
- Dependências sugeridas: confira nome, popularidade, mantenedor, licença — antes de instalar.
- Agente com acesso a shell/rede: menor privilégio, sem credenciais no ambiente, revisar cada comando; nunca
--dangerously-skip-permissionsem repo real sem entender.
✔️ Auto-checagem
O que nunca colar num prompt? Cite 3 falhas de segurança que a IA tende a gerar. O que é prompt injection via arquivo do repo? O que revisar antes de instalar uma dependência sugerida?
Onde brilha e onde não
Use a IA onde ela acelera; pense sozinho onde o custo do erro é alto.
| Brilha | Cuidado / faça você |
|---|---|
| Boilerplate, CRUD, scaffolding | Arquitetura, fronteiras de módulo, escolha de dependência estratégica |
| Testes (a partir de casos que você define) | Decidir o que merece teste |
| Refactor mecânico (renomear, extrair, migrar sintaxe) | Refactor que muda semântica sutil |
| Glue code, parsers simples, scripts | Algoritmo sutil / concorrência / performance crítica |
| Aprender uma API/lib nova; exemplos | Código de segurança (authz, cripto, sanitização) |
| Explicar código legado; docs; commit messages | Regras de negócio complexas sem spec clara |
| Prototipagem descartável | Código que vai para produção sem revisão profunda |
✔️ Auto-checagem
Dê 3 tarefas ideais para IA e 3 onde você não deve delegar. Por quê em cada caso?
Fluxo de time
Vibecoding em equipe precisa de convenção, senão gera inconsistência. → aprofunde em Git & GitHub · Arquitetura de Software
- Regras da IA versionadas no repo (
CLAUDE.md/.cursorrules) — todo mundo gera no mesmo padrão. - PRs pequenos: código gerado precisa de revisão de verdade; PR gigante não é revisado.
- A IA não dirige a arquitetura: decisões estruturais em ADR/design doc, humano no comando (→ Arquitetura, ADRs).
- Custo: monitorar tokens/assinaturas; agentes em loop podem gastar rápido (→ Otimização de Custos de Cloud e IA).
- Consistência de testes/CI: o gate é o mesmo; rodar lint, testes, security scan no PR (→ Testing, IaC/CI).
- Onboarding: novos devs ainda precisam entender o sistema — não deixe a IA ser o único que "sabe".
✔️ Auto-checagem
Por que versionar as regras da IA? Por que PRs pequenos importam mais ainda com IA? Quem decide a arquitetura?
O resto do essencial
Práticas que fecham o quadro.
| Tópico | O mínimo |
|---|---|
| Gerar de spec | Escreva a spec/critérios de aceitação; a IA gera; você valida contra a spec, não contra "parece ok" |
| TDD assistido | Teste primeiro (você decide os casos) → implementação da IA → rodar → iterar |
| Refactor guiado | Um passo por vez, com testes verdes entre cada; a IA propõe, você aprova o diff |
| Rubber-duck | Explicar o problema para o modelo já força você a articular — muitas vezes a solução aparece antes da resposta |
| Debug com IA | Cole o erro + o trecho + o que você já tentou; mas o breakpoint continua sendo seu (→ DevTools & Debug) |
| Commit messages / PR description | Ótimo caso de uso; revise para não inventar o "porquê" |
| Docs | Gerar rascunho de README/docstring a partir do código; revisar precisão |
| Quando parar | Se você está brigando com a IA há 20 min, feche e resolva sozinho — às vezes é mais rápido |
| Manter a habilidade | Continue escrevendo código sem IA às vezes; não atrofie o fundamento |
✔️ Auto-checagem
Como validar código gerado a partir de uma spec? Por que rubber-duck funciona? Quando você deve fechar a IA e resolver sozinho?
Checklist final de vibecoding
Se você marca todos, está usando IA de forma responsável. Onde travar, volte à seção.
- entendo que sou o autor e o revisor do código gerado
- escolho o modo (autocomplete / chat / agente / web) pela tarefa
- quebro tarefas grandes em passos pequenos e aprovo cada diff
- dou contexto: arquivos, seleção, exemplos do repo, e regras versionadas (
CLAUDE.md/.cursorrules) - peço o plano antes do código em tarefas não triviais
- peço diffs pequenos e revisáveis
- leio cada linha, rodo e testo — nunca commito o que não entendo
- submeto o código gerado ao mesmo code review e CI do código humano
- caço API/pacote alucinado, over-engineering, duplicação e padrão errado copiado
- nunca colo segredos/PII/código proprietário no prompt
- reviso o código gerado para falhas de segurança (SQLi, XSS,
eval, authz) - trato arquivos/deps/issues como conteúdo não confiável (prompt injection)
- reviso cada comando/ação de agente; menor privilégio
- deixo arquitetura e escolha de dependência para decisão humana
- mantenho PRs pequenos e não deixo a IA ser a única que "sabe" o sistema
- fecho a IA e resolvo sozinho quando estou brigando com ela
Aprofundamento: Vibecoding (completa) · Aceleração de Código com IA · Criação de Agentes de IA · Segurança de Aplicações de IA · Testing & Automação · DevTools & Debug.