A semana em que a abstração apresentou a conta

Esta semana foi instrutiva.

Em 19 de abril, a Vercel confirmou que foi invadida. No mesmo período, o Lovable estava lidando com o segundo incidente de segurança grave em dois meses — uma vulnerabilidade BOLA que ficou aberta por 48 dias, expondo código-fonte, credenciais de banco de dados, histórico de chats com a IA e dados de clientes reais de qualquer projeto criado antes de novembro de 2025. Qualquer conta free era suficiente para acessar.

Duas plataformas. Dois incidentes. Uma semana. Mas o problema que une os dois não é técnico — é cultural.

O que aconteceu, rápido e sem eufemismo

Vercel (19/04/2026): Um funcionário usava uma ferramenta de IA chamada Context.ai, concedendo acesso OAuth ao seu Google Workspace. A Context.ai foi comprometida. Os atacantes usaram o token para entrar na conta do funcionário na Vercel, chegaram aos sistemas internos e acessaram variáveis de ambiente dos clientes que não estavam marcadas como "sensitive" — ou seja, descriptografadas em texto puro. Os dados estão sendo vendidos no BreachForums por dois milhões de dólares. O CEO da Vercel disse que o ataque foi "significativamente acelerado por IA".

Lovable (fevereiro–abril de 2026): Uma vulnerabilidade de BOLA — Broken Object Level Authorization, número 1 no OWASP API Security Top 10 — foi reportada via HackerOne em março. A Lovable aplicou um fix parcial, só para projetos novos, deixando todos os anteriores expostos. O relatório foi fechado como "duplicata". 48 dias depois, o pesquisador foi a público. Extraindo o código de qualquer projeto legado, você encontrava credenciais Supabase hardcoded. Com essas credenciais, acessava o banco direto. Tudo isso de uma conta gratuita. A Lovable primeiro negou que havia brecha, depois culpou a documentação, depois culpou a HackerOne.

Isso não é azar. Isso é padrão.

O Supabase e a ilusão de segurança por design

O Supabase merece uma pausa aqui, porque ele aparece no centro do problema da Lovable — e porque o modelo de segurança dele exemplifica algo que me incomoda profundamente na forma como segurança é vendida hoje.

O Supabase funciona expondo uma anon key no lado do cliente. Isso é intencional. A documentação diz que é seguro — desde que você configure Row Level Security (RLS) corretamente. O RLS é o sistema de políticas que determina quem pode ler e escrever o quê no banco de dados. Sem ele, a anon key pública dá acesso irrestrito às tabelas.

O Supabase avisa sobre isso. Tem documentação, tem alertas no dashboard, tem boas práticas bem escritas.

Mas aqui está o problema: o aviso existe, e a responsabilidade é completamente do usuário. Não há nada que impeça você de criar uma aplicação com Supabase, deixar o RLS desabilitado e colocar em produção. O painel não bloqueia. Não há um "você tem certeza?" que realmente comunique o que está em jogo.

Quando o Lovable gerava aplicações usando Supabase, ele não configurava o RLS adequadamente. Um scan de 1.645 apps construídas no Lovable encontrou 170 com falhas críticas exatamente nesse ponto. 91,5% dos apps de vibe coding avaliados no primeiro trimestre de 2026 tinham pelo menos uma vulnerabilidade rastreável a uma alucinação da IA.

Mas a Lovable tinha um "security scanner". Que verificava se o RLS existia, não se estava configurado corretamente. Scanner que dava falsa sensação de segurança e deixava o usuário seguir em frente.

Isso é o que eu chamo de segurança sem o sustinho.

Segurança sem o sustinho

Existe uma tendência clara nos últimos anos: as plataformas tornam a segurança conveniente. Botões bonitos, toggles, labels coloridas, checkmarks verdes. A mensagem subliminar é: você está seguro, foi fácil, pode ir.

Não estou dizendo que a experiência deve ser ruim. Estou dizendo que o risco precisa ser comunicado com a gravidade que ele tem.

