Testes a passar, base de dados aberta: pensamento crítico para vibe coders

Os agentes de IA produzem agora trabalho bem escrito e quase sempre correto. Parece só uma boa notícia, e na maior parte das vezes é. O problema é que já nada no teu dia te obriga a olhar duas vezes. Os investigadores da Wharton Steven Shaw e Gideon Nave têm um nome para o sítio onde isso pode acabar: rendição cognitiva, o ponto em que uma resposta passa a ser tua sem dares por isso e não sentes necessidade de a verificar.

Para engenheiros, isto é um problema de qualidade. Para quem constrói com vibe coding (descrever uma app a uma IA e publicar o que ela gera) sem formação em engenharia, é muitas vezes um problema de segurança, e quem acaba por pagar são terceiros, os utilizadores da app.

Quando o bug é uma porta aberta

Os agentes tornam os testes tão baratos que tudo parece coberto. Um teste escrito com o mesmo erro da funcionalidade continua a passar. Um teste a passar prova uma coisa. É fácil assumir que prova tudo.

Na maioria dos bugs, essa diferença custa-te uma funcionalidade partida e uma tarde má. Os bugs de segurança são diferentes. Um teste que confirma que um utilizador com sessão iniciada vê as suas próprias encomendas não diz nada sobre se um desconhecido sem sessão consegue ver as encomendas de toda a gente. A app funciona, a demo funciona, os testes passam, e os dados estão públicos.

Vimos exatamente este padrão há pouco tempo com apps feitas no Lovable. Muitas deixaram mal configuradas as regras de acesso à base de dados no Supabase, por isso qualquer pessoa conseguia ler dados sem fazer login. Os termos do Lovable põem essa responsabilidade em quem constrói a app. Como estas integrações seguem os mesmos padrões em todo o lado, um erro destes pode aparecer em muitas apps ao mesmo tempo.

Isto é rendição cognitiva em escala. Ninguém decidiu deixar a porta aberta. Cada pessoa aceitou um resultado que parecia pronto, e até seguro.

Mais barato de lançar, mais barato de atacar

Há uma ideia a que volto sempre. O vibe coding torna muito mais fácil lançar um produto. Também torna muito mais fácil atacá-lo, por isso o custo total nem sempre desce.

As mesmas ferramentas que deixam uma pessoa publicar uma app num fim de semana deixam um atacante procurar a mesma má configuração em milhares dessas apps numa tarde. Quando toda a gente gera código a partir de prompts parecidos, em stacks parecidas, os erros também se repetem. Uma falha numa app é provavelmente uma falha em centenas de outras, e qualquer pessoa pode ir à procura dela.

Por isso a conta chega mais tarde, e quem a paga são os teus utilizadores.

Cinco perguntas antes de publicar

Não precisas de ser engenheiro de segurança para as fazer.

O que teria de ser verdade para isto estar errado? Pergunta isto sobre acessos. Quem nunca deve ver estes dados? Depois tenta vê-los como essa pessoa. Abre a app numa janela privada, sem fazer login, e chama os mesmos endpoints.

Quando os testes passam, o que é que provaram de facto? Depois pergunta o que é que não provaram. Se todos os testes correm com um utilizador com sessão iniciada, ninguém testou o caso sem sessão.

Lê as decisões por trás do resumo. Pede ao agente que liste as decisões e os pressupostos que tomou. Para a segurança, pede o concreto: que tabelas podem ser lidas sem sessão, que chaves ficam expostas no browser, e que valores por defeito ficaram por mexer.

Define o que é "seguro" antes de começar. Antes de pedires uma funcionalidade que mexe em dados de utilizadores, escreve o que "seguro" significa para ela. Se o escreveres depois, é fácil demais justificar o que quer que tenha saído.

Defendias isto à frente da pessoa cujos dados isto guarda? Numa app com utilizadores reais, são eles quem tem mais a perder.

A responsabilidade não se gera

Podes entregar a um agente o trabalho e boa parte da verificação. A responsabilidade continua a ser tua.

Os agentes podem vir a assumir mais deste trabalho com o tempo. Imagina um agente que vigia os teus projetos, os compara com vulnerabilidades conhecidas e abre um pull request com a correção. Ajudaria muito. Mas não mudaria quem responde quando os dados dos utilizadores são expostos.

Em agosto escrevi que nunca deves dizer a password ao teu agente de IA. O mesmo instinto aplica-se aqui. Delega o trabalho, guarda as chaves e guarda a responsabilidade.

Por isso, quem hoje espera que o orçamento para desenvolver software baixe só porque a IA ajuda está bastante enganado. Passar de uma ideia a um produto ficou mais fácil. Encontrar e explorar falhas também ficou mais fácil, para qualquer pessoa, e é por isso que o valor da engenharia e da segurança é hoje mais evidente do que nunca.