Profissional de marketing criou um monitor de concorrentes com AI: ele detecta recursos discretos e não dispara alertas a cada deploy

Ninguém anuncia as mudanças mais interessantes nos produtos dos concorrentes. Uma nova automação ou um assistente de AI simplesmente aparece para os usuários, sem comunicado à imprensa e sem registro na loja de aplicativos. Vladimir Mikhailov, Marketing Analyst na Garage Eight, decidiu detectar essas novidades automaticamente. Sua experiência é útil para quem já tentou montar um monitoramento com Playwright e acabou soterrado por falsos alertas.

Por que comparar o DOM não funciona

A primeira ideia é óbvia: capturar o HTML hoje, capturar amanhã e comparar. Em uma SPA moderna, isso produz um detector de deploys de frontend, em vez de mudanças no produto. Uma classe CSS mudou, um testid foi alterado, o endereço de uma seção mudou, um componente foi movido, um botão ganhou outro nome ou o usuário recebeu outra variante de um teste A/B. Tudo isso gera centenas de alertas por dia, quase todos inúteis.

O autor mudou a própria pergunta. Em vez de «o que mudou na página», passou a perguntar «o que o usuário pode fazer agora que não podia antes». Daí vem a principal decisão de arquitetura: a LLM não recebe dois arquivos HTML com o pedido «encontre a diferença». O modelo atua antes, na entrada: explora a interface e monta um modelo estruturado do produto. Um código Python determinístico compara os dois modelos. O resultado é estável e reproduzível, sem depender do humor do modelo.

Um exemplo do artigo: uma funcionalidade saiu de /analytics para /insights/analytics, o DOM foi reescrito e o usuário não percebeu nada. O diff estrutural vai gritar «MAJOR CHANGE!». Por outro lado, se a URL e o nome continuarem iguais, mas uma ação manual ganhar a opção de agendar a execução automática, o diff ficará em silêncio, embora seja uma mudança importante. Por isso, cada funcionalidade tem uma lista de capabilities: schedule_action, export_report, create_custom_alert. Um hash separado é calculado para essa lista, e é ele que indica uma mudança de fato.

O pipeline e as duas interfaces

A sequência é esta: navegador com sessão autenticada, AI Discovery, modelo de funcionalidades, snapshot semântico, comparação, filtro de relevância para o negócio e Slack. O site público mostra apenas a vitrine. Saved Views, Custom Alerts, Automation Rules e recomendações só aparecem depois do login, por isso o sistema navega pelo produto como um usuário comum autenticado.

Há também uma camada analítica. O Claude se conecta via MCP ao histórico de monitoramento com ferramentas somente de leitura: funcionalidades atuais dos concorrentes, NEW/UPDATED/REMOVED em um período, filtros por categoria e verificação de cobertura. Isso criou dois modos de uso. O Slack envia as mudanças automaticamente. Já para a pergunta «o que surgiu nos concorrentes no último mês que os demais não têm?», o analista recebe uma resposta em linguagem natural, sem SQL nem JSON. O histórico também é sincronizado com o Google Drive como base de conhecimento para um Claude Project separado.

Autenticação: onde a automação quebra

Boa parte do artigo trata de como evitar que o login quebre a automação. Algumas soluções práticas:

• Estados em vez de verificar a URL. A condição «o endereço não contém /login» não é confiável: uma SPA pode mostrar uma tela por um segundo e logo redirecionar para outra. O autor usa uma máquina de estados (AUTH_OK, AUTH_EXPIRED, AUTH_2FA_REQUIRED, AUTH_CAPTCHA_REQUIRED, AUTH_UNKNOWN) e considera o usuário autenticado quando encontra pelo menos dois de três marcadores independentes, como o menu do usuário e o botão de sair.
• Erros de navegação não significam falha no login. A exceção «Execution context was destroyed» após um login bem-sucedido pode provocar um novo envio do formulário. O estado é verificado em uma sequência de checagens, e erros temporários são ignorados.
• Os segredos não chegam ao modelo. O login e a senha ficam no cofre de credenciais do sistema, e um processo independente do Playwright preenche esses dados. A AI recebe apenas um sinal de que a sessão voltou a funcionar, e não há segredos no histórico de requisições ao modelo.
• O 2FA não é contornado. Se chegar um SMS, o sistema para e espera uma pessoa intervir. Depois que o código é inserido, a sessão é salva e as próximas execuções seguem automaticamente.
• Nem todo captcha é igual. Um selo de reCAPTCHA invisível na página não significa que o serviço esteja pedindo uma verificação naquele momento. É preciso distinguir «existe um captcha» de «o captcha está bloqueando o login».
• Perfil persistente não significa sessão persistente. Um serviço emitia um cookie de autenticação com expires: -1, que morria junto com o processo do Chrome. O autor optou por se adaptar: depois do login automático, o navegador continua aberto, e o Playwright MCP se conecta a ele via CDP (connectOverCDP).

O que aproveitar e o que ter em mente

Três ideias podem ser aplicadas em outros projetos. Primeira: use a LLM para transformar o caos em estrutura e faça a comparação com código determinístico. Segunda: descreva o produto pelas ações do usuário, em vez da marcação da interface. Terceira: trate os segredos como uma área à qual o modelo não tem acesso em hipótese alguma.

Também há limitações. A parte disponível do material não traz números: quanto custa cada execução, com que frequência o modelo deixa passar ou inventa funcionalidades e como o filtro de relevância distingue o que é importante de detalhes menores. Acessar produtos de terceiros com uma conta pode violar os termos de uso do serviço, e vale verificar isso com a equipe jurídica antes de colocar o sistema em operação. Ainda assim, a arquitetura parece funcional e pode servir à inteligência de produto em qualquer equipe.