Vibe coding sem controle: o que se economiza em horas se paga em meses

1Achavam que iam mais rápido

No início de 2025, a organização de pesquisa METR fez um experimento pouco comum: reuniu 16 desenvolvedores experientes, atribuiu-lhes tarefas reais em repositórios de código aberto que conheciam bem e sorteou em quais poderiam usar ferramentas de IA e em quais não. Antes de começar, os desenvolvedores estimaram que a IA os tornaria 24% mais rápidos. Ao terminar, acreditavam que isso havia acontecido: calcularam que tinham ganhado 20% de velocidade. O cronômetro disse outra coisa. Com IA, as tarefas levaram 19% mais tempo.¹

O resultado não pode ser generalizado, e a própria METR publicou em 2026 dados preliminares que sugerem que as ferramentas mais recentes de fato aceleram o trabalho, embora com limitações metodológicas importantes.² Mas o experimento expôs algo que vai além da velocidade: a distância entre o que sentimos que a IA faz por nós e o que ela efetivamente faz. Essa distância é o terreno onde prospera o vibe coding.

Não é o único dado nessa direção. Em 2023, pesquisadores de Stanford constataram que quem programava com um assistente de IA escrevia código menos seguro do que quem não o usava e, ao mesmo tempo, estava mais convencido de que seu código era seguro.³ E na pesquisa de 2025 do Stack Overflow, com mais de 49.000 desenvolvedores, 84% dizem usar ou planejar usar IA, mas apenas 33% confiam na exatidão do que ela produz; dois em cada três apontam como sua maior frustração as respostas “quase corretas”.⁴

O termo foi cunhado por Andrej Karpathy em fevereiro de 2025 para descrever uma forma de programar em que a pessoa descreve o que quer, deixa a IA escrever o código, testa e pede ajustes, sem necessariamente ler o que foi gerado.⁵ O que antes levava semanas hoje pode virar um protótipo funcional em uma tarde. É um avanço extraordinário, e seria um erro minimizá-lo. Mas ele vem com uma ilusão perigosa: acreditar que produzir software que funciona equivale a construir uma solução robusta.

Uma aplicação pode funcionar perfeitamente em uma demonstração e, ao mesmo tempo, ter uma arquitetura que não suporta crescer, dependências difíceis de manter, vulnerabilidades que ninguém vê, nenhum tratamento de erros, problemas de concorrência ou de integridade de dados, e nenhum mecanismo para se recuperar quando algo falha. Nada disso aparece na primeira execução. Por isso o risco não é que a IA escreva código ruim; os humanos também escrevem. O risco é que a facilidade para obter resultados visíveis substitua a disciplina para validar os invisíveis.

2O que as evidências revelam sobre o código gerado por IA

A preocupação não é apenas teórica. Em março de 2026, a Veracode publicou sua avaliação mais recente do código gerado por modelos de linguagem: 80 tarefas de programação em quatro linguagens, desenhadas para tentar os modelos com vulnerabilidades conhecidas. Mais de 95% do código gerado estava sintaticamente correto. Apenas 55% era seguro. Nas tarefas expostas a ataques do tipo cross-site scripting, só 15% das respostas eram seguras; em Java, 29%. Nem mesmo os modelos mais avançados, com raciocínio estendido, passaram de 72%.⁶ Ou seja, o problema não se resolve apenas esperando o próximo modelo. Tampouco é novo: em 2021, um estudo da Universidade de Nova York constatou que cerca de 40% dos programas gerados pelo GitHub Copilot em cenários de risco tinham vulnerabilidades.⁷

A manutenibilidade mostra uma tendência parecida. A GitClear analisou 623 milhões de alterações de código entre 2023 e 2026. A duplicação de blocos de código cresceu 81% desde 2023, e a proporção de código refatorado (reorganizado para ser reutilizado em vez de copiado) caiu de 21% das linhas modificadas em 2022 para menos de 4% em 2026. Hoje os desenvolvedores copiam cinco vezes mais do que refatoram.⁸ A GitClear tem o cuidado de não atribuir toda a causa à IA, mas a direção coincide com o que qualquer equipe de engenharia observa: escreve-se mais código, e organiza-se menos.

