Vibe coding para centralizar comentários de várias aulas numa caixa de entrada

O comentário do aluno nasce dentro da aula e fica guardado ali. Para saber se alguém perguntou alguma coisa, quem administra a escola precisa abrir aula por aula e conferir uma a uma. Dá para viver assim enquanto o catálogo é pequeno, e para de dar exatamente quando o produto começa a crescer, porque a quantidade de lugares para checar cresce junto com a quantidade de aulas. O custo desse trabalho não aparece em relatório nenhum. Ele é pago em dúvida de aluno que fica sem resposta.

Na live do dia 5 de agosto, Jhonatan parou de mexer no fluxo do aluno e pediu ao agente uma caixa de entrada para o administrador, dentro do painel do seu produto, uma plataforma de escola digital para igrejas. Pediu 2 vezes, em momentos bem distantes da mesma transmissão, e foi na segunda que apareceu o detalhe que separa uma tela informativa de uma ferramenta de trabalho.

O comentário mora na aula, o trabalho de quem administra não

Na primeira vez, ele descreve a funcionalidade junto com o diagnóstico:

"vamos criar um um separador lá no dashboard que vai chegar as mensagens quando alguém comenta algo no fórum"

E logo depois o que ele quer evitar:

"o administrador não precisa ficar a entrar numa por uma ali"

O comentário é filho da aula, e é natural montar a interface seguindo esse encaixe: entra na aula, vê os comentários da aula. Só que a pergunta de quem administra não é "o que tem nesta aula", é "o que chegou de novo". São 2 recortes diferentes dos mesmos dados. Um segue a estrutura do conteúdo, o outro segue o tempo. Ele diz qual dos 2 quer:

"vai aparecer-lhe por ordem cronológica"

Quando o trabalho da pessoa é reagir a coisas que chegam, o recorte por tempo é o que organiza o dia dela. A estrutura do conteúdo continua servindo bem a quem estuda e vira obstáculo para quem atende.

Ler num lugar e responder noutro resolve metade do problema

Mais tarde na mesma live ele volta ao assunto:

"vamos criar para o admin um local de chegar a notificação"

"para que o admin não tenha de ficar interno na hora por aula para responder e aparece tudo para ele nesse lugar"

O verbo responder já estava no pedido antes, e agora ele diz onde a resposta acontece:

"E ali responde diretamente"

Uma caixa que só mostra o que chegou, e obriga a navegar até a aula para responder, entrega a metade fácil e deixa de pé a metade cara. A pessoa continua abrindo aula por aula, com a diferença de que agora sabe quais abrir. A funcionalidade só fecha quando a ação acontece no mesmo lugar da leitura.

Ele pediu 2 vezes, e a live não mostra a caixa funcionando

O pedido aparece 2 vezes, separado por um bom pedaço de transmissão, e na segunda passagem está mais completo: o mesmo separador no painel, a mesma ordem cronológica, mais a resposta saindo dali. Não dá para saber pela gravação por que ele voltou ao assunto. O que a gravação sustenta é que ele voltou, e que na volta descreveu mais coisa. No vibe coding o pedido é a especificação, e essa especificação melhorou entre uma passagem e outra. Isso aparece também em multi tenant o que é.

O que a live não mostra é a caixa em funcionamento. A transmissão termina sem a tela pronta na frente da câmera. Quem quiser conferir os 2 momentos pode assistir à live.

Por que no vibe coding a tela de quem opera é a última a ser pedida

O agente constrói o que aparece no pedido, e o que aparece no pedido é quase sempre o fluxo do aluno: como ele entra, como ele assiste. Essa parte qualquer um consegue descrever, porque qualquer um já foi aluno de alguma coisa. O trabalho de operar o produto não tem imagem pronta na cabeça de ninguém, e o que ninguém imagina também não é descrito no pedido. Ele ganha superfície no dia em que alguém senta para operar e sente a falta.

Por isso a caixa de entrada chega solta no meio da live, e não como parte da fundação: é uma tela que só o administrador vê. O vibe coding acelera a parte que você consegue descrever, e com isso o gargalo passa a ser o que você enxerga na hora de descrever.

Do mesmo builder e do outro lado da mesma cegueira: testar como usuário comum sem ser admin. Lá o administrador enxerga demais, e o teste passa sempre. Aqui ele enxerga de menos, porque não existe superfície construída para o trabalho dele. Nos 2 casos o administrador é um usuário com produto próprio, e esse produto costuma ser o último a ser desenhado.

Minha análise: o que eu acrescentaria ao pedido antes de mandar construir

O que vem abaixo não saiu da live. São 3 ressalvas minhas, de quem assistiu ao pedido ser feito e ficou pensando no que acontece depois que a caixa existe.

Ordem cronológica sozinha envelhece mal. Uma caixa que só empilha item novo por cima do anterior vira parede assim que o volume cresce. O que faz uma caixa de entrada funcionar é poder esvaziá-la, e esvaziar exige estado por item: lido, respondido, ignorado. Sem isso, no segundo mês a pessoa volta ao problema original, que é não saber o que já tratou.

A caixa também cria um segundo lugar onde o mesmo comentário aparece, e os 2 lugares precisam concordar. Responder pela caixa tem que produzir exatamente a mesma coisa que responder pela aula, com o mesmo texto no mesmo tópico. Se as 2 rotas divergirem, o aluno vê uma versão e o professor vê outra, e a discussão passa a acontecer em 2 fios que ninguém consegue juntar depois.

A menos óbvia: centralizar muda quem responde. Com a navegação por aula, quem responde é quem cuida daquela aula, porque é essa pessoa que entra ali. Com uma caixa única, quem responde é quem abrir primeiro. Isso é uma mudança de operação disfarçada de mudança de tela, e vale decidir de propósito, com nome de quem fica responsável, em vez de descobrir por acidente no primeiro mês.

Onde está a próxima caixa de entrada do seu produto

Liste os lugares do seu produto onde aparece coisa nova que alguém precisa responder: comentário, formulário de contato, pedido de acesso, resposta de exercício. Para cada um, pergunte se a pessoa descobre sozinha que aquilo chegou ou se ela precisa ir olhar. Todo "precisa ir olhar" é uma caixa de entrada esperando para ser construída.

E antes de pedir a caixa ao agente, defina o que significa um item estar resolvido no seu produto, porque é isso que permite tirar o item da caixa. Sem essa definição, a caixa vira uma lista que só cresce, e o administrador volta a abrir aula por aula para saber onde está o que interessa.