Quando a Vercel apresenta variáveis de ambiente, o padrão histórico era não-sensitive. Não havia nada na interface que dissesse claramente: "se você colocar uma API key aqui sem marcar como sensitive e nós formos invadidos, ela vai vazar". A feature existia. A distinção era documentada. Mas não havia nenhum atrito, nenhuma fricção cognitiva que forçasse o desenvolvedor a pensar.

Agora, depois do breach, a Vercel anunciou que vai mudar o padrão para sensitive. Ótimo. Mas foram necessários dados de clientes comprometidos e 2 milhões de dólares sendo negociados num fórum de hackers para isso acontecer.

A Lovable tinha um scanner de segurança que não detectava o principal vetor de ataque. Mas o botão "publicar" ficava disponível.

Isso não é descuido. É uma escolha de produto. Atrito reduz conversão. Conversão paga os salários. E quando o problema aparece — "foi o usuário que não seguiu as recomendações".

Empresas não são nossas mães. Não tenho expectativa que sejam. Mas há uma diferença entre "não é nossa obrigação te educar" e "vamos projetar a ferramenta de forma que minimiza a percepção do risco para não atrapalhar o growth".

Quem paga a conta

Aqui está a parte que precisa ser dita em voz alta, porque ninguém fala quando está vendendo curso ou bootstrap story:

Empresas como a Vercel podem absorver um breach. Têm equipes jurídicas, seguros, capacidade de negociação, relações públicas experientes. O CEO escreve um post thoughtful no blog, contratam a Mandiant para investigar, notificam as autoridades e seguem em frente.

Você, desenvolvedor que construiu uma aplicação com dados de usuários reais usando uma plataforma de vibe coding ou conectou o Supabase sem RLS porque a documentação parecia complexa — você não tem esse buffer.

A LGPD (Lei Geral de Proteção de Dados) prevê multas de até 2% do faturamento, limitado a R$ 50 milhões por infração. O GDPR europeu vai até 4% do faturamento global anual ou 20 milhões de euros, o que for maior. Dependendo da gravidade e da jurisdição, há previsão de responsabilidade penal para gestores.

E o usuário que teve seus dados expostos? Stripe customer ID, endereço residencial, informações de saúde, dados financeiros — dados reais, de pessoas reais, que confiaram o produto que você construiu.

A abstração que a plataforma oferece não abstrai a responsabilidade legal. Você pode não entender o que acontece por baixo do botão de deploy. Mas o juiz não vai aceitar isso como defesa.

O problema começa antes da plataforma

Vou ser direto sobre algo que observo há anos e que cada vez me preocupa mais.

Existe uma geração de desenvolvedores que aprendeu a programar vendo tutorial de alguém que, ao fim de cada vídeo, conecta o repositório no GitHub, clica em deploy na Vercel e diz "pronto, sua aplicação está no ar". E isso é apresentado como o jeito de fazer. O jeito profissional, moderno, escalável.

O que esses tutoriais raramente ensinam:

• O que acontece entre o git push e a aplicação estar disponível

• Como as variáveis de ambiente são armazenadas e quem pode acessá-las

• Por que credenciais de banco não deveriam ir direto para a plataforma de deploy sem critério

• O que é RLS e por que importa

• Como funciona um pipeline de CI/CD de verdade

• O que fazer quando a plataforma que hospeda sua aplicação é comprometida

E antes disso: o básico de infraestrutura. Configurar um VPS. Escrever um script bash elementar. Entender o que é um processo, um serviço systemd, um reverse proxy. Saber o que ssh user@host significa e o que você está fazendo quando executa.

Consigo imaginar — e não é exagero — a quantidade de desenvolvedores que nunca configurou um servidor. Que o máximo de "infra" que já tocou foi um npm run build e mesmo esse comando não sabe o que executa por trás. Que a ideia de abrir um terminal e digitar qualquer coisa numa VPS parece território de especialistas inacessíveis.

Isso não é elitismo. Não estou dizendo que todo desenvolvedor precisa saber administrar um data center. Estou dizendo que existe um piso de conhecimento técnico abaixo do qual você não consegue avaliar os riscos do que está fazendo — e esse piso está sendo sistematicamente erodido por plataformas que tornam tudo tão fácil que o conhecimento nunca precisa ser adquirido.

Vibe coding e a democratização do risco

O "vibe coding" foi eleito palavra do ano pela Collins em 2025. Andrej Karpathy cunhou o termo em fevereiro do mesmo ano. A ideia é simples: descreva o que você quer, a IA constrói. Sem escrever código, sem entender o que foi gerado.

Os números são claros sobre o resultado:

• Entre 40 e 62% do código gerado por IA contém vulnerabilidades de segurança, dependendo do estudo

• Código escrito por IA produz falhas a 2,74 vezes a taxa de código humano, segundo análise de 470 pull requests no GitHub

• 91,5% dos apps de vibe coding avaliados no Q1 2026 continham pelo menos uma vulnerabilidade rastreável a alucinação da IA

A Lovable tem 8 milhões de usuários e vale 6,6 bilhões de dólares. Parte desses usuários construiu aplicações com dados reais de pessoas reais, usando código que nunca foi revisado por ninguém que entende segurança.

Eu uso IA. Uso diariamente, sem cerimônia, como multiplicador de produtividade. Mas há uma diferença fundamental entre usar IA para acelerar o trabalho de quem sabe o que está fazendo e usar IA para substituir o conhecimento que você não tem.

No primeiro caso, você revisa o output. Você sabe quando algo está errado. Você entende as implicações de segurança de um trecho de código que a IA gerou.

No segundo caso, você não sabe o que está executando. E quando der errado — e vai dar errado — você não vai entender o que aconteceu, não vai saber como consertar e, dependendo dos dados que estavam em jogo, pode ter uma responsabilidade legal que não estava no plano.

O sustinho que as plataformas removeram da experiência do usuário foi transferido para o mundo real, onde ele aparece na forma de dados expostos, multas e pessoas reais prejudicadas.

O hype como critério técnico

Tem outro ângulo aqui que não posso ignorar.

Parte significativa das escolhas técnicas que chegam ao meu campo de visão não são baseadas em avaliação de mérito, segurança ou adequação ao problema. São baseadas em hype. Em quem está falando mais alto no Twitter. Em qual ferramenta aparece mais nos vídeos de "build in public". Em qual stack aquele "dev" que vende curso de 12x R$ 497 está usando essa semana.

Escolhemos Vercel porque é o que se usa. Escolhemos Supabase porque aparece em todo tutorial de Next.js. Escolhemos Lovable porque prometeu que qualquer pessoa pode construir uma startup em 10 minutos. Escolhemos Next.js porque a Vercel financia o marketing e um Youtuber falou bem.

Nenhum desses critérios inclui: como essa ferramenta armazena minhas credenciais? Qual é o modelo de ameaças? O que acontece se essa empresa for comprometida? Essa abstração que estou usando esconde que tipo de risco?

Faço parte desse ecossistema há 19 anos. Já cometi os erros de escolher ferramenta pelo hype. Mas a diferença é que eu tinha base técnica suficiente para entender quando estava errando e corrigir o curso. Quem aprende programming em 2026 assistindo tutorial de vibe coding não tem esse safety net.

Por que nunca me senti bem com a Vercel

Vou ser honesto sobre algo que carreguei sem conseguir articular direito por anos.

Sempre tive uma aversão à Vercel. Não era preconceito vazio — já usei, conheço o produto, entendo a engenharia. Era algo mais difuso. O desconforto de quem passou anos cuidando de infra e de repente se vê usando um sistema onde não sabe exatamente o que está acontecendo por baixo dos panos.

Parte era modelo de negócio. O Next.js é open source — genuinamente. Mas é open source criado, dirigido e financiado por uma empresa cujo produto é vender infraestrutura para esse mesmo framework. Certas features funcionam melhor na Vercel. A documentação aponta para soluções que assumem deployment na Vercel. Não é conspiração — é alinhamento de incentivos. Open source como estratégia de aquisição de usuários é uma prática legítima e bem documentada. Mas é útil reconhecer o que é.

Parte era o ecossistema React, que é basicamente o universo da Vercel. Tenho preconceito com React — não vou fingir que não. Não com o paradigma funcional, não com hooks. Com o JSX. Com a ideia de que misturar HTML em JavaScript é mais "composable" do que separar template, script e style num SFC. Vue com Inertia.js, num projeto Laravel, tem uma coerência que me faz sentido. A sintonia não é acidente.

