🔍 45% de Vulnerabilidades: Pesquisa Stanford
Em 2022, pesquisadores da Stanford University e da University of Illinois publicaram um estudo que deveria ter sido um alarme para qualquer pessoa que usa IA para gerar codigo. Eles pediram a assistentes de IA que gerassem codigo para tarefas comuns de programacao e analisaram os resultados. A conclusao foi devastadora: quase metade do codigo gerado continha pelo menos uma vulnerabilidade de seguranca.
O mais perturbador nao foram as vulnerabilidades em si. Foi o fato de que os participantes do estudo que usaram IA acreditavam que seu codigo era MAIS seguro do que o dos participantes que codaram manualmente. A IA criou uma falsa sensacao de competencia que tornou os desenvolvedores menos cautelosos, nao mais.
Conceito Principal
O estudo analisou codigo gerado por LLMs em cenarios realistas: criptografia, manipulacao de strings, queries SQL, autenticacao e manipulacao de arquivos. Os tipos mais comuns de vulnerabilidade encontrados foram:
SQL Injection
A IA frequentemente gera queries SQL concatenando strings diretamente com input do usuario, sem usar prepared statements ou parametrizacao. Um atacante pode injetar comandos SQL maliciosos e acessar, modificar ou deletar dados inteiros do banco.
Cross-Site Scripting (XSS)
Codigo que renderiza input do usuario diretamente no HTML sem sanitizar. Isso permite que atacantes injetem scripts maliciosos que rodam no navegador de outros usuarios, roubando cookies, sessoes e dados pessoais.
Path Traversal
A IA gera codigo que aceita caminhos de arquivo do usuario sem validar, permitindo acesso a arquivos fora do diretorio permitido. Um input como "../../etc/passwd" pode expor arquivos sensivos do servidor.
A razao fundamental: LLMs aprendem com codigo publico, e uma quantidade enorme de codigo publico contem vulnerabilidades. O modelo reproduz os padroes mais comuns, e vulnerabilidades sao padroes comuns.
Dados da Pesquisa Stanford/UIUC
do codigo gerado continha pelo menos uma vulnerabilidade de seguranca (CWE catalogada)
dos participantes que usaram IA acreditavam que seu codigo era seguro (vs 40% do grupo controle)
CWE-89 (SQL Injection), CWE-79 (XSS), CWE-22 (Path Traversal) foram as mais frequentes
mais provavel que desenvolvedores com IA ignorem verificacoes de seguranca manuais
Dica Pratica
Toda vez que a IA gerar codigo que interage com input do usuario, banco de dados, ou sistema de arquivos, assuma que o codigo e vulneravel ate que voce prove o contrario. Adicione ao seu prompt:
Tratar seguranca como requisito explicito no prompt, nao como algo que a IA "deveria saber", reduz drasticamente o numero de vulnerabilidades no codigo gerado.
Fazer
- ✓Pedir prepared statements explicitamente
- ✓Validar todo input do usuario no servidor
- ✓Rodar scanners de seguranca no codigo gerado
- ✓Ler o estudo original para entender os riscos
Evitar
- ✗Assumir que a IA gera codigo seguro por padrao
- ✗Concatenar strings em queries SQL
- ✗Renderizar input do usuario sem sanitizar
- ✗Confiar no "parece certo" sem testar
💥 Os 5 Erros Fatais em Projetos com IA
Depois de analisar centenas de projetos construidos com Vibe Coding, cinco padroes de falha aparecem repetidamente. Eles nao sao erros tecnicos obscuros. Sao erros de processo e mentalidade que destroem projetos inteiros, geralmente quando ja e tarde demais para corrigir.
O perigo desses erros e que eles nao parecem erros no momento. Cada um deles parece uma decisao razoavel ("a IA gerou, deve estar certo", "vou adicionar so mais essa feature", "pra que commitar se ta funcionando"). O resultado so aparece depois, quando o projeto esta grande demais para consertar.
Os 5 Erros Fatais: Deep Dive
Confianca Cega (Copy-Paste sem Review)
Voce pede a IA para criar um componente. Ela gera 200 linhas de codigo. Voce cola no projeto, roda, funciona. Proximo. Esse ciclo se repete dezenas de vezes ate que voce tem um projeto de 5.000 linhas que voce nao entende. Quando algo quebra (e vai quebrar), voce nao sabe nem por onde comecar a debugar.
Caso real:
Um desenvolvedor construiu um SaaS inteiro com Cursor em 3 dias. Na quarta versao de deploy, um bug de autenticacao permitiu que qualquer pessoa acessasse dados de qualquer usuario. O dev nao conseguiu encontrar o bug porque nao entendia o fluxo de auth que a IA gerou. Levou 2 semanas para corrigir algo que teria sido pego em 5 minutos de code review.
Ignorar Seguranca (Sem Validacao de Input)
A IA gera codigo que funciona para o "happy path" (o caminho feliz onde tudo da certo). Mas software de verdade recebe inputs invalidos, maliciosos e inesperados. Sem validacao, seu app e um convite aberto para atacantes.
Caso real:
Um projeto de marketplace gerado com IA tinha um endpoint de pagamento que aceitava valores negativos. Um usuario descobriu e "comprou" produtos por -R$50, efetivamente recebendo dinheiro a cada compra. O dev nao tinha validacao de input em nenhum endpoint porque "a IA cuidou disso".
Zero Testes ("Works on My Machine")
"Testei manualmente e funciona" nao e teste. Teste manual verifica um caminho especifico com dados especificos em um momento especifico. Sem testes automatizados, cada mudanca que voce faz pode quebrar algo que funcionava antes, e voce so descobre quando o usuario reclama.
Caso real:
Um SaaS de automacao de emails funcionava perfeitamente nos testes manuais. No primeiro dia com usuarios reais, emails duplicados foram enviados para 2.000 pessoas porque o codigo nao tratava retries em caso de timeout da API. Um unico teste de integracao teria pego isso.
Escopo Infinito ("A IA Faz Parecer Facil")
A IA gera features em minutos. Isso cria a ilusao de que adicionar mais coisas nao tem custo. Mas cada feature adicionada aumenta a superficie de bugs, a complexidade de manutencao, e a confusao do usuario. O resultado e um produto que faz 20 coisas meia-boca em vez de 3 coisas muito bem.
Caso real:
Um builder comecou com "um app de lista de tarefas com IA". Em 2 semanas, adicionou: chat com IA, geracao de relatorios, integracao com calendario, dashboard de analytics, notificacoes push e modo offline. O app travava a cada 10 minutos, nenhuma feature funcionava direito, e zero usuarios ficaram apos o primeiro uso.
Sem Versionamento (YOLO Commits)
Voce esta no flow, a IA gerando codigo, tudo funcionando. Ai voce pede uma mudanca e tudo quebra. Sem Git, sem commits regulares, sem branches, voce nao tem para onde voltar. O unico caminho e tentar desfazer mentalmente o que mudou, o que e praticamente impossivel quando a IA gerou centenas de linhas.
Caso real:
Um projeto de 3 semanas de trabalho foi destruido em 30 minutos quando o dev pediu para a IA "refatorar a estrutura do banco de dados". A IA alterou schemas, migrations e queries. Metade do app quebrou. Sem um unico commit no historico, o dev teve que comecar do zero.
O Custo Real dos Erros
mais caro corrigir um bug em producao do que durante o desenvolvimento (IBM Systems Sciences Institute)
dos projetos solo com IA sao abandonados antes de completar 1 mes (pesquisa com builders indie, 2025)
custo medio de um data breach em 2023 (IBM Cost of a Data Breach Report)
dos bugs em codigo IA sao detectaveis com testes basicos (unit + integration)
Dica Pratica: A Regra dos 3 Commits
Antes de pedir qualquer mudanca significativa para a IA, faca um commit. Depois de implementar a mudanca e verificar que funciona, faca outro commit. Se algo quebrar depois, voce tem exatamente onde voltar.
// Fluxo seguro:
1. git commit -m "before: auth refactor"
2. Pedir mudanca para IA
3. Revisar codigo gerado
4. Testar
5. git commit -m "feat: new auth flow with sessions"
// Se quebrar, voltar e simples:
git checkout [hash do commit 1]
Fazer
- ✓Commit antes de cada mudanca grande
- ✓Ler todo codigo antes de aceitar
- ✓Validar inputs em todo endpoint
- ✓Definir escopo e respeitar o limite
Evitar
- ✗Aceitar codigo sem entender o que faz
- ✗Trabalhar sem Git inicializado
- ✗Adicionar features "porque e facil"
- ✗Deployer sem testes automatizados
👻 Alucinacoes de Codigo: Detectar e Prevenir
Alucinacoes nao sao exclusivas de texto. Quando uma IA gera codigo, ela pode inventar APIs que nao existem, usar funcoes com assinaturas erradas, importar pacotes ficticios e referenciar metodos que nunca foram implementados na biblioteca que ela esta usando. O codigo parece perfeitamente valido, a sintaxe esta correta, os nomes fazem sentido. Mas nao funciona.
O problema e que alucinacoes de codigo sao mais dificeis de detectar do que alucinacoes de texto. Um fato errado voce pode verificar no Google. Uma API inventada pode parecer real ate voce tentar executar o codigo e receber um erro criptico.
Conceito Principal: Tipos de Alucinacao em Codigo
APIs Fantasma
A IA inventa metodos que "fazem sentido" mas nao existem na biblioteca. Exemplo: supabase.auth.getUserProfile() parece real mas nao existe na API do Supabase. O metodo correto seria supabase.auth.getUser().
Pacotes Ficticios
A IA sugere instalar pacotes npm/pip que nao existem. Isso e especialmente perigoso porque atacantes criam pacotes com nomes que LLMs costumam alucinar (supply chain attack via "slopsquatting"). Se voce rodar npm install nome-inventado e o pacote existir, pode conter malware.
Assinaturas Erradas
A funcao existe mas os parametros estao errados. A IA mistura versoes de bibliotecas ou combina APIs de frameworks diferentes. Exemplo: usar a sintaxe de React Router v5 em um projeto v6, onde os hooks e componentes mudaram completamente.
Logica Plausivel mas Errada
O tipo mais perigoso. O codigo roda sem erros, parece correto, mas implementa a logica de forma errada. Exemplo: um calculo de juros compostos que usa juros simples, ou um filtro de data que compara strings em vez de objetos Date.
Escala do Problema
das sugestoes de codigo de LLMs contem pelo menos uma referencia a API inexistente (estudo Purdue University, 2024)
nomes de pacotes unicos que LLMs alucinam repetidamente, criando vetores para supply chain attacks
dos pacotes pip/npm sugeridos por GPT-4 nao existiam nos registros oficiais (pesquisa Vulcan Cyber, 2024)
confusao de versoes e a fonte mais comum de APIs "quase certas" mas incompativeis
Dica Pratica: O Teste de Verificacao em 3 Passos
Antes de usar qualquer codigo gerado por IA, passe por este checklist rapido:
Fazer
- ✓Verificar cada pacote no registro oficial antes de instalar
- ✓Consultar a documentacao da versao que voce usa
- ✓Testar com dados invalidos e edge cases
- ✓Especificar versoes de libs no prompt
Evitar
- ✗Rodar npm install sem verificar o pacote
- ✗Confiar em nomes de funcoes que "parecem certos"
- ✗Misturar versoes de bibliotecas no projeto
- ✗Ignorar erros de tipo/compilacao
🦯 Over-Reliance: Quando a IA Vira Muleta
Existe uma diferenca fundamental entre usar IA como ferramenta e depender da IA como muleta. A ferramenta amplifica suas capacidades. A muleta substitui elas. E quando a muleta e tirada (API fora do ar, limite de tokens atingido, bug que a IA nao consegue resolver), voce cai.
O fenomeno de over-reliance (dependencia excessiva) nao e novo. Aconteceu com calculadoras, GPS, autocorrect. Mas com codigo gerado por IA, as consequencias sao mais severas: voce pode construir um produto inteiro sem entender como ele funciona. E um dia voce vai precisar entender.
Conceito Principal: A Armadilha da Dependencia
A dependencia excessiva se manifesta em tres estagios progressivos:
Conforto
Voce usa IA para tudo porque e mais rapido. Faz sentido. E produtivo. Mas voce para de praticar resolucao de problemas por conta propria.
Atrofia
Depois de semanas sem pensar em logica por conta propria, voce percebe que precisa da IA ate para tarefas simples. Escrever um loop, debugar um erro basico, entender um stack trace. Skills que voce tinha estao enferrujadas.
Paralisia
A IA nao consegue resolver um problema (isso acontece mais do que voce imagina). Voce nao consegue resolver sozinho. O projeto para. Voce esta bloqueado por uma ferramenta que deveria te desbloquear.
A Regra 80/20 do Vibe Coding
A utilizacao ideal de IA em desenvolvimento segue um padrao claro. Nem tudo deve ser delegado, e nem tudo deve ser feito manualmente.
IA Brilha (80% do tempo)
- Boilerplate e codigo repetitivo
- Setup de projetos e configuracao
- Componentes UI padrao
- Testes unitarios basicos
- Documentacao e comentarios
- Conversao entre formatos
Voce Precisa Pensar (20% do tempo)
- Decisoes de arquitetura
- Logica de negocio complexa
- Seguranca e autenticacao
- Performance e otimizacao
- Debug de problemas sutis
- Decisoes de trade-off
Dica Pratica: O Exercicio Semanal
Uma vez por semana, resolva um problema pequeno sem IA. Pode ser um bug, um componente novo, ou um algoritmo. Nao precisa ser grande. O objetivo e manter suas habilidades de raciocinio ativas.
Outra pratica eficaz: antes de pedir para a IA resolver algo, tente descrever a solucao em pseudocodigo ou palavras. Isso forca voce a pensar na logica primeiro. Depois peca para a IA implementar a partir da sua descricao, nao do zero.
Pense na IA como um junior muito rapido: voce da a direcao, ele executa. Se voce nao sabe a direcao, ele vai escolher uma para voce. E pode nao ser a melhor.
Fazer
- ✓Usar IA para boilerplate e tarefas repetitivas
- ✓Pensar na logica antes de pedir implementacao
- ✓Praticar resolucao manual semanalmente
- ✓Entender cada parte do codigo do seu projeto
Evitar
- ✗Delegar decisoes de arquitetura para a IA
- ✗Pedir solucao sem entender o problema primeiro
- ✗Parar de estudar porque "a IA faz por mim"
- ✗Ignorar erros que voce nao entende
🛡️ Code Review e Testes como Rede de Seguranca
Se os topicos anteriores mostraram os riscos, este topico mostra a solucao. Code review e testes automatizados sao as duas praticas que transformam codigo IA de "potencialmente perigoso" para "confiavel em producao". A ironia e que a propria IA pode te ajudar a implementar essas redes de seguranca.
Codigo gerado por IA precisa de MAIS review, nao menos. A velocidade de geracao cria volume, e volume sem verificacao e um campo minado. A boa noticia: com um processo estruturado, o review de codigo IA e mais rapido que escrever o codigo do zero.
Conceito Principal: O Processo de Review em 4 Camadas
Camada 1: Logica
O codigo faz o que deveria fazer? Trace o fluxo mentalmente: dado um input X, o output sera Y? Verifique condicoes (if/else), loops (vai terminar?), e retornos (esta retornando o tipo certo?).
Camada 2: Seguranca
Inputs sao validados? Queries sao parametrizadas? Secrets estao protegidos? Autenticacao e verificada em cada rota protegida? Dados sensiveis estao sendo logados? Rate limiting existe?
Camada 3: Performance
Tem queries N+1? Loops desnecessarios? Dados grandes carregados sem paginacao? Chamadas de API sem cache? Imagens sem otimizacao? Componentes re-renderizando sem necessidade?
Camada 4: Edge Cases
O que acontece com input vazio? Null? Undefined? Muito grande? No formato errado? Quando a API externa esta fora do ar? Quando o usuario nao tem permissao? Quando dois usuarios fazem a mesma acao ao mesmo tempo?
Meta-Testing: IA Testando IA
Uma das tecnicas mais poderosas de Vibe Coding e pedir para a IA escrever testes para o codigo que ela mesma gerou. Isso cria uma camada de verificacao cruzada que pega erros que o review manual pode perder.
// Prompt para meta-testing:
"Aqui esta a funcao que voce gerou. Agora escreva:
1. 5 testes unitarios cobrindo o happy path
2. 5 testes cobrindo edge cases (null, vazio, tipo errado)
3. 2 testes de integracao com a API externa
4. 1 teste de performance com 1000 items"
Importante: revise os testes tambem. A IA pode gerar testes que so passam (testes que nao testam nada de verdade). Verifique se os assertions sao especificos e se os testes realmente falhariam se o codigo estivesse errado.
Dica Pratica: Checklist de Review para Codigo IA
Imprima ou salve esse checklist. Use antes de aceitar qualquer bloco significativo de codigo gerado:
Fazer
- ✓Pedir testes junto com cada feature nova
- ✓Revisar as 4 camadas antes de aceitar
- ✓Rodar testes a cada mudanca significativa
- ✓Verificar que os testes realmente testam algo
Evitar
- ✗Aceitar codigo sem nenhuma verificacao
- ✗Escrever testes so no final do projeto
- ✗Ignorar testes que falham ("depois eu arrumo")
- ✗Confiar em testes gerados pela IA sem revisar
📋 Exercicio: Checklist de Qualidade para Codigo IA
Teoria sem pratica e entretenimento. Neste exercicio voce vai construir seu proprio checklist de qualidade personalizado e aplica-lo a codigo real. O objetivo e criar um habito: nenhum codigo IA entra no seu projeto sem passar pelo checklist.
Ao final deste exercicio voce tera um documento que vai usar em todos os projetos das proximas trilhas. Trate isso como um investimento: 30 minutos agora para economizar horas de debug depois.
4 Etapas do Exercicio
Etapa 1: Construa seu Checklist Personalizado
Crie um documento com 4 categorias. Para cada categoria, liste pelo menos 3 itens que voce vai verificar em todo codigo IA:
Seguranca
Ex: Inputs validados? Queries parametrizadas? Secrets em .env? Auth em todas as rotas protegidas?
Logica
Ex: Consigo explicar cada funcao? Tipos corretos? Retornos esperados? Condicoes completas?
Performance
Ex: Sem N+1? Dados paginados? Cache onde necessario? Sem re-renders desnecessarios?
Mantenabilidade
Ex: Nomes claros? Funcoes pequenas? Comentarios onde necessario? Separacao de responsabilidades?
Etapa 2: Analise o Codigo Abaixo (Amostra 1)
Este codigo foi gerado por IA para um endpoint de login. Aplique seu checklist e identifique todos os problemas:
app.post('/login', (req, res) => {
const { email, password } = req.body;
const user = db.query(
`SELECT * FROM users WHERE email = '${email}'
AND password = '${password}'`
);
if (user) {
res.json({ token: jwt.sign(user, 'my-secret-key') });
}
});
Dica: esse snippet tem pelo menos 6 problemas graves. Quantos voce consegue encontrar?
Etapa 3: Analise a Amostra 2
Este componente React foi gerado por IA. Aplique seu checklist:
function UserProfile({ userId }) {
const [user, setUser] = useState(null);
useEffect(() => {
fetch(`/api/users/${userId}`)
.then(res => res.json())
.then(data => setUser(data));
});
return (
<div dangerouslySetInnerHTML=
{{ __html: user?.bio }} />
);
}
Dica: esse componente tem problemas de performance, seguranca e edge cases.
Etapa 4: Corrija e Compare
Para cada amostra, peca a IA para gerar a versao corrigida usando seu checklist como requisito. Compare o antes e depois. Os problemas que voce identificou foram corrigidos? A IA introduziu novos problemas?
Dica Pratica: Itere no Checklist
Seu checklist vai evoluir. Conforme voce constroi mais projetos, vai descobrir novos tipos de erro que a IA comete. Adicione-os ao checklist. Remove itens que se tornam automaticos. O objetivo e um documento vivo que reflete sua experiencia acumulada.
Um bom benchmark: se seu checklist tem menos de 12 items, provavelmente esta faltando algo. Se tem mais de 25, provavelmente tem itens redundantes. O sweet spot fica entre 15-20 itens organizados em 4 categorias.
Fazer
- ✓Criar o checklist antes de seguir para o proximo modulo
- ✓Analisar as amostras sem olhar as respostas
- ✓Salvar o checklist em local acessivel
- ✓Atualizar o checklist conforme ganha experiencia
Evitar
- ✗Pular o exercicio ("ja sei isso")
- ✗Copiar um checklist generico da internet
- ✗Fazer o checklist mas nunca usar
- ✗Criar um checklist enorme que ninguem vai ler
Resumo do Modulo 1.6
Codigo gerado por IA e poderoso, mas so e confiavel quando passa por verificacao rigorosa. Aqui esta o que voce aprendeu: