· Development

What recent REA write-ups actually tested: runs, demos, news and opinion

Eight third-party pieces on REA, sorted by who ran what: two independent runs, two author-claimed demos, three news or opinion pieces and one discussion thread, and what each one can support.

DevelopmentSecurityReverse engineeringAI agents

Within a few weeks of REA (morluto/rea) taking off, there were hands-on reports, YouTube demos, news stories and long discussion threads about it. They do not carry the same weight. This post asks one narrow question: which of these pieces actually ran REA, on what, and what can their results support?

If you want to know what REA is in the first place, start with the overview. This is the first of four follow-ups:

  1. What recent write-ups actually tested (this post)
  2. What REA can do, can do only under conditions, and does not support
  3. Strengths, trade-offs and where it might go
  4. Getting started safely

Observation date: 14 October 2026. All sources below were opened and read on that date. Motitory did not run REA for this series; nothing here is our own benchmark. Where we draw conclusions, they are labelled as our analysis.

Six kinds of source

Seven cards, one for each kind of source. Official docs show intended behaviour and stated limits but not how REA does on your target. Project-reported examples show what the project says it did, not an independent benchmark. Independent runs, 2 of the 8 third-party sources, show results on that target and that version only. Author-claimed demos, 2 of 8, are leads to test, not results you can check. News and opinion, 3 of 8, show what people are saying, not new technical evidence. Anonymous discussion, 1 of 8, offers counterarguments, not facts. Motitory analysis, the dashed card, is our reading of the sources; we did not run REA. Official docs and independent runs have a green outline as the sources to lean on for technical claims.

The useful question for any piece about a tool like this is not “is it positive or negative?” but “who ran what, and can I check it?” We sorted the material into these kinds:

  • Official documentation. The REA repository and its docs, pinned to commit 29d3dcb, plus the 6.4.0 release. This tells you what the project intends and what limits it states. It does not tell you how well it works on your target.
  • Project-reported examples. Showcases in the README and on the project’s site. They are the project’s own reports, not independent benchmarks.
  • Independent runs. Someone outside the project ran REA, stated the version and environment, and kept enough output to be checked.
  • Author-claimed demos. A video or post showing a result, without raw output, a pinned version or a way for you to repeat it.
  • News and opinion. Summaries of the docs, or arguments about what REA means.
  • Anonymous discussion. Forum comments. Useful for counterarguments, not as evidence.

We found eight third-party sources worth reading. A Medium post and its HackerNoon republication count once, and we did not use any source we could not open.

The eight sources at a glance

Source Date Kind What was run What it can support
Ishank Choudhary, HackerNoon 14 Oct Independent run REA 6.4.0 on a real Electron app and a small custom fixture Coverage and output size on one large JavaScript target
Curtis Pyke, Kingy AI 8 Oct, later updated Independent run REA 6.0.0 on the official Notes fixture A complete trace on a tiny, readable target
02ui, YouTube 12 Oct Author-claimed demo Apple Passwords generator rules, per the author A lead only
SI NEWS, YouTube 13 Oct Author-claimed demo Bitburner 3.0.1 on Windows, per the author A lead, plus a useful failure report
Guru Baran, Cyber Security News 10 Oct News Nothing; summarises the docs A fair secondary summary
Abid Ali Awan, KDnuggets 12 Oct Opinion Nothing A view of the “AI clone” trend
Jose Antonio Lanz, Decrypt 13 Oct Opinion / narrative Nothing The viral narrative, not REA evidence
Hacker News thread 12 Oct Anonymous discussion No REA reproduction posted Counterarguments

For the two YouTube videos we read the official page descriptions and metadata, not a full transcript, so we only repeat what the descriptions state.

The two independent runs, read together

The two runs are most useful side by side, because they sit at opposite ends.

A tiny target, traced completely. Pyke pinned REA 6.0.0 on macOS 26.3 (arm64) with Node 24.16 and pointed it at the official Notes Electron fixture, about 1.6 KB of source. According to the write-up, REA recovered the route an “export” action takes from the renderer through the preload bridge and IPC to the main process and its CSV formatter, and a separate reimplementation of the formatter matched 14 declared test cases byte for byte. The author says the ZIP, hashes, lockfile and raw Evidence were kept. Two details matter just as much as the success: the output was around 907 KB for that tiny fixture, and while the focused trace had zero unknowns, the whole-project graph still reported 44.

