Quando a IA mistura código, imagem e vídeo, o verdadeiro trabalho passa a ser versionar a intenção

A parte perigosa de um workflow multimodal nao e a IA errar uma imagem, gerar um componente feio ou devolver um video estranho.

Isso acontece. Voce olha, rejeita, pede outra versao, ajusta o prompt.

O problema mais chato aparece duas horas depois, quando alguem pergunta:

Qual prompt gerou esse asset? Por que escolhemos essa versao? Esse arquivo visual entrou no codigo ou ficou so na exploracao?

Se ninguem sabe responder, a IA nao acelerou o projeto. Ela so espalhou rastro solto pelo chat, pelo download, pela pasta temporaria e pelo historico do navegador.

Esse e o ponto que muita discussao sobre modelo multimodal ainda ignora. O salto de texto para codigo, imagem e video no mesmo fluxo e poderoso, mas tambem aumenta o custo de revisao. Antes voce revisava um diff. Agora voce revisa intencao, prompt, asset, codigo, criterio visual e decisao de produto ao mesmo tempo.

Sem um minimo de organizacao, tudo parece rapido no comeco e confuso no dia seguinte.

A conversa virou parte do build

Ferramentas recentes estao apontando para a mesma direcao: agentes com sessoes, ambientes proprios, revisao de diff, validacao em browser, edicao visual, contexto de projeto e entregas em varios formatos.

Isso muda a forma como a gente trabalha.

Quando a IA so responde uma pergunta, a conversa pode ser descartavel. Voce perguntou, recebeu a explicacao, seguiu a vida.

Quando a IA gera uma tela, altera codigo, sugere copy, cria uma imagem de campanha e ainda ajuda a montar um PR, a conversa deixa de ser "chat". Ela vira parte do processo de build.

E processo de build precisa de rastro.

Nao estou falando de transformar todo prototipo em documentacao corporativa. Pelo amor. Time pequeno nao sobrevive a isso. Mas tambem nao da para tratar prompt final, asset aprovado e criterio de aceite como se fossem papel de rascunho.

Se aquele resultado entrou no produto, ele precisa ser encontrado de novo.

O erro comum e salvar so a saida

O jeito mais facil de se perder e salvar apenas o resultado final.

Voce baixa a imagem boa, copia o componente, cola a copy, fecha o chat e pensa: "pronto".

So que o resultado final raramente explica o caminho.

Uma landing page feita com IA pode depender de um prompt que dizia "mais tecnico, menos marketing". Uma imagem pode ter sido escolhida porque preservava melhor o layout mobile. Um video curto pode ter sido rejeitado porque parecia bonito, mas prometia uma feature que ainda nao existe. Um trecho de codigo pode estar correto so porque voce pediu explicitamente para nao mexer no contrato da API.

Essas decisoes nao aparecem no arquivo final.

Quando voce salva apenas a saida, perde a intencao. E sem intencao, a manutencao vira arqueologia.

Isso vale ainda mais para multimodal porque o trabalho deixa de caber em uma unica linguagem. O diff mostra codigo, mas nao mostra por que a imagem mudou. O Figma mostra tela, mas nao mostra qual restricao tecnica levou aquela escolha. O chat mostra conversa, mas nao mostra qual arquivo entrou na branch.

Cada ferramenta ve um pedaco. O dev precisa costurar o minimo.

Uma regra simples: guarde quatro coisas

Para qualquer entrega pequena feita com IA, eu tentaria guardar quatro coisas:

objetivo;
input usado;
saida aceita;
motivo da aprovacao.

So isso.

O objetivo pode ser uma frase: "criar uma hero section para a pagina de onboarding com tom mais tecnico e menos promocional".

O input usado pode ser o prompt final, a imagem de referencia, o brief curto, o trecho de codigo, o log do erro ou o link da issue.

A saida aceita e o que entrou no projeto: arquivo, commit, asset, branch, screenshot, video, copy, qualquer coisa concreta.

O motivo da aprovacao e a parte que parece pequena, mas salva muito retrabalho: "aprovado porque manteve a hierarquia visual no mobile", "aceito porque nao mudou o contrato publico", "escolhido porque a imagem funciona em fundo claro e escuro", "rejeitamos a outra versao porque parecia anuncio".

Nao precisa virar uma planilha gigante. Pode ser um bloco no PR, um markdown junto do asset, uma nota na issue ou uma pasta pequena dentro do projeto.

O importante e que alguem consiga abrir aquilo depois e entender a decisao sem depender da memoria de quem fez.

Prompts tambem precisam de nome

Um detalhe bem pratico: prompt final deveria ter nome.

Nao todo prompt de exploracao. Isso seria demais. Mas o prompt que realmente gerou a versao aceita merece existir fora do chat.

Eu gosto de uma separacao simples:

prompts de exploracao ficam livres;
prompts finais entram no projeto;
prompts que mexem em comportamento entram perto do codigo;
prompts que geram asset entram perto do asset.

