Sem gerar texto, como o Jev opera um navegador e monta interfaces? Uma análise de Browser Use e json-render

Ao criar um sistema de IA que opera um navegador, o caminho mais intuitivo costuma ser entregar uma captura de tela ou o DOM a um modelo grande de uso geral, pedir que ele analise a página e planeje o próximo passo e, em seguida, faça com que gere uma posição de clique, um seletor ou uma chamada de ferramenta.

A construção de interfaces costuma seguir a mesma lógica. Depois que o usuário descreve o que deseja, o modelo gera diretamente JSON, JSX ou código de front-end, e o sistema tenta analisar, validar e renderizar o resultado.

O Jev Ultrafast do Browser Use e o experimento do Jev no json-render seguem outro caminho:

Primeiro, o código limita o que o modelo pode fazer a um conjunto finito; o Jev apenas escolhe dentro desse conjunto.

No Browser Use, esse conjunto é formado pelas ações executáveis e pelos elementos interativos da página atual. No json-render, ele é formado por componentes, configurações de propriedades, vínculos de dados e posições de layout preparados antecipadamente pela aplicação.

O Jev não precisa escrever um plano completo de operação nem gerar uma árvore inteira de UI em JSON. Ele responde apenas a perguntas como:

• O próximo passo deve ser clicar, inserir texto, rolar ou esperar?
• Em qual elemento da página atual deve atuar?
• Quais componentes devem aparecer na interface?
• Em qual contêiner pai, slot e ordem um componente deve ser colocado?

Esses dois exemplos não mostram que “um modelo que não gera texto consegue fazer tudo”. Eles mostram uma arquitetura de software diferente: transformar uma tarefa de geração aberta em uma sequência de decisões restritas e verificáveis.

O que o Jev realmente faz aqui

O Jev é um modelo System One lançado pela TypeSafe AI. Ele recebe um state e um conjunto de perguntas tipadas definidas pelo desenvolvedor e retorna resultados estruturados, como Choice, Score ou Noul, em vez de um texto longo destinado à leitura humana.

É possível entendê-lo como uma função de decisão com saídas probabilísticas:

Estado atual
   ↓
O desenvolvedor cria um conjunto finito de candidatos
   ↓
O Jev escolhe, pontua ou avalia
   ↓
O código comum valida o resultado
   ↓
Uma ação é executada ou a interface é renderizada

Nesse fluxo:

• Choice: seleciona uma opção de um conjunto fornecido;
• Score: posiciona o resultado nos níveis ordenados definidos pelo desenvolvedor;
• Noul: retorna a probabilidade de uma determinada afirmação ser verdadeira.

O ponto principal não é o formato da resposta, mas a divisão de responsabilidades. O Jev não gera livremente textos de página, seletores de navegador, JavaScript nem JSON completo; o código continua controlando estado, fluxo, permissões e execução. A TypeSafe descreve esse padrão como “estado não estruturado na entrada e decisões probabilísticas tipadas na saída”. (typesafe.ai)

A seguir, veremos como Browser Use e json-render aplicam esse padrão em sistemas reais.

---

Browser Use: primeiro transformar a página em um espaço finito de ações

O projeto jev-ultrafast do Browser Use demonstra um agente de navegador: o usuário fornece um objetivo em linguagem natural, o programa lê a página atual, o Jev escolhe a próxima ação e o código do navegador a executa.

A tarefa da demonstração pública é procurar no Google Flights um voo só de ida de Zürich para London. O projeto relata um tempo gravado de cerca de 7,1 segundos, incluindo chamadas de modelo, geração de texto, execução no navegador, carregamento da página e novas tentativas causadas por decisões desatualizadas. Ainda assim, trata-se de uma única tarefa em uma configuração específica do navegador, e não de um benchmark geral de confiabilidade em sites arbitrários. (github.com)

Etapa 1: o código lê a página; o Jev não apenas “olha uma captura de tela”

Em cada ciclo de decisão, o código do navegador primeiro lê os controles e textos visíveis na página e cria uma tabela numerada de elementos.

Uma versão simplificada poderia ser:

[1] button     Alterar tipo de passagem · Ida e volta
[2] combobox   De onde?                  · San Francisco
[3] combobox   Para onde?                · vazio
[4] textbox    Partida                   · vazio
[5] button     Pesquisar

A tabela contém o tipo de elemento, o nome, o valor atual e o índice. O programa também mantém o nó DOM real associado a cada índice para resolver novamente o alvo antes da execução.

Nesse exemplo, o Jev não observa diretamente uma captura e tenta adivinhar que um botão está nas coordenadas (482, 316). As capturas são usadas principalmente para demonstrações e inspeção humana. As decisões reais são conduzidas pelo estado estruturado extraído do DOM. O projeto também informa que os rótulos da página são adicionados durante a renderização da captura e não controlam o navegador. (github.com)

Essa diferença é importante.

Se um modelo gerar livremente coordenadas ou um CSS Selector, ele poderá retornar:

• um seletor que não existe na página;
• uma posição do elemento que já ficou desatualizada;
• um controle coberto ou impossível de clicar;
• um trecho de JavaScript capaz de executar comportamento arbitrário.

O Jev Ultrafast, em vez disso, limita o modelo aos índices de elementos que o programa acabou de observar.

Etapa 2: o Jev escolhe a ação e o elemento alvo

O projeto oferece o seguinte conjunto de ações:

CLICK
TYPE_TEXT
SELECT
SCROLL_UP
SCROLL_DOWN
WAIT
DONE
BLOCKED

Com base no estado atual da página, o programa oferece apenas as ações e os alvos compatíveis que realmente estão disponíveis naquele momento.

Por exemplo:

• se a página atual não tiver uma lista suspensa, nenhum alvo de SELECT é oferecido;
• se houver três campos de texto, os alvos de entrada ficam limitados a esses três elementos;
• se houver dez elementos clicáveis, os alvos de clique ficam limitados a esses dez elementos.

Uma decisão pode ser simplificada assim:

Pergunta 1: Qual deve ser a próxima ação?
Candidatos: CLICK / TYPE_TEXT / SELECT / WAIT / DONE

Pergunta 2: Se a ação for CLICK, em qual elemento clicar?
Candidatos: [1] / [5] / [8] / [11]

Pergunta 3: Se a ação for TYPE_TEXT, qual elemento deve receber o texto?
Candidatos: [2] / [3] / [4]

Essas perguntas podem ser avaliadas em paralelo dentro de uma única solicitação. Apenas o alvo compatível com a ação selecionada é executado. Se o Jev escolher CLICK, o programa lê somente click_target; ele não executa um alvo calculado antecipadamente para TYPE_TEXT.

O projeto chama isso de espaço de ações dinâmico e indexado. Ele reduz a quantidade de chamadas seriais ao modelo em cada etapa e evita pedir que o modelo gere livremente os parâmetros da operação. (github.com)

Etapa 3: chamar um modelo generativo apenas quando for necessário escrever texto

O Jev pode decidir que agora é preciso preencher o campo de origem, mas não gera o texto que deve ser digitado.

Quando a ação é TYPE_TEXT, o sistema chama um pequeno modelo de geração de texto para produzir o valor com base na tarefa atual e no campo alvo. Por exemplo:

{
  "text": "Zürich"
}

O resultado ainda precisa ser analisado como um objeto JSON muito pequeno antes de o navegador poder digitá-lo.

Portanto, o agente de navegador combina duas capacidades diferentes:

Tarefa	Componente responsável
Decidir se a próxima etapa é clicar, digitar, selecionar ou esperar	Jev
Escolher em qual elemento da página atuar	Jev
Gerar o texto em linguagem natural a ser inserido	Pequeno modelo generativo
Ler o DOM e o estado da página	Código do navegador
Clicar, digitar e selecionar	Código do navegador
Verificar se o objetivo foi realmente concluído	Código de validação independente

Isso também explica por que “o Jev opera o navegador” não significa que ele conclua sozinho toda a tarefa.

Uma descrição mais precisa é: o Jev é o seletor de ações dentro do loop do navegador.

Etapa 4: o código verifica a página novamente antes da execução

Depois que o modelo escolhe, o programa não clica imediatamente às cegas.

Antes de executar, o Jev Ultrafast verifica:

