O código sai voando, mas a vulnerabilidade vai junto

Um desenvolvedor monta um SaaS inteiro em um fim de semana. Sem conhecer framework a fundo, sem revisão de código, sem repertório sólido de segurança. O produto funciona. Os usuários entram. A demo impressiona. Só depois vem o detalhe que ninguém colocou no pitch: as chaves de API ficaram expostas para a internet inteira.

Esse é o paradoxo do vibe coding em 2026. Nunca foi tão fácil publicar software útil. Nunca foi tão fácil publicar falhas junto com ele.

A parte mais rápida do processo continua sendo a mais enganosa

O dado mais desconfortável vem da análise da Veracode, que testou mais de 100 modelos em 80 tarefas reais de programação. O resultado foi direto: 45% do código gerado por IA falhou em testes de segurança, levando vulnerabilidades da OWASP Top 10 para sistemas de produção. Java foi o pior caso, com taxa de falha acima de 70%. Python, C# e JavaScript ficaram entre 38% e 45%.

O que torna isso mais inquietante é o contraste entre funcionalidade e segurança. Há dois anos, menos de 20% das amostras de código gerado por IA sequer rodavam. Agora, cerca de 90% compilam na primeira tentativa. Só que a taxa de insegurança quase não saiu do lugar. A máquina ficou melhor em acertar sintaxe e fluxo. Não ficou melhor em proteger o sistema que ela mesma monta.

Modelos maiores também não resolveram esse descompasso. Segundo a própria leitura da Veracode reproduzida pela Help Net Security, LLMs mais novos e mais robustos não entregam código substancialmente mais seguro do que versões menores.

Cada iteração nova melhora a feature e piora o risco

Esse é o ponto que mais derruba a fantasia do “vai ajustando depois”. Pesquisadores da Kaspersky encontraram um padrão claro: depois de apenas cinco iterações de prompt, o código passou a conter 37% mais vulnerabilidades críticas do que na geração inicial. Os prompts focados em adicionar funcionalidades produziram 158 novas vulnerabilidades, incluindo 29 críticas.

O mecanismo é simples de entender. Cada revisão acrescenta complexidade sem consciência arquitetural. O modelo responde bem à pergunta “funciona?”. Ele responde mal à pergunta “o sistema continua coerente, isolado e defensável?”. No caminho, começa a acumular problemas parecidos com as falhas de segurança em infraestrutura de agentes de IA, que se multiplicam justamente porque ninguém para para redesenhar a base.

A consequência prática é cruel. O código parece mais completo a cada rodada, mas sua superfície de ataque cresce em silêncio. Você ganha velocidade local e perde estabilidade sistêmica.

O erro mais perigoso nem sempre é SQL injection

Há uma nuance importante aqui. Um estudo de dezembro de 2025, citado pela CSO Online a partir da pesquisa da Tenzai, testou cinco ferramentas de coding, entre elas Claude Code, Codex, Cursor, Replit e Devin, criando três aplicações idênticas com cada uma. O grupo encontrou 69 vulnerabilidades em 15 aplicações.

O dado mais interessante não está na quantidade, mas no tipo de falha. As ferramentas não produziram SQL injection explorável nem XSS clássico em nível preocupante. Esses padrões já foram suficientemente documentados e, em certa medida, treinados para fora dos modelos. O risco mais sério apareceu em vulnerabilidades de lógica de negócio.

É o checkout de e-commerce que aceita o preço enviado pelo usuário. É o endpoint que confia em autorização feita no cliente. É o sistema que parece correto linha por linha, mas erra no entendimento do que deveria impedir. São exatamente esses buracos que empresas sem defesa contra exploits ligados a IA costumam deixar passar, porque exigem contexto, intenção e julgamento de produto, não apenas código que compila.

O ganho de 81% pode virar dívida técnica exponencial

A velocidade existe. A questão é o que ela compra e o que ela empurra para depois. A InfoQ, repercutindo uma análise da Ox Security, descreveu o código gerado por IA como altamente funcional, mas sistematicamente fraco em julgamento arquitetural. Entre 80% e 90% dos projetos avaliados apareceram anti padrões recorrentes: comentários em excesso, aversão a refatoração, especificação demais e bugs reincidentes que deveriam ter sido eliminados na primeira correção.

Foi nesse contexto que a analista Ana Bildea chamou o fenômeno de dívida técnica exponencial. A dívida tradicional cresce em linha reta. A dívida criada por IA se acumula por composição. Por um tempo, a empresa sente que está entregando mais. Depois descobre que a manutenção, o retrabalho e os patches comeram a vantagem inteira. É a mesma lógica por trás dos ganhos de produtividade com IA que somem no retrabalho.

A percepção do desenvolvedor também engana. O estudo da METR, citado no artigo base, encontrou um contraste duro: profissionais se sentiram 20% mais rápidos, mas mediram 19% mais lentos em bases reais. O impulso é real. O custo chega depois.

A correção existe, mas ela destrói a fantasia do atalho

Os dados apontam para uma conclusão que pouca gente quer ouvir. Prompting orientado por segurança funciona. O mesmo estudo da Kaspersky mostrou que até uma instrução genérica, como pedir aderência a boas práticas de código seguro, corta a taxa de vulnerabilidade pela metade. Quando a orientação fica específica por linguagem e por contexto, a melhora continua.

Só que isso exige exatamente o tipo de pensamento deliberado que o vibe coding vende como dispensável. Pedir “crie um sistema de pagamentos” é rápido. Pedir “crie um sistema de pagamentos com validação de autorização no servidor, sanitização de entradas, rate limiting e aderência às práticas da OWASP” já pressupõe saber o que precisa ser cobrado.

É por isso que as equipes que acertam tratam o código da IA como rascunho, não como obra pronta. Funciona melhor quando entra no fluxo de engenharia, não quando tenta substituí-lo. O padrão se repete no que explica por que a maioria das empresas usa IA sem lucrar com ela: ferramenta ajuda, julgamento continua humano.

Vibe coding entrega rápido. A pergunta certa não é se ele acelera. É se você consegue pagar pelo que ele quebrou.