Vibe coding para separar tela de aprovar e tela de publicar

O mesmo produto recebe 2 tipos de usuário, e cada um chega com uma pergunta diferente. A frase que descreve isso saiu assim:

"o social manager pergunta: "O que está no ar?" O cliente pergunta: "Preciso decidir algo?" Uma tela só mistura os dois."

Quem escreveu essas 2 perguntas não foi o builder. Foi o agente dele. E o agente só escreveu isso na segunda resposta, porque na primeira tinha recomendado o contrário. Thiago estava construindo uma agência de marketing com IA e pediu ao agente que escolhesse entre 2 caminhos: encaixar as publicações dentro da tela de aprovações, que consertava rápido um bug que ele já tinha sentido e tinha risco baixo, ou criar um módulo de publicações separado, que dava muito mais trabalho. O agente recomendou o caminho rápido.

O builder não aceitou a resposta como veio. Pediu que o agente fosse "brutalmente honesto", e a recomendação virou.

Uma fila que esvazia e um painel que mostra

O argumento do agente, na segunda resposta, foi de princípio:

"[...] existe justamente porque decisão e ir ao ar são jobs [...] diferentes"

A legenda corta a frase. Aprovar e publicar parecem parentes porque acontecem em sequência, e são trabalhos com formatos opostos.

Quem aprova quer uma fila que esvazia. Cada item entra, ele decide, o item sai dali. A tela boa para esse uso é a que fica vazia no fim do dia, e vazio ali é sinal de trabalho feito.

Quem acompanha o que foi ao ar quer um painel que mostra estado, e nada some. O post publicado na semana passada continua sendo informação, porque a pergunta é "o que está no ar agora". Uma tela que esvazia é inútil para essa pergunta.

Os 2 usos brigam pela mesma lista. Ou o item some quando é decidido, e o histórico se perde, ou o item fica, e a fila de decisão nunca fecha.

O que o atalho cobra depois

O agente foi específico sobre o preço da opção rápida:

"Opção a é assinar o cliente o modelo errado e depois pagar o preço de arrancar isso"

"Resolve um bug que você já viu. Barato. Consolida mentira de produto."

O conserto rápido funciona, ele resolve o bug real. O que ele não faz é sumir depois de resolver: vira o modelo mental que o cliente da agência aprende. Se a pessoa passa 2 meses achando que aprovar e ver o que está no ar são a mesma coisa, porque a tela ensinou isso, mudar a tela depois é mudar o que ela entende do produto, com treino e reclamação junto. Foi isso que o agente chamou de arrancar.

A primeira resposta foi a mais barata

Perguntado qual dos 2 recomendava, o agente entregou o caminho rápido, com esta justificativa:

"Agora motivo: desbloqueio o problema real já sentido com risco baixo"

Ela responde exatamente o que foi perguntado, e responde bem. Só não é a resposta que o builder queria, porque o critério embutido ali (destravar rápido, arriscar pouco) foi escolhido pelo agente, não por ele. Quem está fazendo vibe coding recebe esse tipo de resposta já formatada, com motivo e tudo, e ela passa fácil por veredito.

A segunda resposta apareceu depois de "seja brutalmente honesto". E o detalhe que a torna confiável é que ela não apagou a vantagem da primeira:

"Se a pergunta for que desbloqueia caixa essa semana, a é mais rápida"

"A é remendo de sprint"

O agente continuou defendendo a opção que ele mesmo tinha acabado de descartar, dizendo em que cenário ela ganha. Uma resposta que só tem argumento a favor da escolhida é uma resposta que parou de pensar quando escolheu. Essa aqui manteve o trade-off visível, e por isso dá para o builder discordar dela com informação.

O mesmo princípio, um nível abaixo

Mais tarde, olhando a tela pronta, o builder aplica sozinho a mesma ideia, numa escala menor:

"eu tô na aba aprovações e eu vi que ficou tudo junto, né? né, que é roteiro de vídeo, que é lote de [música] roteiro de carrossel, não vai separar isso. Pode confundir o cliente da agência."

A legenda é ruim aqui e o "não vai separar isso" pode ser pergunta ou ordem. O que dá para ver é o resto: ele nota que roteiro de vídeo e lote de carrossel caíram na mesma lista, e trata isso como problema, pelo motivo que ele dá na frase seguinte, que é confundir o cliente da agência. O critério é o mesmo do módulo separado, aplicado dentro de uma tela em vez de entre 2.

A live não mostra o módulo separado pronto e funcionando. Mostra a decisão e, depois, um teste em que a tela de publicações abre zerada.

Por que a tentação do atalho é maior no vibe coding

No vibe coding as 2 opções chegam com o mesmo esforço aparente. Nenhuma delas é "2 semanas de trabalho" na sua cabeça, as 2 são um pedido e o agente escreve as 2. O custo da opção errada não aparece na hora de construir, aparece meses depois, quando alguém já aprendeu a usar a tela que não devia existir.

E o agente otimiza pelo que você pediu, que no vibe coding é quase toda a especificação que existe. Peça o rápido e ele recomenda o rápido, com uma justificativa boa. Em pedir segunda opinião de IA sobre o projeto a mecânica é a mesma, num momento diferente do projeto: "o que falta" devolve lista, "o que você acha" devolve elogio. Aqui, "qual você recomenda" devolveu o caminho barato e "seja brutalmente honesto" devolveu arquitetura. A forma da pergunta decide a qualidade da resposta.

Minha leitura, com 3 ressalvas

Essa parte é análise minha, não está na live.

"Brutalmente honesto" não é fórmula. Funcionou ali porque existia um trade-off real e uma segunda opção já em cima da mesa. Pedir honestidade sobre uma pergunta mal formulada devolve a mesma resposta com tom mais duro.

O agente também não tem como saber qual é a sua pressa. Ele chutou "caixa desta semana" e chutou razoavelmente, mas essa informação é sua. Dizer o horizonte dentro do pedido ("decida pensando em 2 anos, não nesta sprint") faz mais trabalho do que pedir honestidade depois.

E o argumento das 2 personas é bom e continua sendo hipótese. Ele descreve o que um gestor e um cliente perguntariam. Ninguém sentou com um gestor e um cliente de verdade para conferir. Trate como desenho a validar.

O pedido que eu faria da próxima vez

Quando pedir ao agente para escolher entre 2 caminhos, peça as 2 defesas antes da recomendação, e diga o horizonte de tempo da decisão dentro do próprio pedido.

Depois use as perguntas das personas como teste da sua tela: escreva a pergunta que cada tipo de usuário traz quando abre aquilo, e veja se a tela responde 1 pergunta ou 2. Se responder 2, você provavelmente tem 2 telas ali dentro. A virada da recomendação dá para ver em vídeo, é só assistir à live.