Nosso diário9 min de leitura

O problema de granularidade em GenUI: onde a geração por LLM deve parar?

Notas da construção do motor GenUI do AirJelly — e por que dar mais liberdade ao LLM tornou o resultado pior.

Translated by AI

Este blog vem da nossa exploração prática do motor GenUI no projeto AirJelly. Não começamos pela teoria. Começamos por um experimento que, honestamente, foi bem frustrante: por que o resultado piorou quando demos ao LLM mais liberdade para gerar UI?

01 · Contexto

Por que GenUI merece atenção séria

Antes dos detalhes, vale deixar claro por que GenUI é um problema de engenharia sério, e não apenas um truque de demonstração. Em Generative Interfaces for Language Models, a equipe SALT-NLP / Stanford comparou as preferências dos usuários entre GenUI e o chat tradicional baseado em texto. A conclusão é clara: quando um sistema de IA precisa comunicar conteúdo estruturado e denso em informação, uma interface gerada dinamicamente pode ser muito melhor do que uma parede de texto.

A onda GenUI se acelerou entre 2023 e 2025 porque duas condições amadureceram ao mesmo tempo: os LLMs ficaram muito melhores em geração de código, e ecossistemas de componentes como shadcn/ui e Radix se tornaram estáveis o suficiente para construir em cima. Uma vez que essas condições estavam dadas, ferramentas surgiram naturalmente — o Vercel v0 é uma das implementações industriais mais representativas.

02 · O ponto de partida

Deixamos o LLM improvisar, e o resultado piorou

No branch feat/genui-real-content-experiment, rodamos um conjunto de comparações. A abordagem antiga tinha layout fixo e componentes unificados — polida e previsível. A nova abordagem tornou o layout mais flexível, mas o visual ficou bagunçado e os estilos dos componentes, inconsistentes.

Isso foi contra nossa intuição. Quanto mais liberdade demos ao modelo, menos controle tivemos, e pior ficou a consistência visual. O artigo Gen-UI-Lang faz o mesmo ponto: peça a um LLM HTML ou JSX bruto e a saída será verbosa, frágil e fácil de quebrar. Não é um problema de qualidade de prompt — significa que empurramos o LLM para uma granularidade em que ele não está no seu melhor.

03 · A tensão central

Uma contradição estrutural em GenUI

Por meio do experimento, identificamos uma contradição interna que se aplica basicamente a todo sistema GenUI.

Quanto mais liberdade o LLM tem, mais difícil é garantir consistência visual. Quanto mais fortes são as restrições, menos significativo o GenUI se torna.

Essa é uma tensão estrutural do paradigma, não um bug de uma implementação. Todo sistema GenUI precisa encontrar seu equilíbrio em algum ponto entre essas duas forças. Então a pergunta fica muito concreta: onde deve parar a fronteira de geração do LLM?

04 · O cenário

Escolhas de granularidade existentes

Antes de definir nossa própria resposta, ajuda olhar como outros abordaram a mesma questão.

Vercel v0 — gerando até o código do componente

O v0 deixa o LLM ir até o fim e gerar código completo de componentes React. Sua consistência visual vem do sistema de tokens semânticos do shadcn/ui — ele terceiriza a consistência para o tema da biblioteca. O custo: a lógica de geração fica fortemente acoplada ao ecossistema de componentes, então sair da stack shadcn/ui + Next.js + Vercel cria atrito real.

Uma forma típica de código de componente no estilo v0

<Card className={cn("flex flex-col",
  plan.recommended && "border-primary shadow-lg scale-105"
)}>

A abordagem do arXiv — uma representação intermediária estruturada

A abordagem SALT-NLP / Stanford insere uma representação intermediária estruturada entre a linguagem natural e o código de UI, em dois níveis: um fluxo de interação de alto nível (um grafo direcionado de caminhos do usuário e estágios de tarefa) e máquinas de estado finitas de baixo nível (os estados e respostas a eventos de cada componente). A saída final ainda é HTML, CSS e JavaScript — a representação é um trilho, não o destino.

Gen-UI-Lang — definindo uma camada de intenção de UI

O Gen-UI-Lang projeta uma DSL dedicada para que o LLM produza apenas descrições estruturadas de nós. A estrutura de nós é explícita, rasa e consistente — exatamente o que os LLMs geram de forma confiável. Em comparação com gerar HTML diretamente, ele relata uma redução de 65,3% no uso de tokens enquanto melhora a estabilidade, e pode renderizar para HTML, React JSX ou Gradio a partir da mesma descrição.

Uma descrição de intenção de UI do Gen-UI-Lang

genui(
  row(
    text("Sales Overview"),
    btn("Load", on_load=lambda: get_graph(2001, 2002))
  ),
  chart(type="line", data="sales_q4"),
)

05 · Nossa escolha

Parar na camada de semântica de produto

