Vibe Coding e Hacking Code: quando a IA repete o erro e o hacker aprende o padrão.

A inteligência artificial mudou o jeito de criar software.

Hoje, qualquer pessoa com uma boa ideia, um pouco de paciência e uma ferramenta de IA consegue pedir:

“crie um sistema de login com painel administrativo, cadastro de clientes, dashboard e integração com pagamento”.

Em poucos minutos, a tela aparece. O botão funciona. O cadastro salva. O gráfico sobe. A pessoa olha e pensa: pronto, tenho um sistema.

E é exatamente aí que mora o perigo.

Porque uma coisa é um sistema funcionar. Outra coisa, bem diferente, é esse sistema estar seguro.

Essa diferença sempre existiu no mundo da tecnologia. Mas, com o avanço do vibe coding, ela ficou muito mais perigosa.

Primeiro: o que é vibe coding?

Vibe coding é o nome moderno para uma prática cada vez mais comum: desenvolver software conversando com uma IA.

A pessoa descreve o que quer, a IA gera o código, ajusta a tela, cria a API, monta o banco de dados e entrega uma aplicação aparentemente pronta.

É quase como delivery por aplicativo. Só que, em vez de chegar uma pizza, chega um sistema. Às vezes com menos segurança do que a embalagem da pizza.

Eu uso IA todos os dias. Trabalho com GPT, Claude, Gemini e outras ferramentas. Acredito que IA é uma das maiores alavancas de produtividade da história recente da tecnologia.

O meu ponto não é ser contra IA. O meu ponto é outro: IA sem arquitetura, sem revisão e sem segurança é só velocidade em direção ao risco.

Minha tese: a IA aprendeu errado a gerar código.

Depois de trabalhar com diferentes modelos de IA aplicados ao desenvolvimento de software, cheguei a uma tese pessoal: a IA aprendeu errado a gerar Código, não porque ela seja incapaz. Muito pelo contrário.

Os modelos atuais são impressionantes. Eles geram código, corrigem bugs, explicam arquitetura, criam testes, refatoram sistemas e aceleram entregas de uma forma que poucos anos atrás parecia ficção científica.

O problema é que eles foram treinados, usados e validados por uma cultura que muitas vezes premia o “funcionou” antes de perguntar “está seguro?”.A IA aprendeu a entregar resultado visível.

Ela aprendeu a fazer a tela abrir. Aprendeu a fazer o botão salvar. Aprendeu a fazer o login parecer login. Aprendeu a montar dashboard bonito. Aprendeu a impressionar no primeiro teste. Mas segurança quase nunca aparece no primeiro teste. Segurança aparece quando alguém tenta acessar o que não deveria. Quando alguém manipula uma requisição. Quando alguém troca um ID na URL. Quando alguém força uma API. Quando alguém encontra

uma chave esquecida no código. Quando alguém testa o sistema fora do caminho feliz.

É aí que muitos sistemas feitos por IA mostram a verdade: eles funcionam, mas não resistem.

Os vícios da IA nascem do jeito como estamos usando IA

Quando digo que a IA aprendeu errado a gerar código, não estou dizendo que ela aprende automaticamente com cada prompt de um usuário em tempo real.

O problema é mais sutil.

A IA aprendeu a partir de muito código existente no mundo. E o mundo, sejamos sinceros, não é exatamente um templo de boas práticas. Tem código excelente. Tem código aceitável. Tem código feito às pressas. Tem tutorial incompleto. Tem exemplo didático que nunca deveria ir para produção. Tem gambiarra com autoestima alta.

A IA viu tudo isso.

Depois veio o vibe coding. E o vibe coding reforçou uma cultura perigosa: pedir resultado, não segurança. O usuário pede uma tela, um login, uma API. A IA entrega tudo isso.

Mas quase ninguém pede: garanta que esse endpoint não permita acesso indevido entre clientes diferentes.

Implemente auditoria para ações críticas. Proteja os segredos. Revise o fluxo de autorização. Teste se a permissão está sendo validada no backend, não só escondida na tela.

Então a IA entrega o que foi pedido. E o usuário valida pelo que consegue ver.

