Maneiras incríveis de usar o REA, o repo #1 em alta no GitHub

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Insane Ways To Actually Use GitHub’s #1 Trending Repo REA · Canal: AI LABS · 11:50 · Assistir no YouTube

Tópicos: Agentes de IA, Aplicações empresariais de IA, Cibersegurança e segurança de software, Engenharia de software com IA

Resumo

O vídeo apresenta o Reverse Engineer Anything (REA), uma ferramenta que permite a agentes como Claude Code analisar o comportamento de apps e sites, acompanhando interações do navegador e registrando evidências. Mostra cinco usos: reproduzir recursos de outros produtos, pesquisar concorrentes, encontrar bugs em recursos, auditar desempenho e verificar problemas de segurança. Nos testes, o REA identificou discrepâncias de cobrança que não seriam óbvias apenas pela leitura do código, além de problemas de layout e dados expostos. A ferramenta distingue descobertas observadas de inferências e pontos não confirmados.

Pontos-chave

O REA é um servidor MCP que ajuda agentes a analisar como apps e sites funcionam, incluindo o que acontece após interações no navegador.
As descobertas são associadas a evidências e classificadas como observadas, inferidas ou desconhecidas.
É possível estudar recursos de produtos como Obsidian e Notion e usar os resultados como referência para implementar comportamentos semelhantes.
A análise de concorrentes pode revelar detalhes técnicos e recursos que não ficam evidentes em uma pesquisa superficial.
O REA pode testar recursos de um produto sem ler o código e produzir relatórios de falhas com etapas para reproduzi-las.
Nos testes apresentados, foram encontradas cobranças incorretas, aceitação de números negativos de licenças e uma falha no registro de cobrança.
Uma verificação geral pode detectar problemas como elementos que ultrapassam a tela em dispositivos móveis.
A análise de segurança pode encontrar chaves de API expostas e falhas de lógica que permitem acesso a dados de clientes.

Capítulos

Início	Capítulo	Resumo
00:00	O que é o REA e como ele funciona	O vídeo apresenta a ferramenta, explica como ela segue interações até o código e descreve os limites e a instalação.
04:17	Usar recursos de outros apps e pesquisar concorrentes	O REA é usado para estudar recursos de Obsidian e Notion e para investigar concorrentes em mais profundidade.
08:06	Encontrar bugs e auditar o desempenho	A ferramenta testa recursos e o produto inteiro, identificando discrepâncias de cobrança e problemas de layout.
10:45	Verificação de segurança e encerramento	O REA procura chaves expostas e falhas de acesso a dados, e o vídeo termina com informações sobre AI Labs Pro.

Citações

Cada descoberta desta ferramenta vem acompanhada de provas de que é real. — 02:07

Nada desse comportamento aparece em uma captura de tela, mas tudo isso muda a sensação de usar o grafo. — 05:56

No nosso caso, ele informou que os preços exibidos no app eram diferentes dos preços cobrados. — 09:10

Ele também detectou uma falha de lógica que permitia acessar dados de clientes sem precisar de acesso ao backend. — 11:17

Conceitos e entidades

Reverse Engineer Anything (REA) (ferramenta): Ferramenta apresentada como um servidor MCP que permite a agentes analisar o funcionamento de apps e sites e registrar evidências.
Claude Code (ferramenta): Agente de programação usado no vídeo para executar análises com o REA.
Codex (ferramenta): Agente que, segundo o vídeo, também pode se conectar ao REA.
Obsidian (ferramenta): App analisado como referência para entender o funcionamento de sua visualização em grafo.
Notion (ferramenta): App analisado para investigar o funcionamento de sua visualização em quadro.
Hopper (ferramenta): Ferramenta opcional mencionada para análise binária de apps que não são construídos como sites.
Firecrawl (empresa): Patrocinadora do vídeo, apresentada como uma API de contexto para agentes acessarem conteúdo atualizado da web.
AI Labs (empresa): Canal e empresa de software que publica o vídeo.

Tradução completa (pt-BR)

00:00 O repo mais em alta no GitHub permite que o Claude faça engenharia reversa de qualquer aplicativo ou site de um jeito que antes não era possível. E, como acontece com toda ferramenta em alta, a maioria das pessoas só a usa para uma coisa. Mas há muitas outras maneiras de usá-la que a maioria ainda não experimentou. Então, testamos várias maneiras diferentes de usar essa ferramenta e encontramos cinco que são realmente úteis. Uma delas detectou um problema que teria passado despercebido se lêssemos apenas o código, e era grave o suficiente para fazer você perder clientes. Outra encontrou os erros que os agents cometem e que poderiam colocar todo o seu aplicativo em risco. E as outras três acabaram sendo

00:30 igualmente úteis. Então, se esta é sua primeira vez por aqui, seja bem-vindo. Somos uma empresa de software, e este é o nosso canal, AI Labs. Neste vídeo, vamos mostrar cada uma das maneiras de usar essa ferramenta. Mas, antes de chegar a elas, precisamos explicar primeiro o que é essa ferramenta, como configurá-la e como usá-la. Então, se você já sabe tudo isso, pode avançar para os casos de uso usando os marcadores de tempo na descrição. Reverse Engineer Anything é uma ferramenta para agents de IA, como o Claude Code, que permite fazer engenharia reversa dos seus aplicativos. Ela permite desmontar um aplicativo ou site e investigar

01:03 tudo o que chega ao seu navegador, para descobrir como ele realmente funciona. Basicamente, é um servidor MCP que você pode conectar a qualquer um dos seus agents, seja Claude Code ou Codex. Agora, talvez você pergunte: “O Claude já consegue abrir um site no navegador, então por que precisaria disso?” Normalmente, quando você pede ao Claude para criar um recurso, ele deduz como esse recurso funciona com base na sua descrição e nas capturas de tela que faz no navegador. Isso resulta em algo que parece certo, mas geralmente com o comportamento errado, como o que acontece quando você clica, arrasta ou exclui algo. E é o comportamento que faz um recurso parecer pronto. Essa é a lacuna que o REA preenche. Uma ferramenta de navegador comum

01:36 pode navegar por uma página e fazer capturas de tela. Assim, consegue ver o que aparece quando você clica em um botão e, com isso, entende como o aplicativo funciona. Quando você clica em um botão de um site, a página envia alguns dados ao servidor, e o servidor devolve o que a página precisa mostrar. As ferramentas de teste de navegador não percebem isso porque trabalham com capturas de tela. O REA segue esse clique até o trecho exato do código que envia a solicitação ao servidor e salva o que a página enviou e o que recebeu em cada etapa. Depois, transforma tudo isso em uma explicação escrita de como o recurso

02:07 funciona. Cada descoberta dessa ferramenta vem acompanhada de provas que mostram que ela é real. Sempre que o REA captura algo, como uma solicitação enviada por uma página ou um trecho de código executado, ele salva isso como evidência, com um ID próprio. A skill dessa ferramenta faz o Claude vincular cada descoberta à evidência salva correspondente. Basicamente, atribui um rótulo a cada descoberta: observado, deduzido ou desconhecido. Uma descoberta respaldada por algo que o REA capturou é marcada como observada. Se o Claude apenas a deduziu com base em outras pistas, ela é marcada como deduzida. E, se não houver nada que a respalde, ela é marcada como desconhecida. Assim, uma suposição não pode passar por fato

02:41 porque toda afirmação precisa mostrar de onde veio. Mas essas provas cobrem apenas o que chega ao seu navegador. Portanto, tudo o que acontece nos servidores da própria empresa permanece oculto para o REA. Fora do navegador, ele também consegue fazer engenharia reversa de alguns aplicativos para desktop, que se dividem em dois tipos. O primeiro tipo é basicamente construído como um site, então o REA funciona com ele da mesma maneira. O segundo tipo mantém os arquivos de programa reais dos aplicativos no seu computador, então o REA pode lê-los diretamente para descobrir como o aplicativo se comporta. Mas ele não consegue fazer engenharia reversa de aplicativos para desktop que carregam tudo da internet, já que

03:14 não há nada salvo no seu computador para essa ferramenta ler. Mas, antes de configurarmos essa ferramenta, seria ótimo se você se inscrevesse no canal e clicasse no botão de curtir. Esse pequeno gesto de apoio nos ajuda muito. Para instalar essa ferramenta, basta acessar o repo do GitHub, onde você encontrará o comando de instalação. Copie-o, abra um terminal e execute o comando. Quando ele terminar de rodar, detectará todas as suas ferramentas de programação e perguntará para quais delas você quer instalá-la. Use as setas para cima e para baixo para escolher as que quiser e, quando pressionar Enter, a ferramenta será instalada.

03:46 Ele também pergunta se você quer instalar o Hopper para análise de binários. Hopper é uma ferramenta para investigar mais a fundo aplicativos que não são construídos como sites. Você pode responder que sim, se quiser, mas não vai precisar dele se estiver trabalhando com sites ou aplicativos para desktop construídos como sites. Esse comando instala uma skill de engenharia reversa na sua pasta principal do Claude, em vez de instalá-la dentro de um projeto, para que todas as sessões do Claude Code possam usá-la, não importa em qual pasta você as abra. A skill também inclui referências sobre como lidar com diferentes tipos de aplicativos. E, quando você abre o Claude Code e executa o comando MCP, vai

04:17 encontrar o REAMCP conectado. Ele tem cerca de 170 ferramentas, cada uma responsável por uma parte diferente do processo. A primeira maneira de usá-lo é trazer para o seu próprio aplicativo um recurso de outro aplicativo de que você gosta. É para isso que a maioria das pessoas usa essa ferramenta, e ela é muito útil porque você pode escolher recursos que as pessoas adoram em outros aplicativos, deixar o agent entender como eles funcionam e, então, usar isso para criar algo parecido no seu próprio aplicativo. Testamos isso em um aplicativo de demonstração que funciona como o Notion e vincula páginas da mesma forma que o Obsidian, mas só tínhamos criado a primeira versão dele, então ainda não havia a visualização em grafo. Você pode pedir ao Claude

04:51 para usar essa ferramenta em qualquer aplicativo que quiser. Então, pedimos que ele explorasse o Obsidian e descobrisse como ele cria o grafo. Também pedimos que ele usasse o Notion para ver como funciona a visualização em quadro, para podermos criar o mesmo recurso no nosso aplicativo. Mas, primeiro, pedimos ao Claude Code que registrasse o comportamento desses recursos, para que houvesse algo com que comparar depois. Quando enviamos esse prompt, ele primeiro carrega a skill de engenharia reversa e, em seguida, carrega todas as referências para os tipos de sites com que estamos trabalhando. Depois de ler as instruções, começa pelo Obsidian. Não há um MCP conectado ao Obsidian, então o REA analisa o próprio código do aplicativo

05:23 e faz engenharia reversa para descobrir como ele funciona. Mas já tínhamos conectado o MCP do Notion, então, no caso do Notion, ele investiga diretamente por esse meio. Depois de analisar tudo em detalhes, ele cria um arquivo com uma lista de comportamentos, exatamente como pedimos no prompt. Esse arquivo reúne todas as descobertas sobre o Obsidian e o Notion, descritas de modo que o agent possa entendê-las com precisão. Ele inclui detalhes como a forma como o Obsidian decide onde cada nó fica, como desenha as linhas entre eles e com que intensidade páginas muito vinculadas atraem umas às outras. E chega a listar o que acontece quando você arrasta um nó para baixo, com todos os detalhes. A lista

05:56 separa o que o REA realmente observou no código do Obsidian daquilo que não conseguiu determinar. Isso nos dá uma lista clara de comportamentos para implementar no nosso aplicativo e, com base nela, podemos pedir ao nosso agent que implemente o que precisarmos. Por padrão, o Obsidian mantém links para um nó excluído como links quebrados, mas fizemos nosso aplicativo lidar com isso de outra maneira. Quando você exclui uma página aqui, todos os links para ela voltam a ser texto simples. Nada desse comportamento aparece em uma captura de tela, mas tudo isso muda a sensação de uso do grafo. Mas, antes de passarmos ao próximo caso de uso, vamos ouvir nosso patrocinador, Firecrawl. Seu agent de programação é afiado

06:29 até o momento em que precisa de algo mais recente do que os dados de treinamento, como a documentação de uma ferramenta lançada no mês passado. Firecrawl é a API de contexto para agents de IA. O servidor MCP deles é o caminho mais rápido para começar. Ele se conecta ao Claude Code com um único comando, e o agent passa a acessar a web em tempo real. É na busca que isso mostra seu valor. Peça para buscar preços em três sites que você nunca acessou, e ele não vai simplesmente entregar três links. Ele retorna o conteúdo real já lido, pronto para o modelo analisar, em vez de algo que você ainda teria de buscar e limpar. Essa é a mudança: um

