Como construí um software do zero sem saber programar — sem vibe coding

Construir um software do zero sem saber programar ainda é possível em 2026 — mas não do jeito que a maioria imagina. Não é colar código gerado por IA e torcer. Não é usar Lovable ou Cursor no piloto automático. É um trabalho diferente, que exige clareza arquitetural antes de qualquer linha de código. Neste post, conto como construí o Cadencia — um sistema completo de posicionamento digital — em dois meses, sem experiência em código, e o que aprendi com os 8 bugs que quase derrubaram o lançamento.

A pergunta não é "a IA escreve o código por você?". A pergunta é "você consegue pensar com clareza suficiente para especificar o que precisa?"

O ponto de partida: depois do N8N, o que vem?

Durante meses trabalhei com automações em N8N — conectando APIs, criando fluxos, tentando resolver problemas de negócio com agentes. Funcionava. Mas chegou um ponto em que percebo que automação tem teto: ela executa processos, não cria produtos. Se quero algo que escale, que tenha billing, que tenha autenticação, que tenha lógica proprietária — preciso de software.

A virada foi ler um artigo do Fab Dubin: um profissional com 15 anos em eventos que aprendeu a codar com IA e entregou três produtos para sua empresa sozinho. O que ficou não foi o resultado — foi a honestidade sobre o processo. Os erros. Os atalhos que deram errado. A sensação de não entender completamente o que estava construindo.

Aquilo me soou real. Decidi tentar.

Por que não fiz vibe coding — e qual é a diferença

Vibe coding é o termo para descrever o uso de IA generativa para gerar código sem realmente entender o que está sendo criado. Você descreve o que quer, aceita o output, reza para funcionar, e tenta de novo quando quebra. Como explico no post sobre como o vibe prompting explica a inconsistência com IA, o problema não é que o código seja ruim — é que você não sabe por que quebrou quando quebra em produção.

A alternativa que encontrei: usar o Claude Code como parceiro de arquitetura, não como gerador de código. Antes de qualquer implementação, as perguntas são:

• Por que esse banco de dados e não outro? Qual o trade-off?
• O que acontece quando essa API externa retorna vazio ou timeout?
• REST API ou MCP? Quando faz sentido cada um?
• Vercel ou VPS? O que muda no deploy e no custo operacional?

Quando você entende as respostas, o código gerado é consequência — e quando ele quebra, você tem hipóteses sobre o porquê.

O que é o Cadencia: produto construído com essa abordagem

O Cadencia é um sistema de posicionamento digital para profissionais autônomos e consultores. A proposta: aparecer consistentemente para o cliente certo, em todo canal relevante, sem precisar operar manualmente depois do onboarding.

O que o sistema faz:

• Gera carrosséis para o Instagram com o rosto real do profissional (usando Identity Lock do Gemini 2.5 Flash)
• Dispara e-mail diário para a base de leads com conteúdo personalizado
• Publica newsletter semanal de forma automática
• Mantém um blog ativo e rankeado no Google via Next.js 15 com SSG/ISR
• Posta no LinkedIn todo dia com texto adaptado por IA
• Envia WhatsApp para os leads com maior score de interesse
• Roda lead scoring contínuo enquanto o profissional está atendendo clientes

Stack com 20 ferramentas — incluindo Python + FastAPI, Supabase, Playwright, Apify, Anthropic Claude, Asaas para billing e Mixpanel para analytics. Dois meses de construção. Em produção com clientes reais. Veja a stack técnica completa →

Os 8 bugs que quase derrubaram o lançamento

A parte que raramente aparece nos posts sobre "construção com IA" é o debug. Abaixo estão os casos reais — todos documentados nos logs de sessão do projeto.

1. O "s" que quebrou semanas de análise

O scraper Apify que analisa o perfil Instagram do cliente retornava vazio em 100% dos casos. Sem erro. Sem stack trace. Simplesmente vazio. Dias de investigação. Causa: o campo estava sendo passado como usernames (plural) em vez de username. Uma letra. Semanas de análise de perfil inúteis.

2. O carrossel que sempre era genérico

O sistema de personalização visual — a parte que adapta o carrossel à identidade do cliente via shadcn/ui e Tailwind CSS — nunca estava sendo chamado. Todo usuário recebia o template padrão. Descoberto às 23h após uma revisão de logs. Cada carrossel gerado até aquele momento estava incorreto, e ninguém havia percebido porque o carrossel "aparecia". Funcionava. Estava simplesmente errado.

3. O login que quebrou no Gmail mobile

O fluxo de autenticação por e-mail funcionava em desktop. No Gmail mobile, quebrava silenciosamente por isolamento de cookies em WebView — o cliente de e-mail intercepta os links e cria um contexto de navegação isolado. Solução: reimplementar toda a estratégia de login com Google OAuth usando Supabase Auth em 24 horas para salvar o lançamento.

4. O processo "morto" que estava vivo

Disparo de e-mail para 7.153 contatos via cron. O lock file existia. O log ficou vazio por 67 minutos. Diagnóstico: travado. O processo foi morto e um re-run foi lançado.

