Vibe coding para agendar liberação de conteúdo com um campo genérico

Jhonatan pediu, numa frase só, 2 coisas que parecem exigir 2 sistemas diferentes: um devocional que sai um por dia e um curso inteiro, já gravado e já guardado lá dentro, que só destranca numa data marcada. Um conteúdo que pinga e um conteúdo que abre de uma vez.

O acerto foi pedir os 2 juntos. Conteúdo diário e lançamento com data são o mesmo mecanismo com valores diferentes, e quem percebe isso na hora de escrever o pedido recebe 1 regra de liberação em vez de 2 sistemas para manter pelos próximos anos. Foi assim que ele pediu, na live em que constrói uma plataforma de escola digital para igrejas (ele fala português europeu, então "libertado" é dele):

"Vamos criar uma estrutura para que, por exemplo, um devocional diário seja libertado de forma diária ou então para um lançamento, o curso já lá está, mas ser libertado em tal data"

E o que ele quer que aconteça enquanto a data não chega:

"ele ficar lá como eh bloqueado até tal dia, algo semelhante assim"

O que separa os 2 casos é o valor da data, não a natureza da coisa

Nos 2 pedidos o conteúdo já existe: a aula gravada e o devocional escrito já estão guardados dentro da plataforma. O que muda é o instante em que aquilo passa a ficar visível para o aluno. "Todo dia" é uma data que anda; "em tal data" é uma data parada. As 2 frases fazem a mesma pergunta ao sistema, uma vez por conteúdo: hoje isto já pode aparecer?

Quem enxerga isso escreve 1 regra e a usa nos 2 casos. Quem não enxerga escreve 2 telas de configuração, 2 tabelas e 2 caminhos de teste, e depois mantém os 2 para sempre. Chamar essa regra de "um campo" é minha leitura do formato que a solução tende a ter; a palavra que ele usou foi estrutura.

Construir os 2 dobra o número de lugares onde o bug pode nascer

O custo de errar para este lado não é o trabalho de hoje, que até parece pequeno quando os 2 casos são simples. Cada caminho de liberação é um lugar onde um bug de visibilidade pode nascer, e com 2 caminhos surge uma falha que não existia antes: eles discordarem sobre o que está visível. Um acha que a aula abriu, o outro acha que não, e o aluno vê a resposta de um dos 2 dependendo de por onde entrou.

Conteúdo que aparece cedo demais é um vazamento, com o lançamento que você preparou por semanas na rua antes da data. Conteúdo que aparece tarde demais é o aluno esperando o devocional de segunda e mandando mensagem no domingo à noite. Doem em pessoas diferentes e por isso entram no seu quadro como 2 problemas, quando na verdade é o mesmo bug morando em 2 endereços.

A regra pode existir no sistema e ainda não existir para quem precisa usá-la

A live não mostra a coisa pronta e funcionando. Mais tarde, na mesma sessão, ele volta ao assunto procurando o controle.

"onde configuro eh a data que eu quero"

"Eu quero aceder a isso para eu configurar."

A lógica pode estar escrita em algum lugar do projeto e ainda assim a pessoa que vai programar o devocional da semana não tem onde marcar a data. Enquanto esse lugar não aparecer, a estrutura é uma promessa: existe no código, não existe para quem administra a escola. Num projeto tocado por vibe coding, essa distância entre a regra e o painel onde ela se configura costuma passar em branco, porque o agente já respondeu que fez.

No vibe coding, a generalização nasce na frase do pedido

Pedir 1 estrutura para 2 casos é uma decisão de modelagem, e no vibe coding ela é tomada na hora em que você escreve o pedido. O agente entrega o que foi pedido. Se o devocional diário virar um pedido hoje e o lançamento com data virar outro pedido em outro dia, numa conversa nova, ele constrói 2 caminhos e nenhum dos 2 vai saber do outro. Ele não errou; ninguém disse que era o mesmo assunto. A generalização não aparece depois sozinha, ela nasce na frase.

É o mesmo movimento de juntar a navegação numa lista única de telas em vez de tela apontando pra próxima, só que no sentido inverso: lá, um fato que estava espalhado por vários pontos foi reunido num lugar; aqui, 2 casos que pareciam diferentes cabem no mesmo mecanismo. Os 2 posts terminam na mesma pergunta, a de até onde a simplificação aguenta.

Minha leitura, com 3 ressalvas

O que vem agora é análise minha, não fala do Jhonatan. Os 3 momentos estão na live em que ele monta a plataforma.

A primeira ressalva a própria live entrega. Ainda na mesma sessão, ele pede uma terceira regra de liberação, e ela não tem data nenhuma:

"posso deixar o aluno marcar concluído qualquer aula à hora que ele quiser"

"só libertar quando ele assistir a uma"

Liberar a próxima aula depois que o aluno terminar a anterior depende do que a pessoa fez, não do calendário. Nenhum valor de data expressa isso, e é aí que a estrutura única encontra a fronteira dela. O mecanismo que cobre os 2 primeiros casos não estica até o terceiro, e descobrir isso na mesma sessão em que você pediu a generalização sai barato.

A segunda ressalva é o exagero contrário. Generalizar cedo demais também cobra caro: juntar 2 casos que só se parecem por fora produz uma regra cheia de exceção. O sinal de alerta aparece enquanto você escreve o pedido, e se a segunda condição só funciona com um "se" na frente, ela provavelmente não é a mesma coisa que a primeira.

A terceira ressalva é uma pergunta que ninguém faz na hora de pedir a data: em qual fuso horário? Conteúdo diário para gente em fusos diferentes libera em momentos diferentes, e isso fica invisível enquanto todo mundo está na mesma cidade. Vira problema no dia do primeiro aluno de outro continente, que abre o aplicativo e não encontra o devocional que todos os outros já leram.

O teste da frase única, antes de mandar o pedido

Quando 2 pedidos parecerem funcionalidades diferentes, tente escrever a frase que descreve os 2 sem usar o nome de nenhum. Se a frase sair inteira, você tem 1 mecanismo e deve pedir 1. Se precisar de um "e também" no meio para a frase fechar, provavelmente são 2 mesmo, e aí vale construir os 2.

Antes de dar o pedido por encerrado, faça a pergunta que o Jhonatan fez sozinho mais tarde: onde eu vou marcar a data? Regra de liberação sem lugar para configurar não é usável, e essa diferença é fácil de não perceber enquanto o agente responde que está tudo pronto. Isso vale também quando a regra que você criou é compartilhada com vários contextos de administração, como em uma caixa de entrada centralizada de comentários. E quando a ferramenta que você vai usar não suporta exatamente a tarefa que você precisa, leia a documentação antes de arriscar. E antes de mandar gerar uma série inteira, salve as regras positivas e negativas em um arquivo do projeto.