A armadilha do vibe coding: porque é que os projetos com IA morrem ao 3.º mês

O vibe coding — construir software descrevendo a uma IA o que queres, sem perceber a arquitetura que está por baixo — funciona brilhantemente durante cerca de três meses. Depois, cada funcionalidade nova começa a partir as antigas, e a maioria dos projetos morre. A armadilha não é a IA. É quem está a tomar as decisões de arquitetura: ninguém.

Vejo o mesmo ciclo todas as semanas. Semana 1: "Construí o MVP do meu SaaS num fim de semana, a IA é mágica!" Semana 4: "Acrescentei 10 funcionalidades novas esta semana." Semana 12: "Está tudo a partir-se. Cada funcionalidade nova parte 3 antigas. Acho que tenho de reconstruir do zero." Semana 16: "O vibe coding é uma treta. Vou voltar ao desenvolvimento tradicional."

Pessoas inteligentes e capazes. Um impulso incrível. Depois, uma parede tão dura que desistem por completo. Eis porquê — e como seres a exceção.

O que é o vibe coding?

Vibe coding é pedir a uma IA que construa funcionalidades sem tomares tu uma única decisão de arquitetura. "Constrói-me um painel de utilizador." Lançado. "Agora acrescenta equipas." Lançado. "Acrescenta faturação." Lançado. Todos os prompts funcionam. Todas as funcionalidades aparecem. Nunca decidiste como os dados estão estruturados, como funcionam as permissões ou como tudo se liga.

E a experiência inicial é inebriante por razões reais: código a funcionar em minutos em vez de dias, sem curva de aprendizagem, progresso tangível que podes mostrar às pessoas. A dopamina é real. As funcionalidades funcionam mesmo.

Até deixarem de funcionar. Porque eis a verdade desconfortável: o vibe coding parece produtivo porque estás a confundir atividade com progresso. Lançar funcionalidades é atividade. Construir uma arquitetura que sobrevive ao contacto com a funcionalidade 20 é progresso.

O precipício dos 3 meses: como morrem realmente os projetos com IA

O colapso segue uma sequência mecânica previsível:

Semanas 1–4: a lua de mel. Estás a construir funcionalidades isoladas. Cada uma funciona de forma independente, porque ainda nada está ligado. A IA gera código razoável porque cada prompt é simples e autónomo.

Semanas 5–8: as fissuras. As funcionalidades novas passam a interagir com as antigas — e a IA não se lembra das decisões de arquitetura que tomou há quatro semanas. Sessões diferentes fazem escolhas diferentes. Às vezes liga os dados como deve ser, com chaves estrangeiras; às vezes duplica-os. Um dia reparas que o nome do utilizador está guardado em cinco tabelas diferentes. Muda-lo num sítio e fica desatualizado nos outros quatro.

Semanas 9–12: a espiral da morte. Cada funcionalidade nova herda as inconsistências, acrescenta os seus próprios pressupostos e parte algo que estava a funcionar. Escreves: "Corrige o bug em que os nomes dos utilizadores não se atualizam em todo o lado." A IA responde: "Vou atualizar os 6 sítios onde guardamos os nomes dos utilizadores." Perguntas porque é que há seis sítios. Ela oferece-se para os consolidar — mas isso vai partir 15 funcionalidades. Fim de jogo.

O desencontro que engana as pessoas: a IA é genuinamente excelente a gerar código correto para funcionalidades isoladas. Não é boa a lembrar-se de decisões entre sessões, a detetar conflitos com padrões existentes ou a fazer escolhas estratégicas de arquitetura. E responde com total confiança em qualquer dos casos — "por simplicidade, recomendo desnormalizar aqui" soa inteligente, e não consegues distinguir um bom conselho de um mau se não perceberes a arquitetura.

Tu és o arquiteto. A IA é o construtor.

Esta é a mudança de paradigma que muda tudo. Não é "a IA é o meu programador e eu sou o gestor de produto". Não é "estamos a programar juntos, como parceiros". Tu desenhas. A IA constrói.

Pensa na construção de uma casa. O arquiteto decide as fundações, as paredes-mestras, por onde passa a canalização — decisões que não podem ser mudadas depois de a obra começar. O construtor executa essa planta com verdadeira competência, mas não a cria. Diz a um construtor "constrói-me uma casa" sem planta e vais ter algo que se aguenta de pé — até quereres um segundo andar e descobrires que as fundações não o suportam.

No software, as decisões de arquiteto são tuas: que entidades existem e como se relacionam, se o sistema é multi-tenant, como são impostas as permissões, o que é normalizado, que padrões segue cada serviço. O trabalho da IA é a execução: os componentes, o código repetitivo, as migrações que implementam exatamente o teu esquema.