07:01 agent que consegue pesquisar algo no meio da conversa, em vez de trabalhar com o que já sabia. E ainda é o mesmo servidor MCP, sem ferramenta ou configuração separada. O agent para de adivinhar e começa a ler. Você tem 500 buscas gratuitas por mês, sem precisar de uma API, e só precisa se cadastrar quando aumentar a escala. Dê ao seu agent acesso à web em tempo real em firecrawl.dev; os links estão na descrição. Você também pode pedir ao [fungada] R E A para analisar de uma só vez todos os concorrentes do que está desenvolvendo. Para fazer seu produto se destacar, você precisa entender o que faz os outros produtos se destacarem e, então, usar o que aprendeu no seu próprio app. Você começa contando

07:33 ao Claude o que está desenvolvendo e pedindo para listar todos os seus concorrentes. Em seguida, ele procura sites que fazem as mesmas coisas que o app que você está desenvolvendo. Depois que listar todos, você pode pedir ao Claude que escolha os cinco principais e use esta ferramenta para pesquisar cada um em profundidade, para entender como funcionam e o que os diferencia. Quando fizemos isso com um app de demonstração para registrar notas de reuniões, também pedimos ao Claude que pesquisasse os mesmos cinco concorrentes sem o REA. Essa pesquisa cobriu apenas o básico, como os preços e como cada um grava suas reuniões. Mas o REA analisou a fundo o código carregado pela página de login de cada concorrente antes de você entrar, e

08:06 esse código revelou recursos que os sites nunca mencionam. Assim, podemos usar esses insights mais profundos para planejar melhor nosso próprio app. Você [fungada] também pode executar o REA em qualquer recurso do seu app para encontrar problemas. Um recurso pode parecer funcionar bem quando você o testa uma vez e ainda assim falhar em situações raras que você não testou. E a maioria delas não pode ser detectada apenas pelo código. Vale a pena encontrar esses bugs cedo, porque, se um cliente encontrar um bug enquanto usa seu app, você pode perder esse cliente. Para fazer isso, basta pedir ao Claude que use esta ferramenta e fornecer o link do seu site. Depois, peça para verificar se o

08:37 recurso funciona exatamente como deveria. Se algo não funcionar como esperado, peça para apresentar um relatório completo explicando o que deu errado. E pedimos que ele não alterasse nada nem lesse o código, para que tivesse de descobrir tudo a partir do próprio site. Assim, ele pode encontrar problemas mais profundos que talvez não percebesse se analisasse apenas o código. Primeiro, ele grava todos os cenários de teste em uma pasta e depois chama o MCP para executá-los um por um. E, se quiser acompanhar o navegador enquanto os testes são executados, você pode pedir para não usar o modo headless. Por padrão, esta ferramenta é executada em modo headless, o que significa que você

09:10 não consegue ver o navegador, mas pode pedir ao agent para desativar esse modo e acompanhar o que ele está fazendo. Quando todos os testes terminam, ele apresenta um relatório completo de cada problema encontrado. No nosso caso, informou que os preços exibidos no app eram diferentes dos valores cobrados. Esse problema não teria sido encontrado olhando apenas o código, porque o próprio código de preços parecia correto. Ele comparou nossa página de cobrança com as regras de preços que anotamos e as promessas da página inicial. A maioria das contas tinha o preço correto, mas duas contas exibiam um preço na tela e cobravam outro: em uma, aparecia metade do

09:41 total real, e na outra, zero. Ele também rastreou o bug passo a passo. O preço exibido na tela é calculado dentro do navegador, e os itens, o desconto e o imposto estavam todos corretos. Então, o problema só ocorre na última etapa, quando o total é somado. Ele encontrou problemas menores além desse, como o servidor aceitar um número negativo de assentos e vender mais assentos do que o plano permite. Uma conta também não deixou nenhum registro no log de cobrança, embora toda fatura devesse gerar um. E, quando não conseguiu comprovar algo, ele deixou isso claro. Ele supôs que uma lista de configurações incorporada à página estivesse causando os

