Existe um momento previsível em toda empresa que adotou vibe coding. Alguém — muitas vezes fora do TI — constrói em dois dias uma aplicação que resolve um problema real. A demonstração impressiona. A diretoria aprova. E aí a pergunta muda de "isso funciona?" para "isso pode entrar em produção?".
É onde a conversa trava. Não porque o protótipo seja ruim, mas porque produção cobra um conjunto de coisas que a fase de descoberta não precisou responder.
O que muda quando há usuário real
A diferença entre demonstração e operação raramente está na funcionalidade. Está no entorno:
- Identidade e permissão. Quem entra, com qual perfil, e o que cada perfil pode ver. Login improvisado não sobrevive à primeira revisão de segurança.
- Integração com o que já existe. A aplicação corporativa quase nunca vive sozinha: precisa falar com ERP, CRM, base de conhecimento e o diretório de identidade, respeitando o controle de acesso vigente.
- Dado de verdade. Prototipar com dado real de cliente é comum e quase nunca passou por base legal, avaliação de fornecedor ou previsão contratual.
- Continuidade. Backup, plano de recuperação, monitoramento e alguém de plantão quando quebra às onze da noite.
- Evolução. Alguém precisa conseguir ler, testar e mudar o que foi gerado daqui a um ano, quando quem prototipou já mudou de área.
Nenhum desses itens é exótico. Todos são o padrão de qualquer software corporativo — e é exatamente por isso que o protótipo trava: ele não foi construído para respondê-los.
Os três impasses estruturais
1. O ambiente é do fornecedor
A maioria das plataformas de vibe coding gera e executa a aplicação dentro do próprio ambiente. Isso é ótimo para começar e problemático para operar: auditar o que está rodando, atender exigência de residência de dado ou mudar de fornecedor deixam de ser decisões da empresa.
A pergunta que resolve esse ponto é simples e vale fazer cedo: se amanhã eu quiser sair, o que eu levo comigo? Se a resposta não for "o código", há dependência estrutural.
2. Ninguém governa o que a IA gerou
Empresas que investiram em governança de IA costumam ter política, guardrails e trilha de auditoria para o uso de IA — o que as pessoas perguntam ao modelo. Poucas estenderam isso ao que é construído com IA.
O resultado é uma assimetria estranha: um colaborador é impedido de colar um documento sensível num chat, mas uma aplicação inteira gerada por prompt entra em produção sem passar por revisão equivalente.
3. Falta o que vem depois do "funciona"
Vibe coding entrega velocidade até o ponto em que o problema deixa de ser gerar código e passa a ser arquitetura, integração, performance sob carga e segurança. Esse ponto chega mais cedo do que a demonstração sugere.
O que não é solução
Duas reações comuns pioram a situação.
A primeira é proibir. Bloquear a ferramenta não elimina a necessidade que levou a pessoa a usá-la — apenas empurra o uso para fora do radar, o que já discutimos em shadow AI.
A segunda é fingir que o protótipo é produto. Colocar em produção sem identidade, integração e continuidade funciona por algumas semanas e cobra a conta no primeiro incidente — geralmente com dado de cliente envolvido.
O caminho que funciona: fases com critérios diferentes
A saída é reconhecer que descoberta e produção são fases distintas, com critérios distintos, e que a ferramenta certa muda entre elas.
Na descoberta, velocidade vale mais que governança. Plataformas de vibe coding de mercado — Lovable entre elas — são a escolha certa, e a NOBUG trabalha com elas justamente por isso. O objetivo é descobrir rápido se a ideia se sustenta.
Na produção, o critério inverte: controle, integração, residência de dado e continuidade passam à frente da velocidade. É onde entra o NOBUG CODE — a mesma agilidade de construir por prompt, mas executando na nossa infraestrutura, com dado no Brasil, sob a governança de IA da empresa e com o código entregue ao cliente.
O erro não é usar vibe coding. É usar o critério da descoberta quando o problema já é de produção.
Um teste de cinco perguntas
Antes de aprovar a ida de um protótipo para produção, vale responder:
- Quem é o dono do código, e ele está versionado em repositório da empresa?
- Onde o dado fica, e isso atende à exigência regulatória do nosso setor?
- Qual política de IA se aplica ao que foi construído, e como isso é verificado?
- Com quais sistemas internos ele precisa falar, e isso foi desenhado ou improvisado?
- Quem responde quando parar de funcionar?
Protótipo que responde as cinco está pronto. Protótipo que não responde nenhuma não está atrasado — está apenas em outra fase, e tratá-lo como produto é o que gera dívida.