As três abordagens empurram o LLM para cima, para longe da camada de renderização. Elas só diferem em onde param. Escolhemos parar mais alto do que qualquer uma delas: na camada de semântica de produto.

O LLM não produz nós genéricos de UI como row ou btn. Ele produz conceitos de produto — "este é um cartão de resumo de tarefas, alta densidade de informação, originado do calendário de hoje." Qual componente renderizar, e como fazer o layout, é decidido inteiramente pela biblioteca de componentes — não pelo LLM.

01A lição direta do nosso caso de falha

Assim que afrouxamos a liberdade de geração do LLM, o resultado visual piorou. Quanto mais perto o LLM chega da camada de renderização, maior se torna o custo da sua aleatoriedade.

02A analogia com motores de renderização de navegadores

Navegadores não deixam o JavaScript da página controlar pixels diretamente. Eles aceitam uma descrição de DOM controlada, e o motor decide os pixels. Um motor GenUI deveria funcionar da mesma forma.

03A confiabilidade das saídas estruturadas de LLM

A OpenAI lançou os Structured Outputs em 2024 especificamente para combater o desvio de formato. Quanto mais perto a saída está da camada de renderização, maior o custo dos erros de formatação.

04A necessidade de longo prazo de uma biblioteca de componentes substituível

Pare na camada de semântica de produto e a biblioteca de componentes se torna um backend de renderização plugável — troque o design system amanhã sem tocar na camada semântica.

06 · Uma direção não verificada

Geração em duas rodadas

Ao depurar o componente complexo GenUIPager, descobrimos que uma única passada do LLM tinha dificuldade para otimizar a qualidade do conteúdo e a qualidade do layout ao mesmo tempo. Isso nos levou a uma arquitetura de duas rodadas — como hipótese.

Hipótese de geração em duas rodadas

First-round LLM:  content orchestration + page-structure decisions
                  (product semantics layer)
      ↓
Second-round LLM / component library:  concrete rendering decisions

A motivação é razoável: orquestração de conteúdo e renderização são duas tarefas cognitivas diferentes, e forçá-las em uma única passada pode fazer com que interfiram uma na outra.

Mas temos que ser honestos: isso é apenas uma hipótese, e não a validamos completamente.

Ela está aqui porque aponta para uma direção que vale explorar — não porque seja uma conclusão estabelecida.

07 · O mapa

Um mapa de trade-offs das escolhas de granularidade

Nenhuma escolha de granularidade é universalmente correta. Ela depende da tolerância do produto à inconsistência visual, do ciclo de vida esperado da biblioteca de componentes e de quão estruturado é o conteúdo gerado.

Abordagem	Até onde o LLM produz	Como a consistência é garantida	Biblioteca substituível?	Cenários adequados
Vercel v0	Camada de código do componente	Tokens semânticos do shadcn/ui	Não, fortemente acoplada	Prototipagem rápida dentro do ecossistema Vercel
Gen-UI-Lang	Camada de intenção de UI genérica	Renderizador multi-alvo	Sim, agnóstico de framework	Prototipagem entre frameworks, fluxos com foco em eficiência
Abordagem do arXiv	HTML / CSS / JS	Representação intermediária estruturada como trilhos	Depende	Cenários com alta complexidade de interação
AirJelly	Camada de semântica de produto	A biblioteca de componentes controla totalmente a renderização	Sim, plugável	Aplicações com altos requisitos de consistência da UI de produto

Se o produto tem baixa tolerância à inconsistência visual, a granularidade deve ser mais alta, mais próxima da semântica de produto. Se a biblioteca de componentes provavelmente vai evoluir ou ser substituída, mais alta ainda. E se o conteúdo gerado é altamente estruturado, é mais adequado descrevê-lo semanticamente em um nível mais alto.

Fontes

Fontes e leitura adicional

Generative Interfaces for Language Models (SALT-NLP / Stanford) — repositório oficial de código
Gen-UI-Lang — arXiv · repositório no GitHub · SSRN
Vercel v0 — Vercel Docs · Vercel Blog · docs de design systems do v0
shadcn/ui — site oficial

Encerramento

A granularidade é a decisão central de design em GenUI.

O maior aprendizado não é que encontramos a resposta certa. É que esclarecemos a pergunta: GenUI não se trata de deixar o LLM desenhar a interface. Trata-se de projetar uma divisão clara de responsabilidades entre o LLM e o sistema de renderização.

A escolha da granularidade decide onde essa linha é traçada — e onde a linha é traçada decide a manutenibilidade do sistema, a estabilidade visual e a capacidade de evoluir a longo prazo.

Em outubro de 2025, o Design Tokens Community Group do W3C publicou a especificação estável Design Tokens 2025.10 — um sinal de que separar a semântica do visual está se tornando um padrão de engenharia. O problema de granularidade no GenUI é essa mesma tendência aparecendo dentro de interfaces geradas por IA.

Ainda estamos no caminho. Se você está explorando algo semelhante, adoraria conversar.

Mais do time AirJelly →