Descoberta posterior: Python usa buffer de bloco de 8KB quando stdout é redirecionado para arquivo em cron. Com 7.153 contatos e prints esparsos, o buffer nunca encheu rápido o suficiente — zero output no log não significava zero processamento. O processo estava funcionando normalmente. A correção: python3 -u no crontab e sys.stdout.reconfigure(line_buffering=True) no script.

5. A tag que bloqueava o próprio enrollment

A tag de controle da sequência de e-mails estava sendo adicionada ao contato antes de matriculá-lo no workflow. O filtro excluía o contato antes de ele entrar. Zero e-mails enviados para um segmento inteiro — sem erro, sem aviso. Fix: enrollment primeiro, tag depois.

6. A race condition no assunto dos e-mails

Três threads escritas simultaneamente no mesmo campo customizado do contato no CRM. Com três segmentos rodando em paralelo, o assunto do e-mail de um segmento terminava com o subject de outro. Fix: substituir campo por contato por custom values globais por segmento.

7. O 404 que era uma barra

POST /opportunities retornava 404 sem mensagem útil. A causa: a URL precisava de trailing slash — /opportunities/. Horas debugando payload quando o problema era tipográfico.

8. O cache que nunca invalidava

A variável REVALIDATION_SECRET no Vercel tinha um \n invisível no final — adicionado ao setar a variável. O endpoint de revalidação do Next.js falhava silenciosamente. Páginas do blog não atualizavam após publicação. Descoberto com printf em vez de echo.

Uma sessão de debug ao vivo

Se quiser ver como é uma dessas sessões na prática — gravei uma ao vivo enquanto resolvia um problema real no Cadencia:

Não é tutorial. É o processo real — com erro, hipótese, investigação e solução no ar.

O que a maioria não fala sobre desenvolver com IA

A narrativa dominante é "a IA escreve o código". Isso é verdade mas incompleto. O que importa é o que acontece antes:

• Perguntas antes de implementação: "O que acontece quando esse serviço externo retorna vazio?" precede "escreve a função".
• Comportamentos, não arquivos: "O sistema deve fazer X quando Y acontecer" é mais útil que "cria o arquivo Z".
• Revisão como prática: código gerado por IA precisa ser revisado com o mesmo rigor que código humano — e usar um modelo de empresa diferente para o code review ajuda a identificar o que o modelo gerador não vê.

Isso não é programar. É arquitetar. Especificar. Revisar. Decidir. É um trabalho cognitivo diferente do que desenvolvedores fazem — e diferente do que profissionais que travam na síndrome do eterno beta costumam tentar.

O custo que ninguém contabiliza: AI Brain Fry

Houve dias de 12 a 18 horas que começavam com um bug de cor e terminavam com o sistema quebrando em cascata. Gripe que não passava por duas semanas. Mente que travava no meio de conversas simples. Corpo que recusava.

Pesquisando sobre o fenômeno, encontrei que pesquisadores já têm um nome para isso: AI Brain Fry — o esgotamento cognitivo específico de trabalhar em alta intensidade com IA por períodos prolongados. A IA acelera o trabalho, mas também acelera o desgaste. Vale saber disso antes de entrar.

Leia também

• Você está usando IA no modo vibe sem perceber — e isso explica a inconsistência
• AI Brain Fry: pesquisadores criaram um nome para o cansaço de usar IA
• A síndrome do eterno beta: por que profissionais inteligentes travam na IA
• O que são agentes autônomos de IA — e por que isso muda tudo

Perguntas frequentes

Preciso saber programar para construir software com IA?

Não — mas você precisa entender arquitetura. A diferença é grande: programar é escrever sintaxe correta; arquitetar é tomar decisões sobre estrutura, fluxo de dados e pontos de falha. A IA cuida da sintaxe. Você precisa cuidar da lógica.

O que é vibe coding e por que evitar?

Vibe coding é aceitar código gerado por IA sem entender o que ele faz. Funciona para prototipagem rápida. Falha em produção porque quando quebra — e vai quebrar — você não tem hipóteses sobre o motivo. O sistema se torna uma caixa preta que você não consegue debugar.

Quanto tempo leva para construir um produto real do zero?

O Cadencia levou dois meses de trabalho intenso (sessões de 8 a 18 horas). Mas isso incluiu aprender o stack, errar e refazer partes inteiras, e trabalhar com ferramentas que eu nunca havia usado. Com o aprendizado acumulado, estimo que repetiria o projeto em 3 a 4 semanas.

Claude Code é a melhor ferramenta para isso?

Foi a que funcionou melhor para mim — especialmente pela capacidade de manter contexto longo de uma base de código inteira. Mas o ponto mais importante não é a ferramenta: é a abordagem. Usar Claude Code como gerador de código dá o mesmo resultado que usar qualquer outra ferramenta sem método.

Quais as ferramentas que usei no Cadencia?

A stack completa tem 20 ferramentas: Next.js 15, React 19, Tailwind CSS, shadcn/ui, Zustand, TanStack Query, Framer Motion, Python + FastAPI, Pydantic, Anthropic Claude, Gemini 2.5 Flash, Playwright, Supabase, Asaas, Instagram Business API, Apify, Mixpanel, PostHog, Sentry e Vercel. Veja cada uma com a explicação de por que escolhi →