Vibe coding: criar software conversando

O simulador deste site, a calculadora de tokens e o próprio layout foram feitos conversando. Descrevi o que queria, revisei o que veio, pedi ajustes. Não escrevi uma linha de código à mão. Isso é o que passaram a chamar de vibe coding: criar software descrevendo o resultado e deixando a IA escrever e corrigir.

Funciona, e melhor do que eu esperava. Mas tem um limite claro, e quem cruza esse limite sem saber costuma se arrepender. Este guia mostra onde ele funciona, onde exige cuidado e como fazer sem se enganar.

O que é, na prática

Você abre um assistente com capacidade de gerar e executar código (Claude com artifacts ou Claude Code, editores como Cursor, entre outros), descreve o que a pessoa vai fazer na tela e qual resultado espera, e a IA produz o programa. Você testa, aponta o que está errado, ela corrige. O ciclo se repete até funcionar.

A parte nova não é a IA escrever código, isso existe há anos. É a combinação de escrever, rodar, ver o erro e corrigir sozinha, com você só dizendo se o resultado está bom.

Onde funciona muito bem

Protótipos de uma tela com um único fluxo. Calculadoras e simuladores. Páginas e landing pages. Scripts de automação (renomear arquivos, consolidar planilhas, puxar dados de uma API). Dashboards internos. Ferramentas que você usa e pode testar na hora: se o número saiu errado, você vê.

O que esses casos têm em comum: resultado visível, fácil de verificar, sem dado sensível e sem dinheiro passando pelo sistema.

Onde exige alguém que leia código

Autenticação e senhas. Pagamentos. Dados pessoais de clientes. Qualquer coisa que rode sem supervisão e possa falhar em silêncio. A IA vai gerar código que parece correto, e muitas vezes é, mas um erro de segurança não aparece na tela: aparece meses depois, quando alguém acessa o que não devia.

Não é motivo para não usar IA nesses casos; é motivo para ter alguém revisando. A IA acelera; a revisão garante.

O erro mais comum

Chamar a API de IA direto do site, com a chave exposta no navegador. Qualquer visitante pode copiar a chave e gastar seu saldo. A chave tem que ficar em um servidor, e isso a IA só faz se você pedir.

Como pedir bem

Descreva o público, o que a pessoa faz na tela e qual o resultado esperado, em ordem. "Simulador com quatro perguntas de múltipla escolha; ao final mostra uma recomendação, três próximos passos e um botão para refazer" funciona. "Faz um simulador" não. Peça uma tela por vez. Só adicione banco de dados, login ou integrações depois que o fluxo básico funcionou e alguém usou.

Quando der erro, cole a mensagem completa e pergunte a causa antes de pedir a correção. Corrigir sem entender gera código remendado.

Do protótipo ao uso real: a ordem que evita retrabalho

A sequência que funcionou para mim: briefing de uma página (quem usa, o que faz, que resultado espera), protótipo de uma tela, teste com três pessoas de fora, ajustes na mesma conversa, publicação. Só depois disso eu penso em banco de dados, login ou integrações. Inverter essa ordem é o erro mais comum: a pessoa pede um sistema completo, recebe 2 mil linhas de código que não consegue revisar e trava na primeira falha.

Dois hábitos baratos que salvam horas: pedir que a IA escreva testes junto com o código, e guardar cada versão em um repositório com histórico. Quando algo quebra, você volta para a versão anterior em um minuto em vez de tentar entender o que mudou.

O que você ainda precisa saber

Ler código, mesmo devagar. Rodar e testar. Entender onde os dados ficam salvos. Saber o que é uma variável de ambiente. Com esse mínimo, você revisa o que a IA fez e evita os erros caros. Sem ele, você está confiando em algo que não consegue conferir, e software é uma área em que confiar sem conferir custa caro.

Perguntas frequentes

Fontes e método

• Documentação de artifacts e Claude Code da Anthropic
• Experiência própria construindo as ferramentas deste site, 2026