REA: When the application becomes the specification

REA stands for Reverse Engineer Anything. The project connects coding agents with tools for analyzing applications, compiled programs, and runtime behavior. This allows the agent to understand how a feature works and build its own implementation.

This shifts the starting point. Instead of describing every detail of a desired feature, you show the agent an application and ask a specific question: How does this search work? What happens when copying? According to what rule is this value calculated?

The existing software provides reference material and verifiable evidence. From that, a more precise specification can emerge. That is precisely where REA becomes interesting.

Reverse engineering has been around for decades. Analysis tools like Ghidra, Hopper, and IDA are well established too. REA makes them accessible to agents via a common interface and pairs them with structured investigation workflows.

What interests me most about it is how it handles certainty. In its findings, REA differentiates between observations, inferred insights, and assumptions. Evidence retains its provenance, its limitations, and connections to other findings.

This helps counter a familiar pitfall: The agent finds a plausible clue, formulates a convincing explanation, and builds upon it. With traceable evidence and open questions, it is easier to spot early on where a conclusion still needs verification.

The strongest example is unspectacular. In the game DX-Ball, a function was reconstructed that calculates the left-right sound panning based on a horizontal position. The published case study reports 3,205 comparisons with the original machine code and 63 identical compiled function bytes.

Here, a clearly bounded calculation was examined and verified. The reconstruction of the full playable game was still a work in progress at the documented project milestone. It is precisely this boundary that makes the example useful.

A second example traces the path of a copy command in Notion through the various layers of the Electron application all the way to the clipboard. The case study reveals which code locations substantiate the flow. In this way, "copying works somehow" turns into a traceable process.

The viral narrative, by contrast, leaps quickly from a working snippet to a fully replaced product. PhotoCraft, for example, is being passed around as a reconstructed Photoshop. The project itself labels itself an early alpha and explicitly notes that it does not yet replace Photoshop for daily professional work.

Particularly revealing: PhotoCraft distinguishes between wired-up menu commands and genuinely matching behavior. A menu item might exist, while the depth, compatibility, or quality of the feature is still missing. Anyone evaluating software needs to look right there.

For practical use, I would therefore start small. A specific feature provides a testable task. "Rebuild this entire application for me" initially opens up far too much latitude.

The data question remains concrete as well. REA analyzes locally, but the agent receives the findings. With a cloud-hosted model, this information may reach the model provider. For internal applications, this data flow is a key factor when choosing your setup.