• se a página atual ainda é a mesma observada pelo modelo;
• se o nó DOM correspondente ainda existe;
• se o elemento está coberto por outro conteúdo;
• se a geometria atual ainda é válida;
• se o valor do formulário e o contexto próximo continuam iguais ao snapshot;
• se a entrada usada na solicitação de geração de texto mudou.

Se a página mudar antes da resposta do modelo, a decisão anterior pode ter se tornado inválida. O programa a trata como uma decisão desatualizada, em vez de continuar interagindo com um elemento antigo.

O projeto limita explicitamente o que a saída do modelo pode se tornar: ela não é convertida diretamente em um CSS Selector, coordenada de tela, comando de shell ou JavaScript executável. Todo alvo executado precisa ser resolvido novamente como um nó DOM real que havia sido observado. (github.com)

Esse código não é “inteligente”, mas determina se o sistema é confiável.

O resultado de sete segundos não pode ser atribuído apenas ao Jev

Em seis execuções alternadas, o projeto relata que as duas implementações concluíram a tarefa três vezes cada. O tempo mediano caiu de cerca de 9,450 segundos para 7,092 segundos, uma redução de aproximadamente 25%; as chamadas do protocolo do navegador caíram de 1.092 para 101. O autor também ressalta que foram apenas três execuções por implementação na mesma tarefa e configuração, e não um teste geral de confiabilidade. (github.com)

Assim, o ganho de desempenho não vem apenas da velocidade do modelo, mas da implementação do navegador como um todo:

• leitura dos controles visíveis em uma única passagem;
• redução das idas e vindas do protocolo do navegador;
• inclusão das perguntas de ação e alvo na mesma decisão;
• chamada do modelo generativo apenas quando a entrada de texto é necessária;
• espera apenas pelas mudanças de página necessárias após a execução;
• exclusão de texto irrelevante da página do contexto do modelo.

Portanto, seria incorreto concluir que apenas trocar um modelo pelo Jev faz qualquer agente de navegador concluir tarefas em sete segundos.

O MVP atual também não oferece suporte completo a shadow DOM, iframe, canvas, upload de arquivos, abas pop-up, rolagem aninhada e widgets arbitrários de teclado. Mesmo quando o modelo escolhe DONE, o sistema ainda exige uma verificação independente de que a tarefa realmente terminou. (github.com)

---

json-render: deixar o Jev escolher componentes em vez de gerar todo o JSON da página

O json-render trata de outro problema: como montar uma interface diretamente renderizável a partir de uma solicitação em linguagem natural.

Sistemas tradicionais de UI generativa costumam pedir ao modelo que produza diretamente:

• código React ou Vue;
• uma árvore completa de UI em JSON;
• CSS e propriedades de layout;
• lógica de tratamento de eventos;
• configuração de vínculos de dados.

Essa abordagem é flexível, mas também dá ao modelo um espaço de saída enorme. Ele pode escrever errado o nome de um componente, gerar uma propriedade inexistente, referenciar uma ação não registrada ou produzir um JSON impossível de analisar.

O experimento do Jev no json-render reformula o problema:

A aplicação primeiro prepara uma coleção de instâncias válidas de componentes, e o Jev apenas decide quais usar e como combiná-las.

Esse recurso ainda está marcado como experimental. experimental_composeSpec e experimental_createEvaluator não foram lançados como APIs estáveis; seus nomes e comportamentos podem mudar entre versões. A documentação recomenda fixar uma versão exata e acompanhar o changelog. (json-render.dev)

A aplicação fornece primeiro o catálogo de componentes e os candidatos

Suponha que o usuário peça:

Crie um painel de vendas com uma tabela de pedidos no topo, uma linha de métricas de receita, número de pedidos e novos clientes abaixo, e um gráfico de receita semanal no final.

A aplicação não entrega essa frase diretamente ao Jev para que ele escreva livremente o JSON da interface.

Em vez disso, ela fornece primeiro os candidatos:

Dashboard
OrdersTable
MetricRow
RevenueMetric
OrdersMetric
NewCustomersMetric
RevenueBarGraph

Cada candidato não é apenas um nome, mas uma instância de componente configurada pela aplicação. Ele pode incluir:

• tipo de componente;
• propriedades fixas;
• configuração de layout disponível;
• vínculos de estado;
• vínculos de dados;
• ações permitidas;
• uma descrição do candidato destinada ao modelo.

Por exemplo, um candidato de botão pode ser predefinido assim:

Componente: Button
Texto: Salvar
Ação: savePreferences
Argumentos: ler o estado atual de /name

O Jev pode decidir se inclui esse botão, mas não pode inventar uma ação não registrada, como deleteAllUsers.

A documentação do json-render enfatiza que a plataforma controla as capacidades disponíveis e o design system. O Jev só pode escolher entre componentes, configurações e vínculos de ações fornecidos pela aplicação; textos, dados ou componentes ausentes não são criados automaticamente pelo Jev. (json-render.dev)

Fase 1: escolher quais componentes a interface precisa

Ao criar uma nova interface, o primeiro lote de decisões trata de:

• qual candidato será o nó raiz;
• quais componentes devem ser selecionados;
• quantas instâncias de um componente reutilizável são necessárias;
• qual variante escolher quando há várias versões do mesmo recurso.

Por exemplo:

Componente raiz: Dashboard

Incluir:
- OrdersTable
- MetricRow
- RevenueMetric
- OrdersMetric
- NewCustomersMetric
- RevenueBarGraph

Depois dessas escolhas, o código comum monta imediatamente um Spec inicial, verifica as propriedades dos componentes e os argumentos das ações contra o schema do catálogo e transmite uma prévia que já pode ser renderizada.

Nesse momento, o layout ainda pode seguir a ordem do catálogo, mas o usuário já vê um resultado intermediário estruturalmente válido.

Isso é diferente de pedir que o modelo emita o JSON completo token por token: o Jev não escreve JSON serializado. O código monta o JSON a partir de escolhas restritas. (json-render.dev)

Fase 2: decidir relações pai-filho e ordem

Depois que os componentes são selecionados, um segundo lote de decisões trata do layout:

• a qual nó pai cada componente pertence;
• em qual slot nomeado do pai ele deve ficar;
• a ordem entre componentes irmãos.

A estrutura final pode ser:

Dashboard
├── OrdersTable
├── MetricRow
│   ├── RevenueMetric
│   ├── OrdersMetric
│   └── NewCustomersMetric
└── RevenueBarGraph

Em seguida, o código verifica:

• se existe exatamente uma raiz válida;
• se foi introduzido algum ciclo pai-filho;
• se a profundidade excede o limite;
• se o componente foi colocado em um slot válido;
• se cada candidato foi usado o número permitido de vezes;
• se todas as propriedades, vínculos e argumentos de ações passam na validação do schema.

Se o layout composto for inconsistente, o sistema mantém a prévia já validada, em vez de emitir uma árvore de UI quebrada.

Para estruturas simples que contêm apenas uma raiz ou apenas um filho em um único slot, talvez nem seja necessário executar a segunda avaliação de layout. (json-render.dev)

Editar uma interface também é escolher, não reescrever tudo

O json-render também pode editar um Spec existente, por exemplo:

• remover o botão Salvar;
• mover a tabela de pedidos para cima do gráfico;
• substituir um tipo de gráfico por outro candidato fornecido;
• alterar a ordem dos campos;
• substituir a configuração de um componente.

Essas edições geralmente seguem um protocolo sequencial:

1. Selecionar o elemento que precisa mudar.
2. Selecionar a nova receita de componente ou o destino.
3. Aplicar a alteração no código.
4. Validar novamente a árvore inteira.

IDs de componentes não alterados, vínculos de estado, dados e filhos compatíveis são preservados sempre que possível. O Spec de entrada não é mutado diretamente. (json-render.dev)

Selecionar um botão não significa que ele será executado automaticamente

O json-render separa claramente “compor a interface” de “executar uma ação de negócio”.

O Jev pode selecionar um botão vinculado a savePreferences, mas o composer não chama essa ação. A execução só ocorre depois que o usuário clica e é tratada pelo action handler da aplicação hospedeira.

A aplicação ainda precisa fornecer:

• verificação de permissões do usuário;
• validação dos argumentos;
• autorização no servidor;
• validação dos dados;
• idempotência e registro de auditoria;
• confirmação adicional para operações perigosas.

