Vibe coding para guardar valor unitário em vez de média: a lição do maço
Antes de o banco existir, Martin recusou o campo \"gasto semanal\" e pediu o preço do maço. A resposta do agente: \"É uma média morta. Custo unitário é vivo.\"
O campo mais caro de um cadastro é o que guarda uma média, e dá para recusar esse campo antes de o banco existir. Foi o que fez Martin na live do Fumava, o app dele para largar o cigarro: o agente listou os campos que a tabela de perfil ia ter, um deles era "gasto semanal", e ele parou a lista em vez de mandar criar.
A troca que ele pediu serve para qualquer cadastro. Guardar o preço do maço, que a pessoa paga toda semana e sabe de cor, no lugar do gasto semanal, que ela estima de cabeça e erra. Do preço do maço sai o valor de cada cigarro, e cada registro de uso vira um valor exato. Do gasto semanal não sai nenhum dos dois.
A recusa aconteceu com a tabela ainda no papel
A fala dele, na hora:
"eu acho mais interessante pegar esse valor do que quanto que ela gasta por semana, né? que a partir do momento que tu tem o valor da carteira de cigarro que essa pessoa geralmente compra e dificilmente uma pessoa troca de marca de cigarro, tu já sabe quanto custa o unitário"
O argumento está embutido no meio da frase: a pessoa raramente troca de marca, então o preço do maço é um número estável. Ele escolheu o campo que envelhece melhor.
E terminou pedindo conferência em vez de execução:
"Confere aí se isso faz mais sentido do que gasto semanal."
Conferir no papel resolve o desenho do campo, mas não prova que o dado sobrevive ao uso real: para isso o teste tem que ser feito na marra, do jeito que o usuário faz, como em testar retomada matando o app de verdade.
A lista de campos que um agente entrega vem redonda, com nome, tipo e ordem, e essa aparência de coisa resolvida é o que faz você aprovar sem ler. Vale a mesma disciplina que se aplica a pedir uma lista única de telas em vez de tela apontando pra próxima: enxergar o conjunto inteiro de uma vez, numa estrutura consolidada, é o que permite discutir ordem e o que sobra antes de qualquer coisa virar código. Aprovar uma lista de campos é decidir o que o produto vai conseguir calcular pelos próximos meses.
Esse tipo de lista mistura decisões técnicas com trabalho administrativo. Vibe coding para separar o que falta de codigo do que falta de configuracao mostra como separar essas naturezas muda o cronograma.
A média morre na primeira tela, o unitário não
O agente concordou e explicou em 2 linhas:
"É uma média morta. Serve por uma tela e acabou. Custo unitário é vivo."
E, sobre o campo que ia ser criado:
"Com gasto semanal isso é impossível de calcular."
Há um motivo mais forte, que não foi dito na live: agregado se calcula a partir de unidade, e unidade não se recupera a partir de agregado. Quem guardou a média perdeu a informação e não tem de onde reconstruir; quem guardou a unidade monta qualquer média depois, inclusive as que ainda não pensou em perguntar.
O segundo ganho é de formulário. A média chega com menos resolução e mais suja: quem responde "quanto você gasta por semana" faz uma conta de cabeça na hora e erra, enquanto o preço do maço é um número que a pessoa paga toda semana e recita sem pensar. Perguntar o que a pessoa sabe dá dado melhor que perguntar o que ela precisa estimar.
O 20 que virou campo em vez de constante
A mudança coube em uma linha do esquema:
"Em vez de fixar 20 no código, vira um campo com 20 já preenchido."
Um maço tem 20 cigarros, e escrever 20 no código funcionaria para quase todo mundo. Como campo com valor padrão, o app continua aceitando quem compra em quantidade diferente sem virar um app de um maço só.
O custo unitário virou o número mais reaproveitado do app, presente em 6 lugares, e o agente documentou a regra de consistência junto: nada de perguntar gasto semanal em paralelo, porque com os 2 campos no cadastro as respostas se contradizem. Um botão que era simbólico passou a devolver o valor na hora, e o esforço de não fumar virou dinheiro visível na tela.
Por que essa é uma decisão de vibe coding, e não de banco
No vibe coding, o esquema chega pronto para aprovação, e a revisão dos campos é a última janela barata que existe. Trocar um campo enquanto ele é uma linha de conversa custa uma frase. Trocar depois custa migração, e o que foi coletado em média não volta. Quando a conferência deixa de ser de um campo e passa a ser do projeto todo, ela vira vibe coding para pedir segunda opinião de IA sobre o projeto.
O maço de cigarro já tinha aparecido nesta série com outra função: o mesmo builder usou o preço dele como régua para precificar usando referência de hábito, e agora ele volta como o dado que o banco guarda, mesmo objeto em 2 papéis.
Decisões sobre campos que o usuário pode corrigir depois ganham importância especial: vale ver vibe coding para deixar usuario corrigir escolha do onboarding, onde a escolha do usuário também segue a mesma lógica de guardar o que se pode mudar. E vibe coding para decidir paywall sem trial gratuito mostra como adiar decisões sobre monetização até o produto estar pronto economiza argumentação depois.
Para executar bem as decisões que chegam prontas, escreva a ordem do trabalho: vibe coding para prompt de corrigir bug com plano antes de executar mostra como anexar as 4 exigências de processo no mesmo pedido.
E antes de tudo, o projeto precisa estar documentado: vibe coding para documentar projeto antes de codar lembra que o passo a passo precisa estar escrito para o agente conseguir trabalhar sem reinstrução.
O que fazer na próxima lista de campos
Na próxima vez que um agente listar os campos de um cadastro para você aprovar, leia campo a campo e pergunte de cada um se aquele valor é medido ou estimado. Onde for estimado, procure o número cru que dá origem a ele, o que o usuário sabe de cor e que não muda de mês para mês, e guarde esse no lugar.
Onde for um total ou uma média, escreva do lado a conta que o deriva: se a conta fecha com o que já está na tabela, o campo está sobrando, e se ela não fecha por falta de uma unidade, essa unidade é o campo que devia estar ali.
É desse tipo de decisão, pequena e repetida a cada tabela nova, que o vibe coding de quem constrói em público é feito. Dá para assistir à live e ver a cena inteira.