Quero deixar algo bem claro antes de começarmos.
Guarda isto :)
Não sou desenvolvedor. Nunca fui desenvolvedor. Não tenho um diploma em ciência da computação. Não fiz nenhum bootcamp de programação. Não consigo ler a maioria dos códigos e dizer o que eles fazem.
Mas no fim de semana passado, coloquei uma aplicação web funcional no ar. Usuários reais se cadastraram. Dados reais foram armazenados. Funcionalidades reais funcionaram.
Construí tudo com o Claude Code em dois dias. E vou contar a verdade sobre como foi essa experiência. Não a versão editada. A realidade bagunçada, frustrante e cheia de descobertas.
Porque toda história de "construí um app com IA" na internet parece fácil. Não é fácil. Mas é muito, muito possível.
Sábado de Manhã: A Ideia
Queria construir uma ferramenta simples. Um calendário de conteúdo que permite planejar suas postagens em várias plataformas, arrastá-las entre os dias e marcá-las como publicadas. Nada revolucionário. Mas algo que eu realmente precisava para meu próprio fluxo de trabalho.
Abri o Claude Code no meu terminal pela primeira vez às 9h de sábado.
Às 9h15 já tinha cometido meu primeiro erro.
Erro #1: Começar Sem um Plano
Meu primeiro prompt para o Claude Code foi:
Construa um app de calendário de conteúdo para mim
O Claude gerou vários arquivos. Algo apareceu na tela. Parecia um calendário de conteúdo projetado por alguém que nunca viu um calendário.
É aqui que 90% das pessoas desistem. Elas digitam um prompt vago, recebem um resultado vago e concluem que vibe coding não funciona.
O problema não era o Claude. O problema era eu. Não tinha dado nada para ele trabalhar.
O que eu deveria ter feito:
Deveria ter começado no Modo Plano. Pressione Shift + Tab no Claude Code para alternar do Modo Ação para o Modo Plano. No Modo Plano, o Claude pensa antes de construir. Ele faz perguntas. Mapeia a arquitetura. Mostra o que planeja criar.
Voltei atrás e fiz direito:
Quero construir um app web de calendário de conteúdo. Antes de escrever qualquer código, vamos planejar isso.
O app precisa de:
- Uma visão semanal com 7 colunas (segunda a domingo)
- A capacidade de adicionar postagens com título, plataforma (Twitter, LinkedIn, Instagram) e status (rascunho, agendado, publicado)
- Arrastar e soltar para mover postagens entre os dias
- Um design simples e limpo usando Tailwind CSS
- Dados armazenados em um banco de dados local para persistir entre sessões
Qual pilha de tecnologia devemos usar? Qual é a estrutura de pastas? Explique a arquitetura antes de construir qualquer coisa.
O Claude voltou com um plano detalhado. Next.js como framework. SQLite para o banco de dados. Tailwind para estilização. Uma estrutura de pastas limpa, organizada arquivo por arquivo.
Lição aprendida: Sempre comece no Modo Plano. Sempre descreva o que você quer em detalhes. Os 5 minutos que você gasta planejando economizam 2 horas de reconstrução.
Erro #2: Tentar Construir Tudo de Uma Vez
Depois de planejar, fiquei empolgado. Pedi ao Claude para construir tudo de uma só vez.
O resultado foi uma bagunça. Algumas funcionalidades funcionaram. Outras estavam pela metade. O arrastar e soltar estava quebrado. O banco de dados não estava salvando corretamente. Não fazia ideia de por onde começar a consertar.
O que eu deveria ter feito:
Construir uma funcionalidade de cada vez. Essa é a regra de ouro do vibe coding.
Recomecei e segui esta ordem:
Sessão 1: Apenas o layout básico da página. Sete colunas. Sem funcionalidades.
Sessão 2: Adicionar a capacidade de criar uma postagem (apenas um formulário simples).
Sessão 3: Exibir postagens salvas na coluna do dia correto.
Sessão 4: Adicionar funcionalidade de arrastar e soltar.
Sessão 5: Adicionar a funcionalidade de status (rascunho/agendado/publicado).
Sessão 6: Deixar com uma aparência bonita.
Cada funcionalidade teve sua própria conversa. Contexto novo. Tarefa clara. Resultado limpo.
Quando construí uma funcionalidade de cada vez, cada uma funcionou perfeitamente. Quando tentei construir tudo de uma vez, nada funcionou.
Lição aprendida: Uma conversa por funcionalidade. Nunca misture várias funcionalidades na mesma sessão do Claude Code.
Erro #3: Não Criar um Arquivo [CLAUDE.md](http://claude.md/)
No sábado à tarde, já tinha um layout básico funcional e estava animado. Mas continuava encontrando os mesmos problemas:
O Claude insistia em adicionar complexidade desnecessária. Criava sistemas elaborados de tratamento de erros quando eu só queria um try-catch simples. Adicionava bibliotecas de animação quando eu só queria uma transição limpa. Reestruturava todo o meu sistema de pastas quando eu pedia uma pequena alteração.
Estava corrigindo as mesmas coisas repetidamente.
Então lembrei de ter lido sobre o CLAUDE.md.
Criei um arquivo na raiz do meu projeto:
CLAUDE.md
Regras do Projeto
- Este é um calendário de conteúdo simples. Mantenha tudo mínimo.
- Use Next.js 14 com o App Router
- Use Tailwind CSS para toda a estilização. Sem outros frameworks CSS.
- Use SQLite com Prisma ORM para o banco de dados
- Mantenha simples. Sem abstrações ou padrões de projeto desnecessários.
- Quando eu disser "deixe bonito", quero dizer: espaçamento limpo, fontes legíveis, efeitos de hover sutis, cantos arredondados
- Nunca adicione novas dependências sem me perguntar primeiro
- Pergunte antes de refatorar qualquer código existente
Estilo de Código
- Código simples e legível. Um iniciante deve ser capaz de entendê-lo.
- Nomes de variáveis claros. Sem abreviações.
- Comentários apenas para lógica não óbvia
Depois de criar este arquivo, a experiência mudou drasticamente. O Claude parou de superengenharia. Parou de adicionar bibliotecas aleatórias. Parou de reestruturar coisas que eu não tinha pedido para tocar.
Toda vez que o Claude fazia algo que eu não queria, adicionava uma nova regra ao [CLAUDE.md](http://claude.md/). No domingo à noite, este arquivo já tinha mais de 30 regras e o Claude estava seguindo todas perfeitamente.
Lição aprendida: Crie o [CLAUDE.md](http://claude.md/) no primeiro dia. Atualize-o constantemente. É a ferramenta mais poderosa do Claude Code.
Erro #4: Não Usar Screenshots
Sábado à noite. O app funciona, mas está feio. Digitei isto:
Deixe o design mais moderno e profissional
O Claude mudou coisas. Ficou diferente. Não melhor, só diferente.
Eu estava tentando descrever problemas visuais com palavras. Isso é incrivelmente ineficiente.
Em vez disso, comecei a tirar screenshots de sites cujo design eu amava. Colei-os diretamente no Claude Code:
[screenshot de uma interface de calendário limpa]
Quero que meu calendário se pareça com isto. Especificamente:
- Este tom exato de cinza para o fundo
- Estes cards arredondados para cada postagem
- Esta quantidade de espaçamento entre os elementos
- A maneira como o dia ativo é destacado em azul
O Claude combinou o design quase perfeitamente. Na primeira tentativa.
Então, quando algo parecia estranho, em vez de descrever, eu tirava um screenshot, circulava a área problemática, colava e dizia "esse espaçamento está errado" ou "essa fonte está muito pequena."
Lição aprendida: Screenshots são 10x melhores que palavras para feedback visual. Sempre cole imagens em vez de descrever o que você vê.
Domingo: Tudo se Juntou
No domingo de manhã, já tinha um app funcional com design limpo, arrastar e soltar, dados persistentes e um banco de dados funcionando. Tinha construído tudo sem entender a maior parte do código.
Mas ele só existia no meu laptop. Hora de publicar.
Erro #5: Ter Medo da Publicação
Publicação parecia aterrorizante. Servidores. Domínios. DNS. Arquivos de configuração.
Quase parei. Quase decidi que "rodar localmente é suficiente."
Mas insisti e perguntei ao Claude:
Quero publicar este app ao vivo na internet. Quero usar Vercel porque ouvi dizer que é o mais fácil. Explique os passos exatos.
O Claude me deu sete passos:
- Enviar o código para o GitHub (Claude me ajudou a configurar o Git)
- Cadastrar-se no Vercel (gratuito)
- Conectar o Vercel ao meu repositório do GitHub
- Configurar as variáveis de ambiente para o banco de dados
- Clicar em publicar
- Aguardar 90 segundos
- Obter minha URL ao vivo
Segui os passos. Três minutos depois, meu app estava no ar. Enviei a URL para cinco pessoas. Elas abriram. Funcionou.
Lição aprendida: Publicação não é assustadora. É apenas uma lista de verificação. O Claude vai te guiar em cada passo.
As 12 Regras Que Eu Gostaria de Saber Antes de Começar
Tudo que aprendi em dois dias, comprimido em regras:
Regra 1: Comece no Modo Plano toda vez. Shift + Tab. Pense antes de construir.
Regra 2: Uma conversa por funcionalidade. Contexto novo é contexto melhor.
Regra 3: Crie o CLAUDE.md no primeiro dia. Cada correção vira uma regra permanente.
Regra 4: Use screenshots para todo problema visual. Circule o problema. Cole diretamente.
Regra 5: Construa a versão mais simples primeiro. Adicione complexidade só depois que a versão simples funcionar.
Regra 6: Descreva o que você quer em detalhes. Quanto mais específico seu prompt, melhor o resultado. "Construa uma página de login" gera algo ruim. "Construa uma página de login com campos de e-mail e senha, um link 'esqueci a senha' abaixo, um botão de envio azul e um redirecionamento para /dashboard ao sucesso" gera exatamente o que você pediu.
Regra 7: Use /compact quando as conversas ficarem longas. A qualidade do Claude cai quando o contexto fica cheio.
Regra 8: Faça commit no Git após cada funcionalidade funcional. O Claude pode ajudar com isso. Se algo quebrar, você pode reverter.
Regra 9: Quando algo quebrar, copie a mensagem de erro e cole no Claude. Diga "Diagnostique a causa raiz antes de consertar qualquer coisa." O Claude quase sempre encontra o problema instantaneamente.
Regra 10: Não tente entender cada linha de código. Entenda o que cada arquivo faz e como eles se conectam. Isso é suficiente para direcionar o Claude de forma eficaz.
Regra 11: Quando o Claude ficar preso em um loop consertando a mesma coisa repetidamente, pare. Comece uma conversa nova. Cole apenas o arquivo relevante e uma descrição clara do problema.
Regra 12: Publique antes de estar perfeito. A versão um não precisa ser bonita. Precisa funcionar. Você sempre pode melhorar na versão dois.
O Que Construí Desde Aquele Fim de Semana
Isso foi há três semanas. Desde então, construí:
- Um portal de onboarding para clientes com login e upload de arquivos
- Um painel interno que acompanha minhas métricas de conteúdo
- Um gerador de faturas simples que cria PDFs a partir de um formulário
- Um gerenciador de favoritos que salva e organiza links por tópico
Ainda não consigo ler a maioria dos códigos. Ainda não entendo 80% do que está acontecendo nos arquivos. Mas consigo descrever o que quero com clareza suficiente para que o Claude construa. Consigo depurar problemas mostrando o erro ao Claude. Consigo publicar produtos funcionais na internet.
Isso é vibe coding. Você não é o programador. Você é o gerente de produto. Claude é o programador. Seu trabalho é saber o que construir e comunicar isso com clareza.
A maioria das pessoas vai continuar dizendo a si mesmas que precisam aprender a programar antes de construir qualquer coisa.
Aqueles que abrirem o terminal neste fim de semana terão um app funcional até segunda-feira de manhã. Eu sei porque foi exatamente isso que aconteceu comigo.
Siga-me @eng_khairallah1 para mais cursos, ferramentas e fluxos de trabalho sobre IA. Novo conteúdo toda semana.
Espero que tenha sido útil para você, Khairallah ❤️**
