Vibecoding

O termo foi popularizado por Andrej Karpathy no começo de 2025: você descreve o que quer, a IA escreve o código, e você julga pelo resultado em vez de ler linha por linha. Funciona — até o dia em que precisa de alguém que entenda o que foi escrito.

Os nomes mudam todo mês; as categorias, não. Saber em qual categoria está o problema já resolve metade da escolha.

Construtor é ótimo até deixar de ser. Os sinais de que chegou a hora de levar o código para um agente, no seu computador:

• cada ajuste pequeno custa um pedido inteiro e mexe em coisa que você não pediu
• você precisa de algo que a plataforma não oferece — outro banco, outra hospedagem, um script próprio
• o projeto virou coisa séria e precisa de histórico, revisão e backup
• você quer entender o que está no código, não só o que aparece na tela

Antes de começar num construtor, confira como o código sai de lá: a maioria sincroniza com o GitHub ou deixa baixar o projeto. Se não houver saída, o projeto mora na plataforma — e o dia em que ela mudar de preço ou de regra é o dia em que você recomeça do zero.

Quase toda ferramenta deixa escolher entre um modelo mais capaz e um mais rápido. A regra prática: o grande para decidir, o rápido para executar.

Trocar de ferramenta no meio do projeto quase sempre custa mais do que ganha: o contexto, as decisões e o jeito de pedir ficam para trás. Fique com uma principal — e use as outras como revisoras.

Revise este código como se fosse para produção.
Não reescreva nada. Liste, do mais grave ao menos grave:
erros de lógica, falhas de segurança, o que quebra no celular
e o que vai ser difícil de manter.

[cole o arquivo ou o diff]

Cada fonte serve a uma pergunta diferente. Procurar "site bonito" no lugar errado rende uma hora de rolagem e nenhuma decisão.

Pinterest, Behance, Dribbble e Kittl mostram design — o clima, a composição, a identidade. Awwwards, Godly e Land-book mostram site funcionando — a rolagem, o ritmo das seções, a interação. Um projeto bom costuma usar os dois: o primeiro para decidir como ele parece, o segundo para decidir como ele se comporta.

Trinta prints viram "faça algo moderno". Três prints, cada um com o motivo, viram decisão.

Junte muito, mande pouco. Coletar pode ser à vontade: no Pinterest, uma pasta por projeto, com seções dentro dela — layout, tipografia, cor, foto —, e o Behance e o Kittl para ver identidade e tipografia aplicadas de verdade. Na hora de pedir à IA, saem dali só as três que respondem às perguntas do projeto.

REFERÊNCIAS (anexas)
1. site-a.png — pego o ritmo: seções curtas, muito respiro entre elas
2. site-b.png — pego só a hero: título enorme à esquerda, foto recortada à direita
3. site-c.png — pego os cards de serviço: número grande, uma linha de texto

NÃO pego: as cores de nenhum dos três, nem as fotos.

• Uma por pergunta: uma para o layout, uma para a tipografia, uma para o movimento.
• Sempre com o motivo: referência sem motivo vira ordem de cópia.
• Diga o que não pegar: corta a média das três antes de ela aparecer.

Antes de mandar o print para a IA, abra a página original e tire as medidas. Com número na mão, o pedido deixa de ser "parecido com isso" e vira especificação.

Estrutura, ritmo e ideia de interação não têm dono. Texto, foto, ilustração, logo e código com licença têm.

Em projeto React com Tailwind — o que Lovable, v0 e Bolt costumam gerar —, o shadcn/ui virou o ponto de partida mais comum. A diferença para uma biblioteca tradicional: ele copia o código do componente para dentro do seu projeto. O código passa a ser seu; atualização é você quem decide.

# num projeto React + Tailwind já criado
npx shadcn@latest init
npx shadcn@latest add button dialog