O Google chega a uma conclusão parecida por outro ângulo. Seu relatório DORA 2024, o estudo de referência sobre o desempenho das equipes de engenharia, constatou que nas equipes que adotaram IA a velocidade de entrega caiu 1,5% e a estabilidade do que foi entregue, 7,2%.⁹ Escrever código mais rápido não se traduziu em entregar software melhor.

Nenhum desses estudos mede o universo completo do software construído com IA, e seus números não devem ser lidos assim. O que mostram, em conjunto, é um princípio: a velocidade percebida não é produtividade efetiva, e o código que compila não é código seguro nem manutenível.

3O custo não desaparece. Ele se desloca.

A produtividade do desenvolvimento assistido por IA costuma ser medida pelo tempo até ter um protótipo ou pela quantidade de funcionalidades entregues. São métricas legítimas, mas olham apenas a primeira linha da conta. O custo de um sistema inclui também validá-lo, operá-lo, mantê-lo, protegê-lo e, às vezes, reconstruí-lo. A IA reduz drasticamente a primeira rubrica. Se ao mesmo tempo se reduzem a revisão e a compreensão, as demais crescem. O custo se move para a frente, justamente para onde corrigir é mais caro.

Um caso ilustrativo torna isso visível. Os números são premissas arredondadas, não a medição de uma empresa real.

A área comercial de uma empresa precisa de uma aplicação que consolide informações de vendas de várias fontes e sugira quais clientes contatar. Há três caminhos.

Caminho A: desenvolvimento tradicional. Uma equipe pequena a constrói em seis semanas, com arquitetura, testes e revisão de segurança. Desenvolvimento e validação custam USD 110.000, e operá-la e mantê-la durante dois anos, outros USD 80.000.

Caminho B: vibe coding sem controle. Uma pessoa da área a constrói em três dias com IA, por USD 20.000. Funciona tão bem que em poucas semanas toda a força de vendas a usa e começa a carregar dados de clientes. No sexto mês, uma revisão de segurança encontra credenciais expostas e dados de diferentes clientes sem separação: corrigir isso custa USD 35.000. No décimo mês, quando já é usada por 200 pessoas, é preciso reconstruí-la para suportar usuários simultâneos e mudanças nas fontes: USD 110.000. E como ninguém conhece bem sua lógica, operá-la e mantê-la custa USD 125.000 em dois anos, quase o dobro do caminho A.

Caminho C: vibe coding com controles desde o início. A mesma pessoa a constrói com IA em uma semana, mas com um engenheiro que define desde o começo os controles mínimos: onde ficam as credenciais, como os dados são separados, quais testes automatizados são executados e quem responde se algo falhar. Custa USD 45.000 no início, mais USD 40.000 no sexto mês para prepará-la antes de abri-la para toda a área, e USD 80.000 de operação e manutenção.

O caminho B é o mais barato durante os primeiros nove meses, e é o que qualquer comitê aprovaria olhando apenas o orçamento inicial. Ao fim de dois anos é o mais caro, de longe. O caminho C, por sua vez, captura quase toda a velocidade da IA e acaba sendo o mais barato dos três. Além disso, B e C começam a entregar valor desde a primeira semana, enquanto A leva um mês e meio.

A conclusão não é que o vibe coding seja caro. É que o vibe coding sem controle é caro, e o problema se esconde justamente no período em que todos estão celebrando a rapidez com que ficou pronto.

4A dívida de compreensão

Há um custo menos visível do que as vulnerabilidades ou a reconstrução: a perda de compreensão do sistema.

