Seu protótipo com IA ficou pronto em poucas horas. Você colocaria isso em produção?

A demo ficou pronta em uma tarde.

A interface está bonita. O login funciona, o formulário salva e o dashboard carrega os dados. Alguém compartilha o link no Slack e, poucos minutos depois, aparece a frase que todo desenvolvedor já aprendeu a temer:

“Já que está funcionando, não dá para colocar em produção?”

Até pouco tempo atrás, transformar uma ideia em algo funcional levava tempo. E esse tempo, por mais incômodo que fosse, obrigava o time a encarar várias decisões técnicas durante o caminho.

Com a IA generativa↳IA generativa81 conteúdosIA Generativa: 5 alternativas para começar a usar em 2025AI · jan 2025Gartner Revela o Futuro da IA GenerativaAI · jul 2024IA Generativa: Pesquisa global aponta Brasil como segundo país mais otimista com a tecnologiaAI · mar 2024Ver tudo em AI →, esse intervalo encolheu.

Você descreve o que quer, pede uma alteração, cola uma mensagem de erro, tenta outra abordagem e continua até a aplicação parecer pronta. Esse jeito de construir software ganhou um nome: vibe coding.

E funciona muito bem, até certo ponto.

O problema não é usar vibe coding. O problema começa quando ninguém percebe que o experimento terminou. De repente, aquele protótipo tem usuários, dados reais, integrações, custo de manutenção e consequências que não estavam previstas na primeira tarde.

Vibe coding resolve bem uma etapa que a engenharia tradicional costuma encarecer

Existe um momento do desenvolvimento em que você não precisa decidir como o sistema vai funcionar pelos próximos cinco anos.

Primeiro, precisa descobrir se ele deveria existir.

• O fluxo faz sentido?
• A API entrega o que você imaginou?
• O cliente entende a interface?
• A automação economiza tempo suficiente para justificar o projeto?

Para responder a esse tipo de pergunta, vibe coding é uma ferramenta e tanto.

A IA derruba o custo da experimentação. Em vez de passar dias montando estrutura, componentes e integrações só para validar uma hipótese, você consegue colocar algo executável na frente das pessoas em poucas horas.

Isso muda a lógica da prototipagem.

Uma ideia que morreria em uma reunião pode ser testada. Duas abordagens podem ser comparadas lado a lado. Produto e engenharia conseguem discutir olhando para a mesma tela, em vez de cada pessoa imaginar uma versão diferente do que está sendo proposto.

Nesse contexto, não há problema em produzir código descartável.

O problema é que ninguém gosta de jogar fora algo que já parece funcionar.

O protótipo que se recusa a morrer

Press enter or click to view image in full size

Boa parte da dívida técnica não nasce de uma decisão absurda. Nasce de uma decisão temporária que passou da data de validade.

No começo, o protótipo precisava apenas demonstrar um fluxo.

• Depois ganhou autenticação.
• Alguém conectou dados reais.
• Um pequeno grupo começou a usar.
• Uma automação importante passou a depender dele.

Quando o time percebe, a aplicação criada para responder “será que funciona?” precisa responder perguntas bem mais difíceis:

• Continua funcionando com dez vezes mais usuários?
• O que acontece quando uma integração externa cai?
• Os dados sensíveis estão protegidos?
• Há logs suficientes para investigar um erro?
• Alguém entende as dependências que entraram no projeto?
• Os testes protegem os comportamentos importantes ou só confirmam o caminho feliz?
• Quem cuida da manutenção daqui para frente?

Essa mudança de natureza é o centro da discussão.

Um protótipo não vira produto porque ganhou uma interface bonita. Ele vira produto quando alguém passa a depender dele.

Interface bonita não revela dívida técnica

Press enter or click to view image in full size

Vibe coding é sedutor porque o resultado visível aparece depressa.

• Os botões funcionam.
• As telas respondem.
• Os dados aparecem.

O caminho feliz impressiona durante a demo. Só que boa parte da qualidade de um sistema mora justamente no que a demo não mostra:

• tratamento de erros;
• permissões;
• concorrência;
• migração de dados;
• observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps →;
• rollback;
• limites de API;
• segredos e credenciais;
• dependências abandonadas;
• comportamento sob carga;
• acessibilidade↳Acessibilidade11 conteúdosO que é Acessibilidade Web e como tornar seu site mais acessívelDev (Back & Front) · mar 2019Design para veteranos digitais: acessibilidade para nós mesmosProduto & UX · jan 2020Dicas de Front-End para usabilidade, acessibilidade, performance e responsividadeProduto & UX · fev 2025Ver tudo em Produto & UX →;
• Manutenção.

É fácil confundir rapidez para produzir algo visível com rapidez para produzir software confiável.

Não são a mesma coisa.

A interface pode parecer pronta quando o trabalho de engenharia ainda mal começou.

O problema não é a IA escrever código que você não escreveria

Essa conversa perde valor quando vira uma defesa romântica da programação manual.

Não existe mérito especial em digitar cada caractere. Se uma IA consegue montar um componente, uma API, alguns testes ou um script de integração em menos tempo, melhor. O ganho de produtividade é real justamente porque você deixa de gastar energia com partes mecânicas do trabalho.

Mas delegar a escrita não é o mesmo que delegar as decisões.

Se ninguém sabe por que determinada biblioteca entrou no projeto, por que o estado está sendo persistido daquela forma ou quais premissas uma função assume, o problema não é a origem do código.

O problema é que ninguém assumiu responsabilidade por ele.

Vibe coding funciona enquanto o custo de errar é baixo. Quando esse custo cresce, o rigor precisa acompanhar.

Existe uma hora de sair do modo vibe

Em vez de discutir se vibe coding é bom ou ruim, vale fazer uma pergunta mais útil:

O que transforma um experimento em um projeto de engenharia?

Alguns sinais são claros. O contexto mudou se o software:

• armazena dados reais;
• exige autenticação;
• movimenta dinheiro;
• controla permissões;
• participa de processos importantes;
• atende clientes;
• Torna-se dependente de outra equipe.

A partir desse ponto, continuar tratando o projeto como uma sequência de prompts e ajustes visuais deixa de ser experimentação. Passa a ser uma escolha consciente de acumular risco.

É hora de tornar algumas coisas explícitas:

• requisitos e limites;
• decisões de arquitetura;
• modelo de dados;
• estratégia de testes;
• tratamento de erros;
• segurança;
• observabilidade;
• processo de revisão;
• Responsabilidade pela manutenção.

Isso não significa apagar tudo o que a IA produziu e começar do zero. Significa apenas parar de tratar “está funcionando” como prova suficiente de que o sistema está pronto.

Um modelo simples: explorar, validar e industrializar

Uma forma mais madura de trabalhar com vibe coding é separar o projeto em três modos.

Press enter or click to view image in full size

1. Explorar

Aqui, velocidade vem primeiro.

O objetivo é responder perguntas, testar ideias, comparar interfaces e descobrir possibilidades. Código descartável faz parte do jogo. Uma arquitetura preparada para os próximos cinco anos não é prioridade.

O erro, nessa fase, custa pouco. Então faz sentido avançar depressa.

2. Validar

A hipótese parece promissora. Agora você precisa descobrir se ela funciona fora da apresentação.

É hora de usar dados mais próximos da realidade, testar os fluxos importantes, revisar dependências e entender os limites das integrações. Também é o momento de olhar com cuidado para as decisões que a IA tomou sem chamar a atenção durante a construção.

Cada atalho precisa ser identificado.

• O que entrou porque fazia sentido?
• O que entrou apenas porque resolveu o prompt naquele momento?
• O que pode permanecer?
• O que precisa ser refeito antes de seguir?

3. Industrializar

Se o sistema vai para produção, ele precisa entrar no mesmo processo de qualidade aplicado ao restante do produto:

• revisão de código;
• testes proporcionais ao risco;
• segurança;
• observabilidade;
• CI/CD;
• documentação suficiente;
• Responsabilidade bem definida.

A IA pode continuar escrevendo boa parte do código nas três etapas. A diferença não está necessariamente em quem digita.

Está no nível de evidência exigido antes de confiar no resultado.

A pergunta não é quanto código a IA escreveu

Vibe coding talvez seja uma das melhores ferramentas que já tivemos para reduzir a distância entre uma ideia e algo executável.

Seria um desperdício usar essa capacidade apenas para reproduzir, com mais velocidade, o mesmo processo de desenvolvimento de antes.

Mas também seria um erro transformar rapidez de prototipagem em desculpa para abandonar práticas criadas por um motivo simples: software real falha de maneiras muito menos apresentáveis do que uma demo.

A equipe mais preparada não será a que rejeita vibe coding. Também não será a que publica cada protótipo assim que a tela fica bonita.

Será a equipe que sabe mudar de marcha.

Explorar rápido enquanto o custo do erro é baixo.
Aumentar o rigor conforme o impacto cresce.
E reconhecer quando uma experiência deixou de ser descartável e passou a merecer engenharia.

Porque velocidade sem responsabilidade não elimina dívida técnica.

Só faz a conta chegar mais cedo.

E, no seu time, qual é o sinal de que um protótipo feito com vibe coding deixou de ser experimento e passou a exigir engenharia de verdade?