Todo agente lê um arquivo de instruções do projeto antes de começar. É onde moram as decisões travadas, o jeito de entregar e o que não pode ser tocado — o resumo que vira arquivo.

O nome e o lugar mudam de versão para versão — confira na documentação da sua ferramenta. O conteúdo é o mesmo em todas, e dá para manter um arquivo só e apontar os outros para ele.

Uma skill é uma pasta com um arquivo SKILL.md: um nome, uma descrição de quando ela serve, e as instruções. O agente lê só a descrição até precisar; quando a tarefa bate, carrega o resto. É o jeito de ensinar um processo seu — o checklist de entrega, o padrão de commit, o estilo de texto — sem colar tudo em toda conversa.

---
name: entrega-landing
description: Use antes de entregar uma landing page ao cliente — revisa contraste, 390px, formulário e metadados.
---

# Entrega de landing page

1. Abra a página em 390px e aponte o que estoura na horizontal.
2. Confira contraste 4.5:1 em todo texto.
3. Teste o formulário e o link de WhatsApp.
4. Liste o que faltar como [PENDENTE]. Não corrija sem perguntar.

Como usar: com a barra, pelo nome

O jeito garantido de usar uma skill é chamá-la: digite / seguido do nome, e o que vier depois vai junto como pedido. A barra também abre a lista das skills instaladas — não precisa decorar os nomes.

/entrega-landing
/entrega-landing só a página de contato
/emil-design-eng revise os botões desta página

Sem a barra, a skill também pode entrar sozinha: quando o pedido bate com a descrição dela, o agente carrega por conta própria. Mas "pode" não é "vai" — para processo que precisa acontecer, chame pelo nome.

O Model Context Protocol é um padrão aberto, lançado pela Anthropic no fim de 2024, para ligar um assistente a outros sistemas: o navegador, o Figma, o GitHub, um banco de dados. Cada ligação é um "servidor MCP" que expõe ferramentas — e o agente passa a poder abrir a página, ler o frame do design ou consultar a tabela sozinho.

# Claude Code: dar ao agente um navegador para abrir e testar a página
claude mcp add playwright -- npx @playwright/mcp@latest

# ver os que estão ligados
claude mcp list

Três formas de automatizar o que você repete. Nenhuma é obrigatória — comece a usar quando se pegar digitando a mesma coisa pela terceira vez.

No Claude Code, subagentes ficam em .claude/agents/ e hooks nas configurações (settings.json). A diferença que importa: skill e comando são sugestão que o agente segue; hook é regra que o sistema executa — se precisa acontecer sempre, é hook.

Os agentes deixam escolher quanto de liberdade dar: perguntar antes de cada edição, editar sozinho, ou só planejar sem tocar em nada. O modo plano é o plano antes do código transformado em botão.

O sinal é sempre o mesmo: o erro volta, a correção desfaz a anterior, e o arquivo cresce a cada pedido. Continuar pedindo "tente de novo" só aprofunda o buraco.

1. Pare e peça a causa, não a correção: "sem mexer em nada, me diga em uma frase por que isso acontece".
2. Dê o que falta: a mensagem exata de erro, o passo a passo para reproduzir, o que já foi tentado.
3. Volte ao último estado bom: desfaça pelo Git e peça de novo, menor.
4. Recomece a conversa com um resumo curto — o contexto longo é parte do problema.

"Não está funcionando" obriga a IA a adivinhar. Um relato bom tem quatro partes e cabe em cinco linhas:

ONDE: o botão "Enviar" do formulário de contato
O QUE ACONTECE: nada; o console mostra
  TypeError: Cannot read properties of null (reading 'value') em form.js:12
COMO REPRODUZIR: Chrome no celular, 390px, preencher e tocar em Enviar
O QUE DEVERIA: abrir o WhatsApp com a mensagem pronta

• A mensagem do console copiada, não resumida: o arquivo e a linha estão nela.
• O print quando o problema é visual — com a largura da tela anotada.
• O que mudou desde a última vez que funcionou.