10:14 dois preços incorretos e marcou isso como uma suposição, não como um fato. Você também pode usar esta ferramenta para verificar se há problemas de desempenho no produto inteiro. É preciso fazer isso com frequência, porque uma página lenta ou um layout quebrado são alguns dos motivos pelos quais as pessoas deixam um app. Para isso, basta pedir ao agent que execute o app e faça uma verificação completa usando esta ferramenta. Peça para verificar aspectos como a velocidade, o que deixa o site lento, links quebrados e o comportamento geral do site. Quando você pede isso, ele escreve e executa o mesmo tipo de testes de navegador de antes, desta vez no site inteiro. No final,

10:45 ele apresenta o relatório completo. No nosso caso, o site tinha problemas em celulares: o cabeçalho do painel ultrapassava a borda da tela. Então, ele corrige o cabeçalho para você. O último uso é o mais importante antes de publicar seu app. Apps criados com IA muitas vezes expõem coisas que nunca deveriam ser públicas, e nada na tela indica que isso está acontecendo. Você pode pedir ao Claude que execute o app e use o REA para verificar problemas de segurança, como chaves e senhas expostas, e depois relatar tudo o que encontrar. O app que testamos tinha alguns problemas que inserimos de propósito para ver se a ferramenta conseguiria encontrá-los. Alguns eram

11:17 fáceis de identificar, enquanto outros estavam escondidos no código e eram mais difíceis de encontrar. Quando executamos a verificação, ele encontrou os mais fáceis, como chaves de API da OpenAI e da Stripe que poderiam ser acessadas sem muito esforço. Também detectou um problema de lógica que permitia que as pessoas acessassem dados de clientes sem precisar de acesso ao backend. Assim, podemos usar essas descobertas para verificar o nível de segurança do nosso app e corrigir esses problemas também. O relatório organiza os problemas pelo nível de perigo e sugere uma correção para cada um. Assim, você pode corrigir tudo isso, garantir que seu app continue funcionando sem problemas e deixá-lo seguro para ser usado por várias pessoas. Agora, todas as skills, os

11:50 workflows e tudo mais que criamos e mostramos em nossos vídeos podem ser encontrados no AI Labs Pro, que é a nossa comunidade. Então, se você achou nosso conteúdo útil e quer apoiar o canal, essa é a melhor maneira de fazer isso. O link está na descrição. Com isso, chegamos ao fim deste vídeo. Se quiser apoiar o canal e nos ajudar a continuar fazendo vídeos como este, você pode usar o botão Super Thanks abaixo. Como sempre, obrigado por assistir e até o próximo vídeo.

Transcrição original

[00:00] The number one trending repo on GitHub, let’s Claude reverse engineer any app or website in a way it couldn’t before. And like every trending tool, most people are only using it for one thing. But there are a lot of other ways you can use it that most people haven’t tried yet. So, we tried a lot of different ways you could use this tool and found the five that are genuinely helpful. One of them caught an issue that reading the code alone would have missed, and it was critical enough to cost you customers. Another one found the mistakes agents make that could put your whole app at risk. And the other three turned out to

[00:30] be just as useful. So, if this is your first time here, then welcome. We’re a software company, and this is our channel AI Labs. And in this video, we’re going to show you each of the ways you can use this tool. But before we get to them, we need to first go over what this tool even is and how to set it up and use it. So, if you already know all of that, you can skip ahead to the use cases using the timestamps in the description. Reverse [snorts] Engineer Anything is a tool for AI agents like Claude Code that lets them reverse engineer your apps. It lets them take apart an app or website and dig into

[01:03] everything that reaches your browser, so they can find out how it actually works. It’s basically an MCP server that you can connect to any of your agents, whether that’s Claude Code or Codex. Now, you might ask, “Claude can already open a site in the browser, so why would it need this?” Normally, when you ask Claude to build a feature, it works out how that feature works from your description and from screenshots it takes in the browser. That gets you something that looks right, but it usually gets the behavior wrong, like what happens when you click, drag, or delete something. And the behavior is what makes a feature feel finished. That’s the gap REA fills. A normal

[01:36] browser tool can click through a page and take screenshots. That way it can see what appears when you click a button, and from that it understands how the app works. Now, when you click a button on a website, the page sends some data to the server, and the server sends back what the page needs to show you, which browser testing tool miss because they’re working from screenshots. REA follows that click back to the exact piece of code that sends the request to the server, and it saves what the page sent out and what came back at every step. Then it turns all of that into a written explanation of how the feature

