AI Reverse Engineering: Is Software’s Subscription Model at Risk?
“Software is over,” declared developer Brandon Thomas after using AI coding tools to build seven open-source alternatives to Adobe Creative Cloud applications.
His work raises an increasingly important question for the software industry: if AI agents can analyze existing products, reconstruct their functionality, and generate working alternatives in a fraction of the traditional development time, how much longer can proprietary features justify recurring subscription fees?
A second project is pushing the discussion further. REA, short for Reverse Engineer Anything, is an open-source toolkit that allows AI coding agents to investigate software behavior, analyze native binaries, trace application internals, and reproduce individual features. Its repository is available on GitHub. By October 14, the project had attracted more than 230,000 stars, demonstrating the intense interest in AI-assisted reverse engineering.
The approach is not limited to conventional desktop software. Browser-based ports of classic video games are appearing alongside AI-assisted decompilation projects, while tools such as VibeOffice demonstrate how developers can build alternatives to familiar productivity applications.
These projects suggest that the cost of reproducing software functionality is falling. However, they do not prove that arbitrary applications can be reconstructed completely or that working alternatives can immediately replace mature commercial products.
The more consequential development is that AI is reducing the cost of discovering how software works, implementing selected features, and testing the results against an existing reference. That shift could accelerate competition, weaken some software vendors’ pricing power, and force developers to compete on more than code alone.
🔧 How REA Turns Reverse Engineering into an AI Workflow #
Traditional reverse engineering requires engineers to inspect an application’s behavior, examine executable files, trace data flows, identify relevant algorithms, and validate their conclusions. The process can involve disassemblers, decompilers, debuggers, runtime instrumentation, and extensive manual analysis.
REA organizes these activities into a workflow that AI coding agents can execute through connected analysis tools.
Instead of asking an AI to guess how an unfamiliar feature works, a developer can direct an agent to investigate an existing application, collect evidence, identify the relevant implementation, reconstruct the logic, and test the resulting code.
From observable behavior to implementation #
Suppose a developer wants to add search functionality to a note-taking application.
Rather than designing the behavior entirely from assumptions, the developer can ask an agent to investigate how the existing application handles search. The agent can inspect accessible code, observe runtime behavior, trace data structures, and examine how user input moves through the application.
It can then use those findings to implement a similar feature in another codebase.
The process is not limited to applications whose source code is publicly available. Depending on the target and the available analysis tools, REA can investigate native binaries, JavaScript modules, Electron applications, .NET assemblies, websites, and runtime behavior.
The toolkit integrates with tools such as Ghidra, Hopper, and IDA for native binary analysis, while coding agents such as Claude Code and Codex can coordinate the investigation and write the resulting implementation.
REA’s official repository provides installation instructions, tool integrations, and worked examples.
The important distinction is that the agent does not need to understand an entire application before reconstructing one feature. A narrowly defined investigation can be more tractable, easier to verify, and less expensive than attempting to reproduce a complete product.
This reflects a wider shift toward agent-based software engineering, in which models coordinate tools, inspect results, and carry out longer workflows instead of generating isolated code snippets. KAD explores the same broader transition in its analysis of autonomous AI agents and multi-agent software development.
Why structured investigative instructions matter #
REA also supplies agent instructions that help standardize how investigations are conducted.
The workflow encourages agents to locate the code responsible for a specific feature, trace relevant data flows, distinguish direct observations from inferences, and preserve supporting evidence. If an investigation becomes too broad, the agent can narrow its scope and retain findings for subsequent work.
This matters because reverse engineering is fundamentally an evidence problem.
A decompiler might produce incomplete pseudocode. A function name might be misleading. A runtime observation may reveal what happened without explaining why. AI-generated explanations can also contain plausible but incorrect assumptions.
A structured workflow helps agents connect their conclusions to observable behavior rather than treating their first interpretation as established fact.
The process becomes especially useful when the output can be tested against the original application.
Differential testing provides a practical ground truth #
One of the most important advantages of reverse engineering is that an existing implementation can serve as a reference.
Once a feature has been reconstructed, the original and new versions can be run under identical inputs. Their outputs, state changes, interface behavior, file modifications, or other observable results can then be compared.
When the results differ, the agent can investigate the discrepancy, modify the implementation, and run the tests again.
This feedback loop transforms software reconstruction from an open-ended generation task into a more constrained engineering problem.
It does not guarantee that every internal detail will be recovered. Two implementations can produce equivalent observable results while using entirely different algorithms. Nevertheless, behavioral equivalence is often sufficient when the goal is to reproduce a specific feature rather than recreate the original source code.
🧪 Four REA Case Studies Show How AI Can Reconstruct Features #
REA’s documented examples illustrate how the workflow applies to authentication logic, application internals, legacy game code, and low-level binary behavior.
Aegis Authenticator: Reproducing six-digit verification codes #
The open-source Aegis Authenticator for Android displays six-digit authentication codes that change every 30 seconds.
REA’s case study demonstrates how an agent can inspect the application’s Android package, locate the relevant calculation, and reconstruct the code-generation behavior in a browser-based demonstration.
The analysis begins with the observable feature: a code changes as time advances. The agent investigates the application package to identify the relevant methods and determine how the current time and account key are used to generate the result.
The reconstructed implementation exposes an adjustable clock, allowing developers to examine the boundary between consecutive 30-second intervals.
For example, with the same account key, the generated code remains constant from second 30 through second 59 and changes when the clock advances to second 60.
According to the project’s published case study, the reconstructed implementation matched the extracted reference implementation across all 133 test cases. The demonstration also checks against published test vectors for the time-based one-time password algorithm.
The example shows how a relatively small, well-defined feature can be isolated from a much larger application and reconstructed using observable behavior, static analysis, and automated verification.
It also illustrates the value of having testable output: an agent does not need to reproduce the entire authenticator to demonstrate that it has recovered the code-generation algorithm.
Notion: Tracing clipboard behavior across processes #
Rich-text clipboard operations can be more complicated than copying a plain string.
When a user copies formatted content from a desktop application, the system may need to preserve text, HTML markup, links, formatting, and other metadata. An Electron application may also pass clipboard data between its renderer and main processes through preload scripts and inter-process communication.
REA’s Notion case study follows this path through the desktop client, tracing how text and HTML move between components before reaching the system clipboard.
This type of investigation is valuable because many application features depend on behavior distributed across several modules or processes. Looking at a single function may reveal only part of the process.
The agent must identify the relevant entry point, follow the data through the application, and determine which representations are delivered to the operating system.
The resulting knowledge can help developers implement compatible clipboard behavior in their own applications without reproducing the entire original desktop client.
DX-Ball Classic: Reconstructing a sound-panning function #
The DX-Ball case study examines how the original game calculates audio panning based on an object’s horizontal position.
For example, when a ball strikes a target on the left side of the screen, the sound may be shifted toward the left audio channel. Recreating this behavior requires identifying the conversion function that maps screen positions and other parameters to a panning value.
In this case, decompilation did not provide a complete high-level explanation. The investigation therefore examined the underlying machine instructions, function relationships, and constant values before reconstructing the logic in C.
The reconstructed function was tested against the original implementation.
According to REA’s published showcase, the new implementation passed 3,205 test cases and reproduced all 63 bytes of the original compiled function.
This is a stronger form of verification than checking a few representative outputs. Matching every tested return value demonstrates behavioral consistency across the selected test space, while matching the compiled bytes establishes that the reconstructed function reproduces the original machine code for that build.
The distinction matters: successful decompilation is not merely about generating code that looks plausible. In compatibility-sensitive projects, the ability to prove equivalence can be more important than the readability of the reconstructed source.
Touhou Gensokyo: Recovering legacy bullet-angle calculations #
REA also documents work on Touhou Gensokyo, commonly identified as TH04, an older PC-98 game.
The investigation focuses on bullet-ring angles and aiming behavior. For example, a pattern containing 16 bullets must distribute them around a ring and may additionally adjust their direction toward the player.
The project uses REA to inspect the original executable and compare the recovered calculations against an existing C++ reconstruction.
Legacy executables can be particularly challenging because they may rely on older instruction sets, compiler behavior, fixed-point arithmetic, and undocumented conventions. A readable reconstruction must reproduce those details accurately enough to match the original program.
The TH04 example shows how AI-assisted analysis can complement years of community work on legacy software. Rather than beginning with a completely unknown program, the agent can build on existing research and focus on the functions that remain difficult to understand or verify.
The broader lesson from these examples #
Across all four cases, the workflow follows the same basic pattern: identify a narrowly defined feature, locate the implementation, recover its logic, produce a replacement, and test the result against a reference.
The achievements are meaningful, but their scope should not be overstated.
Reconstructing one authentication algorithm or one game function is not equivalent to reproducing an entire application. The examples demonstrate that AI can assist with specific, measurable reverse-engineering tasks; they do not establish that any arbitrary software product can be completely rebuilt from a single prompt.
🎮 Classic Games Are Moving into the Browser #
AI-assisted reverse engineering is also attracting attention in the gaming community, where developers have spent years decompiling older games, building ports, and recreating their behavior on modern platforms.
Recent browser-based demonstrations have expanded the discussion by showing versions of games that originally required dedicated consoles or desktop installations.
Titles appearing in these demonstrations include Halo: Combat Evolved, Grand Theft Auto: Vice City, and The Simpsons: Hit & Run.
What browser-based ports demonstrate #
In an October 9 report, Kotaku journalist Lewis Parker tested several browser-based game builds. He described some as running surprisingly well, reporting that one version of The Simpsons: Hit & Run targeted 240 frames per second and that one of the Halo: Combat Evolved versions he tested connected to online servers with low latency.
These are observations from the reported tests, not standardized performance benchmarks for every available port.
Nevertheless, the demonstrations highlight what becomes possible when existing reverse-engineering work, modern browsers, and AI-assisted development are combined.
A browser can host compiled code through technologies such as WebAssembly and WebGL. If a game’s code has been reconstructed or ported to a compatible environment, users may be able to run it without installing a conventional desktop client.
Projects such as Halo CE Web Multiplayer illustrate this architecture by combining a WebAssembly client with dedicated servers and a networking gateway.
The browser is the delivery mechanism, however, not the source of the reconstruction itself. The underlying work still depends on game-specific code, platform compatibility, rendering, input handling, and networking.
AI accelerates existing community work #
It would be inaccurate to describe every browser port as a game independently recreated by AI overnight.
Many projects depend on existing decompilation efforts, prior research into game engines, and years of community contributions. AI can accelerate parts of the process by analyzing functions, generating candidate implementations, reproducing compiler behavior, and helping developers work through larger codebases.
But the speed of an individual demonstration does not establish the full engineering effort required to produce a stable, maintainable port.
Chris Lewis’s work on the Nintendo 64 game Snowboard Kids provides a useful example.
Snowboard Kids: From 596 days to 84 days #
In an August 2026 post-mortem, Lewis reported that the original Snowboard Kids had reached complete matching decompilation in 84 days. Its sequel, Snowboard Kids 2, had taken 596 days to reach the same milestone.
Matching decompilation means that reconstructed C implementations, when compiled with the appropriate toolchain, reproduce the original machine code for the functions being matched.
Lewis attributed part of the acceleration to AI-assisted workflows, including parallel agents and accumulated knowledge about compiler behavior. The project also benefited from his experience with the sequel and contributions from other developers.
He explicitly cautioned against attributing the time reduction entirely to AI. The projects differed in size, compiler requirements, existing knowledge, and the assistance available from the community.
The distinction is important because recovering code is not the same as fully understanding it. A reconstructed function can reproduce the original machine instructions even when its purpose, data structures, or relationship to the overall game remains unclear.
The speed improvement therefore demonstrates that AI can accelerate parts of a complex reverse-engineering process, not that all of the intellectual work has disappeared.
Copyright enforcement becomes more complicated #
The appearance of browser-based ports also raises practical questions for game publishers.
Kotaku’s coverage raised the possibility that removing one port may not prevent another from appearing, particularly if the necessary research and reconstruction techniques have become easier to reproduce.
This resembles a game of whack-a-mole: individual sites can be taken down, while new implementations may emerge elsewhere.
However, the ease of rebuilding a port does not eliminate intellectual-property rights. Distribution of reconstructed code, use of copyrighted assets, circumvention of technical protections, and unauthorized access to online services raise separate legal questions.
Some projects require users to provide their own legally obtained game files. Others may distribute material that creates additional legal exposure. The details depend on what a specific project contains and how it operates.
🌐 Browser-Based Office Tools Challenge Traditional Software Bundles #
The same broader trend can be seen in productivity software.
One example is VibeOffice on GitHub, an office suite designed around the familiar menu-and-toolbar interface of Office 2003. It provides browser-based word processing, spreadsheet editing, and presentation functionality.
The project supports formats including .docx, .xlsx, and .pptx, with files opened and saved locally in the browser without requiring a user account or a server-side document upload.
Its appeal is straightforward: users can edit common office documents without installing a full desktop suite or maintaining a subscription to a commercial service.
Yet VibeOffice illustrates a different path from REA. The project states that it was built from published file-format standards and documentation, rather than by decompiling or disassembling Microsoft’s Office applications.
That distinction matters. AI-assisted development can produce software alternatives by studying observable behavior and reconstructing binaries, but it can also accelerate implementations based on public specifications.
Both approaches can reduce development costs, although they raise different technical and legal considerations.
Familiar interfaces reduce adoption costs #
VibeOffice recreates a classic office interface that many users already understand. The menus, toolbars, and task panes reduce the learning curve and make common operations familiar.
For developers, interface familiarity is a practical competitive advantage. Users may be more willing to adopt an alternative when it supports their existing workflow and does not require relearning basic commands.
The project includes separate applications for word processing, spreadsheets, and presentations. Its browser-first design can also be useful in environments where users are not allowed to install software locally, including some corporate virtual desktops.
These are specific market needs that a smaller alternative can address without reproducing every feature of a commercial office suite.
Document compatibility is the real engineering challenge #
The hardest part of an office suite is not necessarily the interface. It is preserving complex documents accurately.
A spreadsheet may include charts, formulas, macros, styles, embedded objects, pivot tables, and external references. A presentation may contain animations, media, custom layouts, and effects. A word-processing document may depend on section formatting, comments, content controls, or advanced numbering.
A replacement that supports basic editing but silently discards unsupported information during saving can cause serious problems.
VibeOffice’s documentation describes an effort to preserve data the application cannot directly edit and to limit changes to the parts modified by the user. The project reports testing 4,697 files from public test collections associated with LibreOffice, Apache POI, and the Open XML SDK.
That is a useful testing foundation, but it does not prove perfect compatibility with every office document or every version of Microsoft Office.
A large test corpus can reveal many edge cases, while uncommon features and combinations may still fail. The relevant standard for a professional user is whether important documents survive opening, editing, saving, and reopening without unintended changes.
This is where a seemingly simple office clone encounters years of accumulated complexity.
The cost of compatibility work can exceed the cost of building the interface #
The developer has described spending roughly $1,000 in model usage on the interface and core features, with substantially greater usage afterward as work shifted toward automated testing, compatibility, and lossless editing.
Those figures are self-reported, but the broader lesson is clear: generating an initial implementation and making it dependable are different engineering tasks.
AI can help write file parsers, generate tests, and fix discrepancies. However, each additional document format, legacy behavior, and unsupported object type introduces more cases that must be understood and validated.
For developers, the lesson is not that compatibility work can be skipped. It is that AI may make it cheaper to build alternatives while leaving verification as one of the main determinants of product quality.
⚖️ Reverse Engineering Does Not Automatically Grant the Right to Copy #
The ability to reconstruct a feature and the legal right to distribute the result are separate issues.
Reverse engineering can be used for legitimate purposes such as interoperability, security research, software preservation, compatibility testing, and independent implementations of established behavior. Its legal status depends on the jurisdiction, the method used, the applicable licenses, and the purpose of the work.
Several boundaries deserve particular attention.
Reimplementing behavior versus copying protected expression #
A developer may observe how a feature behaves and independently implement similar functionality. That does not necessarily mean the developer has copied protected source code.
However, directly reproducing copyrighted code, copying protected assets, or distributing proprietary components can create legal problems. An interface can also involve protected elements depending on its design and the applicable law.
A clean-room development process may help establish that an implementation was independently created, but it does not guarantee that every aspect of the resulting product is lawful.
DRM, access restrictions, and trade secrets #
Bypassing digital rights management or other technical protection measures can trigger anti-circumvention rules, even where the broader purpose of a project might otherwise be legitimate.
Trade-secret law also matters. A reverse-engineering workflow cannot automatically legitimize information acquired through improper access, breach of confidentiality, or misuse of protected business information.
Contractual terms and software licenses may impose additional restrictions, although their enforceability and interaction with statutory exceptions vary by jurisdiction.
For these reasons, developers should assess the methods used to obtain information and the material included in the resulting product, rather than assuming that publicly available binaries are free from legal restrictions.
Open-source licensing still matters #
Publishing an implementation under an open-source license does not automatically resolve questions about the provenance of its code.
A repository may include independently written code, dependencies under separate licenses, generated code, or material whose origins need further review.
Projects that aim to provide alternatives to established software benefit from documenting their sources, respecting dependency licenses, reviewing generated code, and maintaining a process for investigating potential infringement claims.
The same principle applies to AI-generated software: the fact that a model produced the implementation does not remove the need to evaluate how it was created and what it contains.
💼 Will AI Reverse Engineering Break the Software Subscription Model? #
The commercial implications extend beyond the ability to reproduce individual features.
Matthew Berman and other commentators have argued that companies whose competitive advantage rests primarily on proprietary code may face growing pressure as AI lowers the cost of implementation.
The important question is not whether every commercial application will be replaced. It is whether the cost and time required to build a sufficiently useful alternative will fall below the threshold at which more developers can compete.
Historically, software companies have benefited from substantial engineering costs, specialized expertise, and years of development. Existing products also provide examples of which features users value, how workflows are organized, and what a successful interface looks like.
AI agents can use that established behavior as a reference. With automated testing and a clear target, developers can prioritize the features that matter most to a particular audience.
This could shorten the period during which an incumbent enjoys a large advantage simply because reproducing a working alternative is too expensive.
Single-purpose applications face the most immediate pressure #
Small utility applications may be particularly vulnerable.
Users often purchase them to complete one or two specific tasks. If an alternative can perform those tasks reliably, with a simpler interface or lower cost, the original product may have difficulty justifying its price.
For example, a user who occasionally needs to convert a file, process an image, or edit a spreadsheet may not require the advanced features of a full commercial suite.
Similarly, employees who cannot install local software may prefer a lightweight browser-based alternative if it works with their existing files and meets their organization’s security requirements.
In these cases, users do not necessarily need complete feature parity. They need the subset of functions that solves their actual problem.
That can lower the bar for competing products and weaken the value of features that users rarely touch.
Enterprise software has more substantial barriers #
Enterprise applications are a different proposition.
Large organizations depend on much more than the behavior of an individual feature. They need reliable integrations, role-based access controls, audit trails, data retention policies, regulatory compliance, predictable updates, migration tools, and support arrangements.
A reconstructed feature that works in a demonstration may not satisfy the requirements of a regulated production environment.
Organizations also need a party they can hold accountable when something fails. That includes security updates, incident response, long-term maintenance, and guarantees about data handling.
For these customers, the cost of switching can exceed the cost of the software subscription itself.
AI-generated alternatives may still create competitive pressure, particularly where existing products are expensive or poorly maintained. But replacing an enterprise platform requires solving organizational and operational problems alongside the software implementation.
Software vendors must compete on more than code #
As AI makes implementation cheaper, software vendors may need to place greater emphasis on advantages that are harder to reproduce.
These include trusted service delivery, proprietary data obtained legitimately, robust integrations, reliability, distribution, security, customer support, and continuous product improvement.
A mature application can remain valuable even if another developer can reproduce individual features. The challenge is to ensure that customers value the complete service enough to justify its price.
That may involve better workflows, dependable updates, team collaboration, compliance capabilities, or services that integrate deeply into an organization’s operations.
Subscription revenue will not necessarily disappear. But a product’s feature list may become a weaker defense against competitors that can implement a useful alternative at a lower cost.
Verification remains the dividing line between a clone and a product #
The examples discussed here demonstrate why testing is central to AI-assisted development.
REA can compare reconstructed behavior with an existing implementation. VibeOffice uses document test collections to check whether files survive editing and saving. Game decompilation projects can compare compiled machine code with the original binary.
Each approach provides a different way to measure correctness.
Yet no single test proves that an entire application is production-ready. Passing selected test cases does not establish compatibility with every input, device, operating system, or workflow.
For commercial products, sustained reliability also requires ongoing testing as dependencies, formats, operating systems, and user expectations change.
AI can accelerate the work of building a product, but its business value still depends on whether the result consistently meets users’ needs.
✅ Conclusion: Software Is Not Over, but Its Competitive Moats Are Changing #
REA, AI-assisted game decompilation, and browser-based office tools point to a common development: reconstructing selected software features is becoming faster and more accessible.
AI agents can investigate existing behavior, inspect executable code, trace data flows, generate implementations, and compare results against a reference. These capabilities reduce the amount of manual work required for some reverse-engineering tasks and make it easier for smaller teams to build alternatives.
The effects are already visible in narrowly defined features, legacy game functions, and office applications designed around common file formats. The projects do not prove that arbitrary software can be reproduced completely, but they show how quickly a capable alternative can emerge when the target behavior is observable and verification is possible.
For software vendors, the risk is not simply that competitors can copy their code. It is that competitors can increasingly reproduce the specific capabilities customers value without rebuilding every feature of the original product.
That makes single-purpose software and products with weak differentiation especially exposed. Enterprise platforms will face different and often larger barriers because compatibility, security, integrations, support, and accountability remain essential.
The legal boundaries also remain important. Technical feasibility does not confer permission to copy protected code, misuse trade secrets, or bypass access restrictions.
The more fundamental shift is that implementation is becoming less expensive, while verification, maintenance, trust, and distribution remain difficult.
Software companies will still be able to charge for products that solve problems reliably. But when a competitor can reconstruct the handful of features a customer actually needs, the incumbent can no longer rely on development cost alone to defend its pricing.
Software may not be over. The assumption that software is difficult to reproduce—and therefore inherently difficult to compete with—is becoming much harder to sustain.
