Vibe coding para separar formato visual da estrutura do conteúdo

Um produto que mostra 14 formatos de carrossel, cada formato com 3 imagens de amostra, e que entrega peças de 7 ou 10 lâminas, convida a uma conta errada: a de que ele repete as 3 amostras até fechar as 7. Thiago fez essa conta em voz alta na live de 4 de agosto e perguntou se era isso. A pergunta veio com a suposição embutida, e é a suposição que torna a resposta útil. Quem a desmontou foi o agente, e ao desmontá-la separou 2 coisas que estavam coladas na leitura da tela: quantas lâminas o carrossel tem, e com que cara ele sai.

Os 2 papéis se somam, e trocá-los estraga a lição. A separação entre tamanho e aparência é saída do agente, em resposta à pergunta. A contribuição do Thiago vem depois, olhando a mesma tela, e aponta um buraco que arquitetura correta nenhuma tapa sozinha.

Por que parece que as 3 amostras são as peças

A pergunta do builder foi essa, nas palavras dele:

"por que só existem três lâminas de cada formato?"

"o sistema consegue usar as três lâminas de cada formato para construir os carrossérios de sete ou 10 lâminas. Seria isso?"

É uma leitura razoável da tela. Você vê 3 imagens presas a um nome de formato, sabe que o produto entrega carrossel de 7 ou 10 lâminas, e monta a única ponte disponível entre os 2 números: as 3 devem estar sendo recombinadas até dar 7. A aritmética funciona. O tropeço está um passo antes, em tratar uma amostra como se fosse um inventário. As 3 imagens existem para você entender o estilo, e não para serem montadas em cima do seu texto.

As 2 decisões que não se tocam

A resposta do agente foi direta:

"Não é inventário de templates."

"São duas decisões separadas."

"Quantas lâminas o produto escolhe 7 ou 10 pelo tamanho do contexto"

"Qual formato? Só escolhe a pele visual"

"não muda o comprimento"

O tamanho do carrossel vem do conteúdo, de quanto há para dizer. A aparência vem da escolha de estilo do usuário. As 2 decisões correm em trilhos diferentes e não se cruzam, e isso tem uma consequência prática: trocar de formato não obriga ninguém a reescrever o texto. O sistema redesenha as mesmas lâminas sob outra regra visual.

O agente ainda deu a formulação técnica de como isso funciona por dentro:

"Na hora de desenhar, o formato é um gerador HTML, tipo tema CSS regras, não deck de três imagens."

E fechou com uma analogia:

"Analogia rápida, formato, tema do PowerPoint, carrossel, apresentação de 7 ou 10 slides com texto novo em cada um."

"O formato é pele, não estrutura."

O tema de apresentação é a comparação certa. Você troca o tema e os slides continuam sendo os mesmos slides, com o mesmo texto, na mesma quantidade. O Thiago aceitou na hora:

"Hum, faz sentido."

Quando 2 decisões moram no mesmo controle

Quando 2 decisões independentes moram no mesmo controle, mexer em uma mexe na outra sem que ninguém tenha pedido. É por isso que a separação interessa a quem nunca vai construir um gerador de carrossel.

Pegue os controles do seu produto que têm nome de aparência: tema, template, layout, estilo. Se o usuário escolhe um deles e o conteúdo muda de tamanho junto, foram fundidas 2 coisas que deviam estar separadas. Ele queria mudar a cara do resultado e mudou o que o resultado diz. Isso raramente é registrado como bug. Vira comportamento estranho que o usuário aprende a evitar, e ninguém volta atrás para separar o que foi fundido.

A arquitetura estava certa e a tela não contava isso

Depois da explicação, olhando a mesma lista de 14 formatos, o Thiago trouxe a observação dele:

"seria bacana ter um prévio onde o usuário consegue visualizar como que é cada formato"

"tudo na tela pra pessoa verificar sem um prévio de como funciona, tá muito ruim"

Por dentro, a separação estava certa, e o agente tinha acabado de explicar por que ela está certa. Na tela, a pessoa vê 14 nomes, nenhuma prévia, e escolhe às cegas. Arquitetura correta não se explica sozinha na interface. Se é preciso perguntar a um agente para descobrir que "formato" só troca a pele, quem falhou em dizer isso foi a tela.

Na live, a prévia não fica pronta. O Thiago pede, o agente propõe um caminho, ele autoriza a execução, e o resultado não aparece na gravação. Dá para assistir à live até o ponto em que a sequência para na autorização.

O que o vibe coding constrói e o que ele deixa invisível

O padrão se repete em vibe coding. O agente constrói a separação certa por dentro e apresenta o resultado como uma lista de nomes, porque ninguém pediu a prévia. Decidir que formato e tamanho são independentes é um pedido. Decidir como essa independência aparece para quem usa é outro. Só o primeiro costuma ser feito, e o segundo entra na conversa quando alguém olha a tela pronta e estranha. O mesmo problema apareceu em vibe coding para agendar liberacao de conteudo com um campo generico.

O caso espelhado está em lista única de telas em vez de tela apontando pra próxima. Lá, um fato só, a ordem das telas, estava espalhado por vários arquivos e precisou ser reunido num lugar. Aqui, 2 decisões diferentes estavam coladas e precisaram ser separadas. Os 2 casos respondem a mesma pergunta: cada decisão está morando no lugar dela?

Minha análise, e 3 ressalvas

O que vem abaixo é leitura minha e não está na live.

Separar tem limite. Nem todo estilo aguenta qualquer tamanho, e um formato pensado para poucas lâminas pode ficar ruim esticado. A separação que é perfeita no papel encontra, mais cedo ou mais tarde, o caso em que a pele não serve para aquela estrutura.

A explicação do agente descreve como o sistema deveria funcionar. A live não mostra o código nem um carrossel sendo gerado com o formato trocado, então vale conferir na prática antes de tratar isso como garantido.

E a prévia que o Thiago pediu resolve a escolha sem resolver a expectativa. Uma prévia mostrada na capa, no miolo e no fim continua sendo amostra, e o usuário vai continuar supondo coisas sobre o que ela representa, que é exatamente o que aconteceu com as 3 imagens. O modo honesto de fazer isso é gerar a prévia com o conteúdo real da pessoa.

O que fazer com isso amanhã

Abra seu produto e escolha um controle onde o usuário decide alguma coisa. Pergunte quantas decisões diferentes aquele controle move. Se mover mais de 1, separe. Depois, ao lado de cada opção, pergunte se a pessoa consegue prever o resultado antes de escolher. Se não consegue, ela está adivinhando, e a explicação do seu produto ficou no código em vez de estar na tela. Em vibe coding, essas 2 perguntas custam um pedido cada, e o segundo quase nunca é feito.