Vibe Video: o modelo de código que faz filmes escrevendo código frontend

No último mês, o vídeo de IA mais comentado do mundo não foi feito por um modelo de vídeo. Foi feito por um modelo de código que escreveu código frontend até surgir uma animação.

Os clipes vieram do Claude Opus 5.5. Em um caso amplamente compartilhado, um criador usou um prompt de referência, acesso ao Midjourney e um mood board para produzir um curta distópico cinematográfico em cerca de doze horas. A publicação passou de 20 milhões de visualizações. Outro criador gerou uma peça de dois minutos e dezesseis segundos sobre a história da civilização com uma única instrução; ela ultrapassou dez milhões de visualizações em dois dias. Uma coleção no GitHub de vídeos do Opus 5.5 reuniu mais de 400 entradas, a maioria com prompts e códigos públicos.

As pessoas começaram a chamar isso de Vibe Video. O nome é desajeitado, mas a técnica vale a pena entender, porque é um caminho genuinamente diferente para imagens em movimento do que aquele que todo mundo está seguindo.

O código como motor de renderização

O pipeline usual de vídeo com IA é um modelo de difusão prevendo pixels. Você fornece um prompt ou uma imagem estática, e ele retorna quadros. O modelo é treinado em vídeo, e seu senso de movimento é aprendido a partir desses dados.

A renderização por código funciona de outra forma. Um modelo de linguagem escreve HTML, CSS, SVG ou JavaScript que desenha uma animação, e um navegador a renderiza. Nada é previsto quadro a quadro. O movimento vem de um código que descreve explicitamente posição, tempo e easing.

Essa distinção importa porque torna fácil algumas coisas que a difusão acha difíceis. Gráficos precisos, tipografia, gráficos de dados, movimento geométrico e transições entre telas são triviais quando são código. São exatamente as coisas que saem borradas de um modelo de vídeo. O trade-off é que a renderização por código não consegue produzir um rosto humano fotorrealista em movimento. Ela desenha o que o código consegue descrever.

Por que os criadores se apegaram a isso

Duas propriedades explicam o entusiasmo. A primeira é a reprodutibilidade. Um clipe de difusão é uma amostra; rode de novo e você obtém um primo, não um gêmeo. Uma animação codificada é um programa. Mude um valor e você sabe o que acontece. Isso torna a revisão barata, e a revisão é onde a maior parte do trabalho realmente está.

A segunda é que a saída já está em um formato que o resto de um fluxo de trabalho pode usar. Uma animação de navegador pode ser capturada, incorporada em um site ou conectada a uma fonte de dados. Ela se encaixa naturalmente dentro de uma página de produto ou de um dashboard, que é de onde vem boa parte da demanda comercial por movimento.

Há também uma razão do lado da oferta. O Claude Opus 5.5 foi lançado em 22 de setembro com um system card de 230 páginas e preço de API a quatro dólares por milhão de tokens de entrada e vinte por milhão de saída. Ele teve desempenho próximo ao antigo modelo de ponta na maioria das tarefas, com um custo significativamente menor. Modelos de fronteira mais baratos tornam a geração de código longa e iterativa viável para indivíduos, que é exatamente o que as construções de doze horas exigem.

A outra pista

Na mesma semana, outro modelo de propósito geral estava avançando sobre o vídeo vindo de uma direção diferente. Relatou-se que o GPT-6 Astra atua como uma espécie de diretor de IA, cuidando do planejamento de storyboard e da pré-visualização em white model, além de acessar Blender, Unreal Engine e DaVinci Resolve para construir cenas, bloquear planos e cuidar das edições.

Junte os dois e um padrão aparece. Modelos de propósito geral não estão tentando superar o Seedance, o Kling ou o MiniMax em movimento fotorrealista. Eles estão se movendo para montante, para o planejamento e o pipeline de produção, e lateralmente, para um movimento que é programático em vez de fotográfico. Isso deixa os modelos de vídeo especializados continuarem pressionando pelo realismo, enquanto os modelos gerais assumem as partes do processo que se parecem com software.

Como o fluxo de trabalho realmente funciona

