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.
Como usar este checklist
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".
1. Quais partes do projeto lidam com usuários, dados pessoais, login, pagamento, administração e upload de arquivos?
Pergunta para copiar
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.
Por que isso importa:
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.
O risco que isso reduz
Tratar o projeto como "um site simples" quando, na prática, ele já virou um sistema com dados, permissões e fluxos sensíveis.
2. Existe algum segredo exposto no código, no frontend ou no histórico do Git?
Pergunta para copiar
Procure sinais de chaves, tokens, senhas, secrets, URLs privadas, chaves da Stripe, JWT secrets, credenciais de banco, arquivos
.enve 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.
Por que isso importa
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.
O risco que isso reduz
Publicar credenciais sem perceber, especialmente depois de pedir para a IA "só fazer funcionar localmente".
3. Quais dependências estão desatualizadas ou têm vulnerabilidades conhecidas?
Pergunta para copiar
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.
Por que isso importa
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.
O risco que isso reduz
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.
4. O login está seguro o suficiente para o tipo de dados que o sistema guarda?
Pergunta para copiar
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?
Por que isso importa
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.
O risco que isso reduz
Achar que "tem login" significa automaticamente "está protegido".
5. Um usuário consegue acessar dados de outro usuário mudando um ID, uma URL ou um parâmetro?
Pergunta para copiar
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.
Por que isso importa
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?
O risco que isso reduz
Proteger apenas a interface visual e esquecer que a regra de acesso precisa existir no servidor.
6. As áreas administrativas estão protegidas no backend ou apenas escondidas no frontend?
Pergunta para copiar
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.
Por que isso importa
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.
O risco que isso reduz
Confundir "não aparece para usuários comuns" com "usuários comuns não conseguem executar".
7. A integração com pagamento confia demais no que vem do navegador?
Pergunta para copiar
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?
Por que isso importa
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.
O risco que isso reduz
Liberar acesso, benefício, assinatura ou conteúdo pago com base em uma informação que o próprio usuário consegue manipular.
8. Os webhooks são verificados e tratados de forma segura?
Pergunta para copiar
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?
Por que isso importa
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.
O risco que isso reduz
Aceitar comandos externos sem ter certeza de que eles vieram mesmo do serviço esperado.
9. Todas as entradas do usuário são validadas antes de chegar ao banco ou a comandos sensíveis?
Pergunta para copiar
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.
Por que isso importa
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.
O risco que isso reduz
Confiar que usuários vão preencher campos do jeito esperado, quando um sistema público precisa assumir o contrário.
10. O sistema de busca pode vazar dados ou ficar caro demais?
Pergunta para copiar
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.
Por que isso importa
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.
O risco que isso reduz
Transformar uma feature simpática em uma ferramenta de vazamento, raspagem de dados ou aumento inesperado de custo.
11. Existem limites contra abuso, spam e tentativas repetidas?
Pergunta para copiar
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.
Por que isso importa
Mesmo sem uma invasão sofisticada, um sistema pode sofrer com spam, tentativa de senha, formulários automatizados ou uso exagerado de recursos pagos.
O risco que isso reduz
Construir uma funcionalidade que funciona para uma pessoa testando manualmente, mas quebra quando alguém automatiza cem, mil ou dez mil tentativas.
12. Erros, logs e telas de debug estão expondo informações sensíveis?
Pergunta para copiar
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.
Por que isso importa
Quando algo dá errado, muitos sistemas mostram informação demais. Isso ajuda quem está desenvolvendo, mas também ajuda quem está atacando.
O risco que isso reduz
Vazar pistas internas justamente nos momentos em que o sistema falha.
13. Uploads e arquivos estão restritos ao que realmente deveria ser público?
Pergunta para copiar
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.
Por que isso importa
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.
O risco que isso reduz
Guardar arquivos em algum lugar e presumir que as permissões certas vieram junto.
14. A configuração de produção está separada da configuração de desenvolvimento?
Pergunta para copiar
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.
Por que isso importa
Vibe coding costuma gerar muitas configurações temporárias para "fazer funcionar". O problema é quando o temporário chega em produção.
O risco que isso reduz
Levar para usuários reais uma configuração que só deveria ter existido durante o teste.
15. Que testes de segurança simples deveriam existir para impedir regressão?
Pergunta para copiar
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.
Por que isso importa
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.
O risco que isso reduz
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.
A pergunta final: o que você não conseguiu garantir?
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.
Conclusão
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.
