REA gives coding agents the tools to reverse-engineer and explain programs

A new tool called REA, short for Reverse Engineering for Your Coding Agent, reached Hacker News's front page on 10 October 2026, according to the site's RSS feed. Its pitch is that instead of a developer grinding through disassembly by hand, an AI coding agent receives a toolkit for examining a target program and describing what it really does.

What REA does

According to the project's site at rea.tools, installing it is a single command — npx rea-agents@latest setup — which links REA to a coding agent, presents a setup plan for approval, verifies the installation and then asks for an agent restart. The same flow can be triggered by pasting a plain-English instruction into the agent instead of typing the command.

From there, the division of labour is deliberate. REA gathers the raw evidence an agent cannot collect on its own, such as instruction listings from a routine, decompiled code, information about which functions call which, or the script actually loaded in a web page. The agent then reasons over that material to determine which code path runs, what it computes and how a feature might be changed or rebuilt. The site defines reverse engineering broadly as learning how software works by studying the program itself, with the aim of understanding a feature well enough to explain, modify or recreate it, and it offers analysis guides for people who already have reverse-engineering experience.

Explaining a Calculator quirk

The first worked example on the site tackles a familiar oddity: why does Windows Calculator answer 220 for 200 + 10%? Done manually, that means decoding x86-64 assembly from the installed Calculator DLL, following calls and piecing the arithmetic back together. With REA, the developer asks the agent a single question in natural language, and the tool hands over the percent-key handler's instructions, decompiled code and call information.

The agent's reported explanation: after a plus operation, the percent key computes a percentage of the first operand. Ten percent of 200 is 20, so the calculation becomes 200 plus 20, which yields 220.

Recovering a game's speed rule

The second example targets Chrome's offline dinosaur game and asks why the dinosaur accelerates over time. According to the site, REA inspected a browser edition of the game — credited as wayou's Chromium-derived port, served over HTTP — through a local debugging connection and returned the loaded index.js file, together with its source and a content digest.

The recovered configuration sets a starting speed of 6, a maximum of 13 and an acceleration constant of 0.001; on every update that does not end in a collision, the speed rises by that constant until it reaches the cap. The site says the rule was validated by invoking the original game's update function in a controlled browser check, with obstacles and automatic scheduling disabled: after 4,000 updates the speed measured 10.0, and after 10,000 updates it reached the 13.0 ceiling. The demo then rebuilds a small version of the game that keeps the original acceleration rule while adding a slider so players can pick their own pace.

Why it matters

Reverse engineering has traditionally demanded scarce skills: fluency with disassemblers, debuggers and instruction-level tracing. REA's wager is that an agent can shoulder the mechanical parts while a developer asks questions in ordinary language, which could widen access to the practice for understanding undocumented behaviour, reimplementing features, interoperability work and security research alike.

Two caveats are worth holding onto. The published examples are curated demos, so real-world usefulness will depend on how reliably agents interpret the evidence REA extracts from messier targets. And because the technique works by probing finished programs, anyone pointing it at third-party software still needs to weigh licences and terms of service before digging in.