A button does something useful. You want to understand the part between the click and the result. That is a much better starting point for REA than asking it to rebuild an entire application.
The answer in a minute
REA connects a coding agent to software analysis tools. The agent asks questions, REA inspects a target, and the returned evidence helps the agent decide what to examine next. That target might be a local application package, a compiled program, or a browser workflow.
Think of the agent as the investigator and REA as the equipment. The equipment matters, but the question determines whether the investigation goes anywhere.
Our recommendation: choose one visible behavior, write down an input and an expected output, and ask for the evidence linking them. A note exporter is a reasonable first target. An entire note-taking service is a very different project.
What you get back
The output depends on the target. A packaged Electron app may reveal JavaScript relationships and IPC boundaries. A native executable may yield instructions, pseudocode and references through an analysis engine. A browser session can reveal client behavior and observed requests.
These are different kinds of access. Looking at a request sent to a server does not reveal the server’s implementation. Reading a native function does not recover its author’s original variable names.
For a useful report, ask the agent to keep three things separate:
- Observed: a source location, instruction, request or captured result it actually found.
- Inferred: an explanation supported by those observations.
- Unknown: the part it could not establish with the available target and tools.
Those labels are our editorial convention. They help you read the underlying REA evidence without mistaking a plausible story for a finished investigation.
Where beginners usually overreach
A screenshot tells you what an interface looks like. It rarely tells you how an export is encoded, how a queue survives a restart, or what a server checks. Starting from a screenshot alone can produce a convincing imitation and leave the important behavior unexplained.
A smaller task gives you something concrete to verify. Can the reconstructed exporter handle a comma inside a note? Does cancellation leave the existing file untouched? Does an empty list produce a sensible result?
Your first useful prompt
Use REA to investigate the export feature in this local learning app.
Trace the button to the code that writes the file.
Show the relevant files and relationships, separate static findings
from runtime behavior, and list what you cannot verify.
Do not implement a replacement yet.You do not need to know assembly to ask this question. You do need a target the tools can inspect and a way to check the answer.
Pick the route that fits
If REA is new to you, connect your agent and try the Pocket Notes investigation. The fixture is deliberately small, and we retain the actual analysis result.
Already comfortable with the basics? Explore Electron IPC or read why the DX-Ball case checks a recovered calculation against the original. The interesting moment is when a claim becomes something you can test.