Se você abrir noticias sobre tecnologia, o Youtube ou o LinkedIn, em menos de 5 minutos será capaz de encontrar alguém (sem nenhuma experiência em programação) mostrando uma aplicação “construída do zero” com IA.

O app funciona. A tela é bonita. A pessoas está radiante.

Logo em seguida, surgem comentários como: "programadores vão ser substituídos", "nunca mais preciso de um Dev", "o futuro chegou".

Será?

Eu mesmo já fiz algumas coisas usando ferramentas de vibe coding. O resultado é bem legal e dá mesmo vontade de mostrar pra alguém. Na minha opinião, é uma tecnologia incrível quando falamos de prototipagem ou de demos funcionais, que são importantes pra validar uma tese ou testar uma idéia promissora.

Porém, quando falamos de sistemas em produção e consequências reais quando algo dá errado… a história é bem diferente.

O que tenho visto na prática me preocupa. Não pela tecnologia, mas pela narrativa que se criou em torno dela.

O termo "Vibe Coding" descreve uma abordagem onde você simplesmente conversa com uma IA em linguagem natural e ela gera código. Sem planejamento, sem especificação, sem arquitetura definida. Você descreve o que quer, a IA produz, e você vai ajustando no "feeling".

Para ser justo: como ferramenta de prototipagem e demonstração, é genuinamente poderoso. É incrível conseguir, em poucas horas, criar uma prova de conceito, testar uma ideia, montar uma demo para validar com stakeholders ou, até mesmo, para levar em uma reunião importante com um possível cliente.

O problema começa quando a demo vira roadmap. Quando o protótipo vira produto. Quando alguém olha para o app que "funciona" e conclui que está pronto para produção.

Aí começa o pesadelo.

Quando saímos da fase de prototipagem e começamos a falar de projetos reais, envolvendo equipes, integrações complexas e com usuários em produção, eu vejo quatro problemas se repetindo toda vez que o "vibe" substitui o método:

Prompts soltos e ad hoc levam a resultados imprevisíveis. Cada pessoa do time entende uma coisa diferente. A IA interpreta outra. O resultado? Código que pode até funcionar, mas não faz o que era esperado e que vai cobrar seu preço na hora que for necessário dar manutenção (correções ou evoluções).

E aqui está um ponto crucial: quanto menos experiência a pessoa tem, menos ela percebe a ambiguidade. Na maioria das vezes, pessoas com pouca experiência não descrevem ou definem decisões importantes de arquitetura, de segurança, de boas praticas e padrões de desenvolvimento. Se a pessoa não tem conhecimento para essas definições, tem menos ainda para criticar o que foi gerado e simplesmente aceita o output, segue em frente, e o problema só aparece nos testes, nas integrações, ou pior, em produção.

Quando você não especifica e define exatamente o que quer (e como quer), não tem como orientar as decisões da IA. O resultado é código verboso, inconsistente, que viola padrões de arquitetura e segurança, mas que compila e “funciona”.

E ninguém sabe explicar como as coisas foram construídas ou por quê foram feitas daquele jeito. Não existe rastreabilidade.

Cada pedaço de código é gerado isoladamente. Funciona sozinho, quebra junto. Componentes que não conversam entre sí, foram feitos em diferentes linguagens de programação, utilizam modelos de dados e tecnologias de base de dados completamente diferentes, interfaces e experiência de usuário inconsistentes, contratos quebrados entre serviços, um verdadeiro caos.

Já viu aquele app que funciona perfeitamente na demo mas explode no primeiro teste de integração? É isso.

Sem testes robustos, pequenas mudanças sem controle feitas pela IA podem introduzir consequências não intencionais em sistemas complexos, alterando partes do código que não precisavam e nem deveriam ser alteradas. Você corrige um bug e cria outros três.

E como não existe especificação para validar contra, ninguém sabe dizer se o comportamento atual é o correto ou um bug.

Existe uma narrativa confortável de que a IA "democratiza" o desenvolvimento. Que nivela o campo de jogo. Que agora qualquer pessoa pode construir software.

Na minha experiência, o que está acontecendo é exatamente o contrário.

A IA amplifica o que você já sabe. E isso cria um gap ainda maior entre profissionais experientes e os iniciantes.

→ Saber o que pedir e como pedir — A qualidade do output da IA Generativa é diretamente proporcional à qualidade do input. Quem tem experiência sabe decompor um problema, definir estratégia e restrições, dar contexto. Quem não tem, pede "faz X pra mim" e aceita qualquer coisa que vier.

→ Saber criticar — Código gerado por IA parece correto. Compila, roda, passa nos testes básicos. Mas quem tem bagagem percebe edge cases, problemas de arquitetura, linhas de código desnecessárias e débito técnico escondido. Quem não tem... aceita e segue.

→ Saber direcionar — Quando o output não está bom, um profissional sênior sabe iterar, entender aonde errou, mudar a abordagem, ajustar a estratégia. Alguém sem experiência não sabe nem que o resultado é ruim.

Isso não é pessimismo. É observação de campo.

E a implicação é importante: IA não substitui fundamento. Ela expõe a falta dele.

Não estou dizendo que Vibe Coding é inútil. Pelo contrário… tem espaço claro:

O problema não é a ferramenta. O problema é confundir a ferramenta de protótipo com a metodologia de produção.

Se Vibe Coding é velocidade sem direção, o que precisamos é de velocidade com intenção.

Precisamos de um modelo de trabalho onde a IA acelere a execução, mas o humano mantenha o controle sobre o que está sendo construído, como e por quê.

A resposta para isso é um processo de Spec-Driven Development, que está se mostrando o próximo grande salto de produtividade real em Engenharia de Software.

A ideia central é simples:

Na próxima edição, vou detalhar exatamente como funciona o Spec-Driven Development, como estamos usando na pratica e os grandes saltos que acredito que sejam possíveis com essa nova forma de encaixar IA no ciclo de vida de desenvolvimento de software, sem tirar o humano do comando.

Até a próxima!

Estratégia e execução, com governança e ROI.