Escrever código à mão nunca garantiu entendê-lo, mas obrigava a tomar decisões explícitas: como estruturar os componentes, o que fazer com os erros, como os serviços se comunicam. Com o vibe coding, muitas dessas decisões são tomadas pelo modelo e ficam implícitas. O resultado são sistemas que funcionam, mas cuja lógica interna ninguém da equipe revisou de verdade.

Vi isso de perto em projetos de agentes de IA para mineração, em sistemas de processamento de imagens e em aplicações da área comercial. O protótipo aparece rapidíssimo e funciona na demonstração. Meses depois, uma parte deixa de funcionar, ou começa a falhar sem aviso, e ninguém da equipe consegue explicar por quê. Tampouco alguém sabe bem que riscos trazem suas integrações com os sistemas da operação. Não é um problema do modelo nem das pessoas: é que as decisões que o modelo tomou nunca foram tomadas, nem documentadas, por ninguém da equipe.

Addy Osmani, engenheiro do Google, deu nome a isso em abril de 2026: dívida de compreensão, a lacuna entre quanto código existe em um sistema e quanto desse código alguém realmente entende.¹⁰ É diferente da dívida técnica. A dívida técnica, a metáfora que Ward Cunningham propôs em 1992, descreve decisões de implementação que encarecem as mudanças futuras.¹¹ A dívida de compreensão surge quando o conhecimento para explicar, modificar, validar ou reconstruir um sistema simplesmente não está na equipe que o opera. Uma aplicação pode ter uma arquitetura razoável e uma dívida de compreensão enorme, se ninguém conhece suas premissas, suas dependências nem seus limites. O fenômeno também tem respaldo experimental: em 2025, o MIT Media Lab constatou que quem escrevia com a ajuda do ChatGPT lembrava menos do que havia produzido e mostrava menor conectividade cerebral do que quem escrevia sem ajuda, um efeito que seus autores chamaram de dívida cognitiva.¹²

O que me interessa acrescentar é sua dimensão econômica. A dívida de compreensão não é um problema dos engenheiros: é um custo diferido que não aparece em nenhum orçamento e que é cobrado no pior momento, quando algo falha e ninguém sabe por quê, quando uma mudança em uma fonte quebra tudo, ou quando é preciso demonstrar a um regulador como o sistema toma suas decisões. No caminho B do caso, boa parte dos USD 125.000 de operação é exatamente isso: pagar, uma vez após a outra, por não entender o que foi construído.

A pergunta deixa de ser técnica: quem entende realmente as decisões que levaram a construir a solução dessa maneira?

A resposta não passa por revisar à mão cada linha; isso eliminaria boa parte do ganho. Em Expert Validation Loop propus que a supervisão humana não se limite a aprovar o que a IA entrega, mas que valide o raciocínio, as premissas e o método antes que um resultado seja usado. Aplicado ao vibe coding, significa que alguém com critério de engenharia define o que é correto, seguro e suficientemente robusto, e que a automação (análise estática, testes, revisão de dependências) verifica o resto. O humano não precisa escrever o código. Precisa manter o controle sobre os critérios que decidem se esse código é aceitável.

5Protótipo não é produto

Isso já não é hipotético. Em 2025, um pesquisador analisou aplicações construídas com o Lovable, uma das plataformas de vibe coding mais populares, e encontrou pelo menos 170 que expunham dados de seus usuários (e-mails, telefones, status de pagamento e chaves de acesso a outros serviços) porque ninguém havia configurado corretamente quem podia ler o quê no banco de dados. O problema foi registrado como uma vulnerabilidade oficial, a CVE-2025-48757.¹³ No mesmo ano, o investidor Jason Lemkin relatou publicamente como o agente de IA da Replit apagou o banco de dados de um projeto que ele estava construindo, em meio a um congelamento de código que ele mesmo havia pedido. O CEO da Replit classificou o episódio como inaceitável e anunciou que passaria a separar automaticamente os ambientes de desenvolvimento e de produção, algo que qualquer equipe de engenharia considera óbvio.¹⁴

