Everyone's asking if AI can copy any app. That's the wrong question.

An open-source project called REA, short for Reverse Engineer Anything, has been getting a lot of attention on GitHub. The idea is blunt: let an AI agent investigate how software is built and how it behaves, even without the source code.

You connect it to Claude Code, Codex or Cursor through MCP, and the agent can study how a website pulls off a complex interaction, how a desktop app handles its data, or with the right professional tooling, what a native binary is actually doing underneath.

Impressive. But after digging into how it works and what it's genuinely useful for, I landed somewhere different from most of the discussion.

Here's what I find exciting instead. If AI can help us understand why a good product works, why a design pulls you in, why a workflow is efficient, then we can turn that understanding into our own products, our own creative systems, maybe our own business models.

Which reframes reverse engineering entirely. It stops being a developer's technical tool and becomes a designer's learning method, a creator's production system, an indie developer's research capability, and a founder's way of spotting an opening. We have barely started exploring that.

Over the last few weeks I've ended up using that idea in three places that have nothing to do with cloning apps: a motion studio, an agent team, and a problem that wasn't about software at all. Those three stories are really what this essay is about. REA is just the way in.

01What REA actually changes

Say I see a beautiful 3D scroll experience on some studio's site. My old process was to grab a few screenshots, maybe record a clip, and tell Claude "I want something like this."

Claude would work from my visual references, its own technical knowledge, and my description. Sometimes the result was decent. More often it reproduced the surface and missed everything underneath: camera movement, scroll progress mapping, transition timing, asset loading, rendering performance. That gap is exactly why so many AI-generated sites look right in a screenshot and feel wrong the moment you touch them.

REA offers a different route. It connects an agent to actual analysis tooling over MCP, so depending on the target it can look at loaded resources, JavaScript modules, Electron structure, runtime behavior, and in some cases compiled binaries. Try both approaches on the same site:

Worth being precise: this does not hand you a complete codebase, and it cannot see what happens on someone's server. What it does is move the agent out of pure speculation and into technical investigation.

We used to tell AI what we wanted. Now we can have it study the problem first.

02The interesting part isn't reversing code. It's reversing results.

Somewhere in the middle of reading about REA I started asking a broader question. Does reverse engineering have to start from code at all?

It doesn't. You can start from a finished piece of work and study why it lands.

Take a really well-made motion graphics piece. Fifteen seconds, but inside it there's deliberate typography, transitions, camera movement, sound design and visual rhythm. Ask AI to "make something like this" and you'll get the usual zoom, fade, bounce, particles.

Now do it the other way. Analyze the key frames. When does text appear, how does the camera move, how do elements hand off to each other, how does the speed change, how does sound reinforce the beat. Then write those rules down as a reusable motion specification, and implement it yourself in Remotion, GSAP or Three.js.

That isn't copying an animation. That's learning its design language.

This is directly connected to what I'm building in Yuya Motion Studio. I don't want a prompt box that produces a random assortment of flashy effects. I want a system that understands why kinetic typography belongs here, why this scene wants an isometric process animation, why some animations need to slow down so a viewer can actually read them, and why one restrained movement often reads as more expensive than twelve complicated ones.

So I'm working on a Motion DNA library: breaking good animation down into the layers underneath it. Click through one:

A professional kinetic typography sequence isn't "text flies in from the left." It involves information hierarchy, the order words arrive in, how long each one holds, the motion curve, and when exactly the viewer is supposed to notice which piece of information.

Once those rules are recorded systematically, an agent can pick the right motion grammar for a given goal and implement it. I should be clear that REA itself is not a frame-by-frame video analysis tool, so this workflow needs video analysis, computer vision, animation tooling and a human design review on top. But the thinking is the same.

03I don't want to rebuild After Effects. I want to build the studio around it.

One of the more revealing things about REA is watching what people decide to do with it. A lot of the early excitement has been about rebuilding: recreating whole product experiences, Adobe-style creative tools included, with a fraction of the team that built the originals.

I get the appeal. Something that used to need a large engineering team can now be explored by two people and an agent. But I keep coming back to one question. If we can finally understand how complex software works, why is our first instinct to build another copy of it?

Take After Effects. I could spend months reproducing its timeline, keyframes, effects panel and composition system. At the end I'd own a second animation editor, competing on home turf with a mature product that already solves thousands of problems I haven't thought of yet.

What interests me is everything around the editor. The production system. The knowledge and decisions that turn a brief into a finished piece.

Picture an AI motion production studio. Instead of a person hand-picking every animation, the system reads the brief, studies the references, identifies the motion language, plans the sequence and hands each piece to a specialist. One agent researches references. Another breaks them into Motion DNA. A creative director agent decides which techniques fit this story. A production agent builds it in Remotion, GSAP or Three.js. A reviewer checks timing, readability, consistency and technical quality.

That isn't another After Effects. It's a different way to run a motion studio, and it's what I'm building as Yuya Motion Studio, on top of my Video OS work. I'm not trying to replace professional software. I'm trying to understand the knowledge and the production process that professional work depends on, and make them repeatable.

A worked example, end to end

Here's the experiment I'm setting up to test whether any of this holds. I want to be clear about its status: I haven't run it end to end yet. When I do, I'll publish the real result, including whatever breaks. Step through it:

Don't just reverse engineer the tool. Reverse engineer the work the tool makes possible.

04The real value is better products, not more code

We can build software incredibly fast now. But as speed went up, a different problem became obvious: you can produce something that looks complete without understanding how it should actually behave.

A button clicks fine, but nothing handles the error state. A dashboard looks great, but the data refresh logic is unreliable. An AI workflow runs once successfully and has no idea what to do with failure, retries or recovery.

I keep running into this in my own work. I'm building Creator OS, Video OS, and a desktop focus tool called Octo Focus. Different technologies, same underlying challenge:

What decides product quality is rarely the obvious feature. It's the behavior nobody thought to specify.

Octo Focus is a good example. I want it to feel like a small creature that genuinely lives on your desktop, not a task manager in a window. That means window dragging, focus switching, local state, task completion, reminders, animation and interaction feedback all have to be right.

If I just tell Claude "build a cute desktop pet," I'll get a visually fine prototype. But if I define the behavior first, the questions get much better. What happens while the user drags the window? How should the character react when a task completes? Does data survive quitting the app? Can a reminder interrupt work in progress? What state should the system restore to on reopen?

Those questions are what make a product usable. We can study how mature software handles each one, understand the tradeoffs, and then design our own answer. For software you're authorized to examine, REA can help investigate the actual implementation. But the decision stays yours.

I don't want to clone a task manager. I want to know which interaction patterns have been proven, which problems are still unsolved, and then design something that fits my product. Stop asking only whether AI can build the feature. Ask why the feature should work that way.

05An underrated move: let AI test what it just built

Imagine a SaaS dashboard. Frontend done, database connected, auth working, Stripe wired up. Everything clicks, nothing errors. Looks shippable.

Then you actually walk a real purchase flow. Run it:

This is why I think black-box product QA matters. The idea is simple: don't only have AI read the code, have it use the product the way a person would. Watch the whole flow, record what the system does, compare the actual result against the expected one.

In Video OS I eventually want to test a full production run: create a video, add shots, call the AI generation service, simulate a failure, check the error message and the retry path, switch between versions, confirm approval state, export. The question isn't whether one function returned correctly. It's whether the product can carry a user all the way to the thing they wanted.

REA can help gather runtime evidence in the right situations, but a complete test setup still needs browser automation, end-to-end tooling and real test infrastructure. The point is the shape of the workflow:

06Agents need to tell facts from guesses

There's one principle in REA I like more than any of its tooling. Its results are meant to carry the evidence and the limitations behind each conclusion, including what remains unknown.

That sounds modest. I think it's the most important idea in the whole project, and the discipline I'd most like to steal. The version I use has three labels:

Here's why this matters so much once you run multiple agents. One does research, one plans, one codes, one reviews. If agent one's guess arrives at agent two looking like a fact, the error propagates all the way down and you end up with a very professional document built on something nobody checked. Watch it happen:

So I want my own agent systems to report more than what they finished. What evidence led to this? Which parts are verified? Which are reasonable inference? What risk is still open? A professional agent shouldn't just be fast. It should be traceable, and capable of checking itself. That gets more important the moment agents start touching client projects and real decisions.

07Reverse engineering can find business opportunities too

You see a successful SaaS product. Most people's first instinct is "could I rebuild this with Claude Code?"

The better question is why is anyone paying for this? What problem does it solve? What were customers doing before? Where is time being wasted? Which features actually matter and which are marketing? And is there a smaller, more specific group of customers still being served badly?

This is basically Jobs to Be Done. Customers don't want the feature, they want the job it gets done. A team buying an AI meeting assistant probably doesn't love AI summaries. They want less post-meeting cleanup, fewer dropped action items, or a CRM that updates itself.

Study a competitor's feature list and you'll build another product with similar features. Study what customers are trying to accomplish and you may find a completely different opening.

I want to push this into Creator OS. My AI Content Radar shouldn't just scrape trending news and generate posts. I want it surfacing which problems keep coming up, which workflows people find painful, which new technologies are creating new demand, where existing solutions are still weak, and which of those signals deserve a real interview. That stops being content research and starts being business intelligence.

08It works on opportunities, not just software

A few weeks ago I ran into a challenge that had nothing to do with code. How does a small creator get the attention of a much bigger one, and maybe turn that into a conversation, or even a collaboration?

On paper it's close to hopeless. A small account messaging someone with a huge audience is competing with hundreds of other messages, probably thousands. The obvious approach is a polite introduction and a lot of hope.

So I tried treating it like any other system. Instead of asking "how do I get this person to reply to me," I asked what the interactions that did work had in common. What kind of work does this person find interesting? What do they share? What makes them stop scrolling? Which creators have they actually engaged with, not just followed?

Here's how I'd test it. Picture a creator with a far bigger audience and a strong reputation in their space, someone who talks publicly, and often, about AI-built businesses, including how to launch personalized physical products with AI and agents. Interactive 3D product customization, where a customer turns and personalizes a product directly in the browser instead of staring at a photo, would sit right next to that territory. It also overlaps almost exactly with what I already build: Three.js, WebGL, spatial interfaces.

So instead of a message that says "I'd love to collaborate," what if I built a small, working experiment in that space first? An interactive product prototype for a Shopify store. A short screen recording of a personalized 3D product changing in real time. A link that makes the opportunity obvious faster than any pitch could.

The 3D isn't the point. The reasoning is. Find the overlap between what someone has publicly said they care about, the kinds of work they've actually responded to, and something I can genuinely demonstrate. Then turn that research into something useful before asking for anything.

That's when it clicked for me. Reverse engineering can study how opportunities happen, not just how software works: successful products, creative careers, partnerships, business models, the way people actually communicate.

09For freelancers and small studios, this is a service

Here's a question I keep turning over. As AI coding spreads, the floor for building a website or a basic feature keeps dropping. So why would a client still need a professional designer, developer or studio?

I don't think the answer is that we use more AI tools. It's whether we can solve harder problems than the ones AI has made cheap.

A client says "our dashboard is hard to use." The ordinary response is a UI redesign. The better one is to study how people actually work, find where the time goes, and propose changes to information architecture, interaction and automation. A client says "we want to add AI." The ordinary response is bolting on a chatbot. The better one is to understand the business process first and find where AI genuinely saves time.

I don't want to be someone who completes tasks faster with AI. I want to be someone who uses AI to help a client understand their problem and then build a better answer to it.

10I don't just want to use agents. I want to understand how to build the team.

Looking back, my own path with AI has a pattern I didn't notice at the time. When agents first started becoming practical, I was already sketching Nora OS: a personal AI system that could hold context, coordinate work, and handle more than one isolated task at a time. Later, as autonomous agents like Grokbot appeared, that idea turned into TeamBot, a team of specialized agents working together.

Now there's a whole wave of products built around persistent assistants, agent collaboration and AI-native workspaces: Dots, Muse, Duet, and more every month. Watching it has made me more confident about the direction. It has also made me ask much harder questions.

I don't think the future of serious AI work is one chatbot asked to do everything. Complex work is going to need specialized agents, shared context, coordinated decisions, and systems that learn from previous projects. The interesting question isn't how many agents you can spin up. It's how you organize them.

Who makes the final call? How does one agent hand reliable information to another? What happens when two of them disagree? How do they recover from a mistake? What should they remember, and what should they forget? Those are product architecture questions, not prompting questions. And they're exactly what I want to understand when I reverse engineer an AI product: not which model it runs or what its interface looks like, but the logic underneath the experience.

My goal isn't another generic assistant. It's understanding the architecture well enough to design an AI team around my own workflow. For Creator OS, that means connecting research, creative direction, production, quality control and publishing. For TeamBot, it means agents that genuinely collaborate instead of behaving like disconnected chatbots that happen to share a sidebar.

One concrete piece of that architecture I'm building now is a shared research layer under Creator OS, Video OS and Motion Studio. Different jobs, but all three need research, judgment and verification:

Next time a similar problem comes up, the agents don't start from nothing. They build on what's already been established and adjust for the new project.

Where the advantage actually lives

This also changed how I think about competing as an independent builder. Where can I make something that isn't just another version of an existing AI product? I don't think the answer is finding a feature nobody can copy. Features can be copied, now more than ever.

The stronger opportunity is understanding a specific workflow so deeply that you can build a system that handles it better than any general-purpose tool. My experience, my creative judgment, my production process and everything accumulated across my projects all become part of that advantage.

I don't want to compete on who has the most agents. I want a team that knows how to work together, and knows what it's working toward.

11It is not magic, and the limits matter

Every time a tool goes viral we get the same headlines. AI can clone any software. Software development is over. Anyone can build anything now.

I understand why those travel. But if you're trying to build something that lasts, they're worth resisting.

There's one more limit, and it's the one I think about most.

Understanding how someone else did it doesn't tell you what you should do.

A mature product may have a genuinely complex architecture that your MVP has no use for. A beautiful site may be full of WebGL, shaders and post-processing that would be wrong for your client. A gorgeous motion piece may contain dozens of refined details, and if your goal is explaining a feature clearly, that level of complexity will actively get in the way.

Research tells you what's possible. Design judgment still has to come back to the user, the goal and the context. Which is exactly why I don't think any of this makes designers or engineers less valuable. It gives people with judgment a much longer reach.

12The reverse engineering mindset

Put the stories in this essay side by side, a motion studio, an agent team, a pitch to a creator I admire, and the same five moves keep appearing. This is the framework I've ended up with. It works on software, but it was never really about software.

One piece of advice before using it: don't begin by pointing AI at an entire complex application, and don't go hunting for something to reverse engineer just to justify a new tool. Start from a real problem you already have. Then pick a step and read across the four domains:

And it's worth being concrete about what you're studying in each domain, and what you should walk away holding:

13Three experiments you could run this week

You don't need an agent team or forty skills installed. Pick whichever one is closest to the work you're already doing:

14I want to understand the system, not just use the product

Researching REA left me more convinced of one thing. AI is making execution easy. We can write code, generate designs, produce video and build automations faster than ever, and put together in days what used to take months.

As execution gets cheaper, other things get more valuable. Observation. Judgment. Taste. Understanding people. The ability to connect knowledge from different fields into something new.

And the more I explore reverse engineering, the less interested I am in recreating what already exists.

I don't want another After Effects. I want to understand how a professional motion production studio works, and see whether I can build a new kind of production system around that knowledge.

I don't want another chatbot. I want to understand how intelligent agents coordinate, make decisions, share context and work as a team.

And I don't want to blindly follow someone else's path to success. I want to study what created their opportunities, figure out which principles might transfer, and run my own experiments.

Not every experiment will work. Not every successful pattern will transfer. And understanding a system doesn't automatically mean I can build a better one. REA won't be the final answer either. More tools like it will come, and some of these capabilities will end up built straight into Claude Code or Codex. Tools change. Methods stay.

But I think this is where the real opportunity is. AI is making it easier to produce things. The more valuable skill may be understanding the systems behind those things, and having the judgment to build something genuinely different.

I don't just want to use the next generation of AI products. I want to understand enough to help build them.

Don't just copy what works. Understand why it works, then build something better.

What I'm doing next

Two experiments, all in public.

Run the Motion Studio example for real. One reference, one new brief, six steps, and an honest write-up of where the creative director agent makes good calls and where it doesn't.

Put evidence labels and black-box QA into my product workflow, so agents help me research and verify, not only build.

If you're building with Claude Code, Codex or another agent, I'd like to know: what do you most want AI to investigate properly for you? A software feature, a design style, an agent architecture, or a door you've been trying to open?

Based on public technical material, product design methods, and workflows I'm still exploring. The experiments suggested here are not claims that everything described has been fully validated.