Seu dev escreve o código, compila, abre o app, clica em cada botão, redimensiona a janela, tira print do bug, volta pro terminal, ajusta o CSS, compila de novo, abre o app de novo, clica de novo.
Isso acontece 10, 15, 20 vezes por dia na sua software house. E ninguém questiona porque “sempre foi assim”. Teste manual de interface é o imposto invisível que todo time de desenvolvimento paga — e que ninguém contabiliza.
O mercado de testes manuais ainda domina 62,5% do mercado global de QA em 2026 (Qyrus). Não porque é eficiente. Porque automatizar GUI sempre foi doloroso demais. Selenium, Playwright, Appium — todos exigem harness, config, manutenção. O custo de entrada é alto o suficiente para que a maioria das SHs desista e volte pro teste na mão.
Até agora.
A Anthropic acabou de lançar Computer Use no CLI — e isso muda o jogo. O Claude Code agora abre apps nativos, clica em botões, digita em campos, redimensiona janelas, tira screenshots e reporta o que encontrou. Tudo do terminal. Sem Playwright. Sem harness. Sem config.
O que é Computer Use no CLI
Computer Use é uma nova capacidade do Claude Code que permite ao modelo controlar fisicamente apps no seu desktop. Não é uma API. Não é um wrapper. O Claude literalmente vê sua tela, move o mouse, clica, digita e interage com qualquer aplicação como um humano faria.
Na prática, funciona assim: você escreve código no terminal, pede pro Claude “compilar, abrir o app e testar o onboarding flow”, e ele faz. Abre o Xcode, compila, lança o app, clica em cada tela, tira screenshot de cada passo e reporta o que encontrou. Tudo na mesma conversa onde ele escreveu o código.
A documentação oficial descreve como “tasks that require a GUI: anything you’d normally have to leave the terminal and do by hand.”
Como ativar
É simples. No Claude Code, rode /mcp, encontre computer-use na lista, e habilite. Na primeira vez, o macOS pede duas permissões: Accessibility (para clicar e digitar) e Screen Recording (para ver a tela). Concedeu, está pronto.
/mcp
→ computer-use → EnableA partir daí, é linguagem natural:
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.O Claude compila, abre, interage e reporta. Uma instrução. Zero config.
Como funciona na prática
O Computer Use segue uma hierarquia inteligente. O Claude não usa controle de tela para tudo — ele tenta o caminho mais preciso primeiro:
- Se tem um MCP server para o serviço, usa ele
- Se é um comando shell, usa o Bash
- Se é tarefa de browser e você tem o Chrome configurado, usa o Chrome
- Se nada disso resolve, aí sim usa Computer Use
Ou seja, controle de tela é reservado para o que nenhuma outra ferramenta alcança: apps nativos, simuladores, ferramentas sem API.
Validar build nativo em um passo
Seu dev fez changes num app macOS. Ao invés de compilar manualmente, abrir, clicar em cada tab:
Build the app target, launch it, and click through each tab to make
sure nothing crashes. Screenshot any error states you find.Claude roda xcodebuild, lança o app, interage com a UI e reporta o que encontrou.
Reproduzir bug visual
Aquele bug que só aparece quando a janela é pequena? Seu dev gasta 15 minutos redimensionando manualmente.
The settings modal clips its footer on narrow windows. Resize the app
window down until you can reproduce it, screenshot the clipped state,
then check the CSS for the modal container.Claude redimensiona, captura o estado quebrado, lê o CSS e sugere o fix.
Testar fluxo no iOS Simulator
Sem escrever XCTest. Sem configurar framework de teste.
Open the iOS Simulator, launch the app, tap through the onboarding
screens, and tell me if any screen takes more than a second to load.Claude controla o simulador exatamente como você faria com o mouse.
Segurança: o que você precisa saber
Sei que o primeiro pensamento de todo dono de SH é: “IA controlando minha máquina? Não obrigado.”
A Anthropic pensou nisso. O modelo de segurança é robusto:
- Aprovação por app, por sessão: na primeira vez que o Claude precisa de um app específico, ele pede permissão. Você aprova ou nega. A aprovação vale só para aquela sessão.
- Warnings de apps sensíveis: terminal, Finder, System Settings — todos mostram warning extra antes da aprovação, explicando o nível de acesso.
- Terminal excluído dos screenshots: o Claude nunca vê o próprio terminal. Isso impede que conteúdo da sua sessão alimente o modelo — proteção contra prompt injection.
- Escape global: apertou
Escem qualquer lugar, o Computer Use para imediatamente. O Claude solta o controle e restaura suas janelas. - Lock file: apenas uma sessão pode controlar a máquina por vez. Sem conflitos.
- Apps são escondidos: enquanto o Claude trabalha, outros apps ficam ocultos para evitar interação acidental. Quando termina, tudo volta ao normal.
Níveis de controle variam por categoria: browsers e plataformas de trading são view-only, terminais e IDEs são click-only, e o resto recebe controle completo.
Por que isso importa para sua Software House
Vou ser direto: teste manual de GUI é o maior desperdício de tempo qualificado na maioria das SHs.
Os números não mentem:
- O mercado global de automação de testes vai de USD 24,25 bilhões em 2026 para USD 84,22 bilhões em 2034 — crescimento de 16,84% ao ano (Gitnux)
- IA reduz custos de teste em 30-50% enquanto escala operações dinamicamente
- Custos de manutenção de testes caem 75% com self-healing de IA
- Cada time economiza em média US$ 200K/ano só em resolução de flaky tests
Agora pense na sua SH. 20 devs. Cada um gasta, conservadoramente, 30 minutos por dia testando interfaces manualmente. São 200 horas por mês — mais de um dev full-time fazendo trabalho que uma instrução em linguagem natural resolve.
E o contexto é ainda pior. Cada vez que o dev sai do terminal para abrir o app, testar, voltar pro terminal, ajustar, testar de novo — são interrupções que custam 23 minutos de foco cada (APA). 15 switches por dia × 20 devs = 300 interrupções diárias que o Computer Use simplesmente elimina porque o dev nunca sai do terminal.
O diferencial competitivo
Sua SH entrega apps nativos? Apps Electron? Ferramentas desktop? Qualquer coisa com GUI?
Com Computer Use, o ciclo muda de:
Antes: código → compila → abre app → testa manual → volta pro terminal → ajusta → compila → abre app → testa manual → …
Depois: código → “compila, abre e testa” → Claude reporta → ajusta → “testa de novo” → done
O dev não sai do terminal. O loop de feedback é uma frase. O teste acontece na mesma conversa onde o código foi escrito.
Limitações atuais
Transparência total — isso é um research preview:
- Só macOS no CLI (Windows pode usar pela Desktop app)
- Só planos Pro e Max (não disponível em Team/Enterprise ainda)
- Requer v2.1.85+ e sessão interativa (não funciona com
-p) - Não funciona com providers third-party (Bedrock, Vertex AI, Foundry)
- Espere rough edges — a Anthropic mesma diz isso
Mas aqui está minha visão: toda feature que começa como research preview e resolve um problema real vira padrão. O fullscreen rendering começou assim. O transcript search também. A diferença é que Computer Use resolve um problema ordens de magnitude maior.
O que eu penso
Na minha experiência com 300+ software houses, teste manual de interface é o último bastião do “a gente sempre fez assim”. Ninguém automatiza porque o custo de entrada dos frameworks tradicionais é alto demais para o ROI imediato que a maioria dos projetos precisa.
Computer Use inverte essa equação. O custo de entrada é uma frase em linguagem natural. Não tem harness para configurar, não tem seletores para manter, não tem framework para atualizar. Você fala o que quer testar, o Claude testa.
Isso não substitui QA profissional. Não substitui testes E2E automatizados em pipelines de CI/CD. Mas elimina aquelas 200 horas mensais que seus devs gastam fazendo o trabalho repetitivo que nenhum framework cobria porque “era simples demais para automatizar e chato demais para fazer na mão”.
A ironia? O teste que era “simples demais para automatizar” sempre foi o que mais consumia tempo.
Conclusão
Computer Use no CLI é a feature que fecha o último gap entre escrever código e validar resultado. Pela primeira vez, o loop inteiro — da primeira linha de código até o screenshot da tela funcionando — acontece numa conversa no terminal.
Se sua SH entrega qualquer coisa com interface gráfica, isso não é opcional. É vantagem competitiva.
Se você quer implementar esse nível de automação na sua software house e precisa de direção estratégica, fale comigo.
Sou Thulio, mentoro 300+ SHs desde 2016. E acredito que as SHs que vão dominar os próximos anos são as que param de tratar IA como gadget e começam a tratar como infraestrutura.
Links úteis:
