Generative UI: o modelo decide a resposta; o produto decide os limites

Uma interface generativa não começa quando um modelo produz HTML. Ela começa antes: quando decidimos que parte da experiência pode mudar conforme a intenção de quem usa o produto e que parte precisa continuar sob controle explícito da aplicação.

Essa distinção parece sutil, mas separa uma demonstração visual de uma arquitetura que pode sobreviver a produção. Um chat pode responder “encontrei três restaurantes”. Uma interface pode mostrar os três no mapa, explicar os filtros aplicados, indicar quais estão abertos, oferecer rotas e permitir que a pessoa refine a busca sem recomeçar a conversa. O salto não é cosmético. Ele muda como dados, regras, componentes e estados circulam pelo sistema.

O artigo Generative UI, publicado pela Boda, organiza bem esse espaço: a IA pode reduzir a “parede de texto” das respostas e transformar intenção em elementos de interface temporários. Mas há mais em jogo do que trocar texto por cards. A pergunta prática é: quanto de liberdade o modelo recebe para decidir a interface?

Generative UI é uma decisão de fronteira

Em produtos tradicionais, a maior parte da UI é decidida em tempo de desenvolvimento. A equipe define telas, fluxos, componentes, estados de erro e regras de navegação. A IA pode entrar como uma busca mais tolerante, uma camada de recomendação ou um assistente dentro de uma tela já conhecida.

Com Generative UI, a entrada passa a ser frequentemente aberta: uma frase, um objetivo, uma solicitação incompleta. “Monte um roteiro para o fim de semana.” “Compare os planos que cabem no meu orçamento.” “Mostre o que mudou neste incidente.” A aplicação precisa traduzir essa intenção em algo que seja útil de olhar e de operar.

Isso cria um problema de engenharia. A mesma abertura que torna a experiência flexível pode produzir uma interface inconsistente, inacessível, difícil de testar ou, no pior caso, exposta à execução de código arbitrário. Por isso, a questão não é se a IA consegue gerar uma tela. É quem continua tendo autoridade sobre:

• quais dados podem ser consultados e exibidos;
• quais ações uma pessoa pode executar a partir daquela tela;
• quais componentes são permitidos;
• como entradas e saídas são validadas;
• o que acontece quando o modelo erra, demora ou não sabe responder.

Uma arquitetura de Generative UI madura não entrega essas decisões ao modelo. Ela dá ao modelo uma área de decisão clara e constrói contratos ao redor dela.

Os três graus de liberdade

Uma classificação útil separa três abordagens: controlada, declarativa e aberta. Elas não são rivais obrigatórias. Podem coexistir no mesmo produto. A diferença é o formato que atravessa a fronteira entre o modelo e a interface.

1. UI controlada: o modelo pede, a aplicação monta

Esse é o caminho mais direto para a maioria dos times. A pessoa descreve o que precisa em linguagem natural; o modelo interpreta o pedido e escolhe argumentos para ferramentas tipadas; a aplicação executa as regras de domínio; o front-end renderiza componentes que já existem.

Imagine uma busca por lugares. O modelo não precisa gerar um mapa, uma lista ou um botão. Ele pode chamar uma ferramenta como recommendPlaces com filtros estruturados: localização, orçamento, horário, categoria e preferência. A ferramenta consulta fontes confiáveis, aplica restrições determinísticas e devolve um resultado validado. O front-end decide se usa cards, mapa, estado vazio ou lista de comparação.

O ganho vem de aceitar uma entrada aberta sem abrir mão do design system. A IA interpreta a intenção; o produto preserva o repertório visual, os critérios de acessibilidade e o comportamento já testado.

Essa abordagem costuma ser a melhor primeira entrega porque mantém o modelo longe de decisões que não precisam ser generativas. Ela também facilita observabilidade: é possível registrar a intenção interpretada, os argumentos escolhidos, a ferramenta chamada, os filtros realmente aplicados e o componente renderizado.

2. UI declarativa: o modelo compõe, o catálogo garante

Há casos em que escolher entre componentes prontos não basta. Um planejador de viagem, por exemplo, pode precisar montar uma introdução, uma previsão do tempo, uma estimativa de voo, uma agenda por dia e uma lista de itens. A combinação e a ordem podem variar com o objetivo da pessoa.

Na abordagem declarativa, o modelo não produz código executável. Ele produz uma descrição estruturada da interface: uma árvore de componentes permitidos, suas propriedades e suas relações. O cliente interpreta essa descrição por meio de um catálogo. Cada item do catálogo possui um schema que define o que aceita e um renderer que a equipe controla.

É aqui que a palavra contrato ganha importância. O catálogo informa ao modelo o que existe; os schemas recusam estruturas inválidas; os renderers garantem que o resultado final seja feito com componentes conhecidos. A interface pode variar bastante, mas não vira um campo aberto para qualquer HTML, CSS ou JavaScript.

