Outro dia eu perguntei pra um líder técnico de uma software house de 30 devs: “Qual a última etapa antes de vocês mandarem a release pro cliente?”
Ele respondeu: “O Marcos abre o app, clica em tudo, e avisa no Slack se tá ok.”
Marcos. Uma pessoa. Clicando. Em tudo.
Se Marcos tá de férias, a release atrasa. Se Marcos tá com pressa, ele pula tela. Se Marcos saiu da empresa — e ele saiu dois meses depois dessa conversa — ninguém sabe o que ele testava.
Na minha experiência com 300+ software houses, esse é o padrão: a última barreira entre o código e o cliente é um humano com mouse e boa vontade. Não é Playwright, não é Selenium, não é teste E2E automatizado. É um dev senior que “conhece o sistema” e clica nos lugares certos.
E o motivo é simples: apps nativos não têm Playwright. iOS Simulator não tem Selenium. Aquele painel desktop em Electron que vocês vendem pra 200 clientes não tem test harness de UI. O browser tem ferramentas maduras de automação visual. O resto do mundo não tem.
Até agora.
O Que É Computer Use no CLI
Na semana de 30 de março a 3 de abril de 2026, a Anthropic habilitou Computer Use no CLI do Claude Code — a mesma capacidade que já existia no Desktop app, agora acessível direto do terminal.
O conceito é direto: Claude abre apps no seu Mac, clica em botões, digita texto, tira screenshots, e vê o que está na tela. Tudo isso dentro da mesma conversa onde ele acabou de escrever o código.
Funciona assim: você pede pro Claude compilar um app Swift, lançar no simulador, clicar em cada aba, e tirar screenshot de qualquer erro. Ele faz. Na mesma sessão. Sem você tocar no mouse.
Isso não é teoria. A documentação oficial descreve o fluxo completo:
“Claude can compile a Swift app, launch it, click through every button, and screenshot the result, all in the same conversation where it wrote the code.”
O que antes era um ciclo de 3 etapas — código no terminal, teste manual na GUI, volta pro terminal — vira um ciclo de 1 etapa. O Claude faz as três.
Como Funciona na Prática
Ativação
Computer Use é um MCP server built-in chamado computer-use. Vem desabilitado por padrão. Pra ativar:
- Na sessão interativa do Claude Code, rode
/mcp - Encontre
computer-usena lista - Selecione Enable
A configuração persiste por projeto. Você faz uma vez.
Na primeira vez que o Claude tenta usar seu computador, o macOS pede duas permissões:
- Accessibility: pra Claude clicar, digitar e rolar
- Screen Recording: pra Claude ver o que está na tela
Aprovação de Apps por Sessão
Ativar o server não dá acesso a todos os apps. Cada sessão, na primeira vez que o Claude precisa de um app específico, aparece um prompt no terminal mostrando:
- Quais apps o Claude quer controlar
- Permissões extras solicitadas (clipboard, por exemplo)
- Quantos outros apps serão escondidos enquanto Claude trabalha
Apps com alcance amplo mostram warnings extras:
| Warning | Apps |
|---|---|
| Equivalente a acesso shell | Terminal, iTerm, VS Code, Warp |
| Pode ler/escrever qualquer arquivo | Finder |
| Pode mudar settings do sistema | System Settings |
Não estão bloqueados. O warning é pra você decidir se a tarefa justifica.
Hierarquia de Ferramentas
O Claude Code não pula direto pro computer use. Ele tenta a ferramenta mais precisa primeiro:
- MCP server dedicado → usa o MCP
- Comando shell → usa Bash
- Tarefa no browser com Claude in Chrome → usa Chrome
- Nada mais funciona → usa Computer Use
Computer use é o fallback pra tudo que nada mais alcança: apps nativos, simuladores, ferramentas sem API.
Segurança
Diferente do Bash tool sandboxed, computer use roda no seu desktop real. As proteções built-in:
- Aprovação por app, por sessão: Claude só controla o que você aprovou
- Terminal excluído de screenshots: Claude nunca vê sua própria janela — prompt injection via tela não funciona
- Esc global: aperta Esc de qualquer lugar e Claude para imediatamente
- Lock machine-wide: só 1 sessão usa computer use por vez
- Sentinel warnings: apps com acesso shell/filesystem/system são flagados antes de aprovar
Por Que Isso Importa Para Sua Software House
Vou ser direto: o mercado global de QA e testing é de US$ 57,73 bilhões em 2026. 48% disso ainda é teste manual. Quase metade do dinheiro gasto em testing no mundo vai pra gente clicando em tela.
E não é por falta de vontade de automatizar. É porque as ferramentas de automação visual pararam no browser. Se seu produto é um SaaS web, você tem Playwright, Cypress, Selenium, Puppeteer. Se seu produto é um app iOS, um painel desktop, um menu bar app — você tem XCTest (se for iOS puro) e muita reza.
Os números contam a história:
- Bug encontrado em produção custa 30-100x mais do que se pego em design — um bug que levaria 1 hora pra corrigir em requirements leva 30-100 horas depois do release
- Ciclos de testing tradicionais levam dias — com agentic AI testing, empresas estão colapsando de dias pra ~2 horas
- 79% das conversas no Claude Code são automação (o AI fazendo direto) vs 21% augmentação (o AI ajudando o humano) — e tarefas de UI estão entre os usos mais comuns
O Case Que Prova o Ponto
Christopher Meiklejohn, PhD em Software Engineering pela Carnegie Mellon, publicou um case study detalhado sobre usar Claude pra fazer QA do Zabriskie, um app mobile com 25 telas em 3 plataformas (web, iOS, Android).
Android: 25 telas testadas em 90 segundos. Zero issues críticos, 2 notas cosméticas. Bug filing automático no fórum de produção com títulos formatados tipo [Android QA] Shows Hub: RSVP button overlaps venue text. Agendado pra rodar diário às 8:47 da manhã.
iOS: Mais complicado. A accuracy inicial de navegação por coordenadas ficou em 42-57% — traduzir coordenadas entre macOS window, device logical points e scaling modes é um pesadelo. A solução foi usar ios-simulator-mcp com ui_describe_point pra medir posições reais dos botões em vez de calcular. Accuracy final: 100%.
A observação mais brutal dele: “Android gives you a WebSocket and says ‘here’s the browser, do whatever you want.’ iOS gives you a locked door.”
O ponto não é que funciona perfeitamente. O ponto é que funciona o suficiente pra substituir Marcos.
Onde Estamos nos Benchmarks
Pra dar contexto sobre o estado da arte em 2026 em agentes de computer use:
| Benchmark | Humano | Melhor Agente AI |
|---|---|---|
| OSWorld (desktop OS) | 72,36% | 34,5% (Agent-S2) |
| WebVoyager (browser) | — | 89,1% (Browser-Use) |
| AndroidWorld (mobile) | — | 100% (Mobile-Use) |
| ScreenSpot (grounding) | — | 84,0% (Project Mariner) |
Desktop OS é onde os agentes mais apanham — 12-34% vs 72% humano. Multi-app orchestration fica em 12-20%. Mas atenção: o Claude Code não tenta orquestrar 15 apps ao mesmo tempo. Ele abre 1 app, clica onde precisa, tira screenshot. Esse tipo de tarefa focada tem success rate muito mais alto.
E o campo está se movendo rápido. 35% das organizações já reportam uso amplo de agentes AI, outros 27% estão experimentando. A adoção enterprise saltou de menos de 5% em 2025 pra 40% projetado em 2026.
O Fluxo Antes vs Depois
Antes do Computer Use:
- Dev escreve código no Claude Code
- Dev compila manualmente
- Dev abre o app manualmente
- Dev clica em cada tela manualmente
- Dev tira screenshot manualmente
- Dev volta pro terminal e reporta
Com Computer Use:
- Dev pede pro Claude Code escrever, compilar, abrir e testar
Não é hipérbole. É literalmente o que a feature faz. O prompt real que a documentação sugere:
Build the MenuBarStats target, launch it, open the preferences window,
and verify the interval slider updates the label. Screenshot the
preferences window when you're done.
Claude roda xcodebuild, lança o app, interage com a UI, e reporta o que encontrou. Uma conversa. Um fluxo.
Três Cenários Reais Pra Sua SH
1. Validação de build nativo
Seu time entrega um app macOS. Cada release, alguém precisa abrir, clicar em cada aba, verificar que nada crashou. Computer Use faz isso automaticamente depois de cada build.
2. Bug de layout que só aparece em tamanho X
“O modal corta o footer em janela estreita.” Em vez de redimensionar manualmente até reproduzir, peça pro Claude: ele redimensiona, encontra o bug, tira screenshot do estado quebrado, lê o CSS, e propõe o fix.
3. Fluxo de onboarding no iOS Simulator
Abrir o Simulator, lançar o app, passar por cada tela de onboarding, verificar se alguma leva mais de 1 segundo pra carregar. Sem XCTest, sem test harness. Claude controla o Simulator como você controlaria com o mouse.
O Que Eu Penso
Vou ser honesto: computer use no CLI ainda é research preview. macOS only. Pro/Max plan. Não funciona com -p (headless). Não funciona com Bedrock/Vertex/Foundry. A documentação é transparente sobre as limitações.
Mas na minha experiência com 300+ software houses, o gap mais caro não é entre “código escrito” e “código compilado” — é entre “código compilado” e “código que funciona na tela”. É o gap que come horas de QA manual, que depende de uma pessoa específica, que ninguém automatiza porque as ferramentas não existem.
Computer use é a primeira ferramenta que ataca esse gap de verdade. Não no browser — no browser já tínhamos Playwright. No mundo dos apps nativos, dos simuladores, das GUIs proprietárias onde a única opção era um humano com mouse.
E quando um pesquisador da Carnegie Mellon consegue testar 25 telas em 90 segundos com bug filing automático rodando diariamente às 8:47 da manhã — a mensagem é clara: Marcos pode ser alocado em algo mais estratégico.
O primeiro passo: rode /mcp, ative computer-use, e peça pro Claude testar algo que hoje só um humano testa na sua SH. Se funcionar — e na maioria dos casos simples, funciona — você acabou de automatizar a última milha que nenhuma ferramenta alcançava.
—
Se você quer implementar esse nível de automação de IA na sua software house, fala comigo.
Sou Thulio, mentoro 300+ SHs desde 2016.
—
Leia também:
