O vibe coding quebrou sua promessa

Passe uma hora em qualquer fórum de construtores e você vai encontrar a mesma confissão escrita de cem formas diferentes. Alguém construiu o próprio aplicativo em um fim de semana com uma ferramenta de IA. Funcionou. Lançou. Agora é segunda-feira, a autenticação está quebrada, o banco de dados perde linhas em silêncio e o erro que ninguém consegue reproduzir é o que está custando clientes.

O sonho que vendemos uns aos outros seis meses atrás está aparecendo na porta pedindo o dinheiro de volta.

Quero ser cuidadoso com o jeito de dizer isso, porque não acho que quem construiu ou usou essas ferramentas estava errado em se entusiasmar. O salto foi real. Ver uma interface funcional se materializar a partir de um parágrafo em linguagem comum é uma das experiências genuinamente mágicas da última década do software. Eu também senti. Todos sentimos.

Mas em algum ponto entre a demonstração e a implantação aconteceu uma substituição silenciosa. Começamos a chamar protótipos de produtos. Começamos a chamar demonstrações de software. E a conta dessa confusão está vencendo agora.

O diagnóstico errado

A explicação mais comum que vejo sobre por que isso está acontecendo culpa o modelo. A IA ainda não é inteligente o suficiente. Ela alucina. Escolhe as bibliotecas erradas. Escreve código que alguém sênior pegaria e reescreveria.

Essa explicação é reconfortante porque sugere uma correção que já está a caminho. Espere seis meses. O próximo modelo será melhor. No fim a lacuna fecha e tudo funciona.

Eu não acredito nisso. E não acredito porque o modo de falha que vejo repetidamente não tem nada a ver com o quão bom é o código.

A Microsoft informou em sua teleconferência de resultados de 2025 que cerca de 46% de todo o código enviado por usuários ativos do GitHub Copilot é agora gerado por IA. Na mesma época, a empresa de segurança de aplicações Veracode publicou uma pesquisa que encontrou código gerado por IA introduzindo vulnerabilidades de segurança em cerca de 45% das amostras testadas. Esses números vão piorar antes de melhorar, e um modelo mais inteligente não vai consertá-los.

O modelo não é o problema. O processo é.

O que realmente falta

Percorra comigo como uma aplicação feita com vibe coding é construída e me diga onde acontece a decisão arquitetônica.

Você descreve o que quer. A IA gera uma interface e algum código por trás. Você olha a interface, clica por aí, ela faz aproximadamente o que você pediu, e você considera pronto. Em nenhum momento desse ciclo alguém, humano ou máquina, parou para definir o que estava sendo construído.

Não há esquema. Não há modelo de dados. Não há uma lista de estados em que o sistema pode estar nem uma definição do que conta como válido. Não há contrato entre o frontend e o que quer que esteja fazendo papel de backend. Não há nenhuma decisão sobre o que acontece quando o usuário faz algo que o gerador não previu, porque ninguém previu.

O que foi construído é uma coisa que se parece com a coisa que você pediu, no caminho específico que você percorreu durante a demonstração. Saia desse caminho e toda a estrutura se revela como andaime. Nunca houve um prédio embaixo.

Isso não é uma falha de inteligência. É uma falha de definição. E nenhuma quantidade de inteligência adicional aplicada a um problema indefinido vai produzir um resultado definido. Só vai produzir uma versão mais convincente do mesmo andaime.

As três decisões que nunca foram tomadas

Vou ser concreto, porque abstrações são a razão pela qual essa conversa fica dando voltas.

A autenticação não é um recurso que você adiciona depois. É uma decisão sobre quem são seus usuários, o que eles podem ver e sobre qual fronteira de confiança sua aplicação se assenta. Aparafusá-la a uma aplicação feita com vibe coding duas semanas depois do lançamento é o equivalente em software a instalar uma porta de entrada em uma casa construída sem paredes.

O esquema de um banco de dados não é algo que uma IA deveria estar adivinhando enquanto gera o formulário que escreve nele. O esquema é a coluna vertebral da aplicação. Cada decisão posterior a ele (o que você pode consultar, o que pode indexar, o que pode mudar depois sem quebrar tudo) é limitada por escolhas que foram feitas, ou não feitas, no início. Quando o esquema é improvisado, cada mudança futura é uma reforma.

Um contrato de API não é opcional, e em uma economia onde os agentes de IA consomem software diretamente, ele está mais perto de ser o produto do que a interface. No momento em que sua aplicação conversa com qualquer outra coisa (um processador de pagamentos, um serviço de e-mail, outro software, um agente de IA) precisa existir uma superfície definida. Sem uma, as integrações se transformam em uma série de remendos pontuais que ninguém consegue manter e ninguém quer herdar.

Esses não são temas avançados. São o mínimo para construir software que vive além do primeiro fim de semana. E são exatamente as coisas que ficam de fora quando todo o processo de construção é descreva, veja, lance.

O problema dos 70% agora tem nome

Não acho que alguém tenha se proposto a construir uma indústria que lança software frágil. Acho que as ferramentas que surgiram nesta categoria otimizaram para o momento que vende a ferramenta: o momento de mágica, quando uma ideia se torna uma tela funcional em menos de um minuto.