O processo descrito pelos criadores que estão obtendo bons resultados se parece mais com desenvolvimento de software do que com cinema. Você escreve um prompt que define o clima e as restrições, o modelo produz código, o código é renderizado no navegador, e você olha o resultado. Depois muda uma coisa e roda de novo. O ciclo é curto e a saída é inspecionável, e é por isso que construções de doze horas são possíveis. Doze horas entregando um parágrafo a um modelo de vídeo produziriam ruído. Doze horas editando código produzem uma peça finalizada.

O mood board e o modelo de referência importam por uma razão que não tem nada a ver com composição. Eles dão às imagens estáticas uma paleta e um tema consistentes, para que, quando o código as posiciona e anima em torno delas, as peças pareçam pertencer a um único filme. O código fornece o movimento e a tipografia. As imagens estáticas fornecem o mundo. Nenhuma das metades funciona sem a outra.

Onde o custo realmente recai

É tentador pensar que vídeo renderizado por código é gratuito, porque a renderização acontece em um navegador na sua própria máquina. As chamadas ao modelo não são gratuitas, e o ciclo é longo. Cada reescrita é uma requisição paga, e uma peça com centenas de edições são centenas de requisições com um grande contexto anexado. O corte de preço da Anthropic para quatro dólares por milhão de tokens de entrada foi o que tornou esse ciclo acessível para indivíduos, e não apenas para estúdios. Quanto mais barato o modelo, mais livremente um criador pode iterar, e a iteração é o método inteiro.

Isso tem uma consequência estranha. O gargalo desse estilo não é o poder de processamento para renderizar. É a revisão. Alguém precisa assistir a cada renderização e decidir o que mudar, e essa atenção não escala com um preço de API mais baixo. Os criadores que estão tendo sucesso com o Vibe Video são, na prática, diretores olhando para os dailies e dando notas, exceto que as notas vão para um diff.

Renderização por código e vídeo gerado, lado a lado

Ajuda ser preciso sobre qual estilo faz o quê. A renderização por código é reproduzível, barata de revisar, nítida em gráficos e texto, e confortável com dados. Ela não consegue gerar um ator fotorrealista, uma multidão ou um momento espontâneo. O vídeo por difusão faz isso bem e trata todo o resto como uma aproximação. Um logo renderizado por um modelo de vídeo sai quase certo. Um logo renderizado por código é exato.

Essa divisão sugere que os dois vão conviver em vez de competir. Uma peça pode abrir com um plano de estabelecimento gerado, cortar para um gráfico animado codificado e fechar com imagens geradas. A questão criativa interessante deixa de ser qual ferramenta usar e passa a ser onde alternar. As equipes que descobrirem essas costuras farão trabalhos que parecem deliberados.

Onde isso não funciona

A renderização por código não é um substituto para a geração de vídeo, e tratá-la como tal vai decepcionar pessoas. Ela não consegue filmar um ator. Não consegue produzir um quadro documental ou uma multidão crível. Ela é forte em design, movimento abstrato, informação e interface, e fraca em qualquer coisa que precise parecer que uma câmera esteve lá.

Ela também tem um perfil de custo do qual ninguém fala. Você pode queimar muitos tokens de modelo antes que um único quadro fique certo, porque o ciclo é escrever, renderizar, inspecionar, reescrever. Modelos mais baratos reduzem esse custo, mas não o eliminam. Os criadores que estão obtendo resultados impressionantes não estão apenas escrevendo prompts; estão revisando código.

O que isso nos diz sobre o setor

O interessante do Vibe Video não é que um modelo de código consiga fazer um clipe bonito. É que a fronteira entre "geração de vídeo" e "software que faz as coisas se moverem" acabou se revelando mais suave do que qualquer um supunha. Quando um modelo de linguagem consegue escrever a animação diretamente, parte da demanda por vídeo generativo é atendida por código.

Para quem cria visuais, a questão prática já não é escolher uma ferramenta. É quais partes de uma peça são melhor atendidas por um quadro previsto e quais são melhor atendidas por um quadro escrito. As equipes que estão descobrindo isso agora são aquelas cujos trabalhos parecerão deliberados em vez de meramente gerados.