Sexta-feira, 14h. O RH manda a quinta planilha do mês pedindo o mesmo relatório: quantas pessoas entraram, saíram e mudaram de cargo nos últimos 30 dias. O dado existe em três sistemas que ninguém integra. Eu abri o Claude Code, descrevi o problema em quatro parágrafos, e em três horas tinha uma ferramenta interna que o time inteiro usa hoje. Não escrevi praticamente nenhuma linha de código — corrigi prompts, li o que a IA me devolveu, rejeitei umas decisões ruins, deixei outras passarem.
Isso é vibe coding. E em 2026 já não é um experimento de fim de semana — é como muita gente está construindo software de verdade.
Por que isso importa para você (mesmo que você não seja dev)
O termo "vibe coding" foi cunhado por Andrej Karpathy em fevereiro de 2025 e descreve um jeito de programar onde você "se entrega às vibrações" e deixa o LLM escrever o código enquanto você guia, testa e dá feedback. A definição original era leve, quase brincalhona — para protótipos descartáveis. Em 2026 a coisa amadureceu: o Collins Dictionary elegeu "vibe coding" Palavra do Ano de 2025, e ferramentas como Claude Code, Cursor, v0 e Replit Agent saíram do hype e foram para a stack diária de times de engenharia.
Para profissionais não-dev — designers, gestores, analistas, gente de marketing — isso muda o jogo. Você não precisa mais esperar fila do squad de engenharia para ter uma ferramenta interna, um scraper, um dashboard. Mas vibe coding tem armadilhas reais, e a maior parte do que se publica é demo de YouTube. Aqui estão sete projetos que realmente construímos entre janeiro e abril de 2026 — com tempos, custos, e o que quebrou.
O que estamos contando: regras do jogo
Para cada projeto abaixo eu listei: o problema, a stack escolhida, quanto tempo levou da ideia até estar rodando para usuários reais, o orçamento de API consumido (quando relevante), e o que falhou. Nenhum desses projetos foi escrito do zero por IA sem revisão — eu li o código, rodei testes, e em alguns casos joguei tudo fora. Isso é importante porque, como o Simon Willison apontou no blog dele, "se um LLM escreveu cada linha do seu código, mas você revisou, testou e entendeu tudo, isso não é vibe coding — é usar o LLM como assistente de digitação". Eu uso os dois modos. Vou dizer qual foi qual.
Projeto 1 — Ferramenta interna de RH (a história do começo)
Problema: planilha mensal de movimentação de pessoal, dados em três fontes (Gupy, ADP, planilha do gestor).
Stack: Claude Code 4.7 no terminal + SQLite local + Next.js 15 (server components) + Tailwind. Deploy em Vercel.
Tempo: 3 horas para o MVP, mais 2 horas no dia seguinte para corrigir o cálculo de turnover (estava contando demissões em duplicidade quando a pessoa mudava de CNPJ interno).
Custo de API: cerca de US$ 4 em tokens (Opus 4.7 cobra o mesmo que 4.6, conforme a Anthropic anunciou).
O que aprendi: descrever o problema de domínio (o que é "movimentação de pessoal", quem usa, qual a saída esperada) vale mais do que descrever a solução técnica. O primeiro prompt que funcionou tinha 380 palavras só explicando o RH. Quando tentei começar com "faça uma API que integre Gupy e ADP", a IA gerou código bonito que respondia a pergunta errada.
O que NÃO funcionou: pedir para a IA "modelar o banco". Os schemas que ela propôs eram genéricos demais. Modelei à mão em 20 minutos, colei o SQL no contexto, e a partir dali o resto fluiu.
Projeto 2 — Scraper de preços de fornecedores
Problema: monitorar preços de 14 fornecedores de equipamento de escritório para uma operação que compra para revenda.
Stack: Cursor (com Sonnet 4.5 para edição rápida e Opus 4.6 para arquitetura) + Playwright + cron no Railway.
Tempo: 6 horas para a primeira versão funcional, 14 horas distribuídas nas seis semanas seguintes consertando coisas.
Custo: R$ 90/mês de Railway + uns US$ 8 de tokens.
O que aprendi: scraping é o caso clássico onde vibe coding parece mágica e quebra cedo. A IA escreve seletores CSS lindamente. Eles funcionam. Aí o site muda o markup, e você não fez teste nenhum, e descobre que o pipeline está silenciosamente reportando o mesmo preço há quatro dias.
O que NÃO funcionou: confiar no scraper. Em 11 dias após o deploy, três dos 14 sites já tinham mudado a estrutura e meu scraper estava devolvendo null sem alertar ninguém. O fix foi pedir para a IA escrever um "schema validator" que falhasse alto se o output não casasse com o formato esperado. Isso eu nunca teria feito sozinho na pressa — foi um prompt explícito do tipo "como você protegeria esse pipeline de mudanças silenciosas no DOM?". A IA respondeu bem, mas só depois que eu perguntei.
Projeto 3 — Dashboard financeiro pessoal
Problema: minha mulher e eu queríamos ver receita, despesa e investimento mês a mês, com importação automática de CSVs do Nubank, Itaú e XP.
Stack: v0 da Vercel para o front, Claude Code para o parser de CSV, Postgres no Neon.
Tempo: 4 horas para a UI no v0, 5 horas para o parser e o banco.
O que aprendi: o v0 é absurdamente bom para protótipo de UI. Você descreve o dashboard, ele entrega componentes shadcn/ui prontos. Mas — e aqui dói — eu confiei em uma agregação de "saldo no mês" que estava com bug de timezone. Por duas semanas nós tomamos decisões de gasto baseadas em saldos errados em até R$ 1.200. O dado do Nubank vinha em UTC, o do Itaú em America/Sao_Paulo, e a IA assumiu que tudo estava em local time. Isso não é culpa da IA — é culpa minha por não ter escrito teste.
O que NÃO funcionou: pular os testes "porque é um projeto pessoal". A regra que adotei depois disso: qualquer projeto que toma uma decisão real (financeira, operacional) tem teste, mesmo que seja pessoal.
Projeto 4 — Gerador de propostas comerciais
Problema: o sócio gastava 90 minutos por proposta editando um Google Doc.
Stack: Claude Code + Next.js + uma API interna chamando o modelo da OpenAI para o texto + jsPDF.
Tempo: 8 horas no total, distribuídas em três sessões.
O que aprendi: separar "lógica determinística" (cálculo de preço, prazo, formatação do PDF) de "lógica criativa" (texto da proposta) salva muita dor. A IA escreveu o gerador determinístico em 1 hora; a parte de texto livre teve 4 iterações até o sócio aprovar o tom.
O que NÃO funcionou: deixar a IA escolher a biblioteca de PDF. Ela puxou três libs diferentes em três prompts. Acabei fixando: "use jsPDF, nada mais". A partir daí o código convergiu.
Projeto 5 — Bot de Telegram para alerta de vagas
Problema: filtrar vagas de Product Manager em São Paulo com salário > R$ 18k publicadas nas últimas 24h.
Stack: Replit Agent + API do LinkedIn (não-oficial, via biblioteca aberta) + Telegram Bot API.
Tempo: 90 minutos. Sério.
Custo: zero, dentro do free tier do Replit.
O que aprendi: para projetos pequenos, encapsulados, sem stakeholder, o Replit Agent é o caminho mais rápido. Você descreve, ele provisiona ambiente, escreve, testa e roda. Esse projeto está rodando há 4 meses sem manutenção.
O que NÃO funcionou: a primeira versão tentou raspar o LinkedIn diretamente. Tomou ban em duas horas. A segunda versão usa um agregador público de vagas como fonte. Lição: quando a IA propõe uma solução que vai contra os Termos de Serviço de uma plataforma, ela vai propor mesmo assim. A responsabilidade de barrar é sua.
Projeto 6 — Conversor de podcast em post de blog
Problema: transformar episódios de 50 minutos em rascunhos de blog post estruturado em pt-BR.
Stack: Whisper (local, via whisper.cpp) para transcrição + Claude (via API) para estruturação + um script CLI escrito 100% por Claude Code.
Tempo: 2 horas para o MVP. Mais 6 horas brincando com prompts para o tom ficar bom.
Custo: cerca de US$ 0,30 por episódio em tokens.
O que aprendi: 90% do trabalho aqui foi prompt engineering, não código. O código tem 180 linhas, escrito num prompt só. Os prompts internos (o que pedir para o modelo gerar o post) tomaram dias de iteração.
O que NÃO funcionou: deixar a IA "resumir" o episódio. Resumos genéricos saíam toda vez. Só funcionou quando eu dei estrutura: hook + 3 sub-temas + quote + call to action. Esqueleto humano, recheio de IA.
Projeto 7 — Ferramenta de revisão de contratos para escritório jurídico
Problema: extrair cláusulas de risco (confidencialidade, multa, foro) de contratos PDF.
Stack: Cursor (Opus 4.6) + LangChain + pgvector no Postgres + interface em Streamlit.
Tempo: 14 horas, distribuídas em 5 dias.
Custo: ~US$ 60 em embeddings e tokens durante o desenvolvimento.
O que aprendi: domínios regulados (jurídico, médico, financeiro) não toleram vibe coding puro. O sócio do escritório passou 6 horas comigo lendo cada teste, marcando falsos positivos. A IA pegava cláusulas de "foro" mas confundia "foro de eleição" com "foro privilegiado" — diferença material em direito processual brasileiro. Sem o especialista no loop, isso vira automação ruim.
O que NÃO funcionou — e aqui foi grave: a primeira versão entregava um "score de risco" de 0 a 100. O sócio me disse: "isso é mentira; risco contratual não é número". Joguei o score fora, virei classificação por categoria com citação literal da cláusula. Foi o melhor feedback que recebi no trimestre.
Os dois projetos que jogamos fora (porque transparência importa)
Além dos sete acima, comecei mais dois projetos em 2026 que não vingaram:
- Um app de receitas com sugestão por foto da geladeira. Funcionou no demo, mas custava ~US$ 0,12 por uso real (visão computacional + LLM). Não havia modelo de receita que sustentasse isso para um app pessoal. Matamos depois de 5 horas investidas.
- Um clone simplificado do Notion para anotações pessoais. Cinco prompts, três bibliotecas conflitantes, dois bugs de drag-and-drop que nunca consegui reproduzir. Aceitei a derrota e voltei para o Obsidian. Lição: editores ricos de texto ainda são um buraco. Vibe coding não é mágica para problemas que continuam difíceis para times humanos experientes.
Framework que eu uso para decidir se um projeto cabe em vibe coding
Depois desses sete (mais os dois fracassos), montei uma checklist mental antes de abrir o Claude Code:
- O domínio é regulado? Se sim, especialista humano no loop, não-negociável.
- A saída toma decisão real (dinheiro, contratação, saúde)? Se sim, teste. Mesmo "projeto pessoal".
- Depende de fonte externa instável (scraping, API não-oficial)? Se sim, schema validator + alerta de quebra desde o dia 1.
- Eu consigo descrever o problema em um parágrafo claro? Se não, não é hora de prompt — é hora de pensar.
- Eu vou manter isso? Se ninguém vai manter, vibe codar com prazer. Se for produção, leia o código.
Essa checklist me poupou de uns 4 retrabalhos no último trimestre.
Honest caveats: onde esse conselho não se aplica
- Sistemas com SLA crítico (saúde, fintech regulada, infra). Vibe coding gera código que funciona; gera muito menos código que sobrevive a edge cases não-óbvios. Eu não usaria essa abordagem em nada que tenha PIX em produção sem revisão linha a linha.
- Times grandes com convenções fortes. A IA escreve código no estilo dela. Em time grande isso vira atrito. Vale ter regras escritas (no Cursor: arquivo
.cursor/rules; no Claude Code: CLAUDE.md no repo) que documentam padrões do time.
- Projetos onde a aprendizagem é o objetivo. Se você está estudando para entender, pedir o código pronto te rouba o aprendizado. Vibe coding é para entregar valor, não para aprender estrutura de dados.
E, acima de tudo: vibe coding não substitui ler código. A própria definição de IBM e Google Cloud deixa claro — você ainda é o responsável pelo que vai para produção.
O que fazer hoje, na prática
Se você nunca fez vibe coding, comece pequeno e específico. Sugestões em ordem:
- Quem nunca programou: abra o v0 ou o Replit Agent. Construa uma calculadora de algo que você usa no trabalho (custo de transporte, ROI de campanha, comissão). 2 horas, produto rodando.
- Quem programa um pouco: instale o Cursor (free tier dá conta), escolha um problema chato do seu trabalho, descreva em 3 parágrafos, deixe a IA propor. Revise antes de aceitar.
- Quem programa profissionalmente: ainda assim vale começar pelo problema chato — não pelo projeto ambicioso. A curva de aprendizado é em "como prompto", não em "qual ferramenta".
Para aprofundar: temos o curso de Programação com IA na aulasdeia.com cobrindo os fluxos do Claude Code e Cursor com projetos guiados em pt-BR. Para ver como esse mesmo padrão se aplica em automação de fluxos de marketing e em ferramentas internas para times pequenos, os outros cornerstones do blog cobrem casos relacionados.
Sobre o autor
Equipe Editorial AulasDeIA é engenheiro de software com mais de uma década de experiência em desenvolvimento web e instrutor da aulasdeia.com. Tem usado ferramentas de IA generativa em produção desde o lançamento do Cursor Composer em 2024 e lidera o currículo de programação assistida por IA da plataforma. Os projetos descritos neste artigo foram construídos pessoalmente entre janeiro e abril de 2026, com aprovação dos clientes para uso anônimo dos números.
