REA for AI Agents: What It Can Prove About an App
REA, short for Reverse Engineer Anything, gives an AI agent tools to inspect software and collect evidence about how it works. It can help answer a concrete question, such as where an export file is created or which function handles a button.
The useful part is being able to check the answer. A confident explanation alone leaves you guessing whether the agent found something in the app or filled a gap.
For this article, we created a tiny JavaScript example and inspected it with REA. The tool found the file connection, reported no parsing failures, and still left a return value unresolved. That combination is a useful lesson in reading AI analysis.
Key Takeaways
- REA connects an AI agent to software inspection tools. The agent turns their results into an explanation.
- Start with one feature and a specific question.
- A complete static scan can still contain unknown values.
- Keep code observations separate from results captured while the app runs.
What does REA do for an AI agent?
REA gives an AI agent software inspection tools over MCP or a command line, and the agent turns their output into an explanation you can check against the tool's own report. It also provides a command-line interface.
Its official repository describes support for native programs, JavaScript and Electron apps, managed code, and browser activity. The available analysis depends on the target and the tools installed on your machine.
Think of an export button. The visible button is only the start. One file may handle the click, another may prepare the data, and another may write the result.
An agent can use REA to locate those pieces and explain their connections. Each finding should point to something you can inspect: a file, a function, a recorded request, or another concrete result.
REA's Electron export guide shows this with a small app. It follows an export request across the page, a bridge between processes, and the file writer. That is the publisher's example; our smaller demonstration appears below.
Why choose the question before the tool?
Choose one feature and one question before choosing a tool, because “explain this whole app” is a request no report can verify. A better starting point is:
When I export a report, which code chooses the destination folder?
That question gives the agent a feature, a boundary, and a useful stopping point.
If you have the complete source code, ordinary code search may answer it first. A two-file project rarely needs a specialized reverse-engineering tool. We use one here because it makes REA's output easy to check.
| What you have | A useful first step | What still needs checking |
|---|---|---|
| A readable source folder | Search for the button label or export function. | Whether that code runs in the situation you care about. |
| A packaged JavaScript or Electron app | Inspect the package and follow the relevant file connections. | Dynamic values and behavior that depends on the running app. |
| A native application | Check REA's supported analysis engine and target format. | Whether recovered code explains the specific feature. |
| A browser interaction | Record the chosen action and inspect its requests or script activity. | Other users, inputs, sessions, and conditions outside that recording. |
REA's browser guide describes the last kind of investigation. A recording can show what happened during an action. It does not cover every action the application could take.
What did a small REA example show?
In a two-file JavaScript example inspected with REA 6.4.0 on October 28, 2026, the tool found the file connection and reported no parsing failures, yet left one return value unresolved.
The example is deliberately small. It represents a preview of approved expenses. No private data or third-party application was involved.
Create a folder with these three files if you want to inspect the same example.
package.json
{
"name": "rea-expense-demo",
"version": "1.0.0",
"type": "module",
"main": "index.js",
"private": true
}
index.js
import { summarize } from "./summary.js";
export function preview(rows) {
return JSON.stringify(summarize(rows));
}
summary.js
export function summarize(rows) {
const approved = rows.filter(row => row.status === "approved");
return {
count: approved.length,
totalCents: approved.reduce((total, row) => total + row.cents, 0)
};
}
In plain English, the source keeps approved rows, counts them, and adds their amounts in cents. The preview function converts that summary to JSON text.
That explanation comes from reading the code. We did not execute the example or test its behavior with sample expenses.
We called REA's analyze_javascript_application tool with the folder path, directory format, complete detail, and a 30-second analysis timeout. The timeout was a limit, not a measured completion time.
The result reported:
| Check | Observed result |
|---|---|
| Relevant files | 3 |
| Parsed JavaScript files | 2 |
| Parsing failures | 0 |
| Graph coverage status | Complete, with no truncation reported |
| Source import | index.js imports summarize from ./summary.js |
| Exported names | preview and summarize |
Inferred return value for preview |
Unknown |
The graph represented the single source import in two relationships: a file connection and its imported binding. Counting those as two separate imports would misread the result.
Why can a “complete” REA scan still report an unknown?
A scan can be complete and still report an unknown, because completeness describes the graph the scan covered rather than every value it could compute.
For preview, the analyzer reported the reason Unsupported CallExpression value.
A call expression is code that calls a function. Our return statement contains function calls, including JSON.stringify. REA's static result did not resolve the returned value.
This does not mean the example failed to run. We never ran it. It means this analysis did not establish that value.
“Complete” described the reported graph coverage within this scan. It did not mean that every possible output had been calculated.
This distinction also appears in REA's reconstruction-readiness documentation. Its static checks and synthetic reports are distinct from running a reconstructed application and checking equivalent behavior.
Our demonstration supports a narrow conclusion: REA recovered the file relationship and exposed a limit in its value analysis. It gives no evidence about large-app coverage, time savings, or the reliability of a rebuilt product.
What prompt keeps an REA answer checkable?
The prompt below gives the agent one folder and one question, and asks it to separate observed facts, inferences and unknowns before it proposes a single test. For our example, you could use:
Use REA to inspect this local example folder.
Question: How does preview depend on summarize?
Inspect the files without executing the application.
List the files and functions that support the answer.
Separate:
- Observed facts from tool output or source
- Inferences that still need checking
- Unknowns and why they remain unknown
Finish with one proposed test for the most useful unknown.
Do not run that test yet.
The last line keeps inspection and execution as separate decisions. It is useful when you want to understand the app before running it.
For a real export feature, change the question to “Where is the export file written?” Keep the same evidence requirements.
A useful answer might identify the path-building function and show the matching source location. If the destination depends on a runtime setting, the answer should say so.
How do you turn a finding into a test?
Turn a finding into a test by naming the input, the expected result and the output you actually observed, then keeping that result with the version and the limits of the check. A proposed test could supply one approved row and one pending row, then compare the output with the expected approved total.
That test has not been run for this article. It illustrates the next step: choose an input, state the expected result, run the relevant behavior, and keep the actual output.
Record the result with enough context to check it later:
- The application or example version.
- The input and action used.
- The observed output.
- Anything the test did not cover.
When switching between AI agents, carry that record forward. Our shared worklog guide for Claude and Codex describes a way to preserve findings and next actions.
For a larger investigation, use a small mission with a clear finish. “Find the export destination and save the evidence” is a manageable first session.
How do you get started with REA?
Start from the official setup guide, match the install route to the kind of software you want to inspect, and ask one question before you widen the scope. Requirements vary with the kind of software you want to inspect. Native analysis can require an additional analysis engine.
Before installing anything, identify your target and check which route supports it. Reading a JavaScript package and inspecting a compiled desktop program are different jobs.
For your first attempt, choose software you own or are authorized to inspect. Ask one question, request the evidence, and read the unknowns before expanding the task.
A successful first session can be small: one feature explained, one source location saved, and one unresolved question stated clearly.
About the author: JH-A publishes Charrette AI Room, a blog about practical workflows and digital tools for everyday work.
Method and disclosure: This article was prepared with AI assistance. The example was created for this article and inspected through REA's static JavaScript analysis tool. Source files and the tool result were compared. No application execution, performance benchmark, or production reconstruction was performed. The illustration is AI-generated.
Sources checked: October 28, 2026. Tool behavior described here comes from the recorded REA 6.4.0 session; later versions may differ.
Frequently Asked Questions
What does REA stand for and what does it do?
REA stands for Reverse Engineer Anything. It connects an AI agent to software inspection tools over MCP or a command line so the agent can collect evidence about how an app works and explain it.
Can REA prove how an app behaves while it runs?
No. A static scan shows code structure, and its report can still contain unknowns such as an unresolved return value. Runtime behavior needs a test you run and record separately.
Do I need REA for a small, readable project?
Usually not. Plain code search answers many questions in a two-file project; this article uses REA only because it makes the tool's own report easy to check.
Which software should I inspect first?
Something you own or are authorized to inspect, with one feature and one question. Before installing anything, confirm that your target type has a supported analysis route.
Comments
Post a Comment