AI Is Reverse-Engineering Everything. Is Software Development Still Valuable?

“Software is done.” Matthew Berman wrote these words when sharing the open-source project REA. That post surpassed 3 million views on X. As of October 12, REA had also exceeded 100,000 stars on GitHub.

REA stands for Reverse Engineer Anything. It connects analysis tools with AI agents, allowing models to study existing software, understand its internal logic, and attempt to reconstruct its functionality. People began asking: Can installed programs on our computers serve as blueprints for AI to rewrite them?

In an earlier public discussion, open-source advocate Eric S. Raymond (ESR) predicted that software barriers maintained through code secrecy are eroding. Commercial competition does not necessarily require recovering original source code line-by-line: replicating the features users rely on most may be enough to produce a viable substitute.

If competitors can recreate your most-used features at an acceptable cost without ever obtaining the original source code, what will keep you paying for the software on your machine?

Reverse Engineering Has Always Existed. Why Worry Now?

Reverse engineering itself is not a new technology. Security researchers and engineers have long used tools like IDA Pro, Ghidra, and Hopper to translate compiled machine instructions into assembly or pseudocode. In traditional workflows, this analysis relied heavily on human expertise:

• Stripped binaries required analysts to trace function branches and reconstruct data structures manually;
• Compiler optimizations and control-flow transformations frequently caused decompiled pseudocode to lose variable types and function arguments;
• Even after understanding an algorithm, engineers still had to write high-level code by hand and design test cases to verify inputs and outputs one by one.

What has changed is not the underlying theory of reverse engineering, but how large language models now coordinate with analysis tools. This automates parts of an investigative workflow that previously required manual back-and-forth between decompilers, editors, and test environments. Existing reverse-engineering tools extract low-level instructions, symbols, and data, while agents issue follow-up queries, infer code intent, generate replacement implementations, and assist in verification. While this pipeline allows agents to handle portions of the analysis and rewriting, these isolated cases do not yet quantify cost reductions across the software industry as a whole.

The open-source tool REA (Reverse Engineer Anything) demonstrates this integration: using the Model Context Protocol (MCP), it bridges low-level analysis engines (such as Hopper, Ghidra, or JavaScript parsers) directly to an agent. REA queries functions, call graphs, and memory data based on instructions to return evidence, while the agent interprets context, writes code, and runs tests.

In the DX-Ball game reconstruction showcase, the decompiler's initial pseudocode for the audio panning function omitted input arguments, showing only a type cast. Using REA to inspect low-level instructions, caller arguments, and constant data at referenced memory addresses, the agent deduced the complete panning logic and rewrote it as a C function. This function passed all 3,205 behavioral test cases against the original x86 implementation and reproduced all 63 compiled bytes. This verification covered that single audio panning function; the full game remains under reconstruction.

When applied to modern bundled desktop applications, this workflow can untangle local logic just as effectively. In an analysis of the Notion desktop client, an agent used REA to locate the clipboard interface exposed by page preload scripts, traced it through the inter-process communication (IPC) channel to the main process handler, and mapped out the complete path for writing plain text and HTML to the system clipboard. This case shows that even minified local scripts bundled within desktop clients have call hierarchies and local implementations that are now easier to trace; however, this is strictly limited to client-side logic and does not equate to accessing backend cloud services directly.

In independent community explorations, developer P.E. Cooper posted that he ported the original Zombies map from the classic game Call of Duty: World at War (WaW) to the web with the help of a model, later sharing a gameplay demo integrating building mechanics. These demonstrations illustrate the growing room for community experiments with cross-platform porting and customized modifications assisted by AI.

In longer-term system reconstruction, the open-source matching decompilation project for Super Smash Bros. Melee offers an instructive example. Developer banteg noted that this six-year effort gained substantial momentum in its later stages using LLMs. Rebuilding the game into an editable, high-level codebase gave the community a foundation to maintain the game, analyze its mechanics, and develop mods.

The analyzability of local logic reflects a foundational principle in the OWASP Client-Side Security Cheat Sheet: never entrust core business secrets or security credentials to client-side logic; once an application is distributed and executed on a user's local machine, its local code and runtime behavior become technically observable and analyzable.

What Do Users Gain, and Which Software Faces the Most Pressure?

Lower technical barriers affect different stakeholders in distinct ways:

Users: More Options for Maintenance, Migration, and Bug Fixes

For end users, lower reverse-engineering and analysis barriers unlock tangible benefits:

• Data Interoperability and Format Parsing: When proprietary local file formats can be parsed more clearly, users face less friction exporting and migrating data across applications—provided external tools can extract adequate format specifications and verify compatibility.

• Legacy and Abandoned Software Maintenance: When an original vendor discontinues support or shuts down, community maintainers or commercial support teams can invest engineering effort to recover missing interfaces and logic through reverse engineering, making it more feasible to patch legacy software or adapt it for modern operating systems.