A documentação alerta especificamente que registrar uma ação no catálogo não a torna segura para receber argumentos arbitrários. O composer também não consegue validar o estado futuro em tempo de execução nem autorizar em nome da aplicação. (json-render.dev)

Estrutura válida não significa que a interface esteja necessariamente correta

O json-render pode garantir que a saída respeite sua estrutura e seu schema, mas não que a interface selecionada pelo Jev seja completa, coerente ou visualmente boa.

A documentação apresenta este exemplo:

Gere um painel com a tabela no topo

Esse pedido pode selecionar apenas uma tabela, porque não exige explicitamente métricas e gráfico.

Uma solicitação mais específica:

Crie um painel de vendas:
coloque a tabela de pedidos no topo;
abaixo, coloque uma linha de métricas de receita, pedidos e novos clientes;
por último, coloque o gráfico de receita semanal.

tem maior chance de selecionar todos os candidatos necessários e organizá-los na ordem esperada.

Isso expõe um limite importante: o Jev só decide dentro do espaço de candidatos; os desenvolvedores continuam responsáveis por tornar esse espaço completo e expressar a solicitação com clareza.

A API reutilizável descrita na documentação pública usa, por padrão, no máximo 32 avaliações, no máximo 32 elementos criados em um lote e profundidade máxima de 8. O Playground público restringe ainda mais: até 14 elementos por lote, 14 avaliações e profundidade 4. Quando os limites de chamadas, elementos ou profundidade são atingidos, o sistema pode retornar um Spec parcial, mas “o processo terminou” ainda não significa que o resultado esteja semanticamente correto. (json-render.dev)

---

Os dois exemplos, na prática, usam a mesma arquitetura

Colocados lado a lado, Browser Use e json-render resolvem problemas diferentes, mas têm estruturas quase idênticas.

Etapa	Browser Use	json-render
Objetivo do usuário	Pesquisar um voo, preencher um formulário, abrir uma página	Criar ou modificar uma interface
Estado lido pelo código	DOM visível, controles, textos e valores	Spec atual, candidatos de componentes, catálogo e estrutura da árvore
Espaço finito de candidatos	Clique, digitação, seleção, rolagem e elementos interativos	Instâncias de componentes, pais, slots e ordenação
Responsabilidade do Jev	Selecionar a ação e o alvo	Selecionar componentes, relações pai-filho e ordem
Responsabilidade do modelo generativo	Gerar texto apenas quando a entrada é necessária	No caminho do Jev, não há geração livre de UI; novos textos e dados precisam ser fornecidos antes ou gerados separadamente
Responsabilidade do código comum	Snapshots do DOM, verificação de atualidade, execução, espera e validação do resultado	Montagem do Spec, validação de schema, validação da árvore, renderização e autorização de ações
Principais modos de falha	Estado de página desatualizado, alvo ausente, controles não suportados	Candidatos ausentes, solicitações ambíguas, layout incompleto, escolhas ruins
Verificação final	Confirmar se o objetivo da tarefa foi realmente concluído	Confirmar se o Spec está completo, utilizável e de acordo com os requisitos do produto

Os dois seguem a mesma fórmula:

Transformar o ambiente em estado estruturado
        ↓
Transformar as ações disponíveis em um conjunto finito de candidatos
        ↓
Deixar o Jev escolher
        ↓
Deixar o código validar e executar
        ↓
Observar o resultado novamente

Em comparação com pedir que um modelo gere livremente a próxima etapa, essa abordagem abre mão de parte da flexibilidade em troca de limites de controle mais claros.

---

Por que um modelo que não gera texto ainda pode parecer “inteligente”

A inteligência não precisa ser expressa como artigo, código ou conversa.

Em muitos fluxos de software, o sistema precisa apenas de uma decisão:

• Qual botão deve ser clicado agora?
• Em qual região esse elemento deve ser colocado?
• A execução deve continuar?
• Qual configuração de componente corresponde melhor ao pedido do usuário?
• O resultado atual já cumpriu o objetivo?

Um LLM de uso geral pode gerar primeiro uma explicação e depois empacotar a resposta em JSON. Mas, se o código precisa apenas de uma opção, boa parte dessa geração intermediária pode não agregar valor.