Abriu? Funcionou. Salvou? Funcionou. Logou? Funcionou. Só que segurança não mora no “funcionou”. Segurança mora no: e se alguém tentar usar errado?

É aí que surgem os vícios de código da IA: padrões repetidos de implementação que parecem resolver o problema, mas deixam frestas abertas. Esses vícios podem aparecer como segredos hardcoded, tokens previsíveis, validação apenas no frontend, endpoints sem autorização real, permissões mal separadas, falta de isolamento entre clientes e APIs que confiam demais no usuário.

Pesquisas recentes sobre aplicações geradas com IA já apontam padrões recorrentes desse tipo, especialmente em segredos hardcoded, credenciais comuns e endpoints previsíveis. O ponto central é simples: quando o erro se repete, ele deixa de ser apenas um erro. Ele vira padrão.E padrão pode ser estudado.

Meu ranking prático dos modelos: todos bons, nenhum sem supervisão.

Quando falamos de GPT, Claude e Gemini, é fácil cair na tentação de transformar tudo em campeonato. Quem ganhou? Quem é mais rápido? Quem programa melhor? Quem é o “Pelé do código”?

A verdade é que todos estão muito fortes. E todos exigem cuidado.

O ranking que me interessa não é apenas: qual modelo escreve mais código?

O ranking que me interessa é outro: qual modelo entrega resultado sem fazer o usuário esquecer da segurança?

E aqui minha resposta é direta: nenhum. Todos entregam muito. Todos impressionam. Todos ajudam. Todos aceleram. Mas nenhum substitui arquitetura, revisão e validação humana.

Esse ranking ajuda a explicar algo importante para quem não é técnico: o problema não é qual IA escreve mais código. O problema é quem está validando o código que ela escreveu.

O GPT pode gerar ótimo código inseguro. O Claude pode explicar lindamente uma arquitetura frágil. O Gemini pode analisar muito contexto e ainda assim não assumir o risco do negócio.

Por isso, no meu método, a IA não decide sozinha. A arquitetura é humana. A revisão é humana. A validação é humana. A responsabilidade é humana. A IA acelera. O especialista garante que essa aceleração não vire exposição.

A IA aprendeu a agradar o usuário, não a proteger a empresa.

A maior parte dos usuários pede resultado. Crie um painel. Faça uma API. Monte um sistema de cadastro. Coloque um login. Publique isso.

A IA responde tentando entregar aquilo que a pessoa consegue ver.

O usuário vê a tela, mas não vê a política de autorização.

Vê o botão de excluir, mas não vê se a API bloqueia exclusão indevida.

Vê a lista de clientes, mas não vê se uma empresa pode acessar dados da outra.

Vê o login, mas não vê se o token é seguro.

Vê o sistema rodando, mas não vê se existe auditoria, segregação, criptografia, controle de sessão, proteção contra abuso e gestão correta de segredos.

Esse é o ponto central da minha tese: a IA aprendeu a entregar o palco iluminado, mas segurança mora nos bastidores. E o problema dos bastidores é que ninguém aplaude quando eles funcionam.

Ninguém entra em um sistema e diz: “nossa, que autorização bem implementada”.

Mas quando ela falha, todo mundo percebe, geralmente tarde.

O “funcionou” virou uma armadilha.

No mundo do vibe coding, a validação costuma ser simples demais. Abriu? Funcionou. Salvou? Funcionou. Logou? Funcionou. Gerou relatório? Funcionou. Então pode publicar. Não pode.

Esse é o tipo de raciocínio que transforma protótipos em bombas-relógio.

Pesquisas sobre código gerado ou assistido por IA mostram que vulnerabilidades não são apenas uma hipótese. Elas aparecem em padrões reais: falhas de autorização, problemas de sessão, segredos expostos, dependências frágeis, entradas mal validadas e APIs confiando demais no usuário.

Em linguagem simples: código gerado ou assistido por IA pode carregar padrões mensuráveis de vulnerabilidade.

A pergunta de negócio não é apenas: esse código funciona? A pergunta correta é: esse código pode ir para produção sem colocar a empresa em risco?

Hacking code: o hacker não ataca só o sistema, ele ataca o padrão.

É aqui que entra um conceito que venho chamando de “hacking code”.

Não estou falando simplesmente de usar IA para atacar sistemas. Isso já existe e muita gente chama de vibe hacking. O que estou defendendo é diferente.

Hacking code é quando o hacker aprende como a IA costuma programar errado.

Ele não olha apenas para um sistema isolado. Ele olha para o padrão. Ele começa a perceber que aplicações geradas por IA repetem certos vícios: segredos deixados no código, tokens previsíveis, validações feitas só na tela, APIs que confiam demais no usuário, permissões mal separadas, rotas administrativas mal protegidas, bancos de dados sem isolamento correto, tratamento fraco de sessão e erros de autorização entre usuários ou empresas.

A partir desse momento, o ataque muda de nível. O hacker não precisa mais descobrir uma falha completamente nova em cada sistema. Ele procura os erros que a IA costuma repetir.

É como um ladrão que descobre que uma construtora instalou a mesma fechadura fraca em mil casas diferentes. Ele não precisa estudar cada casa do zero. Ele estuda a fechadura.

Esse é o ponto central do hacking code.

O risco não está apenas em um código ruim. Está no código ruim sendo replicado em escala, com aparência profissional e pouca revisão humana. Quando um erro se repete em muitos sistemas, ele deixa de ser acidente e vira superfície de ataque.

O hacker moderno não precisa apenas perguntar: qual é a falha deste sistema?

Ele pode perguntar: qual falha a IA provavelmente colocou neste tipo de sistema?

Essa é a virada. O vibe coding acelera quem constrói. O hacking code acelera quem reconhece o padrão fraco. E quando os dois se encontram, um sistema criado em minutos pode ser quebrado em minutos.

O código parece limpo, mas pode estar sujo onde importa.

Um dos pontos mais perigosos do código gerado por IA é que ele muitas vezes parece profissional. A estrutura é bonita. Os nomes das funções fazem sentido. A interface está organizada. O código parece moderno. O README fica até elegante.

Mas aparência de qualidade não é garantia de segurança.

A IA pode criar uma casa bonita e esquecer a chave do cofre embaixo do teclado.

E quando muitos usuários usam os mesmos modelos, os mesmos exemplos e prompts parecidos, o erro pode se repetir em escala.

Esse é um ponto crítico: a IA não erra como uma pessoa isolada. Ela pode errar em massa.

O caso Base44: quando a plataforma também vira parte do risco.

O risco não está apenas no código que a IA escreve. Está também nas plataformas, templates, integrações, deploys e permissões que cercam esse código.

Um caso relevante foi o da Base44, uma plataforma de vibe coding adquirida pela Wix. Pesquisadores da Wiz identificaram uma vulnerabilidade crítica que permitia acesso não autorizado a aplicações privadas criadas por usuários.

Esse caso é importante porque mostra que a discussão vai além de “o usuário gerou um código ruim”. O risco está na cadeia inteira. A plataforma precisa ser segura. O template precisa ser seguro. A autenticação precisa ser segura. O deploy precisa ser seguro. O armazenamento precisa ser seguro. As permissões precisam ser seguras.

Quando qualquer elo dessa corrente falha, a aplicação pode parecer normal para o dono e vulnerável para quem sabe onde olhar. É como uma loja com fachada bonita, vitrine iluminada, maquininha funcionando e café gourmet na recepção. Mas com a porta dos fundos aberta.

Segurança não é uma funcionalidade.

Um erro comum é tratar segurança como algo que se adiciona no final. Como se fosse um plugin. Depois a gente coloca segurança. Não funciona assim.

Segurança não é acabamento. Segurança é fundação.

Antes de gerar código, alguém precisa fazer perguntas que a IA não deveria responder sozinha:

Quem acessa esse sistema? Que tipo de dado será armazenado? Esse dado é sensível? Existem perfis diferentes de usuário? Uma empresa pode ver dados de outra? Como os acessos serão auditados? Onde ficam as chaves e segredos? O que acontece se alguém tentar usar a API fora da tela? Que impacto existe se esse sistema vazar informação? O que pode parar a operação da empresa?

Essas perguntas não são detalhes técnicos. São perguntas de negócio.

