Outro dia, vi nos stories do Instagram uma amiga pesquisadora contando que estava usando o Claude para ressuscitar uma plataforma criada anos antes por parceiros. Ela não é da área de desenvolvimento de software.
O projeto estava praticamente parado. Não havia mais recurso para manter tudo como estava. Com a ajuda da IA generativa, ela conseguiu migrar serviços, reduzir custo, melhorar performance, redesenhar partes da experiência e voltar a implementar coisas que estavam no backlog havia muito tempo.
Achei aquilo inspirador! Mas também um pouco assustador.
Não por ela estar usando IA generativa. Pelo contrário: acho fascinante que pessoas que não programam profissionalmente estejam conseguindo recuperar autonomia sobre projetos que antes ficavam dependentes de verba, disponibilidade de terceiros ou uma fila infinita de prioridades.
O ponto que me acendeu uma luz amarela foi outro: em certo momento da conversa ela comentou que o projeto tinha dados de usuários e pagamentos via Stripe.
Antes de seguir, uma ressalva: eu não gosto muito do termo "vibe coding".
Vou usar o termo aqui porque ele pegou, e porque todo mundo entende mais ou menos o que ele quer dizer: criar software com muita ajuda de IA generativa, muitas vezes sem dominar profundamente a linguagem, o framework ou a arquitetura por trás do projeto.
Mas o termo me incomoda porque parece diminuir a responsabilidade envolvida. Se você está criando código, alterando código e colocando esse código no ar, você é sim uma pessoa desenvolvedora. Talvez iniciante. Talvez insegura. Talvez dependente demais da IA generativa. Talvez uma pessoa desenvolvedora ruim ou medíocre, como todos nós somos em algum recorte.
Mas é.
E isso traz responsabilidades.
Vibe coding em uma página pessoal é uma coisa. Vibe coding em um sistema com login, dados pessoais, áreas administrativas, arquivos, integrações externas ou pagamento é outra.
E aqui existe uma tensão interessante. Eu trabalho com desenvolvimento de software há bastante tempo e também venho usando IA generativa para projetos pessoais. Já gerei coisas incrivelmente úteis. Também já vi a IA gerar código com falhas de segurança bem grosseiras.
Ao mesmo tempo, fazendo as perguntas certas, muitas vezes a própria IA consegue encontrar e corrigir problemas que passariam batido em projetos pequenos, especialmente quando não existe uma pessoa de segurança olhando tudo.
Então este texto não é um "não use IA para programar".
É quase o contrário.
É um convite para usar melhor.
Se você está usando Claude, Gemini, Codex ou qualquer assistente para tocar um projeto web, especialmente se você não vem de uma formação técnica, aqui vai uma lista de perguntas que eu faria antes de colocar mudanças no ar.
Eu poderia listar 15 razões para uma pessoa que não é desenvolvedora não tentar produzir código. Mas não adianta fingir que ninguém vai fazer. As pessoas vão fazer.
Então, se for fazer, não faça sem apoio e no escuro. Procure ajuda de uma pessoa profissional antes de colocar em produção, especialmente se o projeto tiver usuários, dados pessoais, permissões, pagamentos ou qualquer coisa que possa afetar outras pessoas. Peça para alguém olhar a arquitetura, autenticação, regras de acesso, logs, secrets e integrações.
Este checklist está mais no campo da redução de danos do que no campo do selo de qualidade. Ele não substitui uma auditoria profissional. Ele não garante que o sistema está seguro. Mas pode ajudar você a fazer perguntas melhores, enxergar riscos que não estavam no seu radar e chegar à conversa com alguém experiente com mais contexto.
Talvez esse seja também um dever de pessoas desenvolvedoras mais experientes: não apenas dizer "não faça", mas alertar, explicar riscos e compartilhar técnicas mínimas para reduzir danos quando a prática inevitavelmente acontecer.
Não cole todas as perguntas de uma vez.
Escolha uma, peça para a IA analisar o projeto, gerar um relatório e apontar arquivos ou trechos concretos que justificam a conclusão.
Também vale pedir uma resposta neste formato:
## Resumo
## Riscos encontrados
- Risco:
- Severidade:
- Onde aparece:
- Como corrigir:
- Esforço estimado:
## Coisas que você não conseguiu verificar
A última parte é importante. Uma IA muito confiante pode ser mais perigosa do que uma IA que diz "não consegui verificar".
Leia o projeto e faça um mapa das partes sensíveis: cadastro, login, sessões, permissões, dados pessoais, pagamentos, webhooks, área administrativa, upload de arquivos, envio de e-mails e integrações externas. Para cada parte, explique em linguagem simples qual é o risco principal.
Antes de perguntar se algo está seguro, você precisa saber o que existe. Projetos criados com muita ajuda de IA tendem a crescer por impulso: uma tela aqui, uma integração ali, um painel improvisado depois.
Tratar o projeto como "um site simples" quando, na prática, ele já virou um sistema com dados, permissões e fluxos sensíveis.
Procure sinais de chaves, tokens, senhas, secrets, URLs privadas, chaves da Stripe, JWT secrets, credenciais de banco, arquivos
.env
e qualquer configuração sensível versionada. Verifique também se alguma informação que deveria existir apenas no backend está sendo enviada para o frontend.
Uma chave secreta exposta pode permitir que outra pessoa acesse serviços, leia dados, faça chamadas pagas ou finja ser o seu sistema. Em muitos frameworks modernos, variáveis com certos prefixos podem acabar indo para o navegador.
Publicar credenciais sem perceber, especialmente depois de pedir para a IA "só fazer funcionar localmente".
Liste as dependências diretas do projeto, diga quais estão desatualizadas, quais têm alertas de segurança conhecidos e classifique a atualização de cada uma como fácil, média ou difícil. Se houver risco de quebra, explique o que deve ser testado depois.
Muitos projetos pequenos ficam vulneráveis não por causa do código escrito pela equipe, mas por bibliotecas antigas. Atualizar tudo cegamente também pode quebrar o sistema, então a resposta precisa vir com priorização.
Acumular pacotes instalados pela IA sem saber por que eles estão ali, se ainda são mantidos ou se já têm falhas conhecidas.
Revise o sistema de autenticação. Como o usuário faz login? Como a senha é armazenada? Como funcionam recuperação de senha, expiração de sessão, cookies, tokens e logout? Existe algum fluxo que permita assumir a conta de outra pessoa?
Login não é só uma tela que compara e-mail e senha. O perigo está nos detalhes: token que não expira, senha salva do jeito errado, link de recuperação previsível, cookie mal configurado.
Achar que "tem login" significa automaticamente "está protegido".
Procure falhas de autorização. Verifique se um usuário comum conseguiria acessar, editar ou apagar dados de outro usuário alterando IDs em URLs, parâmetros, formulários, chamadas de API ou requisições do frontend. Mostre exemplos concretos de onde isso poderia acontecer.
Essa é uma das falhas mais comuns em sistemas web. A tela pode esconder o botão, mas uma pessoa mal-intencionada pode chamar a API diretamente. A pergunta central é: o backend confere permissão ou apenas confia no que o frontend mandou?
Proteger apenas a interface visual e esquecer que a regra de acesso precisa existir no servidor.
Identifique todas as funções administrativas ou internas. Verifique se a proteção acontece no servidor/backend, não apenas por esconder menus, botões ou rotas no frontend. Explique quem pode acessar cada ação administrativa e onde essa regra é aplicada.
Um painel admin escondido ainda pode ser acessível se a rota existir e o servidor não bloquear corretamente. Controle visual ajuda na experiência, mas não garante segurança.
Confundir "não aparece para usuários comuns" com "usuários comuns não conseguem executar".
Revise a integração de pagamentos, se existir. O sistema confia em preço, plano, status de pagamento ou ID de usuário enviado pelo frontend? Os pagamentos são confirmados por webhook assinado pelo provedor, como Stripe? Existe risco de marcar algo como pago sem confirmação real do provedor?
Em pagamentos, o navegador deve ser tratado como ambiente hostil. Uma pessoa pode alterar valores, parâmetros ou chamadas. O servidor precisa confirmar tudo com o provedor de pagamento, e não apenas acreditar no que a tela informou.
Liberar acesso, benefício, assinatura ou conteúdo pago com base em uma informação que o próprio usuário consegue manipular.
Verifique todos os webhooks do projeto, especialmente pagamentos e integrações externas. Eles validam assinatura ou segredo do provedor? Tratam eventos repetidos sem duplicar cobranças, e-mails ou benefícios? Ignoram eventos desconhecidos? Registram erros sem expor dados sensíveis?
Webhooks são chamadas externas que avisam seu sistema sobre eventos. Se qualquer pessoa puder simular um webhook, ela pode tentar liberar acesso, alterar status, disparar ações indevidas ou bagunçar dados.
Aceitar comandos externos sem ter certeza de que eles vieram mesmo do serviço esperado.
Liste todos os pontos onde usuários enviam dados: formulários, busca, filtros, comentários, upload, APIs, parâmetros de URL e campos de perfil. Para cada ponto, verifique se há validação, limite de tamanho e proteção contra injeção, XSS e dados inesperados.
Todo campo que aceita texto pode virar uma porta de entrada para abuso. Busca, filtros e comentários parecem inocentes, mas podem causar vazamento, erro, lentidão ou execução de código no navegador.
Confiar que usuários vão preencher campos do jeito esperado, quando um sistema público precisa assumir o contrário.
Revise especificamente o sistema de busca. A busca respeita permissões de usuário? Pode retornar dados privados? Tem paginação e limite de resultados? Pode ser usada para sobrecarregar o banco ou gerar custo excessivo? Explique como melhorar sem quebrar a experiência.
Busca é uma área traiçoeira porque parece apenas uma melhoria de usabilidade. Mas uma busca mal feita pode revelar dados que deveriam estar ocultos, permitir enumeração de usuários ou gerar consultas pesadas.
Transformar uma feature simpática em uma ferramenta de vazamento, raspagem de dados ou aumento inesperado de custo.
Verifique se existem limites de uso para login, recuperação de senha, busca, envio de formulários, criação de contas, chamadas de API e ações que geram custo. Onde não houver limite, proponha uma proteção simples e proporcional.
Mesmo sem uma invasão sofisticada, um sistema pode sofrer com spam, tentativa de senha, formulários automatizados ou uso exagerado de recursos pagos.
Construir uma funcionalidade que funciona para uma pessoa testando manualmente, mas quebra quando alguém automatiza cem, mil ou dez mil tentativas.
Procure lugares onde erros, logs, respostas de API ou telas de debug possam expor senhas, tokens, dados pessoais, stack traces, informações do banco ou detalhes internos. Separe o que aparece para o usuário do que fica apenas nos logs internos.
Quando algo dá errado, muitos sistemas mostram informação demais. Isso ajuda quem está desenvolvendo, mas também ajuda quem está atacando.
Vazar pistas internas justamente nos momentos em que o sistema falha.
Se o projeto permite upload ou armazenamento de arquivos, revise tamanho máximo, tipos permitidos, nomes de arquivo, permissão de acesso, links públicos, remoção de arquivos antigos e risco de alguém acessar arquivos de outra pessoa.
Arquivos costumam virar um canto esquecido do sistema. Um bucket público, um link previsível ou um upload sem limite pode causar vazamento de dados ou custo inesperado.
Guardar arquivos em algum lugar e presumir que as permissões certas vieram junto.
Compare configurações de desenvolvimento, teste e produção. Verifique se produção não está usando chaves de teste, banco local, modo debug, CORS aberto demais, permissões amplas, secrets fracos ou configurações temporárias criadas durante o desenvolvimento.
Vibe coding costuma gerar muitas configurações temporárias para "fazer funcionar". O problema é quando o temporário chega em produção.
Levar para usuários reais uma configuração que só deveria ter existido durante o teste.
Proponha testes automatizados simples para os principais riscos encontrados: usuário acessando dado de outro usuário, webhook falso, pagamento não confirmado, formulário com entrada inválida, rota admin acessada por usuário comum e busca retornando dado privado. Priorize testes que uma pessoa leiga consiga entender pelo nome e pelo resultado.
Corrigir uma falha uma vez é bom. Impedir que ela volte é melhor. Testes simples funcionam como uma rede de proteção quando você continua pedindo novas mudanças para a IA.
Depender da memória, da sorte ou da boa vontade da próxima conversa com a IA para não quebrar uma proteção que já tinha sido corrigida.
Depois de rodar esse checklist, eu faria uma última pergunta:
Com base no que você conseguiu analisar, quais riscos de segurança você não consegue descartar? Liste o que exigiria acesso a configurações externas, painel do provedor, banco de produção, logs reais ou revisão humana especializada.
Essa talvez seja a pergunta mais importante de todas.
Porque o objetivo não é fazer a IA dizer que está tudo seguro.
O objetivo é fazer a IA ajudar você a enxergar melhor onde ainda existe incerteza.
Eu continuo achando incrível que uma pessoa fora da área de software consiga usar IA generativa para manter viva uma plataforma que talvez tivesse morrido por falta de recurso.
Isso é poderoso.
Mas poder sem responsabilidade vira aposta.
Se você está praticando vibe coding em um projeto real, com usuários reais, dados reais ou dinheiro real, não trate segurança como uma etapa distante que vem depois de "terminar as features".
Você pode estar aprendendo. Pode estar improvisando. Pode estar pedindo para a IA explicar cada detalhe três vezes. Tudo bem.
Mas, se o código vai para o mundo, ele passa a afetar outras pessoas.
Transforme segurança em conversa recorrente com a própria IA.
Pergunte. Peça evidência. Peça para explicar de novo em linguagem simples. Peça para mostrar onde no código aquilo está garantido. Peça para separar o que ela sabe do que ela está presumindo.
Talvez esse seja um dos usos mais interessantes da IA para pessoas não técnicas: não apenas escrever código, mas ajudar a fazer perguntas melhores sobre o código que ela mesma escreveu.
E quando estiver em dúvida, peça ajuda para alguém mais experiente que você. 🙂
Você tem usado IA generativa para criar ou manter projetos? Que outras perguntas você acha importante fazer antes de colocar algo no ar?
Conte um pouco da sua experiência e deixe suas dicas nos comentários.