Vibe coding parece mágica até o 3º mês, quando cada nova funcionalidade quebra três antigas. Por que projetos com IA caem no abismo — e a virada que funciona.
Vibe coding — construir software descrevendo para uma IA o que você quer, sem entender a arquitetura por baixo — funciona brilhantemente por uns três meses. Depois, cada nova funcionalidade começa a quebrar as antigas, e a maioria dos projetos morre. A armadilha não é a IA. É quem está tomando as decisões de arquitetura: ninguém.
Vejo o mesmo ciclo toda santa semana. Semana 1: "Construí meu MVP de SaaS num fim de semana, IA é mágica!" Semana 4: "Adicionei 10 funcionalidades novas esta semana." Semana 12: "Está tudo quebrando. Cada funcionalidade nova quebra 3 antigas. Acho que preciso reconstruir do zero." Semana 16: "Vibe coding é furada. Voltando para o desenvolvimento tradicional."
Pessoas inteligentes e capazes. Um impulso incrível. Depois, um muro tão duro que elas desistem de vez. Veja por quê — e como ser a exceção.
O que é vibe coding?
Vibe coding é pedir para uma IA construir funcionalidades sem você tomar nenhuma decisão de arquitetura. "Cria um painel de usuário." Publica. "Agora adiciona times." Publica. "Adiciona cobrança." Publica. Todo prompt funciona. Toda funcionalidade aparece. Em nenhum momento você decidiu como os dados são estruturados, como as permissões funcionam ou como tudo se conecta.
E a experiência inicial é inebriante por motivos reais: código funcionando em minutos em vez de dias, nenhuma curva de aprendizado, progresso concreto para mostrar às pessoas. A dopamina é real. As funcionalidades realmente funcionam.
Até que deixam de funcionar. Porque aqui está a verdade desconfortável: vibe coding parece produtivo porque você está confundindo atividade com progresso. Lançar funcionalidades é atividade. Construir uma arquitetura que sobrevive ao contato com a funcionalidade número 20 é progresso.
O abismo do 3º mês: como projetos com IA realmente morrem
O colapso segue uma sequência mecânica previsível:
Semanas 1–4: a lua de mel. Você está construindo funcionalidades isoladas. Cada uma funciona de forma independente, porque nada está conectado ainda. A IA gera um código razoável porque cada prompt é simples e autocontido.
Semanas 5–8: as rachaduras. Agora as funcionalidades novas interagem com as antigas — e a IA não lembra das decisões de arquitetura que tomou quatro semanas atrás. Sessões diferentes fazem escolhas diferentes. Às vezes ela liga os dados direito com chaves estrangeiras; às vezes duplica. Um dia você percebe que o nome do usuário está guardado em cinco tabelas diferentes. Muda num lugar e fica desatualizado nos outros quatro.
Semanas 9–12: a espiral da morte. Cada funcionalidade nova herda as inconsistências, acrescenta suas próprias suposições e quebra algo que estava funcionando. Você pede: "Corrige o bug em que os nomes dos usuários não atualizam em todo lugar." A IA responde: "Vou atualizar os 6 lugares onde guardamos nomes de usuários." Você pergunta por que existem seis lugares. Ela se oferece para consolidar — mas isso vai quebrar 15 funcionalidades. Fim de jogo.
A desconexão que engana as pessoas: a IA é genuinamente excelente em gerar código correto para funcionalidades isoladas. Ela não é boa em lembrar decisões entre sessões, perceber conflitos com padrões existentes ou fazer escolhas estratégicas de arquitetura. E ela responde com total confiança de qualquer jeito — "para simplificar, recomendo desnormalizar aqui" soa inteligente, e você não consegue distinguir conselho bom de ruim se não entende a arquitetura.
Você é o arquiteto. A IA é o construtor.
Essa é a mudança de paradigma que muda tudo. Não "a IA é minha desenvolvedora e eu sou o gerente de produto". Não "estamos programando juntos como parceiros". Você projeta. A IA constrói.
Pense na construção de uma casa. O arquiteto decide a fundação, as paredes estruturais, por onde passa o encanamento — decisões que não dá para mudar depois que a obra começa. O construtor executa essa planta com habilidade de verdade, mas não a cria. Diga a um construtor "me faz uma casa" sem planta nenhuma e você vai ter algo que fica de pé — até querer um segundo andar e descobrir que a fundação não aguenta.
Em software, as decisões do arquiteto são suas: quais entidades existem e como se relacionam, se o sistema é multi-tenant, como as permissões são aplicadas, o que é normalizado, quais padrões todo serviço segue. O trabalho da IA é a execução: os componentes, o código repetitivo, as migrações que implementam exatamente o seu schema.
E parte do trabalho é dizer não. Quando a IA diz "para simplificar, vamos guardar o nome do usuário na tabela de pedidos também" — não, normaliza. Quando ela diz "por performance, vamos desnormalizar" — me mostra o problema de performance primeiro. Quando ela sugere um conserto rápido — nada de gambiarra, encontra a causa raiz. A IA otimiza para código que funciona rápido. Você precisa de código de produção que nunca precise ser reconstruído.
| Aspecto | Vibe coder | Arquiteto |
|---|---|---|
| Ponto de partida | "Cria um painel para mim" | "Aqui está meu modelo de dados e meu padrão de serviços — agora cria o painel" |
| Design do banco de dados | Tabelas criadas conforme a necessidade, inconsistentes | Projetado de antemão, com relacionamentos claros |
| Sugestões da IA | Aceita tudo | Rejeita padrões ruins |
| Multi-tenancy | Encaixada depois, gera caos | Projetada desde o dia 1 |
| Situação no 3º mês | Pensando em reescrever tudo | Adicionando funcionalidades sem atrito |
| Situação no 6º mês | Abandonado ou reescrito | Pronto para produção |
A alternativa da arquitetura primeiro (com prova)
Não desenvolvi essa abordagem por ser esperto. Desenvolvi porque não tinha escolha. Depois de perder tudo num negócio que fracassou, eu estava me reerguendo na casa dos meus pais — meus pais, de 83 anos, pagavam a minha assinatura do Claude porque eu não tinha como pagar. Eu tinha meses de fôlego, não anos. Se eu fizesse vibe coding e batesse no muro no 3º mês, não haveria segunda tentativa.
Então, antes de escrever uma única linha de interface, passei 2 semanas projetando o schema completo do banco de dados do FIKR Space: cada relacionamento mapeado, multi-tenancy em todas as tabelas desde o dia 1, segurança em nível de linha aplicada no próprio banco, mais de 90% dos dados normalizados numa única fonte da verdade. Depois entreguei essa planta à IA e a coloquei para construir — brigando com ela todos os dias quando sugeria atalhos.
O resultado depois de doze meses: 8–12 produtos integrados, prontos para produção, zero reescritas. Com a fundação sólida, as funcionalidades voaram — um sistema completo de OKR em 3 dias, gestão de cap table em 4. Quando as pessoas testavam, a pergunta era sempre a mesma: "Como você conseguiu construir isso sozinho?" O orçamento tradicional para essa plataforma é de 10–15 desenvolvedores ao longo de 2 anos — R$ 9,6–14,4 milhões só em salários de desenvolvimento, fácil mais de R$ 12 milhões com todos os custos. Para mim custou menos de R$ 19.500 no primeiro ano. (O detalhamento completo do custo das ferramentas tem um post só para ele.)
A escolha à sua frente é simples de enunciar: rápido agora e lento depois, ou lento agora e rápido para sempre. O vibe coding lança 20 funcionalidades no 1º mês e passa o 3º mês consertando o que o 1º construiu. A arquitetura primeiro gasta 2 semanas na planta e depois lança funcionalidades que continuam funcionando.
Perguntas frequentes
Como sei se estou fazendo vibe coding?
Os sinais de alerta: você já pediu para a IA corrigir o mesmo bug mais de 3 vezes, não consegue explicar o schema do seu banco para outra pessoa, o mesmo dado parece estar guardado de formas diferentes em funcionalidades diferentes, você evita adicionar funcionalidades porque não sabe o que elas vão quebrar, ou está pensando baixinho em "começar de novo do zero". Três ou mais desses sinais significam que você está indo para o abismo.
Vibe coding às vezes é aceitável?
Sim — para protótipos e apps simples que você topa jogar fora. Ferramentas feitas só para prompts são ótimas para MVPs rápidos. A armadilha se fecha quando um protótipo descartável vira, sem ninguém perceber, o produto, e as decisões de arquitetura do 3º mês foram tomadas por ninguém.
Dá para salvar um projeto feito com vibe coding ou preciso reconstruir?
Normalmente dá para salvar. Pause o desenvolvimento de funcionalidades por alguns dias, mapeie cada tabela e como elas se conectam, identifique onde os dados estão duplicados, projete o schema que essas entidades deveriam ter tido e então migre: consolide os duplicados, adicione as chaves estrangeiras que faltam, adicione o escopo por tenant, ative a segurança em nível de linha. Parece lento. É meses mais rápido do que a reescrita para onde você está indo.
Preciso aprender a programar para ser o arquiteto?
Não — mas você precisa aprender os fundamentos de como os sistemas se encaixam: entidades, relacionamentos, fonte única da verdade, permissões. Você toma essas decisões; a IA escreve a implementação. Essa habilidade se aprende em semanas, e é a diferença entre um projeto que morre no 3º mês e um que se acumula. Se você está construindo sua saída do corporativo em cima disso, comece medindo o quanto você precisa de uma com o Índice de Sufocamento Corporativo (CSI) — e depois construa sobre uma fundação de verdade.