E é por isso que CEOs, diretores e conselheiros precisam entrar nessa conversa.

Porque uma falha de segurança raramente fica restrita ao departamento de TI. Ela vira problema financeiro, jurídico, reputacional e operacional.

O especialista não perdeu valor. Ele ficou mais importante.

Durante muito tempo, o valor do profissional de tecnologia estava muito ligado à capacidade de escrever código.

Hoje, isso mudou. Código ficou mais barato. Contexto ficou mais caro.

A IA consegue escrever código. Mas ela não entende sozinha o risco do seu negócio, a sensibilidade dos seus dados, a maturidade da sua operação, o impacto de uma falha ou as consequências de uma decisão mal tomada.

É aí que entra o especialista. O especialista não é mais apenas quem digita código. É quem sabe orientar a IA. É quem sabe revisar o que ela gerou. É quem sabe dizer: isso funciona, mas não deve ir para produção. É quem sabe desenhar a arquitetura antes da implementação. É quem sabe olhar para uma tela bonita e perguntar: e por trás, está seguro?

Esse é o papel que eu defendo.

A IA gera. O especialista conduz. A empresa só deveria publicar depois de validar.

Como uso IA no desenvolvimento seguro.

No meu trabalho, a IA entra como aceleradora. Não como arquiteta final.

Antes de pedir código, eu defino o desenho da solução.

Antes de criar banco, eu penso nos dados.

Antes de montar login, eu desenho autorização.

Antes de publicar, eu reviso segurança.

Antes de confiar, eu testo.

Esse é o fluxo correto.

A IA é útil para acelerar protótipos, gerar testes, criar documentação, comparar alternativas, revisar trechos, automatizar tarefas repetitivas e aumentar a produtividade da equipe.

Mas algumas decisões precisam continuar humanas: arquitetura do sistema, modelo de segurança, controle de acesso, segregação de dados, estratégia de deploy, gestão de segredos, rastreabilidade, validação de integrações críticas e revisão final antes de produção.

Porque no fim, quando o sistema falha, ninguém chama o modelo de IA para a reunião.

Chamam o responsável. E é exatamente por isso que o humano não ficou menos importante. Ficou mais.

O recado para CEOs.

Se você é CEO, diretor, conselheiro ou gestor de uma área não técnica, o ponto não é aprender a programar. O ponto é entender o risco.

A pergunta não é mais: minha empresa deve usar IA para desenvolver?

Essa pergunta já ficou velha. A pergunta agora é: quem está garantindo que o que a IA desenvolveu pode ir para produção sem colocar meu negócio em risco?

Porque qualquer empresa pode ganhar velocidade com IA. A diferença está em saber se essa velocidade está sendo aplicada dentro de um processo maduro ou dentro

de um improviso bonito.

Empresas apressadas vão publicar rápido e descobrir depois. Empresas maduras vão publicar rápido também, mas com arquitetura, revisão, segurança e governança.

Essa é a diferença entre inovação e exposição.

Conclusão: quando a IA repete o erro, o hacker aprende o caminho.

A IA é poderosa. Ela acelera desenvolvimento, reduz barreiras, democratiza criação de software e permite que ideias saiam do papel em uma velocidade inédita.

Mas velocidade sem segurança não é transformação digital. É risco digital.

Minha tese é que a IA aprendeu a gerar código olhando demais para o resultado e de menos para a responsabilidade. Ela aprendeu a fazer o botão funcionar, mas nem sempre aprendeu a trancar a porta.

O vibe coding reforça esse problema quando valida o software pelo “funcionou”. E o hacking code nasce quando o hacker aprende os vícios que a IA costuma repetir. Esse é o novo risco.

Não é apenas um sistema com uma falha. É um padrão fraco replicado em muitos sistemas.

E quando o padrão se repete, a exploração fica mais rápida. A próxima fase da tecnologia não será dominada por quem apenas usa IA. Será dominada por quem sabe usar IA com método, arquitetura, segurança e responsabilidade.

Vibe coding entrega software em minutos. Engenharia segura garante que esse software possa existir por anos. E, no fim das contas, qualquer ferramenta pode criar uma tela bonita.O que protege uma empresa é o que acontece por trás dela.