• Platform Porting and Targeted Bug Fixes: When software lacks a version for a specific platform or suffers from unpatched bugs, teams with engineering capacity—or those willing to buy third-party support—can pinpoint low-level behavior directly to assist in porting or bug fixes.

Yet these use cases depend on whether maintainers are willing to continuously undertake compatibility testing and updates. Even when switching to open-source or independent alternatives, users must evaluate how they will handle technical support—whether through in-house maintenance, or by purchasing commercial support backed by service level agreements (SLAs).

Local Software: Common Features May Face Fast Substitution

If an application's core functionality runs entirely on local machines, has a clearly defined scope, and easily lends itself to test cases, it directly faces the risk of feature recreation as external developers more easily understand its algorithms and implementation details. Such products encounter immediate commoditization pressure.

The open-source creative suite ArtCraft provides a concrete reference point. In a Futurism interview, co-founder Michael Caffrey stated that the team used Claude 5.5 to reverse-engineer and rebuild seven core Adobe tools: photo editor PhotoCraft corresponding to Photoshop, vector illustrator VectorCraft to Illustrator, video editor FilmCraft to Premiere Pro, and photo grading tool LightCraft to Lightroom, alongside PdfCraft for PDF handling, EffectCraft for motion graphics, and DesignCraft for page layout.

The project's official documentation defines these tools as "clean-room reimplementations" rewritten from public specifications and observable behaviors, rather than acquired or leaked Adobe source code. At present, all tools remain in early development and do not demonstrate that they can fully replace the original suite in professional daily workflows.

Familiar layers, timelines, menus, and shortcuts can lower the friction of switching applications for creators. Even without recovering original source code, an alternative that covers daily workflows at lower cost can still challenge the subscription value of the original software. ArtCraft translates this competitive pressure into concrete interfaces and workflows.

Faced with this challenge, moving critical logic to the cloud is a defensive strategy some vendors may consider. But shifting to the cloud comes with trade-offs:

• Offloading compute to the cloud shifts hardware and storage costs from user devices onto the vendor;
• Users must remain constantly online and may face privacy concerns over data uploads, losing control over purely local execution;
• For low-cost or offline-dependent applications, forcing cloud connectivity can prove unsustainable both financially and in terms of user experience.

Cloud Services: Competitors Can Emerge Even Without Source Code

Cloud-based services cannot rest easy either. While installers rarely package complete backend logic, this does not mean cloud features cannot be replicated. Competitors can observe input/output exchanges, invocation flows, and frontend behavior to reimplement comparable workflows on their own tech stacks. For SaaS products with straightforward business logic, popular features face similar cloning pressure.

However, a cloud product's true defense lies in operational foundations that cannot simply be extracted:

• Unpublished Backend Logic and Proprietary Data: Internal scheduling mechanisms, risk control algorithms, data pipelines, and proprietary datasets built up over years cannot be extracted from a client installer;

• Real Infrastructure and Operational Overhead: Even if an alternative mirrors frontend interfaces and APIs, it must still build out and pay for server infrastructure matching that scale;

• User Trust and Workflow Inertia: The historical records, operational habits, and collaborative networks that businesses rely on daily cannot be migrated merely by copying code.

What Is Still Missing After Getting the Installer?

The delivery model and architecture of software dictate its exposure to reverse engineering and functional reconstruction. The following qualitative condition model compares what external developers can extract, what engineering gaps must be bridged, and what operational foundations cannot simply be taken from client binaries across different software architectures:

If Features Can Be Cloned, Why Will Users Still Pay?

In discussions on Reddit addressing fears that AI could rapidly replicate product features, several developers pointed out that core software value rarely resides in the code itself:

One developer building software for small brick-and-mortar businesses commented that customers do not buy UI and logic; they buy peace of mind. When a free clone breaks on a Tuesday morning, someone still needs to troubleshoot and fix it. A cloned application can mimic functionality, but it will not automatically migrate years of historical records, retrain staff, or answer support calls when payroll exports fail.

Another developer added that if an agent can clone an interface in short order, the interface itself was never a core moat. Buyers ultimately pay for the certainty that someone takes responsibility when things break; cloning can replicate interactions, but it does not automatically take over 24/7 on-call incident response.

In reality, continuous maintenance, brand trust, business integrations, and support services have always formed essential pillars of commercial software value. As AI drives down the cost of writing and reading code, the relative importance of these preexisting engineering and operational factors becomes even more pronounced:

1. Real-World Workflows and System Integration: A primary difficulty in enterprise software lies in navigating complex domain scenarios—such as integrating with legacy systems, heterogeneous databases, and third-party APIs. Even if external developers rewrite core algorithms, this concrete integration work must still be delivered one step at a time.
2. Data Accumulation and Switching Costs: Long-term business records, configuration preferences, and collaboration networks are deeply embedded in existing software. Replacing a platform involves real expenses and disruption risks from data migration, business logic verification, and employee retraining.
3. Continuous Delivery and Accountability: Every live production system must continually handle environment updates, security patches, and disaster recovery. Even if code can be synthesized quickly, subsequent iteration, availability guarantees, and accountability for outages still require an established organization or team. This ongoing work requires capital and labor, which any lasting alternative must also support.