Volto à área comercial do caso. O protótipo ficou pronto em três dias. A interface era atraente, os resultados pareciam corretos e a demonstração para a diretoria foi impecável. A organização concluiu o óbvio: o produto está praticamente pronto.

Ninguém fez as perguntas que separam uma demonstração de uma capacidade operacional. O que acontece se uma fonte mudar sua estrutura? Onde estão guardadas as credenciais? O que ocorre quando cem pessoas consultam ao mesmo tempo? Como ele se recupera se falhar? Quem controla as versões? Como se audita por que recomendou contatar um cliente e não outro? O que garante que os dados de um cliente não se misturem com os de outro? Não são exigências de uma grande plataforma corporativa. São o mínimo para passar de uma ideia validada a algo de que a empresa depende.

O custo oculto aparece no dia em que a organização descobre que aquilo que tratava como produto acabado era, na verdade, uma prova de conceito. Fred Brooks advertiu sobre isso há meio século em The Mythical Man-Month: o primeiro sistema que se constrói quase sempre acaba sendo descartado, e a única coisa que se pode decidir é se isso será planejado ou descoberto tarde.¹⁵ E isso não é um fracasso do vibe coding. É um fracasso de liderança ao fixar expectativas, orçamentos e critérios de maturidade.

Em The P&L Can Be Right descrevi a Dívida de Liderança em IA (AI Leadership Debt): o custo futuro que se acumula quando as decisões de liderança sobre IA avançam mais rápido do que a capacidade da organização de sustentá-las. Uma de suas seis formas é a dívida de arquitetura, e o vibe coding a acelera como nenhuma outra coisa. É possível incorrer nela de duas maneiras opostas: usar uma arquitetura experimental para algo que depois precisa escalar, ser seguro e estar sempre disponível; ou exigir desde o primeiro dia uma arquitetura superdimensionada para uma ideia que ninguém validou ainda. As duas destroem valor. A primeira adia custos de reconstrução; a segunda gasta capital antes de saber se há uma necessidade real.

Por que o vibe coding a acelera? Porque a velocidade com que surge uma solução funcional comprime a percepção de complexidade. A liderança vê o resultado, mas não o trabalho que falta para convertê-lo em uma capacidade sustentável. A facilidade para desenvolver acaba amplificando o custo de não saber o que se está desenvolvendo.

6Desenvolver rápido sem hipotecar o futuro

A resposta não é abandonar essas ferramentas nem voltar a processos rígidos e desnecessariamente lentos. Seria renunciar a uma das transformações mais importantes da engenharia de software. A alternativa é aproveitar a velocidade e introduzir, desde o começo, os controles mínimos para que o que foi construído possa evoluir. Chamo isso de vibe coding pronto para evoluir (Evolution-Ready Vibe Coding): não se trata de que cada protótipo esteja preparado para operar em escala corporativa, mas de distinguir quais decisões podem ficar em modo experimental e quais é preciso avaliar antes de comprometer o futuro do sistema.

Sete perguntas organizam essa distinção: que problema resolve e como saberemos que o resolveu; como vai evoluir; o que poderia comprometer; como sabemos que funciona corretamente, incluindo os casos-limite; quem entende o sistema; quem responde quando falha; e quanto custará mantê-lo e escalá-lo. Alguns desses controles podem ser automatizados dentro do próprio processo de geração. Outros são decisões explícitas que não deveriam ser delegadas a um modelo.

A chave é a proporcionalidade. Uma ferramenta interna de uso temporário justifica controles simples. Uma aplicação que processa dados pessoais, apoia operações financeiras ou intervém em decisões clínicas precisa de padrões muito mais exigentes. No Chile, além disso, a Lei 21.719 exigirá que se possa explicar as decisões automatizadas que afetam significativamente as pessoas e responder em 30 dias a quem solicitar acesso a seus dados, algo muito difícil de cumprir com um sistema que ninguém entende.¹⁶ O rigor deve responder ao risco e ao impacto do sistema, não à ferramenta com que foi construído.

