The System Nobody Can Explain Just Became Callable

This week I pointed an AI agent at Preview, the PDF and image viewer that ships on every Mac, and asked it a simple question: what's actually inside? I picked it because it's the opposite of your legacy system. It's polished and maintained, and it's still a black box to anyone without the source.

The agent used an open-source tool called REA to inventory the binary on my own machine. Within minutes I had a structural map I'd never have produced by hand: the libraries it depends on, the hundreds of internal components it's built from, and the permissions it runs with. This was personal research. I kept it to structure and didn't extract anyone's code.

Then I had the agent write a from-scratch equivalent on public frameworks. About 5,000 lines, 26 automated tests, one sitting. The tests caught a crash before anyone opened the app. It isn't Preview. It's a capable subset, and parts of its interface still need a human pass.

But the clone isn't the point. The point is what that session means for the system in your building that nobody can explain.

The cost of the current way

Almost every mid-market company has one. A pricing engine, a claims rater, a scheduling app, a nightly batch job. It runs on its own. It makes decisions that touch revenue. The person who wrote it left years ago. The source code is missing, or present and untrusted. The documentation is a wiki page last edited before the pandemic.

The problem with that system isn't that it's old. It's illegible.

Illegible software is expensive in ways that never show up as one line item:

You can't modernize it. Every rewrite needs a specification, and the only specification is the binary. So the rewrite estimate starts with "discovery," and discovery is where budgets go to die.
You can't change it safely. When nobody can say what a system does, every change is a bet. So nobody changes it, and the business routes around it with spreadsheets and tribal knowledge.
You can't connect it to agents. It has no API, no events, no tools. The best an agent can do is drive the screen like a person would, which breaks the first time a button moves.

This isn't a niche problem. The U.S. federal government, the best-measured example we have, spends more than $100 billion a year on IT and reports about 80 percent of it going to operating and maintaining existing systems. GAO says its 11 most critical legacy systems range from 23 to 60 years old. CISQ estimates accumulated U.S. technical debt at about $1.52 trillion. Your version is smaller. The shape is the same: most of the money keeps the lights on, and the lights are wired to something nobody can read.

What changed this year

Reverse engineering used to mean a specialist, a disassembler, and weeks. I started my career close to the metal in C and C++, so I know what reading someone else's machine code costs.

REA, short for "Reverse Engineer Anything," is an open-source MCP server that hands that work to an agent. It connects coding agents like Claude Code, Codex, and Cursor to the professional tools (Ghidra, IDA, Hopper) and covers native binaries, .NET assemblies, Electron apps, and firmware. Analysis runs locally. Every finding comes back with evidence attached: the function, the pseudocode, the call path. The agent does the tedium. A human checks the evidence chain.

That last part matters more than the speed. You don't have to trust the agent's summary. You can audit it.

Two ways to make a black box callable

Once a system is legible, there are two paths.

Path one: expose it. Keep the legacy code running exactly as it is. Reverse engineer its internals and wrap the important functions as tools an agent can call. Nothing gets rewritten. The same code production runs now answers questions.

Path two: rebuild it agent-native. Use the behavior you've observed to write a from-scratch replacement designed for agents from day one.

The loudest example of path two arrived this month. Developer Brandon Thomas released ArtCraft, a set of open-source rewrites of seven Adobe apps, including Photoshop, Lightroom, and After Effects, built with Claude Opus 5.5. Strictly speaking, that isn't reverse engineering in REA's sense. The project says the apps were built from public specs and observed behavior, with no Adobe code. But look at the architecture: the project says every menu item in its Photoshop rewrite runs through one registry of more than 500 commands, shared by the interface, a command line, and an MCP server. That's what agent-native looks like.

The project's own READMEs are honest about the gap. Its Lightroom rewrite estimates it covers about half of what a working photographer needs day to day. Both paths take discipline. Neither one is magic.

For most CIOs, path one is where the money is, because it works on Monday without betting the business on a rewrite.

What path one looks like

Here's an illustrative example. The company and numbers are invented. Each step maps to a capability REA documents for .NET assemblies.

A regional insurer prices policies with a .NET component written in 2009. The developer left in 2014. The source was lost in a repository migration. Every night it reprices tens of thousands of policies. Underwriting keeps asking one question nobody can answer: why did this customer's premium go up 18 percent?

Inventory. The agent opens the assembly with REA and maps it: a RatingEngine class, a CalculatePremium entry point, and dozens of rule methods hanging off it.
Trace. It decompiles CalculatePremium and follows the call graph. There's a territory factor table, a credit-tier adjustment, and a hard-coded surcharge added in 2011 that nobody remembered existed. Each finding points to the exact function that proves it.
Document. The rules become a readable specification with evidence links. It's the first accurate documentation that system has had in over a decade.
Expose. The original component, unchanged, is wrapped in a small MCP server with three tools: rate_policy, which returns the premium with its factor breakdown; explain_premium_change, which diffs two ratings rule by rule; and list_rating_rules.
Verify. Before anyone trusts it, replay last month's production batch through the wrapper and diff the outputs. The target is zero differences.

Now an underwriting agent answers the 18 percent question in seconds and cites the rule that caused it. And modernization finally has a starting point. Every rule has a spec and a test, so you can replace them one at a time instead of rewriting the whole system and hoping.

Before you try this

Rights first. Do this on code you own or are licensed to analyze. Vendor license agreements often prohibit reverse engineering. Ask counsel before you point an agent at third-party software.
Evidence over summaries. If a finding has no evidence attached, it's a guess.
Read-only first. Wrap and observe before you let an agent change anything.
Decompiled isn't original. You recover logic and behavior, not the original source or its comments. Verify against production outputs every time.

The excuse expired

For twenty years, "we can't touch it" was a reasonable answer. The knowledge was gone, and getting it back cost more than living with the risk.

That math changed. Most systems with observable behavior can now be made legible, documented, and callable. The question for your next planning cycle isn't whether you can understand the system nobody can explain. It's which one you start with.

What's the one system in your organization everyone is afraid to touch?

Sources: GAO-25-107795 (federal IT spending and critical legacy systems); CISQ, "The Cost of Poor Software Quality in the U.S.: A 2022 Report"; REA repository (github.com/morluto/rea); ArtCraft project READMEs and press coverage, October 2026.