Tu app hecha con vibe coding puede verse bien y fallar tras el lanzamiento. REA muestra cómo trabajan los equipos reales.

[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
[0:30] hardest problems in tech. It's why so much of what people write code looks right and falls apart soon after it's launched. REA closes a huge piece of that gap. It plugs into Claude 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 I'm going to
[1:01] 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 into 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
[1:31] numbers. The calculation combines an account key with a 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
[2:02] 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. It 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 it. 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
[2:32] 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
[3:02] 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
[3:32] 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?
[4:04] Does that solve my problem? Can I go faster by learning that? Okay, now I get it. Let's get going or let's tell my AI to get going as it happens in 2026. See the takeaway here? The pattern is that you can have the same tool REA, but with different starting knowledge you use it differently. And so like any instrument, you have to learn how to use it well. So let's get a little bit more specific about what REA looks like in practice. Suppose you want to make a tool for your own research. You want to collect passages from different documents, put
[4:34] your notes beside them, and find everything again when you sit down to write. You don't want a cluttered desk. You know the work. You know what annoys you about the tools you use. That gives you a good reason to build something. But knowing the work doesn't automatically tell you how it should be represented in software. I can't underline that enough. Is a quote just text on a page? Is it a separate object with a source attached? When you copy it into another project, what has to travel along? If you edit the copy, should the original change? These are real
[5:04] technical requirements you will have to discover, and each answer is going to push you toward different technical choices. This is where a lot of people, when I look over their shoulders, get bogged down. It's really hard. It's super difficult. You cannot always finish figuring out what you want, and then hand the completed requirements to somebody else, because sometimes you're discovering it as you go. Sometimes seeing how a system works is what lets you recognize the requirement in the first place. You didn't know a particular distinction mattered until you saw what it made
[5:35] possible, then it mattered. I have literally been this person for over a decade, looking over developers' shoulders, and REA is something I would have killed for. REA's notion investigation gives us a really concrete example here. It starts with an ordinary action. You copy something. Arya helps locate the desktop applications exposed clipboard interface, and it reads the surrounding code connects that interface into the system. The investigation also examines saved web editor code to understand how a copy can preserve
[6:05] Notion's richer block structures. In that code, Notion then sends text and HTML to the clipboard. It also keeps structured block data locally and puts an identifier in the HTML. So, when you hit paste, that identifier can reconnect the visible content with the saved structure. The recorded module test gets the rich block data back when the identifiers match. All of this is possible because we used Arya to understand how Notion does this.
[6:36] Now, look at what that teaches you about the research app we're talking about. Before this, you might have told your agent, "Make sure copy and paste works." It's a super reasonable request, but what does it mean? Does the quote arrive? Does the link to the source arrive? Does the note you attach arrive? How much do you care about these details? These details are what makes software feel polished. You can have the words on the screen and still be missing something you profoundly care about, and you may not even know it until you've built it, which has been a curse for Vibe Coders for over a year now. This is a much
[7:07] richer conversation you can have now before you've built the whole editor. Arya makes this possible. You're discovering what your information needs to have to be effective in a computing environment. If the relationship between a quote and the source matters, you'll need to find a way to preserve that relationship. You can ask your agent to show you a simple way to represent it, and then ask what copying that representation would involve. All of this, everything we're talking about, affects the technical stack you choose. An editor that handles a page of
[7:38] plain text gives you one starting point. An editor that needs to retain separate quotes and notes and relationships gives you a whole different starting point, much more complex. The way you store information has to support what you want to do with it. That is a larger lesson in 2026, guys. You're learning what to ask for and what the tech needs to support at the same time. And if you think none of the components in your idea match previous software, I have got news for you. They do. You may have a very particular
[8:09] combination of needs. Your workflow may be unusual, but I promise you other people have worked on editors, on document storage, on search, on copying, on linking, on moving information between places, anything in the computing environment, people have worked on it. You can learn from those solutions while you figure out your own, whatever your topic is. I feel very confident in that. Notice you didn't need to arrive knowing the entire detail or what the phrase structured block data means. All you had to show up knowing is I'm curious and I would like to understand what I'm working on and building. And then you keep
[8:40] interrogating using REA until you understand the connection yourself. And that's really your first job. Understand what you're trying to build. Your second job is to start when you ask why someone would arrange things this way and to get persistently curious cuz that leads you to your insight, what you want to make different. So, take the clipboard design. Why have ordinary text in HTML as well as a separate, richer representation? Think through what each one allows.
[9:10] Other applications can do something with text. Your own application may know about relationships and editing features. And you have to figure out, if you're designing a research tool, how much of all of these other requirements you've studied survives a particular copy-paste action. Copy-paste is very top of mind for me cuz I was just telling you guys a couple weeks ago how I built an active clipboard manager. So, I thought through a lot of this. And so, I wish REA had been out at that time. That would have been fun. Then, REA also
[9:40] helps us ask about the hidden costs of software. If your richer information depends on a saved local entry of data, what happens when that entry is gone? What is the delete function? Where Where does this dead information going? What happens when the content goes to another computer? Would your app need to put more information into the copied content? Would a separate export be a better choice? Basically, you can find out where there are dead ends in software or even what I would call bugs in software that you don't want to replicate. So, these are all questions
[10:11] for you to think about through your design prompted by an observed implementation. We can reason about consequences for the first time without pretending we know everything ahead of time. If the original team published an explanation, which they almost never do, that's great. But, we don't have to have that. We can just ask the agent to understand the code and help us to interpret it together. You can work with Codex with Claude to do that. You are now, like it or not, participating in an engineering conversation. You can say, "I need the source to survive when I
[10:41] send this quote to a colleague even if they don't use my app." Or, you can say, "This only needs to work inside my workspace, and a simple approach is more than enough." Either way, it's up to you. You understand more of what you're asking for and what the implementation has to preserve. You are smarter as a leader for AI, which is another big theme for this year. There's another REA example that makes this problem almost ridiculously clear. The percentage button in a Windows calculator. Enter 200 + 10% and you get 220. Enter 200 *
[11:12] 10% and you get 20. Same button, different context. If you investigate that, and REA did, you find out that the installed calculator library and the recovered branch behind that behavior helps you figure out what it's doing. After it adds 10% becomes 10% of the first number. After a multiplication, uses the operation you've already selected to contextually decide what that button means when you click it.
[11:42] Imagine specifying that feature to an AI builder for something as simple as a calculator. I need a percentage button. Okay, great. The agent can give you one. But until you've thought through those different situations, you haven't actually specified the real behavior. A screenshot's not going to fix that, is it? Looking at a working implementation can tell you what's missing here. It It tells you that percentage matters in context, and you have to wire up the context awareness into the calculator. And that carries over to much bigger
[12:12] decisions. When you say send a reminder, when does the clock start? I've seen literal examples of this, by the way, where I've seen Mews and other agents send reminders and they're late, and the clock started late. So, this is not theoretical. People are experiencing this in 2026. Or when you say approve a request, which permissions change? When you say undo, how much work ought to disappear? Understanding a real implementation helps you get past the high-level teaser trailer feature and
[12:43] into the decisions that make the feature useful. It's as if we're watching a teaser trailer for the Odyssey and we didn't actually see the whole film. This is why I don't want to undersell what is happening here with REA. We get to see the whole film. We get to see all of software. Getting from I want this to a description that fits a technical system is one of the most difficult things in software. If you get it wrong, you can spend a lot of time making something very polished that does not handle the situation you needed it for. An agent
[13:13] can help you discover those requirements by studying how an existing application handles a related problem in detail. Now, let's come back, as I promised, to the QuickBooks example, because this is happening beyond little teaching demos. A community developer published a project called Ledger Reborn, which hey, great name, after investigating QuickBooks Desktop for Mac with REA. The account describes focused work on inventory arithmetic, budget signs, reconciliation balances, and branches
[13:44] involved in cash basis recording. They then independently implemented an application that does all that using Python and SQLite. The developer's published preview saves invoices and recorded payments in a local ledger, inventory, and calculates reports, all this stuff, right? Basically, REA supplied evidence and pseudo code to sort of show how stuff works, and then they did an independent implementation to actually follow the patterns that interested them. So, what fascinates me here is the kind of
[14:15] question they investigated. If all you do is copy an accounting screen, you can reproduce where the number appears without understanding how that number was produced. So, in this case, the investigation went into calculations, went into ledger behavior, and that's where the software's meaning actually lives. And it's the part you need to understand if you want to make a workable version. Think about a requirement as ordinary as recording a payment. Does the payment cover the whole invoice?
[14:45] Can one payment cover several invoices? What remains outstanding? What should a report show? Those are all interconnected decisions. You need a representation of the information that can support the behavior, and you need checks that tell you whether the result is right. You can see why domain knowledge matters so much here. Somebody who handles invoices every single day may know which situations are common and which mistakes create extra work. REA gives that person another way to connect
[15:17] their knowledge to the technical decisions underneath. They can investigate with an agent and keep asking questions until the proposed system actually accounts for work. The original application might use a very very different stack from the one that you choose. You don't necessarily want the entire architecture. You want to understand the behavior that matters to you, right? Like that's what we all want to do. We're not trying to necessarily make clones here. We're trying to make personal software that matters to us or software for a small
[15:48] audience. That's why the move from an inspected desktop product to a separate Python and SQLite application is super interesting. The investigation informs a new set of engineering choices. And you can do that useful work without setting out to replace the accounting product, right? I keep saying that because people misunderstand when they think it's just copying. Your product might handle the only task you need in the business. And the opportunity here is to understand that particular task at a level where you can explain what ought
[16:18] to happen, choose an appropriate implementation with a lot of background knowledge, and recognize whether it works. You decide how much you need to build, and now you have the technical lenses to examine software and understand how to do it. For developers, we can zoom in much farther, right? You may already know the data structures, the framework, the constraints. You're looking at a feature and thinking, "How exactly did they get that behavior? Give me the relevant mechanisms, and I can get moving, right?" So, I think REA's dinosaur game example is a great demonstration of that. They inspected a
[16:48] browser edition derived from Chromium's dinosaur game and retrieved the JavaScript actually loaded by the page. The question was why the game keeps getting faster. The code starts with a speed value of six and adds a thousandth on each update without a collision while the speed is below 13. And this gives you a nice rule to work with and explains the game feel. The project uses it in a small new game with a speed control, and you can actually just implement it right away. You can keep the recovered acceleration, you can speed it up faster to make it even harder. But regardless, the
[17:19] project's comparison actually digs into the behavior underneath the screenshot. The behavior that you need to have on interactivity at the code level, so you can use it for yourself if you're building your own game. That lets you make much more precise changes. Maybe you want a gentler increase, maybe you don't, but you get to decide because you looked under the hood. The last question here is about engineering work. Really, engineering work is becoming less can I understand the system and more deciding
[17:49] how I want to configure the system. REA just accelerates that. The agent can help follow these dependencies, explain the rules, implement the version you choose, and the investigation is all sped up for you now. But you still have to decide what you want to build. The native code version of this is in REA's DX ball case study. They traced how a brick's horizontal position becomes a left-right sound pan value inside the compiled game. The initial decompiler output was incomplete, so the investigation followed instructions and callers and
[18:20] constraints, and the published reconstruction figured out a recovered function that actually works against the original. Now, that's a super focused question. You don't need to reconstruct an entire game to learn how that relationship works, but if a developer can take REA and go to that level of detail, then you can really ask anything you want. A non-developer can ask a much simpler question and get a great explanation. And one of the things that I would think about if you're using this tool
[18:50] is I would think about how deep you ask it to go. If you ask for a complete explanation of an application, you will get an enormous amount of material that doesn't help you make your next decision. Give the agent a reason to investigate. I I like that behavior. I just I want to understand the result. Help me follow the relevant part. My ask to you is if you're using REA, you're getting the idea here. Tell it how deep to go. Tell your microscope what to focus on. And so for a non-developer, I would start by describing the work I
[19:20] want my software to support and then ask the agent to identify familiar components and dig into them for me. And you can keep kind of digging around and understanding the terms. You can even get it to make you diagrams. For a developer, you can describe the situation and your own constraints more precisely. So find this implementation, help me understand these dependencies. This is what I'm stuck on. Help some examples here and then help me implement. And that can be a very short, sharp investigation when the question is narrow. Basically, don't burn your tokens if you don't need to. That's an
[19:50] evergreen recommendation I have. To get started, you just connect REA to a coding agent like Claude or Codex as I've been saying. And you do want to be aware there's some official setup here. It will use node.js, it will use npm, and different targets need different inspection tools. So there's some stuff where it's going to say, as you install it, do you want to add this? Look, this is going to sound silly, but ask your AI what adding it would make a difference for in terms of the project you have. Sometimes you'll need it, sometimes you won't. node.js is not a scary thing if you need to install it. And remember when you dig in, you are not going to
[20:21] see server-side code. So this is just showing you client-side code and so there are some instances where a company is going to have their own private server-side code that's never exposed. You may infer what some of that code does from the interactions on the application, but you're not going to see it, nor should you try because that would be hacking. Don't do it. And as a teaching tool, like if you're starting to install this and use it, you're like, Nate says to use it. Here's the first thing I would do. Make sure that you are using it to learn. This is such a powerful tool for learning. Even as an
[20:51] engineer, you can talk to an application, understand how it works, and then try and explain it back in your own words. That's how so much of learning works. And now we basically have a tireless teacher who understands software on the internet, who can go to a technical depth that was a little bit harder to get to before this and we can actually dig in and learn. And I think that's how this starts to change our relationship with software. We can look at something familiar and realize there's a question that we always wanted to pursue and just go and do that. And if you're wondering, couldn't Codex do
[21:21] this before? Couldn't Claude do this before? They could if you prompted them carefully and you were patient with them, but RAE gives us all of that out of the box and it's super simple. For the non-developer, for all of us who are not technical builders, this is a route into understanding software we never had before. We were unlikely to be able to do that fancy prompting. We can actually get in and understand it and get an x-ray vision that we never could have had to software. There's an enormous amount of human problem-solving embedded
[21:53] inside the applications you already use. Whether you're developer or not, you now have another way to examine it with an agent that can help explain what you're seeing. So, pick something you're curious about. Start digging in and looking. You may discover that you're capable of asking and answering much more interesting questions than you thought. If you're a software nerd, RAE is a great date. You might be wondering, how do I get started with RAE? Nate just gave us the install thing. So, I'm going to put together a Substack post that actually gives you dig points, specific
[22:24] places to go in and start to use RAE. So, if you're like, I have this power, I don't know where to use it, we're going to help you find a way to use it. Hop on in, the community is cooking. Cheers.