Insane Ways To Actually Use GitHub's #1 Trending Repo REA

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Insane Ways To Actually Use GitHub’s #1 Trending Repo REA · Channel: AI LABS · 11:50 · Watch on YouTube

Topics: AI agents, Enterprise AI applications, Cybersecurity and software security, Software engineering with AI

Summary

The video explains Reverse Engineer Anything (REA), an MCP tool that lets AI coding agents inspect how websites and some desktop apps behave by tracing browser interactions to code and saving evidence. It shows how to install and connect REA, then demonstrates five uses: recreating features, researching competitors, testing a feature for bugs, checking a whole product for performance problems, and finding security issues. The examples include uncovering incorrect billing totals, a mobile layout overflow, exposed API keys, and unauthorized access to customer data. REA labels findings as seen, guessed, or unknown so claims are distinguished from evidence.

Key points

REA lets agents such as Claude Code and Codex inspect app behavior, including requests sent to and received from servers through the browser.
Findings are linked to saved evidence and labeled as seen, guessed, or unknown; REA cannot see what happens only on a company’s servers.
REA can reverse engineer some desktop apps, but not apps that load everything from the internet and have no relevant files saved locally.
The setup involves running the install command from the GitHub repository, choosing coding tools, and optionally installing Hopper for binary analysis.
REA can study features in other products, document their behavior, and help implement similar features in your own app.
It can research several competitors in depth, including details in code loaded by sign-in pages that may not be mentioned on public websites.
Testing a feature through the site can reveal bugs that code review alone may miss, such as customers seeing a different price from what they are charged.
A product-wide check can identify issues such as broken links, slow pages, or layouts that overflow on phones.
Before release, REA can check for security problems such as exposed API keys and weaknesses that allow access to customer data.

Chapters

Start	Chapter	Summary
00:00	What REA is and how it works	The video introduces REA, explains how it traces browser behavior to code and evidence, and describes its limitations.
03:14	Installation and feature research	The presenters walk through installation and show how REA can study features in Obsidian and Notion to guide implementation.
06:29	Competitor research and bug testing	After a Firecrawl sponsor segment, the video demonstrates competitor analysis and browser-based testing that finds billing errors.
10:14	Performance and security checks	REA checks the product for performance and layout problems, then scans for exposed secrets and access-control issues.
11:50	Closing	The presenter points viewers to AI Labs Pro and thanks them for watching.

Quotes

we tried a lot of different ways you could use this tool and found the five that are genuinely helpful. — 00:00

A finding that is backed by something REA captured is marked as seen. — 02:07

None of this behavior shows up in a screenshot, but all of it changes how the graph feels to use. — 05:56

the prices shown in our app were different from the prices charged. — 09:10

It also caught a logic issue that let people access customer data without needing access to the back end. — 11:17

Concepts and entities

Reverse Engineer Anything (REA), Claude Code, Codex, Obsidian, Notion, Hopper, Firecrawl, AI Labs

Full transcript (original language)

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.