Vibe coding para preencher segurança de dados quando app cria conta anônima

O formulário de segurança de dados da loja de aplicativos pergunta qual é o método de criação de conta. Para um app sem tela de login, a resposta tentadora é marcar que ele não permite criar conta. Quando o app gera sozinho uma conta anônima na primeira abertura, essa resposta é a errada, por um motivo prático: ela contradiz coisas que você já declarou em público sobre o mesmo app.

A cena é de Martin, na segunda parte do dia 13 de construção do Fumava, o app dele para quem quer parar de fumar. Ele estava preenchendo o formulário para publicar, chegou no campo do método de criação de conta e leu em voz alta o que apareceu:

"Cliquei noutro e ele colocou ali, descreva o método de criação."

O Fumava não pede login e não usa biometria. A recomendação que veio do agente foi marcar "outro":

"Marque outro porque o Fumava não oferece qualquer dos métodos listados."

Ausência de senha não é ausência de conta

A autoria aqui muda o peso do que vem a seguir: as perguntas são do Martin, e o raciocínio da resposta é saída do agente. Foi o agente que descreveu o app em 3 pedaços, nesta ordem:

"nem biometria, nem login nenhum"

"mas ele cria uma conta de verdade anónima sem credencial"

"com o ID que persiste e guarda todos os dados da pessoa"

O identificador é o que transforma aquilo em conta. Ele nasce sozinho na primeira abertura e sobrevive de uma sessão para a outra. A pessoa nunca escolheu uma senha, e ainda assim existe um lugar onde tudo o que ela registrou fica amarrado a ela. É isso que o formulário quer saber quando pergunta por conta. A credencial diz respeito a como se entra na conta; a conta existe de qualquer jeito.

O argumento que decidiu a resposta foi consistência

O agente nomeou a tentação e recusou, apoiado em uma palavra só:

"A tentação é marcar."

"Não marque isso por consistência."

O agente deixou de lado a discussão sobre o que conta como conta e foi direto ao inventário: onde aquela resposta bateria de frente com o resto do que o Martin já estava dizendo. O app mostra o código da conta no perfil. O app tem um botão de apagar:

"a app tem um um botão apagar a a minha conta"

A política de privacidade tinha acabado de ir para o ar, e ela descreve a conta:

"A política de privacidade que acabámos de publicar descreve a conta e como apagá-la."

E o próprio formulário, mais adiante, cobra uma declaração que só faz sentido se a conta existir:

"Você vai declarar mais à frente que existe eliminação de dados dentro da app."

Marcar "não cria conta" colocaria uma linha do formulário contra 4 coisas que o Martin já tinha declarado ou estava prestes a declarar. A lição serve para qualquer formulário de conformidade: a sua resposta não é avaliada sozinha. Ela é lida junto com a política de privacidade, com a ficha da loja, com as telas do app e com as outras respostas do mesmo formulário. Uma resposta pode parecer defensável isolada e ficar indefensável ao lado do que está publicado a 2 cliques dali.

A melhor pergunta da cena é sobre a versão seguinte

O Martin não parou na recomendação. Ele quis saber por quanto tempo aquela resposta continuaria valendo:

"quando a pessoa for comprar mais para a frente, terás que fazer login ali com a conta Gmail ou da Play Store dela, certo?"

"Ou como esta configuração é só para esta versão que nós estamos a mandar"

E deixou o critério dele explícito:

"Eu só quero ter a certeza que a maneira que nós estamos a fazer é a melhor forma de o fazer."

Ele está perguntando se aquilo é um retrato desta versão ou uma verdade permanente sobre o produto. A cena não responde. A legenda segue para outro assunto e a pergunta fica aberta. A live também não mostra o formulário sendo enviado nem aprovado, então o que ficou registrado é a decisão de como responder.

No vibe coding a escolha técnica vira obrigação de descrever

A conta anônima do Fumava nasceu como decisão de implementação num app construído rápido, provavelmente para tirar atrito da primeira abertura: a pessoa instala, abre e já está usando. Meses depois, essa mesma escolha reaparece como campo obrigatório de um formulário de loja. Quem constrói no ritmo do vibe coding acaba conhecendo esse trajeto: o que você resolveu em 10 minutos para destravar o primeiro uso volta como declaração pública que você precisa saber defender. Vale ver como isso terminou em anonimização de dados. Isso aparece também em proteção de dados empresariais. Vale ver como isso terminou em vibe coding para saber quando o app esta pronto. Foi o mesmo caminho de conta desenvolvedor google. O mesmo problema apareceu em como continuar vibe coding quando acaba o limite.

Numa cena anterior do mesmo Martin, na mesma fase de publicação, o gargalo já tinha aparecido com outro nome: separar o que falta de código do que falta de configuração mostrou que o que impedia o Fumava de ir ao ar era configuração de loja. Esta cena mostra o que essa configuração cobra de quem faz vibe coding: julgamento sobre o próprio produto, e ninguém consegue fazer esse julgamento no seu lugar.

Isso é o que o formulário pedia em 5 de agosto de 2026, lido naquele dia. Regra de loja muda, e quem for preencher precisa conferir o formulário atual. Este post não é orientação jurídica nem de conformidade.

Minha leitura, com 3 ressalvas

Daqui em diante é análise minha, e não o que foi dito na live.

A primeira ressalva é que resposta de formulário sobrevive à versão que a gerou. Se o login entrar depois, para compra ou para outra coisa, a declaração precisa mudar, e ninguém volta lá espontaneamente. A pergunta do Martin sobre a próxima versão era exatamente essa, e ela continua boa depois que a live acabou.

A segunda é que a palavra "anônima" está fazendo muito trabalho nessa frase. Um identificador que persiste e concentra todos os dados de uma pessoa se parece mais com uma conta sem nome do que com ausência de conta. No vocabulário de formulário, a palavra que soa mais segura costuma ser a que descreve pior.

A terceira é sobre o limite do argumento que venceu a cena. Consistência é uma boa regra e não é uma regra completa. As suas declarações podem combinar perfeitamente entre si e ainda assim descrever mal o que o app faz com os dados. Consistência protege você de ser pego em contradição; ela não torna a descrição verdadeira, e é a descrição que importa para quem instala o app.

O que fazer antes de abrir o formulário

Junte, antes de responder qualquer coisa, tudo o que você já declarou em público sobre dados: a política de privacidade no ar, o texto da ficha da loja, as telas do app que falam de conta e de exclusão. Responda o formulário contra essa lista, e não de memória. Anote a data da resposta junto da declaração e deixe um lembrete para revisar quando mexer em autenticação, porque é aí que a resposta antiga vira declaração errada sem ninguém perceber. A cena está na live do dia 13 do Fumava.