A real app, covered partly. Choudhary ran REA 6.4.0 on Debian 13 (8 vCPU) against the 100 MB ASAR of a real Electron desktop app, plus a five-file fixture they wrote. The run processed 459 files, 421 of them JavaScript, roughly 3.1 million AST nodes, in about 52 seconds. Window, bridge and IPC counts agreed with a plain grep. But the author reports REA missed two preload paths, left relationships for 365 files out because of the resource budget, and did not catch sender validation that happened indirectly. The tool surface was large too: the tools/list response was about 1.95 MB and the compact mode only about 9% smaller, while a summary ran to around 672 KB. The author’s token figure was a rough estimate, not a measured bill.

What neither tested matters as much: agent judgement over a long investigation, native code, web pages, APKs or firmware, Ghidra, Hopper or IDA, and anything like “cloning” an app. Both were JavaScript. Pyke’s target is also one the author could read as source, so it is not evidence about opaque or proprietary software and not a clean-room exercise.

Our reading (Motitory analysis): success on a small readable fixture and partial coverage on a large real app are both true at once, and anyone quoting one should quote the other. And accuracy is not the only bottleneck. Output size, the cost of putting the tool schema into a model’s context, version pinning and the time a person needs to review the result all decide whether the tool is worth it.

The two demos: leads, not results

Apple Passwords rules. The 02ui video description says REA was used to investigate how Apple Passwords generates strong passwords, that 17 rules came out of it, that 100 newly generated passwords all passed those rules, and that it took about 40 minutes and about $10 of API usage. The description gives no REA version, no raw Evidence and no repository to repeat it. The deeper problem is the test itself: passwords passing rules the same investigation extracted shows the rules are self-consistent, not that they match Apple’s generator. An independent oracle would be needed for that, such as rules published by Apple or a test that could fail.

Bitburner. The SI NEWS video describes using the REA CLI on Windows against Bitburner 3.0.1 and finding the ns.exploit() function. Bitburner is open source, so that function is in the public source, and the game is designed for players to discover such things. It shows a workflow, not analysis of closed software. The most useful part is a failure report: the free model in use repeatedly passed wrong arguments to follow-up tool calls, and the author fell back to the CLI. That matches the HackerNoon finding that tool-call reliability is a cost of its own.

News and opinion: what they add

  • Cyber Security News is a reasonable summary of the official docs. It labels project-reported demonstrations as such and repeats two warnings the docs make: local analysis is not the same as no data leaving your machine, because tool results go to a model provider, and runtime features can have side effects.
  • KDnuggets places REA in a trend of “AI software clones” next to ArtCraft. ArtCraft is a different project, not an REA case study, and the breadth and readiness figures in that comparison are the developers’ own self-assessment.
  • Decrypt ties REA to GTA, Fable, mods and ArtCraft. The article itself concedes that several of those stories involved other tools or no REA at all. None of it is evidence about REA, and its most quoted lines are claims we would not repeat.
  • Hacker News: no commenter posted an REA reproduction. The strongest counterargument in the thread is worth keeping, though, as an opinion: being able to analyse a client is not the same as being able to use what you found. A client does not contain the server’s data, the accounts, the operations of a service, its network effects, its trademarks or its assets.

Why viral examples are often not REA evidence

Most of the striking stories fail one of these checks. It is a short list to run before you share one:

  1. Was REA used at all? Several viral stories involved other tools.
  2. Which version, on what system? REA changes fast, and the npm release and the main branch are not the same thing (more in part 2).
  3. Was the result already public? Finding a function in an open-source game is finding it in published source.
  4. Is there raw output you could check? A summary in a video is not Evidence.
  5. Was the check independent? Passing tests the same investigation wrote does not prove equivalence to the original.
  6. Were the rights in place? A demo on someone else’s product does not show that the analysis was authorised. REA’s MIT licence covers REA’s own code; it grants no rights to the target or to third-party tools (disclaimer). Only analyse software you own or are explicitly allowed to analyse. This is not legal advice.

The same goes for source-looking output. Code that reads like the original, a byte-for-byte match on some cases, or a passing rules test does not prove the reimplementation behaves the same at runtime, and none of it says anything about who owns the result.

What to take from this

  • Two independent runs is a small base. Both were JavaScript and Electron, which is REA’s built-in, no-extra-provider path. The rest of the matrix has not been tested in public as far as we found.
  • The project’s own showcases are a starting point, not a benchmark.
  • When a new write-up appears, sort it with the six kinds above before deciding what it means.

Part 2 turns from what others tested to what the docs say is possible, conditional or unsupported.

References

Links and content checked on 14 October 2026.

Back to the blog