[02:07] works. Every finding from this tool comes with proof to show that it’s real. Every time REA captures something, like a request a page sent or a piece of code that ran, it saves it as evidence with its own ID. This tool’s skill then makes Claude tie every finding back to that saved evidence. It basically assigns a label to each finding, which is either seen, guessed, or unknown. A finding that is backed by something REA captured is marked as seen. If Claude only worked it out from other clues, it’s marked as guessed. And if there’s nothing to back it up at all, it’s marked as unknown. This way a guess can’t pass as a fact

[02:41] because every claim has to show where it came from. But that proof only covers what reaches your browser. So anything that happens on the company’s own servers stays hidden from REA. Outside the browser, it can also reverse engineer some desktop apps, and these come in two types. The first type is basically built like a website, so REA just works on it the same way. The second type keeps the apps’ actual program files on your computer, so REA can read them directly to work out how the app behaves. But it can’t reverse engineer desktop apps that just load everything from the internet since

[03:14] there’s nothing saved on your computer for this tool to read. But before we set this tool up, it would be great if you subscribe to the channel and hit the like button. This small gesture of support goes a long way for us. Now, to install this tool, you just need to go to the GitHub repo, and you’ll find the install command listed here. You need to copy it and then open a terminal and run the command there. Once it runs, it detects all your coding tools and asks which ones you want to install it for. You move up and down with the arrow keys to pick the ones you want, and when you press enter, this tool gets installed.

[03:46] It also asks if you want to install Hopper for binary analysis. Hopper is a tool for going deeper into apps that aren’t built like websites. You can say yes if you want it, but if you’re working with websites or desktop apps that are built like websites, you won’t need it. And this command installs a reverse engineering skill in your main Claude folder instead of inside one project, so every Claude code session can use it no matter which folder you open it in. The skill also comes with references on how to handle different types of apps. And when you open Claude code and run the MCP command, you’ll

[04:17] find the REAMCP connected. It has around 170 tools, and each one handles a different part of the process. The first way to use it is bringing a feature you like from another app into your own. This is what most people use this tool for, and it’s really useful because you can take features that people love in other apps, let the agent understand how they work, and then use that to build something similar in your own app. Now, we tested this on a demo app that works like Notion and links pages the same way Obsidian does, but we’d only built the first version of it, so it didn’t have the graph view yet. You can ask Claude

[04:51] to use this tool on any app you want, so we prompted it to go through Obsidian and work out how it builds its graph. We also had it use Notion to see how its board view works, so we can build the same thing into our app. But first, we asked Claude code to write down how these features behave, so it has something to compare against later. When we send that prompt, it first loads the reverse engineering skill, and then it loads all the references for the types of sites we’re working with. Once it has read the instructions, it starts with Obsidian. There’s no MCP connected for Obsidian, so REA looks at the app’s code

[05:23] itself and reverse engineers how it works from there. But we’d already connected the Notion MCP, so for Notion, it goes through that directly instead. Once it has gone through everything in detail, it writes a behavior list file just as we asked in the prompt. That file holds all the findings from both Obsidian and Notion written so the agent can understand them exactly. It includes details like how Obsidian decides where each node goes, how it draws the lines between them, and how strongly linked pages pull toward each other. And it even lists what happens when you drag a node down to each detail. The list

[05:56] splits what R E A actually saw in Obsidian’s code from what it couldn’t pin down. This gives us a clear list of behaviors to build into our app, from which we can ask our agent to implement whatever we need. By default, Obsidian leaves links to a deleted node behind as broken links, but we had our app handle that differently. When you delete a page here, every link to it turns back into plain text. None of this behavior shows up in a screenshot, but all of it changes how the graph feels to use. But before we move on to the next use case, let’s first have a word by our sponsor, Firecrawl. Your coding agent is sharp

[06:29] right up until it needs something newer than its training data, like the documentation for a tool that shipped last month. Firecrawl is the context API for AI agents. Their MCP server is the fastest way in. It plugs into Claude code with a single command, and the agent can suddenly reach the live web itself. Search is where this earns its keep. Ask it to pull pricing from three sites you’ve never touched, and it doesn’t just hand you three links. It comes back with the real content already read, ready for the model to reason over instead of something you still have to fetch and clean. That’s the shift, an

