Vibe coding para testar como usuário comum sem ser admin

Um teste de permissão feito pela conta que ignora todas as permissões não prova nada. Na live de 3 de agosto, Jhonatan tinha acabado de gerar um curso inteiro dentro da plataforma que está montando e quis conferir como aquilo aparece para quem vai consumir. Trocou de área, tentou entrar como aluno e esbarrou na própria conta.

"Tem um erro aqui. É porque eu sou tudo, né?"

O obstáculo estava na conta que ele usava para olhar. Ele estava logado como administrador máster, e administrador máster enxerga tudo por padrão. A tela que abriu ali continuava sendo a dele, com o administrador passando por cima de qualquer restrição que existisse no caminho.

Entrar como aluno é um pedido que a sua própria sessão atende errado

Alguns segundos antes, ele tinha dito o que queria fazer:

"Eu quero entrar como aluno."

Quando volta ao assunto, depois de mexer em outras coisas da escola, o problema continua no mesmo lugar:

"Só que aqui nós temos um problema que é isso."

A área restrita abriu, o conteúdo carregou, e nada na tela avisou que aquela visão pertencia ao administrador. Se ele não tivesse desconfiado da própria conta, teria anotado que a área do aluno está funcionando e seguido para a próxima tarefa da live.

O teste que passa sempre não serve para nada

Quase toda implementação de permissão começa com um atalho no topo, alguma variação de "se for admin, libera". Esse atalho roda antes da checagem que você queria exercitar e responde sim para tudo, então o teste passa com a regra certa e passa com a regra errada. Passa também quando a regra nunca chegou a ser escrita.

O único fato que uma conferência dessas estabelece é que o administrador consegue ver a página, o que você já sabia antes de abrir o navegador. Os defeitos que você está caçando são justamente os que desaparecem sob o olhar do admin: o botão que não deveria existir para aquele papel, o dado de outra pessoa que deveria estar escondido. Como nenhum deles aparece na sessão que tem direito a tudo, o teste volta verde toda vez, inclusive nos dias em que a permissão está quebrada.

Por que o vibe coding cai nisso com mais facilidade

Quem constrói com agente pede a regra de permissão, recebe o código pronto em segundos e confere na mesma janela onde estava trabalhando, que é a janela do administrador. A regra pode ter ficado só no texto da resposta, sem nunca ter sido aplicada ao lugar certo, e a conferência passa igual. Gerando código nessa velocidade e sem uma sessão de usuário comum aberta do lado, você produz em série permissão que ninguém nunca viu funcionar.

O volume piora a conta. Numa sessão de vibe coding, você mexe em muita tela e muito fluxo por hora, e quase todos carregam alguma decisão sobre quem pode ver o quê. Se a conferência acontece toda na conta que passa por cima de tudo, essas decisões se acumulam sem verificação nenhuma, e você descobre quais estavam erradas quando o primeiro usuário comum entrar. Mexer em série no sistema cobra o mesmo cuidado quando o que muda é o dado e não a regra: renomear uma entidade sem quebrar link no sistema parece inofensivo no banco de dados até o endereço antigo passar a apontar para o nada. Vale ver como isso terminou em vibe coding para mostrar o efeito lado a lado sem nomear. O mesmo problema apareceu em vibe coding para nao escrever ats se o usuario nao sabe o que e.

É a mesma falha de forma do post sobre exigir evidência antes de confiar na IA, em que o assistente afirmou que a telemetria estava funcionando por ter lido o próprio código enquanto o painel continuava vazio: a checagem foi feita no lugar errado, então passar não significou nada.

Ver com os olhos certos

2 caminhos resolvem isso. Um é ter no produto um mecanismo real de troca de papel ou de impersonação, que carregue a sessão com as permissões daquele papel e nada além delas. O outro não exige código novo: criar uma conta comum de verdade, com o papel que você quer testar, e abrir essa conta em outra sessão do navegador, numa janela anônima ou num perfil separado, enquanto a sessão de administrador continua na primeira. Na live, ele parte para configurar isso e chega a abrir outra janela, e a live segue para outras tarefas sem mostrar se ficou resolvido.

Se você for adicionar impersonação ao seu produto, trate como o poder perigoso que ela é: restrita a quem tem esse direito, e com registro de quem entrou como quem.

Hoje mesmo, antes de pedir mais uma regra de permissão ao agente, crie uma conta comum de teste no seu próprio produto e deixe ela aberta numa janela separada, ao lado da sua. Cada vez que uma restrição por papel ficar pronta, confira do outro lado, na janela do usuário comum, antes de considerar a tarefa terminada. É o hábito mais barato para o vibe coding não te entregar uma pilha de permissão de mentira. Esse cuidado é essencial quando você quer rodar campanhas de prospecção ativa e precisa garantir que os alunos só veem o conteúdo deles. Permissões corretas também suportam modelos de negócio diferenciados: revenue share só funciona se cada cliente vir apenas suas próprias métricas. E quando as permissões estão pronta, use instruções negativas para manter o agente dentro do padrão que foi aprovado. Dá para assistir à live e ver o momento em que a área do aluno abre para quem não é aluno.