Reverse Engineer Anything: The GitHub Repo That Clones App Features With AI
How the viral Reverse Engineer Anything (REA) repo uses a five-stage framework to help AI agents decompile and rebuild app features.
What is the Reverse Engineer Anything (REA) repo?
Reverse Engineer Anything, often shortened to REA, is a GitHub repo that gives AI coding agents a structured process for studying an existing app’s feature and rebuilding it from scratch. Instead of asking an agent to “build me a screen recorder” and getting something generic, you point it at a specific feature in a specific app (say, Loom’s floating camera bubble), let it inspect how that feature behaves, and then have it reconstruct the functionality in your own codebase. It doesn’t copy code or assets. It studies behavior and rebuilds it independently.
TL;DR
- REA structures reverse engineering into five repeatable stages so an agent doesn’t just poke around an app randomly and guess at how it works.
- The framework works best when you pick a single feature (like a camera bubble or a recording countdown) rather than pointing an agent at an entire app and asking it to clone everything.
- A core idea is labeling findings as seen, inferred, or unknown, so the agent (and you) can tell confirmed facts apart from guesses before building on top of them.
- REA compresses a huge raw analysis (one creator reported a gigabyte of analysis for Loom) into a shorter summary first, so the agent isn’t re-reading everything on every task.
- The method isn’t new. It’s essentially reverse engineering the output, a technique coders and prompt engineers have used for a while: show the agent a target instead of describing it in the abstract.
- The repo emphasizes rebuilding and testing as one step, not shipping a first draft and calling it done.
- It explicitly warns against copying exact code or assets, since the point is replicating functionality, not lifting someone else’s intellectual property.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
How does the REA framework actually work?
REA breaks the reverse engineering process into five stages:
1. Pick a feature. Rather than aiming an agent at an entire application, you isolate one specific piece of functionality you want to replicate. One demonstrated example: Loom’s camera bubble, which can be moved, resized, and paused during a recording. Picking a narrow feature gives the agent a much more specific target than “clone this app.”
2. Route by build. The agent considers what the original app is actually built with before deciding how to investigate it. Understanding the likely tech stack changes which tools and inspection methods make sense, so this step is about giving the agent context on what kind of codebase or runtime it’s dealing with before it starts digging.
3. Summary first. When an agent inspects a real app, the raw analysis can be enormous. One demonstration mentioned a full Loom analysis exceeding a gigabyte of data, far too much for a model to usefully reread on every subsequent task. REA condenses that raw analysis into a shorter summary covering what works, how it works, and what remains unclear, then lets the agent drill into specific modules or traces only when needed. That summary gets saved locally so the agent isn’t rerunning a massive analysis every time it needs context.
4. Seen, inferred, unknown. This is the step most people skip when they freestyle reverse engineering with an AI agent. Everything the agent discovers gets tagged into one of three buckets: things it directly observed and can cite (seen), things the code or data strongly suggests but doesn’t confirm (inferred), and things it genuinely could not determine (unknown). This matters because agents will often present inferred guesses with the same confidence as confirmed facts. If you build on an inferred assumption as though it were verified, you can end up debugging a feature that was never actually built the way you thought it was.
5. Rebuild and test. The final stage is where findings turn into working code, and it’s explicitly paired with testing, not treated as a separate afterthought. The agent runs test cases, checks that the rebuilt feature behaves like the original, and iterates until the functionality matches, rather than shipping a single pass and assuming it’s correct.
Why is this different from just asking an agent to “build a clone”?
The difference comes down to specificity. An agent given a vague goal, like “build me a CRM” or “build me a video editor,” produces a generic result because it has nothing concrete to aim at. Pointing an agent at an existing feature and saying “understand this, then rebuild it” functions like handing it a fully fleshed out product spec without having to type one out yourself. The app becomes the spec.
This is the same logic behind a technique sometimes called reverse engineering the output: if you want a good version of some recurring deliverable (a report, a video edit, a landing page), show the agent several strong examples of that deliverable and have it extract the pattern, rather than describing what you want in the abstract. One creator demonstrated this by having an agent analyze dozens of well-performing Instagram Reels frame by frame to extract a consistent editing style (fonts, transitions, B-roll pacing), then turning that analysis into a reusable editing skill. A separate example involved feeding a motion design video to an AI model (Opus) and asking it to analyze the video frame by frame, infer why the design choices worked, and then build a skill that could produce similar edits. The AI couldn’t have invented that creative direction on its own, but once shown a concrete target, it could reconstruct the mechanics behind it.
REA essentially formalizes that same workflow specifically for software functionality: here’s the behavior, go figure out how it’s built, then build me a version that works the same way.
What are some real examples of REA in action?
Beyond the Instagram Reels and motion design examples, REA has reportedly been used to:
- Rebuild Loom’s core recording experience, including the movable camera bubble, pause/resume functionality, and recording countdown, as a local screen recorder that saves files to a folder instead of the cloud.
- Study a tool called Sand Castles and reproduce a personal version of its core functionality once an API key was connected.
- Analyze Langfuse to help build a custom evaluation tool for reviewing automations, drawing on Langfuse’s core interaction patterns without duplicating its interface.
In each case, the end result reportedly looked visually different from the original app. The goal wasn’t to copy the UI or design pixel-for-pixel. It was to extract how a specific interaction or feature worked and reimplement that mechanic inside a different product.
Is the REA approach worth using?
For anyone building software with AI agents, yes, mainly because it turns a vague, error-prone process into something repeatable. Without a framework, asking an agent to “look at this app and build something like it” tends to produce shallow, surface-level guesses that look plausible but fall apart under testing. The seen/inferred/unknown labeling in particular forces a level of rigor that’s easy to skip when you’re moving fast with an agent, and skipping it is usually what leads to wasted iteration cycles later.
That said, the underlying idea isn’t new. Developers and prompt engineers have been “reverse engineering the output” long before this repo existed, by studying examples, decompiling binaries, or inspecting network traffic to understand how an app behaves. What REA adds is a packaged, repeatable process that any agent can follow consistently, plus a sensible warning built into the practice: study functionality, not someone else’s exact code or assets. That line matters both practically (avoiding sloppy copy-paste) and legally (avoiding clear IP infringement).
Frequently Asked Questions
What does REA stand for?
REA stands for Reverse Engineer Anything, the name of the GitHub repo and the framework it documents for having AI agents study and rebuild existing app functionality.
Does REA copy code directly from other apps?
No. The framework is built around studying how a feature behaves and then rebuilding it independently, not copying exact source code or visual assets from the original app.
Do I need Claude specifically to use this framework?
The demonstrated examples used Claude-based tools (including Claude Code and Opus), but the underlying five-stage process, picking a feature, routing by build, summarizing first, tagging findings by confidence, and rebuilding with tests, is a methodology that could be applied with other capable coding agents.
What’s the biggest mistake people make when reverse engineering apps with AI?
One coffee. One working app.
You bring the idea. Remy manages the project.
Pointing an agent at an entire app and asking it to “clone everything” instead of isolating one specific feature. Vague, broad requests produce vague, broad (and often wrong) results. Narrow, concrete targets produce much better output.
Why does the seen/inferred/unknown labeling matter so much?
Because agents can present a guess about how something works with the same confidence as a confirmed observation. If you build new functionality on top of an unverified inference without knowing it was a guess, you risk compounding errors that are much harder to debug later.