O Solaris da Runway removeu a camada de código. Pergunte o que seu auditor compara.

A Runway rodou um estudo com 250 participantes em 30 exemplos de interação, coletando quase 7.500 julgamentos pareados. Cada julgamento comparou uma interface gerada pelo Solaris com a mesma interface produzida como código pelo Claude Opus 5, ambas partindo da mesma imagem e dos mesmos pedidos de interação. Para seguir a interação solicitada, o Solaris foi preferido em 61% das comparações contra 24% do resultado em código, com 13% avaliados como equivalentes. Para comportamento natural a margem cresceu: 71% contra 21%, com 6% equivalentes.

As duas linhas somam 98%. A Runway publica assim e deixa os dois pontos faltantes sem explicação. Estou reproduzindo como está impresso, em vez de arredondar para um número que a fonte nunca publicou.

Para quem responde por software, o dado decisivo está no que o Solaris deixa de produzir. Nas palavras da própria Runway, cada quadro é sintetizado enquanto você interage, permitindo que a interface responda continuamente. Faltam HTML, árvore de componentes, folha de estilo e repositório. A interface existe apenas enquanto está sendo observada.

Todo controle que você tem pressupõe um artefato

Percorra seu próprio pipeline de release e nomeie sobre o que cada etapa opera. Revisão de código lê um diff. Análise estática interpreta uma árvore sintática. Histórico de mudanças guarda commits. Builds reprodutíveis calculam hash das entradas e comparam saídas. Teste de acessibilidade consulta um DOM. Todas essas etapas recebem como entrada uma representação intermediária, situada entre o que alguém pretendeu e o que o usuário finalmente vê.

Geração direta para pixels apaga essa representação por decisão de projeto. Isso é uma escolha de produto assumida, e a Runway é transparente a respeito. A consequência é que o aparato de governança não degrada de forma elegante. Ele fica sem nada a que se prender. Um revisor fica sem como aprovar aquilo que nunca foi escrito, e um teste de regressão fica sem como asseverar sobre uma superfície sintetizada de novo a cada interação.

Argumentamos, em modelos de mundo como camada de governança, que um modelo do ambiente dá aos sistemas de controle algo sobre o que raciocinar. O Solaris roda a mesma classe de tecnologia na direção oposta. O modelo de mundo é o renderizador, e o renderizador descarta a ata.

Acessibilidade é a consequência que já está na lei

A Runway lista as próprias limitações: legibilidade do texto gerado, confiança e alucinação em contextos instrucionais, coerência ao longo de sessões extensas, e integração com acessibilidade e tecnologias assistivas. Três delas são problemas de qualidade que melhoram conforme os modelos melhoram. A quarta é estrutural.

Leitores de tela ignoram os pixels. Eles leem uma árvore de acessibilidade derivada do DOM: papéis, rótulos, ordem de foco, regiões vivas, relações entre um controle e o texto que o descreve. Os regimes de acessibilidade sob os quais nossos compradores operam, e as auditorias que esses regimes disparam, são expressos como asserções sobre essa árvore. Declarações de conformidade com WCAG são feitas sobre marcação. Scanners automáticos leem marcação. Tickets de remediação citam seletores.

Uma interface sintetizada quadro a quadro carece de árvore estável para receber asserção. Um botão que existe como pixels em um quadro era, em sentido estrutural, outro botão no quadro anterior. A Runway nomear integração com tecnologia assistiva como limitação em aberto é a versão honesta disso. É também, para um comprador regulado, a frase que encerra a conversa de compra.

Repare no que os resultados publicados cobrem. A Runway relata preferência para seguir a interação solicitada e para comportamento natural. Nenhuma das duas dimensões diz se alguém usando tecnologia assistiva conseguiria operar a interface. Uma preferência de 71% em comportamento natural e uma limitação de acessibilidade em aberto convivem sem contradição. São respostas a perguntas diferentes, e só uma delas tem um responsável por conformidade anexado.

Onde isso chega primeiro

Duvido que superfícies reguladas em produção migrem para geração quadro a quadro. Espero que a pressão venha de uma direção que a maioria dos programas de governança ignora: o protótipo que deixa de ser protótipo.

A Runway afirma que interações deixam de parecer interativas por volta de meio segundo de atraso, e a demonstração responde rápido o bastante para que as pessoas a conduzam em vez de assistir. Um designer gera uma interface funcional, um stakeholder a conduz, e ela se comporta melhor que a versão em código na maioria das comparações lado a lado. O que acontece depois é a parte que eu nunca vi escrita em um padrão de release. Alguém pergunta se dá para simplesmente colocar no ar.

O argumento sobre governança de output vale aqui com mais força do que em qualquer cenário de código gerado, porque código gerado ao menos aterrissa em um repositório onde os controles existentes conseguem interceptá-lo. Quando a saída são quadros, o pouso deixa de existir.

Esta é também a fronteira entre dois problemas que costumam ser discutidos como um só. Agentes escrevendo o design system é um problema de revisão: o artefato existe, e a pergunta é quem o lê e contra qual padrão. Geração quadro a quadro escapa dessa categoria. Ela remove o objeto sob revisão.

Faça isto agora

Escreva uma frase no seu padrão de engenharia que nomeie explicitamente a exigência de artefato. Algo próximo de: qualquer interface que chegue a um usuário de produção precisa ter uma representação durável, versionada e inspecionável, que a renderize.

Essa frase fica inerte no dia em que você a escreve. Quase toda ferramenta que você usa já a cumpre. O valor dela é já estar no lugar quando alguém trouxer uma demo funcional construída sem representação e fizer uma pergunta razoável sobre publicá-la. Nesse momento a conversa passa a ser sobre um padrão existente, em vez de uma objeção improvisada de quem por acaso se preocupa com auditoria.

Depois rode a segunda checagem. Pergunte a quem responde por conformidade de acessibilidade na sua organização o que essa pessoa compara quando certifica um release. Peça a resposta concreta: um snapshot de DOM, um relatório de scanner, uma passagem manual com leitor de tela, uma declaração assinada referenciando marcação específica. O que ela nomear é o artefato que seu pipeline não pode se dar ao luxo de perder. Se ninguém souber nomear nenhum, a interface entra bem depois na sua fila de problemas.

A Runway construiu algo que usuários preferem por margem larga e publicou a própria lista do que ainda não resolveu. Isso é mais transparência do que a maioria dos fornecedores oferece. O trabalho do nosso lado é saber quais dos nossos controles o desenho descarta por premissa, antes que um número de preferência desse tamanho faça a pergunta parecer retórica.

Fontes

Runway. “Introducing Solaris.” Agosto de 2026.

A Victorino ajuda organizações de engenharia a definir quais artefatos um pipeline de release governado exige, antes que uma ferramenta de geração remova um deles: contato@victorino.com.br | www.victorino.com.br