Reverse Engineer Anything (REA): 5 Places to Point Your AI

Nate B. Jones (0:00)

You may have watched REA blow up this month, or maybe you missed it, but either way, you want to pay attention to this one. Reverse engineer anything. Well over 100,000 GitHub stars in just a few days, and the loudest takes say software is done. I don't think that's right. You know exactly what you want your software to do. What you've never been able to see is how a real team turned that kind of want into something that actually works. That gap between the business requirement and how something's put together is one of the hardest problems in tech. It's why so much of what People Vibe Code looks right and falls apart soon after it's launched. REA closes a huge piece of that gap. It plugs into Cloud Code or Codex, and it lets your AI open up software on your computer and show you how it's actually built. You're not cloning anybody. You're learning from people who did the hard thinking so you can learn to build better software. Look, there are two very different ways to use this. If you build software, it's an accelerator. If you don't, it's an x-ray machine, right? I'm going to show you both, starting with the one most people are missing. Think about the authenticator on your phone. You probably have one. Six digits show up, the little timer runs down, and the digits change. You probably use something like that to log in to a work account. But where does that number come from? What makes it change? What would you actually have to build to make a tool like that happen if you wanted to make one? REA has a published investigation of Aegis, which is an Android authenticator app. They took the released application package, and they followed the code that generates those numbers. The calculation combines an account key with the current time grouped into 30-second intervals. It basically shows you how it works. The same key in the same interval can produce the same code. They then made a small demonstration where you can move the clock and watch the result change. The point here is not that you want to build an authenticator app, right? The point is that you can take the most trivial examples of software where you've always wondered how does this work and I want to make something like this but polished or I want to make something like this but a little different. You now understand how it works. You can go from looking at six mysterious digits to actually understanding and picking apart the relationship that produces those digits. You can ask which part depends on the clock and which part depends on the account. You have a real implementation of whatever you want. Doesn't have to be an authenticator app. It doesn't have to be a calendar app. It can be literally anything on the web to examine while the agent helps you understand and that's what I'm interested in. It's like getting X-ray vision for all of the software in the computing world. All these things you interact with every day contain decisions that somebody made. And now you have a way to start seeing those decisions in detail. You can ask questions about them. You can learn from them. Yes, you, including you, if you've never written a line of code. And there are people already using this on much, much larger projects. The authenticator app is a silly one. You can get much bigger. One developer used REA already to investigate parts of QuickBooks' desktop and then built an independent accounting application. We'll get into what that actually involved, because the interesting part is how the investigation helped connect the behavior of the software to the work of building something else. People are calling REA the death of software. Boy, have we heard that before. I'm so tired of it. I think that misses how few people understand the software they're already using, much less the software they're trying to build. Giving more of us a way to acquire understanding is a positive thing. It's a huge deal, especially now that an agent can write so much of the code for you. You still need some way to figure out what code should do, but for a non-developer, you have a huge leg up. In fact, I'll go farther. For a non-developer, I think there are two key jobs that REA does. First, understand the software you want to build. We've talked about that a little bit here. Like what are the components? What needs to happen inside it? Second, understand why an implementation makes the engineering choices it makes, so you can decide which choices belong in your implementation. For a dev, the question is often narrower. How did they do that? Does that solve my problem? Can I go faster by learning that?