7Quando a velocidade se torna uma decisão de liderança

Há um paradoxo por trás de tudo isso. À medida que a IA automatiza a escrita de código, saber escrever instruções sintaticamente corretas vale menos. Mas outras capacidades valem mais: arquitetura, pensamento sistêmico, avaliação de riscos, compreensão de requisitos, desenho de testes e, sobretudo, a capacidade de reconhecer uma má decisão técnica quando ela parece boa. Um desenvolvedor experiente e uma pessoa sem formação podem construir aplicações que parecem equivalentes. A diferença aparece quando algo falha, quando os requisitos mudam, quando os usuários crescem ou quando é preciso demonstrar que o sistema cumpre alguma exigência. Aí, entender o software deixa de ser uma vantagem e se torna a condição para controlá-lo.

Por isso, capacitar as pessoas para usar assistentes de programação não basta. As organizações precisam da capacidade de especificar, avaliar, governar e manter software que em grande parte não foi escrito por nenhum humano. A alfabetização em IA não substitui a engenharia, e a facilidade de geração não substitui a responsabilidade técnica.

Na perspectiva da AI Value Realization Theory (AVRT), o marco com que analiso como a IA se converte em valor, a cadeia não termina quando a IA produz código. Esse código precisa ser validado, integrado a um processo, convertido em uma capacidade e produzir resultados mensuráveis. Cada passo pode falhar, e uma solução que começa com resultados positivos pode acabar destruindo valor se sua manutenção, seu risco e sua reconstrução custarem mais do que ela entrega.

Para um conselho, a pergunta não deveria ser quanto mais rápido a empresa pode construir software com IA. Deveria ser esta: que parte dessa velocidade está se convertendo em sistemas confiáveis, manuteníveis e capazes de gerar valor ao longo do tempo, e que parte em custos que ainda não vemos?

Acelerar a produção de software se nota em minutos. Acelerar a criação de valor só se demonstra quando o sistema é usado, mantido, adaptado e avaliado em condições reais. É aí que o custo oculto deixa de ser oculto.

A IA pode fazer com que desenvolver software pareça cada vez mais simples. Mas a simplicidade para criar não é simplicidade de engenharia.

Referências

1. METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. metr.org
2. METR (2026). Uplift update, 24 de fevereiro de 2026. metr.org
3. Perry, N., Srivastava, M., Kumar, D. e Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? Stanford University. arxiv.org/abs/2211.03622
4. Stack Overflow (2025). 2025 Developer Survey.
5. Karpathy, A. (2025). Publicação no X que cunhou o termo vibe coding, fevereiro de 2025.
6. Veracode (2026). Spring 2026 GenAI Code Security Update, 24 de março de 2026. veracode.com
7. Pearce, H. e outros (2022). Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. IEEE Symposium on Security and Privacy.
8. GitClear (2026). The AI Code Quality Maintainability Gap. gitclear.com
9. Google Cloud (2024). DORA: Accelerate State of DevOps Report 2024.
10. Osmani, A. (2026). Comprehension debt: the hidden cost of AI-generated code. O’Reilly Radar, 13 de abril de 2026.
11. Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA ’92.
12. Kosmyna, N. e outros (2025). Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task. MIT Media Lab.
13. CVE-2025-48757 (2025). Falta de controles de acesso em projetos gerados com Lovable. Reportado por Matt Palmer.
14. The Stack (2025). Vibe coding CEO deletes production database, 21 de julho de 2025.
15. Brooks, F. (1975). The Mythical Man-Month. Addison-Wesley.
16. Chile, Lei nº 21.719 sobre proteção e tratamento de dados pessoais. Biblioteca do Congresso Nacional do Chile.

O caso da área comercial é ilustrativo. O conceito de vibe coding pronto para evoluir é uma proposta do autor, ainda não validada empiricamente.