O MVP estava perfeito. Então, chegou o estágio de produção…

O fundador de uma empresa publicou no Instagram uma confissão que parou meu scroll. Ele usou quatro ferramentas de Inteligência Artificial para construir o produto: uma para a interface, outra para as funcionalidades, uma terceira para corrigir bugs, uma quarta para o deploy. O MVP (Minimum Viable Product) ficou perfeito, em suas próprias palavras.

Então chegou o estágio de produção.

Authentication com vazamento. Rate limiting ausente. RLS (Row-Level Security) quebrado. Erros silenciosos que ninguém via. Sem cache. O produto, que parecia pronto, não estava. Estava apenas apresentável.

CADASTRE-SE GRÁTIS PARA ACESSAR 5 CONTEÚDOS MENSAIS

Já recebe a newsletter? Ative seu acesso

Ao cadastrar-se você declara que está de acordo
com nossos Termos de Uso e Privacidade.

Cadastrar

Ele encerrou o post com uma frase que vou carregar por um tempo: “Frontend e backend não é full-stack*. É só a ponta do iceberg.”

Essa história não é sobre incompetência. Esse fundador não era acomodado, não era avesso à tecnologia, não estava fugindo do aprendizado. Era exatamente o perfil que a narrativa atual celebra: curioso, engajado, dominando as ferramentas disponíveis. E mesmo assim levou o impacto completo.

Por quê?

Tenho escrito nos últimos meses sobre dois problemas que a adoção de IA cria nas organizações. Um é financeiro: o custo da transição antes do retorno aparecer (Por que a IA pode custar mais caro para o Brasil do que para os EUA? ). O outro é cognitivo: equipes que usam IA sem saber auditar o que ela produz perdem a capacidade de perceber quando ela está errada (Tokenmaxxing: quando a ferramenta vira métrica e a métrica vira problema).

Existe uma conclusão razoável que um leitor atento pode tirar desses dois problemas. Se você montar um time pequeno, curioso, engajado e com capacidade para auditar os resultados da IA, você está do lado certo.

Essa conclusão é verdadeira. Com uma condição que eu não havia dito de forma direta.

O time precisa ter competência técnica real. Não familiaridade com as ferramentas. Competência técnica: alguém que entende o que acontece depois que o código vai para produção.

Sem essa pessoa, você não está evitando os problemas. Você está escolhendo encontrá-los depois.

O que acontece depois do deployment  não tem a estética do começo. O começo tem o prazer da construção, a velocidade, a sensação de que a ideia está tomando forma. O depois tem Authentication com lógica invertida, que mantém ex-colaboradores com acesso de administrador. Tem banco de dados que apaga os registros dos clientes porque o servidor reiniciou. Tem credenciais de API expostas no código que qualquer usuário captura pelo navegador. Tem sistema que funciona com dez usuários e para com duzentos.

Nenhum desses problemas aparece no MVP. Todos aparecem em produção.

E nenhuma ferramenta de vibe coding** resolve qualquer um deles automaticamente. As ferramentas geram o que você pede. Elas não sabem o que você não perguntou. E o que você não perguntou é exatamente o que derruba produto em produção: segurança no nível de banco de dados, controle de acesso real, limitação de requisições, rastreamento de erros, plano de recuperação quando o sistema cai.

(A pesquisa que fiz para este texto documentou 13 camadas de competência que um ambiente de produção real exige. O ponto não é a lista. É que elas existem, que o vibe coding não as cobre por padrão, e que descobrir cada uma delas em produção tem um custo que vai muito além do tempo de correção.)

Quero ser justo com o argumento contrário.

É uma decisão válida construir com as ferramentas disponíveis, chegar rápido ao mercado, validar o produto e resolver as camadas técnicas depois. Empresas fazem isso há décadas. Dívida técnica é uma estratégia, não um erro por definição.

O problema é que o prazo do “depois” encolheu.

Escrevi em outro texto que a IA amplifica e acelera os ciclos organizacionais, saudáveis ou não (Sua equipe usa IA todo dia. Por isso está regredindo). O que levava três anos para explodir agora explode em dois meses. Isso vale para processos internos de grandes empresas. Vale igualmente para as treze camadas de um produto em produção.

Um vazamento de credencial, que você descobriria em seis meses de operação normal, você descobre agora em seis semanas. Uma falha de escalabilidade, que apareceria com crescimento gradual, aparece no primeiro pico de acesso. O tempo que você tinha para consertar enquanto o produto ainda era pequeno ficou menor. Consideravelmente menor.

“Decidir depois” continua sendo uma opção. Só não é mais a mesma opção de antes.

O fundador do Instagram não errou por usar as ferramentas. Errou por não ter no time alguém que soubesse o que vem depois das ferramentas.

Essa é a condição que faltava na equação. Time curioso, engajado, que audita o que a IA produz, mais competência técnica de quem entende produção. Não necessariamente um time grande. Não necessariamente um CTO, mas alguém que conhece as camadas que o MVP não mostra.

Sem essa pessoa, você não está construindo um produto. Está construindo uma apresentação muito convincente do que o produto vai ser.

A diferença aparece quando a produção chega.

* Frontend → interface com o usuário (HTML, CSS, React), Backend → lógica, banco de dados, APIs (Node, Java, Python), Full-stack → alguém que atua nas duas camadas

** Vibe coding é um termo informal da comunidade de desenvolvedores que significa: programar guiado mais pela intuição e sensação (“vibe”) do que por planejamento rígido