Com Git, errar sai barato: cada pedido grande começa de um ponto salvo, e voltar é um comando. Sem Git, a IA pode reescrever o arquivo que funcionava e não existe caminho de volta.

git add -A && git commit -m "antes de refazer o menu"   # salva o ponto

git diff                 # o que a IA mudou desde o último commit
git restore arquivo.css  # desfaz as mudanças de um arquivo
git restore .            # desfaz todas as mudanças ainda não salvas

git log --oneline        # os pontos salvos
git revert HEAD          # desfaz o último commit criando outro — seguro

A resposta diz "pronto, corrigi". O diff mostra o que de fato mudou — e é onde aparecem os problemas que a resposta não conta.

Vai acontecer, e não é motivo para aceitar no escuro. Três pedidos resolvem quase sempre:

Explique este arquivo em dez linhas, para quem não programa:
o que ele faz, de onde vêm os dados e para onde vão.

Quais três coisas neste código quebrariam primeiro se
mudássemos de hospedagem ou se dez vezes mais gente usasse?

Me mostre a menor mudança possível para [o que eu quero],
e explique cada linha dela antes de aplicar.

Tudo o que está no JavaScript do navegador é público — qualquer pessoa abre o DevTools e lê. Isso inclui variável de ambiente com prefixo de "pública": VITE_ no Vite e NEXT_PUBLIC_ no Next.js vão parar dentro do arquivo que o visitante baixa.

# .env — nunca vai para o Git
OPENAI_API_KEY=sk-...          # só o servidor lê
VITE_SUPABASE_URL=https://...  # público de propósito
VITE_SUPABASE_ANON_KEY=...     # público de propósito, protegido pelas regras do banco

# .gitignore
.env
.env.local

No Supabase, a chave pública fica no front por projeto — quem protege os dados são as regras de acesso por linha (Row Level Security). Tabela sem essas regras, com a chave pública à vista, é tabela que qualquer pessoa lê e apaga.

-- liga a proteção: sem regra, ninguém acessa pela chave pública
alter table pedidos enable row level security;

-- cada pessoa lê só os próprios pedidos
create policy "ler os meus pedidos" on pedidos
  for select using (auth.uid() = user_id);

-- e só cria pedido em nome de si mesma
create policy "criar o meu pedido" on pedidos
  for insert with check (auth.uid() = user_id);

No Firebase, o equivalente são as regras de segurança do Firestore — e o "modo de teste", que libera tudo por um tempo, não é para ir ao ar.

Serviço cobrado por uso não avisa quando algo dá errado — cobra. Um laço que chama a API sem parar, um formulário sem proteção contra robô, ou uma chave vazada viram fatura.

• Limite de gasto e alerta no painel de cada serviço pago, antes de ir ao ar.
• Chamada paga sempre pelo servidor, nunca direto do navegador — e com limite de pedidos por pessoa.
• Proteção no formulário: um campo-armadilha ou um desafio simples já barra a maior parte dos robôs.
• Olhe o painel de uso nos primeiros dias depois de publicar.

O caminho mais curto hoje, e o que a maioria dos construtores e agentes já prepara:

1. o código num repositório do GitHub (o construtor sincroniza, ou o agente faz o primeiro push);
2. na Vercel, Netlify ou Cloudflare Pages: "importar projeto do GitHub";
3. as variáveis de ambiente cadastradas no painel da hospedagem — não no código;
4. cada push publica sozinho, e cada branch ganha um endereço de prévia para testar antes;
5. o domínio próprio apontado por último, quando tudo estiver certo.

A checagem curta que separa protótipo de coisa publicável. Peça à IA para conferir item por item — e confira você os três primeiros.

Ferramenta troca; o método vai junto. Tudo isto funciona igual em qualquer uma delas — e é por isso que vale mais do que dominar os atalhos de uma só: