O que é vibe coding?
Vibe coding é construir software descrevendo a uma ferramenta de IA — Lovable, Bolt, Replit, Cursor — aquilo que quer, aceitando o código gerado praticamente sem o ler. O termo foi cunhado por Andrej Karpathy em fevereiro de 2025 e cobre hoje desde demos de fim de semana até aplicações feitas com IA com utilizadores pagantes.
É nessa última parte que a definição fica cara. Cerca de 45% do código gerado por IA introduz vulnerabilidades conhecidas, segundo o GenAI Code Security Report 2025 da Veracode, que testou mais de 100 modelos de linguagem em tarefas reais de programação. A Doomity, empresa de desenvolvimento de software com clientes nos EUA, Reino Unido, Espanha e Portugal, endurece aplicações feitas com IA para produção — este glossário explica o que o termo significa e onde estão os seus limites.
Atualizado: julho de 2026
O que significa vibe coding na prática, para lá do termo?
Na prática, vibe coding significa que a pessoa descreve resultados e a IA escreve a implementação, sem que ninguém leia o diff. Escreve o prompt, a ferramenta gera, experimenta o resultado com cliques e, se parecer certo, continua. O código passa a ser algo que tem, não algo que conhece.
O vocabulário ainda não assentou: aplicação vibe-coded, aplicação feita com IA ou protótipo gerado por IA descrevem o mesmo artefacto. A Doomity usa os termos indistintamente de propósito: para o risco não interessa o nome da aplicação, mas se alguém qualificado leu o que a IA produziu antes de utilizadores reais dependerem dela. As ferramentas em si — e o que cada uma deixa de fora — estão comparadas em ferramentas de vibe coding.
Para que serve realmente o vibe coding?
Para validar depressa — e nisso é genuinamente bom. Um fundador sem equipa técnica consegue pôr um produto funcional à frente de utilizadores reais em dias, observar o que fazem e perceber se alguém quer o produto. Isso antes custava meses e uma equipa contratada.
Aquilo que um protótipo vibe-coded acerta são ativos reais. Os ecrãs, os fluxos e as regras de negócio sobreviveram ao contacto com utilizadores verdadeiros — por isso a posição da Doomity é conservar o que o protótipo validou e reconstruir apenas o que a IA fingiu, não deitar fora o trabalho.
Onde falha uma aplicação vibe-coded quando chegam utilizadores reais?
Falha nos pontos que uma demo nunca exercita. Cinco falhas aparecem com tanta consistência, seja qual for a ferramenta, que a Doomity as verifica primeiro em cada auditoria:
- Autenticação de fachada. Um ecrã de login que convence, à frente de verificações que não verificam nada.
- Regras de base de dados abertas. O segundo utilizador consegue ler os dados do primeiro: a fuga clássica do vibe coding.
- Segredos no frontend. Chaves de API enviadas para todos os browsers, à espera de serem copiadas e faturadas.
- Sem rollback. Um deploy mau e não há volta, porque os deploys nunca foram desenhados, apenas repetidos.
- Sem testes. Cada alteração é uma aposta, e a IA que escreveu o código não sabe dizer o que parte.
Nenhuma das cinco aparece numa demo — exatamente por isso as demos continuam a convencer toda a gente até a produção discordar.
O vibe coding é suficientemente seguro para produção?
Por defeito, não — e quem o diz são os mais próximos das ferramentas. O inquérito da Stack Overflow de 2025 aos programadores mostra uma desconfiança crescente face ao código de IA não revisto entre quem usa estas ferramentas diariamente: os profissionais confiam menos no resultado precisamente porque são quem mais o lê.
A posição da Doomity, dita sem rodeios nas suas próprias páginas de serviço: a maioria dos protótipos vibe-coded não devia ir para produção tal como está, e alguns não deviam ir de todo. Não é um argumento contra as ferramentas. É um argumento contra publicar o resultado sem o ler, com dados de utilizadores reais por trás.
Como se compara o vibe coding com o desenvolvimento profissional?
A comparação honesta não é vibe coding contra código escrito à mão: é validar depressa contra operar em segurança à escala, e a estratégia vencedora costuma encadeá-los por esta ordem.
| Dimensão | Vibe coding | Desenvolvimento profissional |
|---|---|---|
| Tempo até à primeira demo | Dias: o argumento mais forte da abordagem | De semanas a meses, conforme o âmbito |
| Custo da primeira versão | A subscrição da ferramenta e o tempo do fundador | Uma rubrica de orçamento real desde o primeiro dia |
| Segurança e tratamento de dados | Desconhecidos até auditar; ~45% do código de IA traz vulnerabilidades (Veracode 2025) | Desenhados, revistos e testados como parte do trabalho |
| Quando ganha | Para validar uma ideia antes de comprometer dinheiro | Utilizadores reais, dados reais, pagamentos reais: tudo o que tem consequências |
É preciso abandonar a aplicação vibe-coded para a profissionalizar?
Não — e um fornecedor que o afirme antes de ler o seu código está a vender conforto, não engenharia. Na maioria das auditorias sobrevive mais protótipo do que o dono espera: os ecrãs, os fluxos e a lógica de negócio validados ficam; reconstroem-se a autenticação, as regras de dados e a infraestrutura onde a IA as fingiu. A comparação completa está em corrigir código feito com IA vs refazer do zero.
A Doomity executa isto como um trabalho de âmbito fechado: uma auditoria de cinco dias ao que aguenta e ao que não, seguida de um plano de endurecimento. Os seus engenheiros vêm de equipas que construíram para a Holcim, a Canon España e a Indra, e o seu próprio processo de entrega integra IA — até 40% mais rápido, com cada conclusão verificada por um engenheiro sénior.
FAQ
Para validar, sim: é o caminho mais rápido de uma ideia até algo que utilizadores reais podem tocar. O problema começa quando a validação se transforma em produção sem ninguém o decidir: o mesmo código não lido que servia para a demo passa a guardar dados e pagamentos de utilizadores reais. A Doomity trata o vibe coding como um primeiro capítulo legítimo — e publicar o resultado sem o ler como o verdadeiro erro.
Só depois de tornar reais as partes que a IA fingiu. As lacunas recorrentes: autenticação que não verifica nada, regras de base de dados que deixam um utilizador ler os dados de outro, segredos no frontend, ausência de rollback e de testes. Uma auditoria diz-lhe quais das cinco a sua aplicação tem. O Production Readiness Sprint da Doomity responde em cinco dias úteis, com um plano de endurecimento ordenado por risco.
Assuma que não é até alguém qualificado ler o código: o relatório 2025 da Veracode concluiu que cerca de 45% do código gerado por IA introduz vulnerabilidades conhecidas. Como primeiro sinal, a Doomity publica um diagnóstico de produção gratuito em /pt/ferramentas/diagnostico-de-producao: dez perguntas, três minutos, e sai a saber se o próximo passo honesto é lançar ou endurecer.
Conte que vão descobrir, porque o assessor técnico deles vai ler o repositório. Código feito com IA não é um red flag por si; código de IA não revisto a funcionar em produção, é. Se há uma ronda no seu roteiro, a sequência que funciona é endurecer primeiro e preparar a due diligence depois: entrar com a sua própria auditoria ganha a explicar as conclusões de outro.
Se a sua aplicação vibe-coded ultrapassou a fase de demo e estão a chegar utilizadores reais, o próximo passo é uma auditoria de âmbito fechado que diga o que aguenta e o que precisa de endurecimento — antes que os seus utilizadores o descubram por si.