DEV Community: Shapovalov Valentine

REA: ask your coding agent how a finished app works

Shapovalov Valentine — Sat, 17 Oct 2026 09:51:16 +0000

I recently came across REA, short for Reverse Engineer Anything. It connects a coding agent to tools for inspecting a finished app, so you can ask how a particular feature works.

REA is an open-source MCP server under the MIT license. It connects Claude Code, Codex, Cursor, Gemini CLI and other agents to reverse-engineering tools. You point the agent at an app, ask about one feature, and it traces the code behind it.

I haven't run it myself yet. Everything below comes from the project's documentation, plus how I plan to check it.

What it can look at

The documented targets include:

Target	What comes back
Native binaries	Pseudocode, assembly, strings, symbols, calls and references (Hopper, Ghidra or IDA for deep analysis)
JavaScript and Electron apps	Modules, imports, source maps, routes and IPC
.NET assemblies	Metadata and CIL instructions, static analysis only
Android APKs	Manifest, classes and decompiled methods (needs JADX and a JDK)
Websites	Page structure, scripts and network observations

Setup

With Node.js and npm installed, run:

npx rea-agents setup

Review and approve the proposed configuration changes, then restart your agent. Setup registers the MCP server and installs matching workflow instructions. Static JavaScript and .NET analysis work without a native engine. The FAQ says analysis runs locally, although your agent still sends the tool results to its model provider.

Every finding comes with evidence

REA returns each finding together with the evidence and the limitations behind it. One showcase follows Notion's clipboard API from the renderer, through preload and IPC, into the main process.

In another, REA supplies the instructions and data reads behind a sound-pan function in the old game DX-Ball, and a reconstruction project rewrites it in C. That version passes 3,205 test cases against the original x86 code and reproduces all 63 compiled bytes of the function.

That's the level of detail I want from an engineering agent. You can follow the path behind a feature and ask where each conclusion came from.

From explanation to your own feature

The example prompt in the README asks the agent to understand how search works in the Notes app, show the evidence, and build a similar feature for your project. That gives the agent a way to use what it finds when writing an implementation. I'd still test that implementation against the behavior I wanted to reproduce.

Before you try it

The README is explicit that REA is for lawful research, interoperability, software preservation, and software you own or are authorized to examine. Commercial tools such as IDA, Hopper and JEB need your own valid licenses.

Install it only from the official sources (the GitHub repo, rea.tools or the rea-agents npm package), because the project warns about look-alike repositories.

How I'd test it

I'd start with one narrow question on an Electron app I'm authorized to inspect: which code path produces this behavior? Then I'd check whether another engineer can reproduce the finding from REA's evidence alone, and whether the app behaves the way the explanation predicts when I change the input.

Claude Code skills: stop onboarding your agent every Monday

Shapovalov Valentine — Wed, 07 Oct 2026 08:53:59 +0000

Writing the same long prompt for the same task every time is like onboarding a new intern every Monday.

Skills are how you stop.

A skill sits somewhere between a program and a prompt. At its core is a SKILL.md file of instructions for one specific job. It can also include reference material, templates, and scripts. The aim is a repeatable workflow, not a guarantee of an identical result.

Claude Code has them. Anthropic published the format as an open standard in December 2025. Codex and Cursor support skills too.

What changes in practice

Think about a skill for writing blog posts. Instead of leaving "write a post" open to interpretation, you can specify a workflow: read your previous posts, check for repeats, look for fresh data, ask a couple of clarifying questions, suggest a few options, then write in your voice. That's the difference between a stranger on the street and an assistant who's worked with you for six months.

Describe the logic once, then invoke it when you need that job done.

A monthly content plan. Sorting a folder full of documents. A proposal tailored to one client.

One skill to start each workflow.

Why skills scale better than one long prompt

The Agent Skills standard uses progressive disclosure: the agent starts with skill names and descriptions, then loads the full instructions when a skill is activated. You can also invoke a skill directly.

That keeps the full procedures out of context until you need them. The names and descriptions still take up space.

For me, that's the reason to keep task-specific procedures in skills. I want the workflow for the current job loaded when I need it, rather than carrying every procedure into every conversation.

Think of a tool as an action with a clear contract, like sending an email. A skill describes the workflow around those actions: what to check, which tools to call, and what the finished result should look like.

Building your first one

The Claude Code documentation explains how to create and invoke skills. There are already skill packs for development, like Superpowers. There are even skills for building skills.

The ones I'd tried felt closer to one-shot generation than to working through the design with a brainstorming partner. I wanted a process that helped me decide what the skill should do before writing it.

So I built my own: SuperSkill Creator. You answer questions, it checks for overlap with existing skills, and it helps you choose ready-made building blocks. Then it writes the skill, pressure-tests it with you, and saves it. The design happens in conversation; you do not have to hand-write the instructions.

If you want agents to take over everyday work and you'd rather not write code, skills are where I'd start. Pick one task you do every week and make it your first skill.

How to tell if your AI agent actually got better

Shapovalov Valentine — Wed, 23 Sep 2026 20:40:15 +0000

People keep asking me how you actually know an agent got better. I collected my answers to the most common questions in one place.

Isn't it obvious from the answers?

No. The agent says "You're booked for Thursday," and that sentence tells you nothing.

Anthropic's guide on agent evals shows it with a flight-booking agent: it may say "Your flight has been booked," but the outcome is whether a reservation actually exists in the database. What counts is the state the agent leaves behind, not what it says.

So the questions that matter are boring. Did the row appear in the database? Did the tool call fire with the right arguments?

A demo watches the reply. An eval watches the system. That is why demos always look great.

Doesn't an LLM judge solve this?

Partly. The judge brings its own bias.

In June a study of 21 LLM judges came out, Claude Opus 4.6 and GPT-5.4 among them. One of the tests: show the judge two answers, then swap their order and ask again. A good judge should not care which one came first.

On the easier benchmark, the median judge flipped its verdict 9% of the time. On the harder one it was 17%, and some judges went as high as 38%. The harder the task, the closer the judge gets to a coin toss.

The unpleasant part is that rerunning does not help. On a rerun, the same judge gives the same verdict roughly nine times out of ten or more, bias included. Stable is not the same as correct, so the only way to catch the bias is to calibrate the judge against human labels.

Should I score from 1 to 10?

Binary. Pass or fail.

The gap between a 3 and a 4 is a matter of taste, and everyone hides their uncertainty in the middle of the scale. A binary verdict makes you name the reason something failed instead of quietly giving it a 7.

How many cases do I need?

Dozens, not thousands. Start with 20 to 50 tasks pulled from real failures.

Thirty ugly cases from production beat a thousand synthetic ones.

So evals come before prompts?

It sounds logical, like TDD. For capabilities it can work: writing the eval first pins down what done means, and the Anthropic guide recommends exactly that.

For failures, no. An LLM can break in practically endless ways, so whatever you write upfront covers the failures you imagined, not the ones that will happen.

For failures the order is different:

ship → read the traces → write an eval for a failure that really happened.

While you are looking at replies, you are not measuring the agent, you are measuring its politeness.