[07:01] agent that can look something up mid-conversation instead of working from what it knew. And it’s still that same MCP server, no separate tool or setup. The agent stops guessing and starts reading. You get 500 free searches a month with no API all, and you sign up only when you scale. Give your agent the live web at firecrawl.dev, links in the description. You can also have [snorts] R E A go through all competitors of what you’re building at once. To make your product stand out, you need to understand what makes others products stand out, and then use what you learn in your own app. You start by telling

[07:33] Claude what you’re building and asking it to list all your competitors. It then looks for sites that do the same things as the app you’re building. Once it lists them all, you can ask Claude to pick the top five and use this tool to research each one in depth so it understands how they work and what sets them apart. When we ran it for a demo meeting note taker, we also had Claude research the same five competitors without REA. That research just covered the basics like pricing and how each one records your meetings. But REA went deep through the code each competitor’s sign-in page loads before you log in and

[08:06] that code showed features the websites never mentions. So we can use these deeper insights to plan our own app better. You [snorts] can also run REA on any feature in your own app to find issues in it. A feature can look fine when you try it once and still break in the rare cases you didn’t try and most of those can’t be spotted from the code alone. It’s worth catching these bugs early because if a customer finds a bug while using your app, it can cost you that customer. To do that, you just need to ask Claude to use this tool and you need to give it the link to your site. Then you need to have it check that the

[08:37] feature works exactly the way it’s supposed to. If anything doesn’t work as expected, you need to ask it to tell you what went wrong in a full report. And we asked it not to change anything or read the code so it has to work everything out from the site itself. That way it can uncover deeper issues that it might miss if it only worked from the code. It first writes all the test scenarios into a folder and then it calls the MCP to run them one by one. And if you want to watch the browser while it runs the tests, you can ask it not to use headless mode. This tool runs in headless mode by default which means you

[09:10] can’t see the browser, but you can ask the agent to turn it off so you can watch what it’s doing. Once all the tests are done, it gives you a full report of every issue it found. In our case, it reported that the prices shown in our app were different from the prices charged. This one wouldn’t have been found by looking at the code alone because the pricing code itself looked fine. It checked our billing page against the pricing rules we wrote down and the promises on our home page. Most accounts were priced correctly, but two accounts saw one price on screen and got charged another with one seeing half the

[09:41] real total and the other seeing zero. It also traced the bug step-by-step. The price on screen gets worked out inside the browser and the line items, discount, and tax were all correct. So, it only goes wrong at the very last step where it adds up the total. It found smaller problems on top of that like the server accepting a negative number of seats and selling more seats than the plan allows. One account also left no record in the billing log even though every invoice is supposed to write one. And where it couldn’t prove something, it said so. It guessed that a settings list built into the page was causing the

[10:14] two wrong prices and it marked that as a guess instead of a fact. You can also use this tool to check your whole product for performance issues. You need to check this often because a slow page or a broken layout is one of the reasons people leave an app. To do that, you just need to ask your agent to run the app and then do a complete checkup using this tool. You need to ask to check things like speed, what slows the site down, broken links, and how the site behaves overall. When you prompt it to do that, it writes and runs the same kind of browser tests as before. This time across the whole site. At the end,

[10:45] it gives you the whole report. In our case, the site had issues on phones where the dashboard header actually runs past the edge of the screen. Then it fixes the header for you. The last use is the one that matters most before you publish your app. Apps built with AI often leak things that should never be public and nothing on the screen tells you it’s happening. You can ask Claude to run the app and use REA to check it for security issues like exposed keys and passwords and then report everything it finds. The app we tested had some issues that we put in on purpose to see if the tool could find them. Some were

[11:17] easy to spot while others were hidden in the code and harder to find. When we ran the check, it found the easy ones like OpenAI and Stripe API keys that could be accessed without much effort. It also caught a logic issue that let people access customer data without needing access to the back end. So, we can use these findings to check how safe our app is and fix those issues as well. The report sorts these by how dangerous they are and gives a fix for each one. So, you can fix these all and ensure that your app works without any issue later on and is secure for letting multiple people use it. Now, all the skills and

[11:50] workflows and everything else we build and show you in all our videos can be found in AI Labs Pro, which is our community. So, if you found value in what we do and want to support the channel, this is the best way to do it. The link’s in the description. That brings us to the end of this video. If you’d like to support the channel and help us keep making videos like this, you can do so by using the Super Thanks button below. As always, thank you for watching and I’ll see you in the next one.