A IA Pode Navegar na Web. Por Que Não Pode Tocar em um Telefone?

Sou o criador do Drengr, um servidor MCP que dá aos agentes de IA olhos e mãos em dispositivos móveis. Comecei este blog para compartilhar a engenharia por trás disso. Sem fingir ser um observador neutro escrevendo um artigo de opinião — eu construí isso, e estou aqui para falar sobre isso.

A lacuna que ninguém fala

Toda semana há um novo "Show HN" para testes de navegador com IA. Agentes Playwright, bots Puppeteer, extensões do Chrome que transformam o DOM em JSON para LLMs. O espaço de automação da web está transbordando de ferramentas nativas de IA.

Então alguém pergunta: "Como faço isso em um telefone?"

Silêncio.

A melhor resposta que a indústria tem é o Appium — uma ferramenta de 2013 que exige que você configure uma grade Selenium, escreva seletores XPath e mantenha localizadores de elementos frágeis que quebram toda vez que um designer move um botão. Ou Espresso/XCTest, que exigem que você incorpore o código de teste dentro do próprio aplicativo.

Nenhuma dessas é nativa de IA. Elas foram construídas para humanos escreverem scripts, não para LLMs raciocinarem sobre telas.

Por que o móvel é mais difícil que a web

A web tem uma API universal: o DOM. Cada navegador expõe a mesma árvore de elementos com os mesmos atributos. O Playwright lê o DOM, a IA decide o que clicar, pronto.

O móvel não tem isso. O Android tem uiautomator. O iOS tem seu próprio framework de acessibilidade. Eles retornam estruturas diferentes, atributos diferentes, sistemas de coordenadas diferentes. Fazendas de dispositivos em nuvem adicionam outra camada — agora você está se comunicando com um dispositivo via Appium WebDriver, que adiciona sua própria abstração por cima.

O resultado: cada ferramenta de teste móvel é específica da plataforma, pesada para configurar e hostil a agentes de IA que apenas querem saber "o que está na tela?" e "toque naquele botão."

O que eu construí em vez disso

Drengr é um único binário Rust que fica entre a IA e o dispositivo. Ele expõe exatamente 3 ferramentas sobre o Protocolo de Contexto do Modelo (MCP):

• drengr_look — informa à IA o que está na tela, seja como uma imagem anotada ou uma descrição de texto compacta (~300 tokens em vez de uma captura de tela de 200KB)
• drengr_do — executa uma ação (tocar, digitar, deslizar, pressionar longamente, rolar, iniciar aplicativo, etc.) e relata o que mudou
• drengr_query — responde perguntas sem tocar na tela (o aplicativo travou? quais chamadas HTTP aconteceram? qual é a atividade atual?)

O cliente de IA — Claude Desktop, Cursor, VS Code, o que for — é o cérebro. Ele decide a estratégia. Drengr é as mãos. Ele lida com a confusão da plataforma para que a IA nunca precise pensar sobre ADB vs simctl vs Appium.

A coisa que faz funcionar: relatórios de situação

Após cada ação, Drengr não diz apenas "ok, feito." Ele informa à IA o que mudou:

{
  "screen_changed": true,
  "new_elements": [12, 15],
  "disappeared_elements": [7],
  "activity_changed": true,
  "crash": false,
  "stuck": false
}

A IA lê isso e imediatamente sabe: a tela foi atualizada, dois novos elementos apareceram, um desapareceu, navegamos para algum lugar novo, e o aplicativo ainda está vivo. Não há necessidade de tirar outra captura de tela e fazer uma diferença visual.

Isso é o que as ferramentas de teste de navegador não precisam — o DOM lhe dá eventos de mudança de graça. No móvel, você precisa construir essa camada você mesmo. Eu passei meses nisso para que você não precise.

Um teste real se parece com isso

app: com.example.app
tasks:
  - name: login
    task: "Log in com user@test.com e senha123"
    timeout: 60s
  - name: checkout
    task: "Adicionar fones de ouvido ao carrinho e concluir compra"
    timeout: 90s

É isso. Sem seletores. Sem XPath. Sem IDs de elementos para manter. A IA lê a tela, decide o que fazer, e Drengr executa. Quando a interface do usuário muda, o YAML não quebra — porque não há nada frágil nele.

Execute com drengr test tests.yml e obtenha saída legível por humanos, JSON ou JUnit XML para seu pipeline CI.

Por que eu acho que essa lacuna existe

Os testes de navegador obtiveram ferramentas nativas de IA cedo porque o DOM é um formato aberto e amigável ao texto que os LLMs podem raciocinar diretamente. As interfaces móveis são visuais, proprietárias e bloqueadas por APIs específicas de plataforma que ninguém unificou.

O protocolo MCP muda isso. Ele dá aos agentes de IA uma maneira padrão de se conectar a ferramentas — e Drengr é a ferramenta que conecta o MCP a dispositivos móveis. Android, iOS, simuladores, fazendas em nuvem — uma interface, um binário, uma instalação:

npm install -g drengr

A web teve seu momento de teste com IA. A vez do móvel é agora.