REA: Checking an AI-Written Technical Guide Against the Source Repo

Asking an AI to write a technical guide is easy. Trusting the commands in it is the hard part. This post walks through a real example from today and shows the simple habit that kept the guide honest.

Today is October 17, 2026. AI coding agents are now common, and many teams connect them to local tools through the Model Context Protocol (MCP), a standard way for an agent to call tools on your machine. Guides for these tools go out of date fast, and a single wrong flag can waste a reader's afternoon. That is why checking against the source matters right now.

The task

I wanted a long technical blog post about REA. REA is an open-source MCP server and command line tool that lets AI coding agents reverse engineer binaries, Electron apps and Android packages. Reverse engineering means studying a finished program to learn how it works without having its source code.

The request included a clear rule: read the project's own files first, and do not invent any command line flags. That rule drove everything that followed.

Why not just write from memory?

A language model can produce a convincing guide in seconds. The risk is that the commands look right but are not. A flag that almost exists is worse than a missing one, because the reader trusts it.

So I treated the model's memory as a draft, not a source. The source was the project's repository, which was already checked out on my machine.

The process

Step 1: Read the project's own documents

I started with the README, the installation guide, the command line guide and the package file. These are the files the authors keep current. From them I collected the facts the post needed:

• The Node.js versions the package supports.
• The setup and diagnosis commands.
• The environment variables for the Ghidra analysis engine.
• The licence terms and the responsible-use notes.

Step 2: Search for the claims I was not sure about

Some details from the brief were not in the README. I searched the repository for them instead of trusting the brief.

grep -n -E "\-\-client|\-\-dry-run|GHIDRA_INSTALL_DIR|JAVA_HOME|CLAUDE_CONFIG_DIR" docs/installation.md

The search confirmed most of the brief. The repository history also confirmed the origin story: the first commit was an early project called betterBinaryMCP, a bridge for the Hopper disassembler, which later grew into the multi-target tool.

Step 3: Try to run the tool, and report the limit

I tried to print the tool's help text from the checkout. It failed with a message saying the compiled runtime was missing, because the project had not been built on this machine. I did not hide that. I wrote in the post that the flags came from the documents, and I left out the exact arguments for one command that I could not confirm.

Step 4: Fix what the source contradicted

The brief used the client name gemini in a setup example. The installation guide lists the real value as gemini_cli. A reader who copied the original would have hit an error on the first command.

# Wrong, from the brief
rea setup --client claude_code --client gemini --dry-run

# Correct, from the installation guide
rea setup --client claude_code --client gemini_cli --dry-run

The --dry-run flag shows a plan without changing anything, which makes it a good first command for readers.

Other corrections worth making

Two more statements needed care.

The first was "your binary is never uploaded." The README says analysis runs locally, but it also says the agent receives the tool results, and the agent's model provider has its own data policy. So the honest wording is that REA does not upload the file, but what the tool returns still goes to your model provider.

The second was a tool called Wakaru, which cleans up minified JavaScript. The docs show it is optional, supported on Linux x64, and supplied by the user through an environment variable. A guide that implied it was built in would have misled readers.

A short checklist you can reuse

• Read the project's README and install guide before writing a single command.
• Search the repo for every flag, variable and client name you plan to print.
• Run the tool if you can. If you cannot, say so in the text.
• Do not write arguments you could not confirm. Point to the help command instead.
• Re-read claims about privacy and licences against the project's own wording.

Conclusion

The AI wrote the draft quickly, but the value came from the checking. Reading the source turned up one wrong client name and two statements that were too strong. None of that needed special tools, only a habit of searching the repo before trusting the text.

Merits

• Commands in the final guide match the project's own documents.
• Readers see honest limits instead of confident guesses.
• The checklist is short and works for any tool, not only this one.
• Catching errors early saves readers from copy-paste failures.

Demerits

• Reading and searching the repo adds time compared with writing from memory.
• Documents can be out of date, so they are not perfect sources either.
• If the tool cannot be run, some details stay unverified.
• The method does not replace testing the steps on a clean machine.

Caution

This article is for education. Replace any placeholder paths and values with your own, and check the current documents of any tool before you rely on a command. Only analyse software you own or have clear permission to examine, and follow the licence terms of the tools you use.

Frequently asked questions

• What is REA? — REA is an open-source MCP server and command line tool that lets AI coding agents inspect binaries, Electron apps and Android packages on your own machine.
• What is the Model Context Protocol? — MCP is a standard that lets an AI agent call tools and read data from your computer in a structured way.
• Why check AI-written guides against the source? — A model can write commands that look right but are not, and a wrong flag wastes the reader's time.
• What does a dry run do? — A dry run prints the changes a command would make without applying them, so you can review them first.
• Does REA upload my files? — The project says analysis runs locally, but the results go to your agent, and its model provider has its own data policy.
• Can I trust the tool help text? — Usually yes, but run it on your installed version, because flags can change between releases.
• What should I do if I cannot run the tool? — Say so in the text, avoid writing arguments you could not confirm, and point readers to the help command.
• Is reverse engineering legal? — It depends on your country and the software licence, so analyse only software you own or are authorised to examine.

Tags

#AIAgents #MCP #ReverseEngineering #TechnicalWriting #Documentation #DevSecOps #ClaudeCode #OpenSource #CLI #FactChecking