Não é confiável até ser validado.
A camada de validação é onde o aplicativo transforma a saída do modelo probabilístico em algo determinístico o suficiente para ser renderizado. Quer uma equipe use JSON Schema, Zod, Valibot ou outra biblioteca de validação, o aplicativo deve receber a resposta do modelo como dados desconhecidos e validá-la antes que algo chegue à tela. Essa etapa de validação deve rejeitar tipos de componentes desconhecidos, adereços malformados, ações não suportadas e qualquer estrutura que o aplicativo não compreenda explicitamente. Somente depois que a resposta ultrapassar esse limite ela deverá ser renderizada por meio do registro do componente.
Com uma biblioteca de esquemas, o limite de validação pode ser assim:
const CostSummarySchema = z.object({
type: z.literal('cost-summary'),
props: z.object({
period: z.enum(('current-week', 'current-month')),
comparisonPeriod: z.enum(('previous-week', 'previous-month'))
})
});
const AnomalyListSchema = z.object({
type: z.literal('anomaly-list'),
props: z.object({
severity: z.enum(('medium', 'high'))
})
});
const UIBlockSchema = z.discriminatedUnion('type', (
CostSummarySchema,
AnomalyListSchema
));
function parseUIResponse(response: unknown): UIBlock() {
const result = z.array(UIBlockSchema).safeParse(response);
if (!result.success) {
return ();
}
return result.data;
}
Em uma aplicação real, o esquema provavelmente cobriria regras de layout, limites de componentes, aninhamento permitido, referências de ação e controle de versão. A questão não é a biblioteca específica. O ponto é o limite.
O modelo não decide se sua saída é segura. O aplicativo faz.
Um caminho alternativo também é essencial. Se a validação falhar, a aplicação não deverá tentar improvisar. Deve mostrar um substituto seguro, pedir ao usuário para reformular a frase ou retornar uma resposta de texto convencional. Interfaces orientadas por IA precisam de falhas normais. Uma descrição de UI malformada nunca deve se tornar uma tela quebrada ou insegura.
Separe a renderização das ações
O limite mais importante na UI generativa não é a renderização. É execução.
Uma interface dinâmica pode incluir botões, formulários, confirmações ou etapas de fluxo de trabalho. Esses controles podem solicitar operações reais: encerrar uma instância, redimensionar um banco de dados, abrir um ticket de suporte, aprovar uma implantação, atualizar uma política ou alterar configurações de conta.
O modelo não deve executar essas ações. Não deve decidir que uma operação é permitida simplesmente porque o usuário a solicitou. Em vez disso, a execução da ação deve fluir através de um registro de ação pertencente ao aplicativo.
Por exemplo, um modelo pode solicitar um componente de confirmação:
{
"type": "confirmation",
"props": {
"message": "Do you want to open a remediation task for the unused compute instances?",
"actionId": "create-remediation-task"
}
}
Mas a ação em si deve ser definida e executada pela aplicação:
type UIAction =
| {
type: 'create-remediation-task';
resourceIds: string();
}
| {
type: 'open-support-ticket';
category: 'billing' | 'performance' | 'security';
};
const actionRegistry = {
'create-remediation-task': createRemediationTask,
'open-support-ticket': openSupportTicket
};
async function executeAction(action: UIAction, user: CurrentUser) {
if (!isActionAllowed(action, user)) {
throw new Error('Action not allowed');
}
return actionRegistry(action.type)(action);
}
Antes de uma operação ser executada, o aplicativo precisa tomar decisões determinísticas que o modelo não deve controlar. A ação deve existir no registro do aplicativo, o usuário atual deve estar autorizado a executá-la, os recursos de destino devem pertencer a um contexto que o usuário possa acessar e a operação ainda deve ser válida no estado atual. Algumas ações podem exigir confirmação, auditoria, roteamento de aprovação ou uma verificação final de permissão no servidor antes de qualquer alteração.
Estas questões não podem ser delegadas ao modelo. Eles pertencem ao aplicativo e, em última análise, aos sistemas back-end que aplicam as regras de negócios.
O modelo pode ajudar a gerar o caminho. Não pode se tornar a autoridade.
Estado ainda pertence ao aplicativo
A UI generativa também cria um problema sutil de gerenciamento de estado.
Em uma aplicação tradicional, o front-end sabe onde reside o estado. Dados de cobrança, permissões de usuário, metadados de recursos, status de anomalia, tarefas de correção e progresso do fluxo de trabalho são carregados, armazenados em cache, invalidados e atualizados por meio de caminhos de aplicativos conhecidos.
Uma interface orientada por IA pode confundir essa fronteira. O modelo pode resumir o estado, inferir o estado, lembrar o contexto da conversa ou descrever uma tela com base em mensagens anteriores. Se as equipes não tomarem cuidado, a interface gerada se tornará um segundo sistema de estado oculto.
Isso é perigoso.
A interface do usuário pode indicar que uma instância de computação não está sendo usada, mesmo que seu status tenha sido alterado. Pode mostrar uma opção de correção baseada em dados de faturamento desatualizados. Pode produzir uma mensagem de confirmação que não corresponda mais ao fluxo de trabalho atual. Pode lembrar de algo da conversa que o próprio aplicativo não verificou.
O pedido deve permanecer sempre sob a autoridade do estado.
O modelo pode ajudar a decidir quais componentes exibir, mas esses componentes devem ler o estado real do aplicativo e de suas APIs. UM CostSummary O componente deve buscar ou receber dados de cobrança pelo mesmo caminho confiável que qualquer outra parte do produto. Uma ação de remediação deve atualizar o estado através do fluxo normal do aplicativo. Um componente de confirmação não deve se tornar a fonte da verdade sobre se uma operação é possível.
A UI generativa deve ser uma projeção do estado do aplicativo, não o proprietário dele.
Esta distinção torna-se ainda mais importante em aplicações de agente, onde as interfaces podem mudar ao longo de vários turnos de conversação. Um usuário pode fazer uma pergunta, inspecionar um resultado, solicitar uma ação, mudar de ideia e retornar mais tarde. A aplicação precisa de um modelo confiável para o que aconteceu, o que está pendente, o que falhou e o que ainda requer aprovação humana.
Isso não pode residir apenas na janela de contexto do modelo.
Design para composição controlada
O futuro da UI generativa não é a geração arbitrária de código em tempo de execução. É uma composição controlada.
O modelo deve ser capaz de reunir experiências a partir de capacidades confiáveis: componentes, layouts, ações, regras de validação e transições de estado que o aplicativo expõe intencionalmente.
Isso dá aos desenvolvedores o melhor dos dois mundos.
A interface pode se adaptar ao objetivo do usuário, mas o sistema permanece testável. O modelo pode escolher os blocos de UI corretos, mas o sistema de design permanece intacto. O usuário pode passar por fluxos de trabalho dinâmicos, mas as permissões e regras de negócios permanecem determinísticas. O aplicativo pode parecer inteligente sem se tornar imprevisível.
Este também é um modelo mental melhor para equipes de front-end. A UI generativa não substitui a arquitetura front-end. Aumenta a necessidade de arquitetura front-end.
As equipes ainda precisam de sistemas de componentes. Eles ainda precisam de validação em tempo de execução. Eles ainda precisam de propriedade estatal. Eles ainda precisam de padrões de acessibilidade. Eles ainda precisam de limites de ação. Eles ainda precisam de autorização do servidor. A IA não elimina essas preocupações. Isso torna os limites fracos mais fáceis de expor.
Neste modelo, o usuário expressa a intenção e o modelo responde com uma intenção de UI estruturada. O aplicativo valida essa resposta, renderiza-a por meio de um registro de componente e roteia qualquer comportamento solicitado por meio de um registro de ação. O estado do aplicativo continua sendo a fonte da verdade, enquanto o servidor permanece responsável pela autorização final.
Esse é o limite que os sistemas de produção precisam.
A IA pode ajudar os desenvolvedores a gerar recursos completos durante o desenvolvimento. Esse código pode e deve passar por revisão, teste e entrega normal. Mas quando a IA participa de uma aplicação em execução, o contrato de tempo de execução precisa ser muito mais restrito. O modelo ativo deve descrever o que a interface do usuário deve expressar, e não gerar código não verificado que o produto executa.
A melhor abordagem é dar à IA um sistema de componentes.
Deixe o modelo compor. Deixe o aplicativo controlar. Deixe a experiência do usuário se tornar mais dinâmica sem sacrificar a arquitetura que torna o software confiável.