Exemplo:

assets/
  landing-ai-editor/
    2026-06-01-hero-brief.md
    2026-06-01-hero-final-prompt.md
    2026-06-01-hero-v3.png
    2026-06-01-approval-note.md

Parece bobo ate voce precisar trocar o asset daqui a um mes.

Sem isso, voce tenta recriar pelo "faz uma imagem parecida com aquela". Com isso, voce tem a intencao original, sabe qual versao foi aprovada e consegue pedir uma variacao com menos chute.

Asset visual precisa de criterio visual

Codigo costuma ter algum criterio de aceite: teste passa, tipo compila, endpoint responde, UI nao quebra no mobile.

Imagem e video muitas vezes entram no projeto com um criterio bem mais nebuloso: "ficou bom".

Esse "ficou bom" e perigoso quando IA esta no fluxo.

Uma imagem pode ficar bonita e ainda assim atrapalhar leitura. Pode parecer profissional e quebrar quando cortada para thumbnail. Pode estar coerente com o prompt, mas errada para o produto. Pode ficar otima no desktop e pessima no card social.

Entao o criterio visual precisa ser escrito de um jeito simples.

Por exemplo:

funciona em 16:9 e 1:1;
nao cobre texto importante;
combina com fundo claro;
nao promete uma tela que o produto nao tem;
passa no preview mobile;
o asset final tem nome e versao.

Se o fluxo envolve imagens geradas no Gemini, uma etapa pequena de pos-processamento tambem pode entrar nesse checklist. Em casos especificos, algo como Removedor de Marca d'água do Gemini pode ser apenas uma ferramenta de limpeza dentro do pipeline, nao o centro do trabalho.

Repara na diferenca: o ponto nao e "use tal ferramenta". O ponto e tratar limpeza, recorte, dimensao, nome de arquivo e aprovacao como etapas do mesmo processo. Asset que vai para produto precisa ser reproduzivel.

PR pequeno ainda e o melhor amigo do agente

Quando o workflow cruza codigo e visual, a tentacao e deixar a IA resolver tudo em uma tacada.

"Cria a tela, ajusta a copy, gera a imagem, integra o componente, atualiza teste e abre o PR."

Pode funcionar em demo. Em projeto real, eu prefiro quebrar.

Um PR bom para agente deveria ter uma intencao facil de revisar:

"adicionar componente com placeholders";
"trocar asset visual aprovado";
"ajustar copy sem mudar layout";
"integrar endpoint mantendo contrato";
"atualizar teste do fluxo afetado".

Se o PR mistura decisao visual, refactor, mudanca de comportamento e asset novo, o review fica caro. E quando review fica caro, todo mundo comeca a revisar de mentirinha.

Agente nao elimina esse problema. Na verdade, agente deixa o problema mais rapido.

Por isso o mesmo cuidado que ja vale para codigo humano vale em dobro aqui: escopo pequeno, criterio claro, diff revisavel.

O custo do rastro e menor que o custo da duvida

Guardar intencao parece burocracia quando tudo esta fresco na cabeca.

Mas o custo aparece depois.

Quando o designer pergunta por que aquela imagem foi escolhida. Quando o dev precisa adaptar a feature para outro cliente. Quando o fundador quer mudar a copy, mas manter o mesmo tom. Quando alguem abre o PR e nao entende se aquele asset e definitivo ou exploracao. Quando uma tela precisa ser refeita e ninguem sabe qual prompt gerou a versao boa.

Ai os cinco minutos que voce economizou viram meia hora de reconstrucao.

Eu nao acho que a resposta seja criar um processo pesado. A resposta e ter um rastro minimo e repetivel.

Para mim, um bom fluxo multimodal com IA caberia nisso:

brief de cinco linhas;
prompt final salvo;
asset final nomeado por data e intencao;
comparacao antes/depois quando houver visual;
criterio de aceite no PR;
nota curta dizendo por que aquela saida foi aprovada.

Da para fazer isso em poucos minutos.

E esses poucos minutos compram algo que modelo nenhum entrega sozinho: continuidade.

O dev que ganha nao e o que gera mais variacao

Multimodal vai fazer muita gente produzir mais coisas. Mais telas, mais imagens, mais videos, mais drafts, mais PRs, mais alternativas.

Legal. Mas volume bruto nao e vantagem se o time nao consegue revisar, escolher e reproduzir.

O dev que vai tirar mais valor disso nao e necessariamente quem gera cinquenta variacoes por tarde. E quem monta um fluxo pequeno o bastante para continuar andando, mas organizado o bastante para nao virar bagunca.

Porque no fim, IA multimodal nao muda uma regra basica de engenharia:

o que entra no produto precisa ser entendido depois.

Se a intencao ficou presa no chat, voce ainda nao terminou. Voce so gerou uma saida.