O tempo até a mágica se tornou o mensurável. O tempo até a produção era problema de outra pessoa.

Essa é uma otimização razoável para uma demonstração. É uma otimização terrível para uma categoria de software que agora é responsável por entregar aplicações reais a usuários reais com dinheiro real em jogo. Deixa uma geração inteira de construtores encalhada nos 90%, com uma coisa que funciona na tela deles e desmorona em todo lugar mais.

Construtores da comunidade do Lovable deram um nome a isso: o problema dos 70%. Você chega a algo que parece quase pronto, e então o progresso para. Cada correção quebra outra coisa. O trabalho restante não é trabalho que você resolve com prompts, porque o que te bloqueia não é código faltando. É uma decisão faltando, tomada em silêncio, várias centenas de gerações atrás.

O segredo sujo desta categoria é que a parte fácil eram os primeiros 90%. Os 9% seguintes (fazer funcionar de verdade para mais de um usuário, em mais de um dispositivo, sob condições que você não previu) são mais difíceis que os primeiros 90% juntos. E o último 1%, a parte que distingue uma aplicação que funciona de uma frágil, é a parte que exige que você soubesse o que estava construindo antes de começar.

A regra que a IA não mudou

Aqui está o que ninguém quer ouvir, porque soa como um passo atrás em um momento que deveria ser todo movimento para frente.

O melhor software sempre começou com uma definição. Arquitetura antes do código. Um modelo claro do problema antes de qualquer linha ser escrita. Isso era verdade quando times de cinquenta pessoas construíam sistemas à mão, e é verdade agora que uma pessoa e um modelo podem construir o mesmo sistema em um fim de semana.

A IA não mudou essa regra. A IA a tornou mais importante, não menos.

Quando o custo de produzir código se aproxima de zero, o custo de produzir o código errado também se aproxima de zero. O que significa que a única coisa que ainda tem custo é descobrir qual seria o código certo. Esse trabalho (o trabalho de definição, o trabalho de arquitetura, a parte em que você decide o que está realmente construindo antes de começar a construir) é a única parte que não se tornou matéria-prima.

E é também a parte que a geração atual de ferramentas pulou.

Para onde isso vai de verdade

Não acho que a resposta seja ir mais devagar. Não acho que a resposta seja voltar a escrever tudo à mão. O salto foi real, e o salto veio para ficar.

A resposta é incorporar a etapa de definição ao ciclo, a prática que a indústria agora chama de desenvolvimento guiado por especificação. Não como uma porta manual que te freia, mas como o alicerce real sobre o qual o resto do trabalho se assenta. Quem está descobrindo como fazer isso trabalha em algo mais silencioso do que o que você tem visto. Eles estão a ponto de fazer a versão ruidosa desta categoria parecer o que ela sempre foi. Escrevi separadamente sobre como é de verdade essa próxima geração.

Uma tela que funciona nunca foi a mesma coisa que um sistema que funciona. Todos estamos a ponto de lembrar por quê.

Leituras relacionadas

O que a substituiu: o desenvolvimento guiado por especificação. Como as ferramentas se comparam agora: os melhores construtores de aplicações com IA em 2026.

Perguntas frequentes

O que significa “vibe coding”? Vibe coding é escrever software descrevendo o que você quer em linguagem comum e aceitando o que a IA gera, sem especificar a arquitetura, o modelo de dados ou os contratos por baixo. Andrej Karpathy cunhou o termo no início de 2025. Ele descreve um fluxo de trabalho, não uma categoria de ferramenta: você pode fazer vibe coding em quase qualquer construtor com IA.

Por que as aplicações feitas com vibe coding quebram em produção? Porque a falha é estrutural, não um problema de qualidade do código. O ciclo de geração nunca produz um esquema, nem um conjunto definido de estados válidos, nem um contrato entre frontend e backend. A aplicação funciona no caminho em que foi demonstrada e desmorona fora dele. Um modelo mais inteligente aplicado a um problema indefinido continua produzindo um resultado indefinido.

O que é o problema dos 70%? É o padrão em que uma aplicação construída com IA chega a cerca de 70% de conclusão e então para de avançar: cada correção quebra outra coisa e nenhuma quantidade de prompts adicionais fecha a lacuna. O que bloqueia normalmente é uma decisão arquitetônica tomada de forma implícita, centenas de gerações antes, que já não pode ser mudada sem uma reescrita.

O código gerado por IA é menos seguro? A evidência atual diz que precisa de revisão. A pesquisa da Veracode encontrou código gerado por IA introduzindo vulnerabilidades de segurança em cerca de 45% das amostras testadas, num momento em que a Microsoft informava que cerca de 46% do código enviado por usuários ativos do GitHub Copilot era gerado por IA. O volume cresce mais rápido que a verificação.

Isso significa que os construtores de aplicações com IA não deveriam ser usados? Não. Para protótipos, demonstrações e ferramentas internas eles são genuinamente excelentes e a velocidade é real. O argumento aqui é mais estreito: uma tela que funciona não é um sistema que funciona, e as ferramentas que pulam a fase de definição não conseguem produzir a segunda por melhor que o modelo fique.