Notes on working with AI
Understand the software before you clone it
Agents can now explain how an app works without its source code. The valuable output is the mechanism and its evidence, not the clone. Here is the line.
The clone is the least useful output
A new kind of tool lets a coding agent study software it has no source for. REA (Reverse Engineer Anything) is an open-source MCP server plus workflow instructions, MIT licensed, that works with Claude Code, Codex, Cursor and Gemini CLI. Point it at a native binary, an Electron app, a .NET assembly or a website, and the agent inspects the target and reports how a feature works. It also reports the evidence behind each conclusion and the limits of the analysis. Analysis runs locally.
The obvious use is to ask for a copy. I think that is the least valuable thing it produces. The valuable output is the explained mechanism: this feature does this, in this order, because of this evidence, and here is what I could not determine.
Why the evidence matters more than the answer
A conclusion drawn from a binary or a bundled script is a hypothesis. Static analysis shows structure. It does not show intent, and it can't show what happens on a server you never touched. An agent will explain a function confidently even when it understood half of it, which is the same failure mode as any fluent model.
This is why the evidence-and-limitations part of the output is the product. A claim with a pointer to where it came from can be checked in a minute. A claim without one has to be trusted, and trust is the wrong default for a reverse-engineered conclusion.
When you read the report, sort it into three piles: observed directly, inferred from what was observed, and unknown. Only the first pile is a fact. Build on the second only after you have tested it.
Understand, then build your own
The pattern I teach has three steps.
First, extract the mechanism: what the feature does, what data moves where, which edge cases it handles. Second, write a spec in your own words, for the simple version you actually need. Third, implement from the spec, not from the original.
That order does two things. It gives you a version fitted to your project instead of someone else's compromises. And it keeps the work clean: you carry forward an understanding, not their code, their text or their design.
Copying is the wrong pattern, technically as well as legally. A lifted implementation drags in assumptions that made sense in a different product, and you inherit bugs you can't explain.
Where the line is
Licenses and terms of service decide what you may analyse, and many forbid reverse engineering outright. Analyse software you have rights to, or work for interoperability and learning where the law and the terms allow it. Studying how your own legacy system works, or how a file format behaves so your tool can read it, is a different act from lifting a competitor's product. If you are unsure, ask someone who reads contracts for a living before you start.
Install it only from the source
This kind of tool has deep access to your machine, which makes a fake copy valuable to an attacker. The project's own README warns that copies circulate. Get it only from the official repository, from rea.tools, or from the rea-agents npm package. Setup needs Node.js and one command:
npx rea-agents setup
What to do tomorrow
Pick one feature of an app you rely on and have the right to study. Ask your agent for three things: how it works, what supports each claim, and what remains unknown. Then ask for a one-page spec of the simplest version you would build yourself.
Read the unknowns first. They tell you how far to trust the rest.