Running Demos vs. Reliable Replacements: How Far Apart Are They?

Rapid reverse-engineering demos easily create the impression that commercial software will soon face free replacements everywhere. Yet an unvalidated demo and a reliable substitute that runs stably in production environments remain separated by a significant engineering chasm.

To understand the verification overhead between an "initial reproduction" and "accurate reliability," developer Maurice Heumann's decompilation experiment on a classic first-person shooter offers an insightful case study. Independent of REA, this project illustrated the practical reality of multi-agent decompilation on a large-scale program:

• Executable Does Not Mean Logically Sound: During the project's first month, agents decompiled roughly 80% of the codebase, and the game could boot and load maps. However, closer inspection revealed widespread type errors and fabricated logic; seemingly coherent code diverged sharply from original semantics;

• Giving AI a Reliable Evaluator: The team switched to the original compiler and wrote scripts to compare recompiled functions byte-for-byte, backed by CI checks verifying script hashes to prevent bypassing. This mechanism functioned like a strict evaluator: whenever an AI rewrote a function, the checker compared it against the original binary; failures triggered revisions, while passes allowed the code to be accepted. With unambiguous pass/fail signals, even cheaper models could iteratively refine code until it passed. According to the author, the later stages primarily ran 14 Luna and 2 Opus 5.5 models in parallel, showing that replication barriers depend not only on the strongest model, but also on whether automated verification can be established;

• Scale and Boundaries of Results: After introducing machine-code comparisons and spending two months debugging, the reconstructed codebase covered 99% of original functions; dividing byte-matching functions by all original functions, 83% achieved compiled byte matching. This 83% figure reflects functions whose compiled binaries match byte-for-byte; it should not be misunderstood as "only 83% of features worked." Remaining functions may use different instruction orderings while producing identical outcomes. In the author's assessment, all functions were semantically correct, and the reconstructed game retained full original gameplay without noticeable glitches. Byte-for-byte fidelity also reproduces original bugs, leaving bug fixing and cross-platform porting as separate tasks. Due to lost log files, the author estimated consuming approximately 600 to 700 billion tokens. While the team considered the project complete, the code was kept private due to copyright concerns and never released publicly.

This project suggests that automated verification enables more cost-effective models to handle demanding reconstruction workloads. However, the months of effort and vast compute consumed here targeted strict, byte-level reproduction. Commercial competitors seeking only to replicate core, high-frequency features would not necessarily incur the same cost. Thus, extrapolating from a specific game reconstruction that "software secrecy barriers are collapsing" remains speculative. Whether software can easily be substituted depends both on whether automated verification can be constructed and whether competitors are willing to absorb long-term maintenance and adaptation costs.

“Forced Open Source”: What Has Actually Been Surrendered?

“Forced open source” is a provocative phrase, but it is inaccurate in copyright law and commercial reality.

According to the Open Source Definition (OSD) by the Open Source Initiative (OSI), open source does not mean that outside observers can read or reconstruct code. Rather, it requires that software distribution terms satisfy specific criteria, including free redistribution, source code availability, permission for modifications and derivative works, and no discrimination against persons, groups, or fields of endeavor.

When commercial software is reverse-engineered or its features are rewritten:

1. Original Software Receives No Open-Source License: Reverse engineering does not grant new licenses from original authors, nor does it convert proprietary binaries, code, or art assets into freely distributable material.
2. Functional Similarity Does Not Grant Rights to Proprietary Assets: Reimplementing similar behavior is entirely distinct from extracting and copying protected source code or assets. Even if a reconstructed application runs flawlessly, that does not mean it can legally be distributed or commercialized.
3. Erosion of Secrecy Changes Competitive Dynamics: While the software does not become open source, the moat previously maintained by machine code's opacity is weakening. In commercial competition, alternatives do not need 100% of original source code; replicating the core features users rely on and pay for at an acceptable cost directly challenges an incumbent's exclusive advantage.

What Can Developers Protect Without Open Sourcing?

Commercial software will not turn into open source overnight because of advances in AI-assisted reverse engineering, nor will creators forfeit their intellectual property rights.

At a technical level, however, relying solely on compiled binary opacity to defend long-term implementation exclusivity is becoming increasingly fragile. This shift has multifaceted consequences:

• For Users: There are more potential avenues for maintaining legacy software and extracting proprietary data. But if vendors accelerate moves to the cloud to shield their logic, users may face increased network dependency and a further loss of local control;

• For Developers: Rather than worrying whether code can be reverse-engineered, it is better to return to two concrete questions: Why did users choose your product in the first place? And beyond replicating logic, what unavoidable maintenance, integration, and operational burdens must a competitor shoulder to match your reliability?