Como dar um navegador a um agente de IA de programação?

Resposta curta: dá para dar um navegador a um agente de IA de programação por três caminhos: um servidor MCP de automação de navegador (Chrome DevTools MCP ou Playwright MCP), testes de browser da própria stack (Pest, Playwright), ou um aplicativo com navegador embutido por agente, como o CanvasCode. Seja qual for o caminho, o motivo é o mesmo: um agente de IA que só lê código está deduzindo o resultado visual, e dedução de layout erra.

O que o agente de IA não vê quando só lê o código

CSS não se executa na cabeça: cascata, especificidade, viewport estreito, conteúdo real maior que o conteúdo de exemplo. Um agente de IA lê o diff, o diff parece certo, e a página está com o menu por cima do título no celular. Num caso real deste site, um estouro de largura no celular sobreviveu a três rodadas de correção às cegas, com o agente relendo código e declarando resolvido; na primeira rodada em que o agente tirou uma foto da tela, o bug fechou. A regra da casa virou: bug visual só fecha depois de ver.

A foto mostra o layout, o console mostra o erro

A captura de tela responde "como ficou": elemento vazando, texto cortado, botão fora do lugar. O console responde "por quê": o erro de JavaScript que quebrou a renderização nunca aparece na foto, só no log. Um agente de IA equipado com os dois fecha o ciclo sozinho: foto estranha leva ao console, console aponta o erro, o erro vira correção, nova foto confirma. Sem o par completo, metade dos diagnósticos vira chute.

Como dar um navegador a um agente de IA?

Três caminhos. Automação de navegador via MCP (Chrome DevTools MCP, Playwright MCP): funciona com qualquer CLI, exige configurar servidor MCP por projeto. Testes de browser da própria stack (Pest, Playwright): ótimos para regressão, menos para exploração. Ou um aplicativo com navegador embutido por agente: no CanvasCode, cada agente de IA tem um browser próprio no canvas, que abre a página, clica, digita, rola, lê o console e devolve a foto ao agente, sem configuração por projeto. O caminho certo depende de quanto do seu trabalho é visual.

O que muda no fluxo quando o agente vê a tela

Muda o ponto de parada. Sem navegador, o agente de IA para em "editei os arquivos"; a conferência visual sobra para você, e o vaivém (você olha, descreve o problema, o agente tenta de novo) consome mais tempo que a correção. Com navegador, o agente para em "olhei e está certo", e a sua revisão começa de uma tela que já foi conferida uma vez. O ganho não é o print: é o vaivém que deixa de existir.

Isso vale para aplicativo nativo também?

Em parte. Para web, o navegador embutido resolve inteiro. Para aplicativo nativo (SwiftUI, por exemplo), o equivalente é capturar a tela do simulador, o que funciona mas com mais fricção: build mais lento, navegação até a tela certa, sem console de JavaScript. A honestidade manda dizer: o ciclo foto-console é uma vantagem específica do desenvolvimento web, e é lá que um agente de IA com navegador rende mais.

Quais são os limites de deixar o agente navegar?

Dois que importam. Custo: cada foto entra no contexto do modelo como imagem, e uma sessão visual longa consome tokens sensivelmente mais rápido que texto. Segurança: um agente que clica precisa de limites claros em área logada e em ação destrutiva (pagar, apagar, publicar); o padrão sensato é navegar livre em ambiente local e pedir confirmação humana fora dele. Nenhum dos dois limites anula o ganho; os dois pedem que o navegador seja dado com regras.