Ok, that caught me for a moment: a framework that connects the classic disassemblers, Ghidra, Hopper, IDA, with a coding agent. You point at a feature in a foreign app, the database view, an interface element, and the agent analyses how it works and rebuilds it in your own code. Without source code. Locally on your machine. It is called "Reverse Engineer Anything", and the name is not even exaggerated. I find that heavy. Not because it is new. Because it no longer costs anything.
What the tool does
The approach is clever because it thinks small. Not take the whole application apart, but isolate one feature. You use the feature in the app so it is visible, then you let the tools collect the binary code, the calls and the data flows for it, and the agent translates that into something a human can read: this is how it works, these are the interfaces, these are the steps. From that comes a specification, and from the specification your own code. One feature after the other. With the instruction to deliver evidence instead of guesses, and with the advice to run the whole thing locally so nothing leaves the house.
I read the article, I did not try the repo. So I take the demo for what it is: a demo. But I know all the building blocks, and they work individually. That they work together is no longer a question for me, only a question of reach.
How it works, in five steps
On the side, for those who want to know technically. None of it is magic, it is the work a reverse engineer used to do by hand, just split between tool and agent.
Trigger the feature. You start the app and use exactly the feature you want to understand. Meanwhile a tracer watches: which functions in the binary run, which calls go into the system, what goes over the network, what is written to disk. That narrows it down. Of millions of lines, the few hundred remain that really have to do with the feature.
Make the code readable. A disassembler like Ghidra takes the binary and translates the machine instructions back into something that looks like code: functions, variables, call graphs, with invented names, because the real ones were lost at compile time. That used to be the part for which you needed years of experience to recognise anything in it.
Give the agent only the excerpt. Not the whole application, only the functions from step one, in the form from step two, plus the observed calls. That is the clever part of the framework: the agent gets little context and a clear question, and that is exactly how models work best. I described why in the MCP article.
Describe with evidence. The agent writes down what the function does: input, output, intermediate steps, which data it reads, which interfaces it calls. And for every statement the place in the disassembled code or the observed call it comes from. Without that evidence the description is a guess, with it it is a specification.
Rebuild and test against the behaviour. From the specification comes your own code, in the language you want. And then the part many leave out: the same inputs as in step one, and check whether the same outputs come. If not, the description was wrong, not the code.
What is new about it, and what is not
Reverse engineering has existed for decades. I have rebuilt protocols myself because the documentation was missing, and read binaries because the manufacturer no longer existed. It was always possible. It was only expensive: specialists, weeks, tools with a learning curve like a wall. Those costs were the protection. Not the law, not the encryption. The costs.
That is the same movement as with code itself. I wrote that code is getting cheap and knowledge is not. Now reading foreign code is getting cheap too. And with that falls a protection many did not know they had.
Who it hits
Not everyone equally. It hits the companies whose lead consists of a feature you can see. The pretty database view, the clever export, the one function people pay the subscription for. If an agent analyses and rebuilds that in an afternoon, the lead is an afternoon. The subscription model for small tools that rests on "we have this one feature" comes under pressure with that, and not from big competitors, but from every single customer who can build it himself.
It does not hit the companies whose value lies elsewhere. More on that in a moment. But it also hits security, and that is the part the article only touches: whoever can understand a feature can also understand its weakness. The same cost reduction applies to the attacker. That is not an argument against the tool, attackers always had the specialists. It is an argument for no longer building security on "nobody understands that anyway". That was always a bad idea. Now it is a wrong one.
Where it does not work
I do not want to make this bigger than it is. Four limits I see, from experience with exactly this work.
The backend. What happens on the server, the agent does not see. It sees the request and the response. The logic in between, the business rules, the data they rest on, remain invisible. For most serious applications that is the part that counts.
What is not in the code. Why the feature is built this way. Which edge cases from ten years of customer operation are in it. The agent rebuilds what it sees. It does not rebuild what someone learned. That is the process knowledge I wrote about in "Human times AI", and it is not in the binary.
The evidence. The article rightly says: always ask for evidence. I say: that is not enough. An agent that misunderstands a feature and still rebuilds it plausibly delivers code that looks like the original and behaves differently. You do not notice that when reading. You notice it at the customer.
"Local" is not automatically private. The tool runs locally. The agent behind it calls a model in the cloud. What it analyses goes to the model. Whoever examines foreign software to protect his own may be sending his own along. Local only means local when the model is local too.
What I would do with it
I see one use that really interests me, and it has nothing to do with foreign software. Almost every company I work with has legacy systems nobody understands anymore. The manufacturer is gone, the developer is retired, the source code is there but explains nothing, or it is not there, and the binary has been running for twelve years because nobody dares to touch it. That is the system where everyone says: we cannot replace that, we do not know what it does.
That is exactly where I would use such an agent. Not to rebuild, but to understand: produce a specification feature by feature, with evidence, which input leads to which output, which interfaces are called, which edge cases are in the code. Then, for the first time in twelve years, you have a description of what the thing does. And only then, with people who can place the edge cases, you build anew.
That is the idea I want to examine for NeoCoder: a software understanding agent for your own legacy systems. With two things the framework in the article does not have. First, a permission check up front: the agent only works on systems for which there is proof that they belong to us or to the customer. Not as a prompt, as a gate. Second, the evidence as a chain: every statement in the specification points to the place in the code or the observed call it comes from. The way everything with us has to be backed. An agent that explains to me what a legacy system does without showing where it knows that from is an agent that guesses.
What I would not do with it
Rebuild foreign products to sell them. And here I have to be precise, because the reflex "that is prohibited" falls short. What the agent does here is not copying code. It looks at what a feature does and builds it anew, in its own code, perhaps in another language. Copyright protects the code, not the idea and not the function, I described that in the copyright piece, and a clean rebuild from observed behaviour has been a known and often permitted practice for decades. I am not a lawyer. But this much I know: it is not automatically prohibited, and it is not automatically permitted either. In between lie licence terms that often forbid disassembly, patents on individual methods, trademarks, trade secrets, and the question of whether the agent did not after all carry pieces of the original along while analysing. Whoever does this commercially needs someone to check that. That is why I would not do it. And second, because it brings nothing. Whoever rebuilds a feature has a feature. He does not have the customers, not the knowledge, not the twelve years of edge cases. I wrote in the copyright piece what a software company still sells in the future: architecture, decisions, understanding, care. None of that can be pulled from a binary.
What your code is worth in five years
And with that to the question that occupies me most, because it goes beyond the tool. If an agent can understand foreign software, rebuild it and then improve it, what is the pure source code of a software company still worth in five years?
I think: little. It was not what people thought even before, I described that in the copyright piece: purely machine-generated code belongs to nobody, and two companies with the same model get the same software. Now add that code written by humans can be rebuilt too, by anyone, in an afternoon. What remains is the same as there: the knowledge of why it is built this way, the people who can explain it, and the ability to keep developing it over years without it tipping. That is the film, not the photo. An agent with a disassembler sees a very good photo.
What stays
The tool is heavy, and it is here. I would use it for the one thing it is really good for: understanding your own legacy systems nobody understands anymore, with evidence, with a permission check, with people who afterwards place the edge cases. I would not use it to rebuild foreign products, not because it is automatically prohibited, but because the grey zone is large and because it brings nothing. And I would stop regarding source code as a lead. It has not been one for a long time. Now you just notice.
Reverse engineering always existed, the price was the protection, and the price is gone. Who it hits: companies whose lead is a visible feature. Who not: companies whose value lies in the knowledge of the system. I would point the tool at our own legacy systems, with evidence and a permission check, and at nothing else. The code was never the treasure. The understanding is.
Source: Julian Horsey, "Pair REA with Claude Code to Analyze Apps Without Source Code", Geeky Gadgets, 22 October 2026, on the framework "Reverse Engineer Anything" by Zinho Automates. Read, not tried. geeky-gadgets.com
Written by me. The thoughts, the values, the learnings, the mistakes: all mine. Grammar and spelling are corrected by a twin model of my own, trained on my texts. Sometimes that turns into a mix. Of course I read everything again, but nobody is infallible. Whatever stays in is mine too.