Dito isso: o breach da Vercel não me traz satisfação. Me preocupa, porque tem gente boa usando a plataforma, com dados reais de clientes reais.

Mas confirma algo que eu sentia sem poder provar: conforto não é sinônimo de controle. Facilidade não é sinônimo de segurança. E a sensação de desconforto que eu tinha sobre não entender exatamente como as coisas funcionavam por baixo era um instinto válido, não paranoia.

Quem cresceu entendendo infra, mesmo que básica, tem um radar para quando está delegando responsabilidade que não deveria. Quem nunca teve que lidar com isso — nunca.

O que você deveria saber, independente do que usa

Não importa se você usa Vercel, Railway, Render, DigitalOcean App Platform ou uma VPS configurada à mão. Existe um conjunto de coisas que você deve entender:

Sobre deploy: Onde o código vai parar fisicamente? O que acontece entre o git push e a aplicação online? Quem tem acesso ao servidor onde sua aplicação roda? Você consegue reverter para a versão anterior em menos de dois minutos se algo der errado?

Sobre credenciais: Onde estão armazenadas suas variáveis de ambiente? Quem pode acessá-las — desenvolvedores do time, a própria plataforma, sistemas internos da empresa que te hospeda? O que acontece com elas se a plataforma for comprometida? Você tem um plano de rotação?

Use o recurso de secrets da plataforma de forma consciente:

GitHub Secrets
→ Repository Secrets: visíveis só para workflows daquele repo
→ Environment Secrets: vinculados a environments específicos
→ Nunca ficam em log, nunca aparecem em output

Vercel Sensitive Variables
→ Armazenadas de forma não-recuperável nem pela própria Vercel
→ Só disponíveis durante builds e runtime
→ Qualquer chave que começa com SECRET_, KEY_, TOKEN_ deve ser sensitive

Sobre o que você não deve fazer:

• Colocar credenciais em código, mesmo que "temporariamente"

• Confiar que "criptografado por padrão" significa o mesmo que "inacessível se comprometido"

• Usar a mesma credencial para dev e produção

• Não rotacionar secrets porque "não houve incidente"

Sobre o que a IA não substitui: Entendimento. A IA pode gerar o código, o pipeline, a configuração. Mas ela não conhece seu contexto de ameaças, não vai te avisar que você está colocando uma chave de produção onde não deveria, e não vai estar lá quando o dado do seu usuário vazar. Revisão é responsabilidade sua.

A pergunta que não consigo tirar da cabeça

Como vai ser a experiência técnica dos desenvolvedores daqui a dez anos?

É uma pergunta genuína, sem resposta fácil. Parte de mim entende que abstração é o progresso natural da engenharia — ninguém escreve assembly hoje, e está tudo bem. Parte de mim sente que há um piso de conhecimento que está sendo erodido mais rápido do que deveria.

Quando você não sabe o que está por baixo, você não sabe o que pode dar errado. Você não consegue avaliar o risco do que está usando. Você escolhe plataformas por hype porque não tem critérios técnicos para avaliar. Você coloca dados de usuários reais em sistemas que não entende, sob responsabilidade legal que também não entende, e torce para que não dê errado.

Essa semana, para muitos usuários da Vercel e do Lovable, deu.

Não é questão de ser "o velho gritando com a nuvem". É questão de que software que falha tem consequências no mundo real. Dados expostos são de pessoas reais. Multas da LGPD e do GDPR são reais. E a empresa que facilitou o deploy com um clique vai continuar operando, enquanto você vai ter que lidar com o aftermath.

Aprender o básico de bash não vai te tornar um administrador de sistemas. Mas vai te dar vocabulário para entender o que está acontecendo quando sua aplicação está no ar. Saber configurar uma VPS não é requirement de 1995 — é fundação para entender o que você está delegando quando não configura.

O deploy fácil é uma conquista real de engenharia. Mas ela não substitui entender o que você está fazendo. E a conta dessa confusão, como esta semana demonstrou, não é cobrada da plataforma.

É cobrada de você.