Os experimentos Browser Use e json-render transferem mais do “processo de pensamento” para o design do sistema:

• o desenvolvedor define o estado;
• o desenvolvedor define o espaço de candidatos;
• o desenvolvedor define as regras de execução;
• o modelo preenche apenas as lacunas de decisão semântica que regras tradicionais não cobrem bem.

Essa arquitetura não elimina erros; ela muda a forma deles.

O Jev não retornará um componente ou ação fora do conjunto de candidatos, mas ainda pode:

• escolher o botão errado;
• escolher o componente errado;
• declarar a conclusão cedo demais;
• selecionar um layout pior entre várias opções razoáveis;
• omitir conteúdo necessário porque o pedido é ambíguo.

Segurança de tipos garante a interface, não a verdade. O relatório de pesquisa enviado também destaca que estrutura restrita não garante uma decisão de negócio correta; design das perguntas, modelagem do estado, limiares e validação independente continuam centrais em sistemas de produção.

---

Quais tarefas combinam com esse padrão

Browser Use e json-render sugerem um teste prático:

Se uma tarefa puder ser decomposta em “escolher entre um conjunto finito de candidatos”, pode valer a pena entregar esse nó de decisão ao Jev.

Tarefas que combinam relativamente bem incluem:

• seleção de ações em navegadores e aplicativos desktop;
• roteamento de ferramentas e habilidades de agentes;
• composição de interfaces a partir de um catálogo controlado de componentes;
• escolha entre layouts candidatos;
• classificação de e-mails, tickets de suporte e documentos;
• seleção de conteúdo relevante entre evidências candidatas;
• decisão de tentar novamente ou encaminhar para uma pessoa.

Tarefas que não devem ser entregues diretamente ao Jev incluem:

• escrever artigos longos ou respostas de atendimento;
• gerar textos novos que não existem no conjunto de candidatos;
• projetar livremente um sistema visual totalmente novo;
• escrever programas complexos;
• executar cálculos aritméticos ou de datas em várias etapas;
• inventar uma solução quando nenhuma ação candidata existe;
• tarefas que exigem raciocínio longo e planejamento aberto.

Produtos reais normalmente precisam combinar modelos diferentes:

Modelo de uso geral: gera objetivos, texto, código ou planos candidatos
Jev: avalia, filtra e roteia entre candidatos
Código comum: valida, executa, aplica fallback e registra

O pequeno modelo de texto do Browser Use é um exemplo direto dessa divisão: o Jev decide que um texto deve ser inserido; o modelo generativo decide qual texto inserir.

---

A verdadeira lição é a separação de responsabilidades, não os dois demos

A lição mais reutilizável de Browser Use e json-render não é que “o Jev consegue navegar na web” ou que “o Jev consegue gerar UI”.

Uma conclusão mais precisa é:

• Browser Use transforma a operação livre do navegador em seleção de ações sobre elementos DOM reais;
• json-render transforma a escrita livre de JSON de UI em seleção e ordenação sobre o catálogo de componentes da própria aplicação;
• o Jev fornece decisões semânticas;
• o código limita permissões, mantém estado, valida estrutura e executa resultados;
• quando é necessário texto aberto, um modelo generativo continua cuidando disso.

Essa arquitetura transforma a IA de único condutor do sistema em um nó de decisão dentro de um fluxo controlado por código.

Para equipes que realmente querem colocar IA em software de produção, isso pode ser mais importante do que a capacidade de um modelo gerar uma resposta completa de uma só vez. A confiabilidade de um sistema depende não apenas do que o modelo escolheu, mas também de:

• qual estado foi mostrado ao modelo;
• quais candidatos o desenvolvedor forneceu;
• quais ações o sistema permite;
• se resultados incorretos podem ser interceptados;
• se o sistema consegue decidir novamente depois de mudanças na página ou na interface;
• se a conclusão é verificada de forma independente.

Não gerar texto não significa que o Jev não consegue fazer nada.

Significa que a inteligência do modelo não se expressa principalmente como uma string, mas como um conjunto de escolhas que o software consegue consumir diretamente — e ainda precisa validar com cuidado.