O texto da Boda usa uma separação que ajuda a evitar confusão: há o transporte dos eventos entre servidor e cliente e há a forma como a interface é descrita. Protocolos de eventos, como AG-UI, cuidam de sinais de execução, texto, ferramentas, estado e atividades. Especificações de interface, como A2UI, descrevem os componentes e a composição. São camadas diferentes e vale mantê-las diferentes no desenho do sistema.

A vantagem é a flexibilidade com portabilidade. O custo é real: é preciso manter schemas, catálogo, renderers, política de uso, versão de componentes e bons testes. A flexibilidade não desaparece; ela é deslocada para um conjunto de regras que a equipe consegue revisar.

3. UI aberta: o modelo gera código, o sandbox limita o dano

A terceira opção deixa o modelo emitir código de interface: HTML, CSS e JavaScript. Ela é sedutora porque parece eliminar o trabalho de definir catálogo e schemas. Se o pedido é novo, a IA cria algo novo.

O problema é que “algo novo” também pode ser código que lê o que não deveria, se comporta de forma inesperada, quebra em navegadores diferentes, ignora acessibilidade ou cria uma tela impossível de auditar. A execução de código arbitrário no navegador não é um detalhe de implementação.

Por isso, interfaces abertas tendem a usar isolamento, frequentemente em iframes com sandbox. Mesmo com isolamento, continuam existindo decisões sobre permissões, comunicação com o host, cache, latência, limite de recursos, registro de versões e reversão. A ausência de um catálogo não remove a necessidade de governança; ela apenas torna essa governança mais cara.

Essa abordagem pode fazer sentido para widgets efêmeros, protótipos internos, superfícies descartáveis ou tarefas muito específicas que não justificam um catálogo completo. Para fluxos centrais, transacionais ou que manipulam dados sensíveis, ela pede cuidado redobrado.

Não escolha uma única abordagem para o produto inteiro

O cenário mais plausível não é um aplicativo 100% controlado, declarativo ou aberto. É uma composição.

• Controlado para os fluxos que precisam de previsibilidade: pagamentos, permissões, ações destrutivas, dados regulados e tarefas repetidas.
• Declarativo para experiências em que o arranjo da informação muda conforme a intenção, mas os blocos de construção continuam sendo do produto.
• Aberto e isolado para uma necessidade temporária, específica ou experimental em que o custo de criar um componente dedicado ainda não se justifica.

O ponto não é escolher a categoria mais sofisticada. É usar o menor grau de liberdade que resolve o problema de experiência. Dar liberdade demais ao modelo cria uma nova superfície de falha. Dar liberdade de menos pode reduzir a IA a um campo de busca caro. O trabalho de arquitetura está em encontrar o meio-termo que vale a pena.

Um roteiro de adoção que evita atalhos frágeis

Para quem quer experimentar Generative UI sem reconstruir o produto, eu seguiria uma sequência simples:

1. Escolha uma intenção recorrente. Comece onde as pessoas já escrevem consultas difíceis de expressar em filtros: busca, planejamento, comparação, suporte operacional ou exploração de dados.
2. Modele ferramentas antes da interface. A primeira camada de confiança está em ferramentas com entradas e saídas tipadas, autorização e regras de domínio fora do prompt.
3. Reutilize componentes existentes. Faça o modelo escolher dados e variações, não recriar o design system. Meça se a interpretação melhorou a tarefa.
4. Registre a decisão inteira. Intenção, chamada de ferramenta, resultado validado, componente mostrado e feedback da pessoa formam uma trilha melhor para depuração do que apenas guardar o texto do chat.
5. Crie um catálogo quando a composição se repetir. Quando diferentes intenções começarem a pedir os mesmos blocos em arranjos variados, vale investir na camada declarativa.
6. Isole o que for realmente aberto. Se gerar código for inevitável, trate a execução como conteúdo não confiável desde o primeiro dia.

O modelo sugere; o produto responde por isso

Generative UI desloca parte da autoria da interface para o tempo de execução. Isso pode tornar um produto mais útil porque a tela passa a se adaptar ao objetivo, e não apenas ao menu disponível. Mas adaptação não dispensa responsabilidade.

O modelo pode priorizar informação, compor blocos e explicar uma decisão. A aplicação continua responsável por acesso a dados, efeitos no mundo real, transições de estado, validação, acessibilidade, telemetria e fallback. Essa divisão não diminui a IA. Ela é o que permite usá-la sem transformar cada nova interface em uma aposta.

Em vez de perguntar “como fazer a IA gerar toda a tela?”, talvez a pergunta melhor seja: qual interface esta intenção precisa, e qual contrato impede que a flexibilidade vire risco?

---

Fonte e leitura recomendada: Generative UI — Boda. O artigo discute a redução da “parede de texto”, as categorias controlada, declarativa e aberta, e exemplos de composição com especificações e componentes.