Vibe coding para deixar usuário corrigir escolha do onboarding

Quando uma pergunta de onboarding muda a interface para sempre, ela parou de ser pergunta e virou configuração do produto. Configuração mora nos ajustes, e não numa tela que a pessoa atravessa uma vez, antes de o produto ter funcionado diante dela. Foi essa a condição que o agente de Martin cobrou dele antes de aceitar personalizar a tela inicial do Fumava, o app que ele está construindo para quem quer parar de fumar.

A ideia tinha origem fora do produto. Martin leu as avaliações de apps concorrentes do mesmo nicho e encontrou gente reclamando que o app batia na tecla da economia de dinheiro quando o que importava era a saúde, e gente reclamando do contrário. Dali saiu o requisito: perguntar no onboarding o que pesa mais para a pessoa, dinheiro ou saúde, e mudar a tela inicial conforme a resposta. Esse garimpo tem post próprio, com o método de separar defeito real de reclamação de quem nunca ia pagar, em avaliações negativas de app no vibe coding. O que interessa aqui é a continuação: a reclamação lida virou especificação de tela.

O aceite veio com uma condição

O agente concordou com a personalização e emendou uma exigência:

"Duas coisas que eu acho que não são opcionais. Aqui tem que dar para trocar depois. Se o app escolher errado e a pessoa não puder corrigir, você reproduz exatamente a avaliação ruim que leu, só que com um passo a mais de frustração."

E fechou com a reclamação imaginada de quem passaria por isso:

"Ele até me perguntou e ignorou."

O dano aí é de outra natureza. Quando um app não pergunta nada e entrega uma tela genérica, o usuário culpa o produto por ser genérico, uma decepção morna que ele já esperava de um app que não o conhece. Quando o app pergunta e depois não deixa corrigir, o usuário sabe que o produto tinha a informação certa na mão e entregou errado assim mesmo, o que irrita bem mais e só existe em produto que se deu ao trabalho de perguntar. Vale ver como isso terminou em vibe coding para nao escrever ats se o usuario nao sabe o que e. O mesmo problema apareceu em vibe coding para deixar o aluno pular a aula.

A hora do onboarding é a pior hora para uma escolha definitiva

A pessoa responde antes de ter visto o produto funcionar. Ela ainda não sabe o que o app chama de progresso, o que ele mostra na tela inicial, se o número de cigarros evitados vai pesar mais do que o valor guardado. Escolher "saúde" ali é palpite sobre uma interface que ela nunca viu.

O segundo motivo é mais forte e é específico do nicho do Fumava. Num app de mudança de hábito, a razão de continuar muda durante o uso. Quem começa pelo dinheiro passa a olhar o fôlego quando ele volta, e quem começou pela saúde topa com uma conta apertada e volta a olhar o que deixou de gastar. Travar o destaque da tela inicial na primeira resposta é apostar que a motivação da pessoa fica parada, quando ela é justamente a coisa que o produto existe para movimentar.

Personalizar mexendo no destaque, com a tela inteira preservada

O desenho que o agente descreveu depois resolve a outra metade do risco. As falas foram estas:

"É o mecanismo central do app, não se troca, o que muda pelo motivo"

"O resto da tela é idêntico para todo mundo e nenhuma informação some."

Quem escolheu saúde continua vendo o dinheiro economizado, só não como manchete. A resposta do onboarding controla o topo da tela, e tudo o que existe nela continua existindo para todo mundo.

Essa distinção decide quanto custa o erro. Na personalização por ocultação, uma resposta dada na primeira tela vira amputação do produto: a pessoa marcou uma opção sem entender a pergunta e perdeu acesso a parte do que pagou, e a falta de caminho de correção deixa de ser um incômodo visual para virar funcionalidade sumida. Preservar tudo na tela ainda barateia a correção, porque não há estado a restaurar nem funcionalidade a desbloquear quando alguém troca o motivo, só uma tela que se reordena. Isso aparece também em vibe coding para confirmar deploy sem esperar verificacao completa, onde o sinal que você usa antes da verificação estar pronta precisa conservar a verificação completa como meta. E também em vibe coding para preencher seguranca de dados quando app cria conta anonima, onde as escolhas feitas no onboarding precisam estar documentadas depois em formulário de loja.

O que o vibe coding entrega rápido e o que ele deixa faltando

A tela de onboarding sai pronta assim que você a descreve, e o detalhe importante da cena é que o pedido de Martin não incluía a tela de correção. Ele pediu a pergunta e a personalização. O caminho de volta entrou porque o agente o exigiu como condição de aceitar o trabalho, e é aí que vale prestar atenção no vibe coding: você narra a jornada feliz, o agente constrói a jornada feliz, e o que fica de fora são os estados que ninguém narrou. Ninguém narra o momento em que o usuário percebe que escolheu errado. Essa tela não é pedida, não é gerada, e a falta dela só aparece depois, na avaliação de quem já desinstalou. A live inteira está gravada, e é a mesma em que o Fumava chegou ao fim do fluxo de onboarding.

Vale fazer isso no seu produto antes de desenhar a próxima tela. Percorra o onboarding e marque cada pergunta cuja resposta continua tendo efeito depois que ele termina. Para cada uma delas, escreva onde a pessoa troca a resposta com o produto já em uso: o nome do item e a tela onde ele mora. Quando o único lugar em que a pergunta aparece for o próprio onboarding, o que você construiu foi uma escolha permanente feita por alguém que ainda não conhecia o produto, e o conserto é uma linha nos ajustes que refaz a mesma pergunta, agora para quem tem repertório para responder.