E parte do trabalho é contrariar. Quando a IA diz "por simplicidade, vamos guardar também o nome do utilizador na tabela de encomendas" — não, normaliza. Quando diz "por desempenho, vamos desnormalizar" — mostra-me primeiro o problema de desempenho. Quando sugere uma solução rápida — nada de remendos, encontra a causa de fundo. A IA otimiza para código que funciona depressa. Tu precisas de código de produção que nunca tenha de ser reconstruído.

Aspeto	Quem faz vibe coding	Arquiteto
Ponto de partida	"Constrói-me um painel"	"Eis o meu modelo de dados e o padrão dos serviços — agora constrói o painel"
Desenho da base de dados	Tabelas criadas à medida das necessidades, inconsistentes	Desenhada à partida, com relações claras
Sugestões da IA	Aceita tudo	Contraria os maus padrões
Multi-tenancy	Acrescentado mais tarde, provoca o caos	Desenhado desde o dia 1
Estado ao 3.º mês	A ponderar reescrever tudo	A acrescentar funcionalidades sem sobressaltos
Estado ao 6.º mês	Abandonado ou reescrito	Pronto para produção

A alternativa que começa pela arquitetura (com provas)

Não desenvolvi esta abordagem por ser esperto. Desenvolvi-a porque não tinha escolha. Depois de perder tudo num projeto falhado, estava a reconstruir-me a partir da casa dos meus pais — os meus pais, com 83 anos, pagavam a minha subscrição do Claude porque eu não a conseguia pagar. Tinha meses de margem, não anos. Se fizesse vibe coding e batesse na parede ao 3.º mês, não haveria segunda tentativa.

Por isso, antes de escrever uma única linha de interface, passei 2 semanas a desenhar o esquema completo da base de dados do FIKR Space: cada relação mapeada, multi-tenancy em todas as tabelas desde o dia 1, row-level security imposta ao nível da base de dados, mais de 90% dos dados normalizados numa única fonte de verdade. Depois dei essa planta à IA e pu-la a construir — a lutar com ela todos os dias quando sugeria atalhos.

O resultado ao fim de doze meses: 8–12 produtos integrados, prontos para produção, zero reescritas. Com as fundações sólidas, as funcionalidades voaram — um sistema completo de OKR em 3 dias, gestão de cap table em 4. Quando as pessoas o testavam, a pergunta era sempre a mesma: "Como é que conseguiste construir isto sozinho?" O orçamento tradicional para essa plataforma são 10–15 programadores durante 2 anos — 1,6 a 2,4 milhões de euros só em salários de desenvolvimento, facilmente mais de 2 milhões de euros com todos os custos. A mim custou-me menos de 3.250 € no primeiro ano. (A decomposição completa do custo das ferramentas tem um artigo próprio.)

A escolha que tens à 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 a corrigir o que o 1.º construiu. Começar pela arquitetura gasta 2 semanas na planta e depois lança funcionalidades que continuam a funcionar.

Perguntas frequentes

Como sei se estou a fazer vibe coding?

Os sinais de alerta: já pediste à IA para corrigir o mesmo bug mais de 3 vezes, não consegues explicar o esquema da tua base de dados a outra pessoa, os mesmos dados parecem estar guardados de forma diferente em funcionalidades diferentes, evitas acrescentar funcionalidades porque não sabes o que vão partir, ou andas a pensar em silêncio em "recomeçar do zero". Três ou mais destes sinais significam que vais a caminho do precipício.

O vibe coding alguma vez é aceitável?

Sim — para protótipos e aplicações simples que estás disposto a deitar fora. As ferramentas feitas para trabalhar só com prompts são ótimas para MVP rápidos. A armadilha fecha-se quando um protótipo descartável se torna, sem ninguém dar por isso, o produto, e as decisões de arquitetura do 3.º mês foram tomadas por ninguém.

Consigo recuperar um projeto feito em vibe coding, ou tenho de o reconstruir?

Normalmente consegues recuperá-lo. Faz uma pausa de alguns dias no desenvolvimento de funcionalidades, mapeia todas as tabelas e a forma como se ligam, identifica onde há dados duplicados, desenha o esquema que essas entidades deviam ter tido e depois migra: consolida os duplicados, acrescenta as chaves estrangeiras em falta, acrescenta a separação por cliente, ativa a row-level security. Parece lento. É meses mais rápido do que a reescrita para onde, de outra forma, te diriges.

Preciso de aprender a programar para ser o arquiteto?

Não — mas precisas de aprender os fundamentos de como os sistemas encaixam: entidades, relações, fonte única de verdade, permissões. Tu tomas essas decisões; a IA escreve a implementação. Essa competência aprende-se em semanas, e é a diferença entre um projeto que morre ao 3.º mês e um que se acumula. Se estás a construir a tua saída do mundo corporativo em cima disso, começa por medir o quanto precisas de uma — e depois constrói-a sobre fundações a sério.