A Camada Faltante Entre LLMs e Seu DOM

Todo produto de IA sério está correndo em direção à mesma funcionalidade: em vez de retornar texto, retornar UI. Peça um painel, receba um painel. Peça um formulário, receba um formulário funcional. Não um blob JSON que você tem que renderizar sozinho — o modelo produz a interface diretamente. Isso é uma UI generativa, e está passando de truque de demonstração para funcionalidade esperada mais rápido do que a infraestrutura da maioria das equipes pode lidar.

Ninguém está falando o suficiente sobre o que quebra quando você realmente entrega isso.

Três problemas que todos enfrentam, em ordem

1. A saída não é confiável, e você está prestes a renderizá-la de qualquer maneira.

Um LLM produz HTML/JS e você o coloca no DOM. Isso é dangerouslySetInnerHTML com um modelo no loop em vez de um CMS. O modelo pode alucinar uma <script>, um manipulador de eventos inline, uma busca para algum lugar onde não deveria. A maioria das equipes lida com isso... não lidando com isso, e esperando que o prompt do sistema seja uma barreira de segurança. Não é.

2. O modelo não conhece realmente seus componentes.

Peça a um LLM para gerar um botão usando seu sistema de design, e ele inventará props que não existem, pulará atributos de acessibilidade obrigatórios ou usará com confiança uma API de seis versões atrás porque é isso que está em seus dados de treinamento. Não há uma fonte de verdade que ele está verificando no momento da geração — é correspondência de padrões, não pesquisa.

3. UI em streaming é um problema diferente de texto em streaming.

Texto token por token apenas se anexa. HTML token por token não — uma tag meio fechada, um componente que precisa de todo o seu conjunto de props antes de poder renderizar, uma re-renderização que redefine a posição de rolagem e perde o foco a cada pedaço. A maioria das demonstrações de "UI em streaming" na verdade apenas espera pela resposta completa e finge o efeito de digitação, porque fazê-lo de verdade é mais difícil.

Juntando tudo: a UI generativa precisa de uma barreira de isolamento, uma verificação de verdade fundamental e um caminho de renderização em streaming real. A maioria das implementações atuais não tem nenhuma das três.

Como é uma solução real

Isolamento. A saída do modelo deve ser renderizada em algum lugar que estruturalmente não possa alcançar a página host — sem DOM compartilhado, sem acesso a cookies, sem busca ambiental. Um iframe isolado com uma Política de Segurança de Conteúdo restritiva auto-gerada e um canal de mensagem tipado de volta para o host, para que erros e eventos cruzem a barreira deliberadamente em vez de acidentalmente.

Verdade fundamental no momento da geração. O modelo não deve estar adivinhando sua API de componentes de memória. Ele deve ser capaz de consultar a real — props atuais, tipos atuais, exemplos atuais — e, idealmente, ter sua saída verificada contra essa mesma fonte antes que qualquer coisa seja renderizada. Não um documento mantido manualmente que se desvia do código real; o código real.

Um patch real, não uma re-renderização. Streaming HTML em uma pré-visualização ao vivo precisa atualizar no lugar — DOM diferenciado ou corpo substituído sem derrubar scripts, estado ou foco — com um canal de redimensionamento/erro de volta para o host para que um pedaço ruim apareça como uma mensagem, não como uma falha.

Um exemplo funcional disso, de ponta a ponta

Esta é a versão concreta do acima, não uma hipótese, de uma ferramenta de TypeScript de código aberto chamada Vielzeug:

• Um servidor MCP expõe a documentação real de uma biblioteca de componentes, assinaturas de tipo e exemplos para que um cliente de IA consulte a verdade atual em vez de corresponder a dados de treinamento desatualizados.
• A própria biblioteca de componentes envia uma ferramenta de validação: o markup gerado é verificado contra o mesmo Manifesto de Elementos Personalizados gerado a partir da saída de construção real — não uma especificação escrita à mão — antes de ser confiável.
• Um runtime de iframe isolado lida com a renderização: CSP auto-gerada rigorosa, allow-scripts apenas, uma ponte postMessage tipada e uma chamada patch() construída especificamente para streaming:

// Transmitir tokens de um LLM diretamente para uma pré-visualização isolada e ao vivo
let accumulated = '';
for await (const chunk of streamUI(userPrompt)) {
  accumulated += chunk;
  preview.patch(accumulated); // atualização ao vivo, sem recarregar, sem perda de estado
}

// Erros de dentro do sandbox aparecem como mensagens, não falhas
sandbox.onMessage((msg) => {
  if (msg.type === 'error') showError(msg.message);
});

Consulte a especificação real → gere contra ela → valide o resultado → renderize em algum lugar que não possa te machucar, ao vivo, enquanto transmite. Três preocupações separadas, três peças separadas, conectadas em vez de coladas.

Isso não substitui seu frontend — ele se conecta a ele

Vale a pena ser direto sobre isso, porque o ciclo de hype não é: a UI generativa não está vindo para o seu sistema de design, seus painéis construídos à mão ou seu fluxo de checkout cuidadosamente ajustado. Ninguém quer que sua navegação principal, seu onboarding ou sua página de cobrança sejam refeito por um modelo em cada visita. UI estática e dinâmica — construída, revisada, testada, versionada por humanos — permanece exatamente onde está para qualquer coisa que precise ser consistente, acessível e previsível toda vez.

O que a UI generativa é boa é para a área de superfície que sempre foi cara de construir manualmente para cada caso possível: um gráfico ad-hoc para qualquer pergunta que um usuário acabou de fazer, um formulário único moldado por uma conversa, um relatório que ninguém escreveu um modelo porque há variações infinitas dele. Isso é um complemento ao seu aplicativo, não uma substituição dele.

A arquitetura reflete essa divisão literalmente. No exemplo acima, o sandbox é um slot dentro de uma página normal, construída à mão — um contêiner isolado que o resto da sua UI estática hospeda, não uma tomada de controle dela. O sistema de design é o mesmo que suas telas construídas por humanos já usam; o modelo é apenas mais um produtor de markup contra ele, mantido à mesma especificação, renderizado em um espaço contido ao lado de tudo o que você construiu da maneira regular. A UI generativa ganha um lugar dentro do aplicativo que você já tem. Não pede que você jogue esse aplicativo fora.

A verdadeira lição

Nada disso requer uma "estrutura de IA" especializada. Requer as mesmas coisas que uma boa infraestrutura de frontend sempre exigiu — contratos tipados, verdadeiro isolamento, estado previsível — apontados para um novo tipo de entrada não confiável, e aplicados apenas onde essa entrada realmente ganha seu lugar. As equipes que acertarem a UI generativa não serão aquelas que substituírem seu frontend por um modelo. Serão aquelas que deram o m