REA and ArtCraft Build AI Clones of Adobe and Microsoft Software Without Access to Source Code

KDnuggets wrote on October 12, 2026 about two projects, REA and ArtCraft, that have set off a wave of AI clones of commercial software. The idea is to recreate Adobe- and Microsoft-class tools without having their source code. The article gives no public numbers: no feature counts, no download figures, no compatibility test results. So below we look at the mechanics and the risks, not the scale.

How a clone is built without source code

Reverse engineering is older than any neural network. You take a finished program and study how it behaves from the outside: which file formats it reads and writes, what it outputs for a given input, what the interface looks like, what the public documentation says. From these observations, you write your own implementation. This work used to take a team months or years.

Now a coding agent can handle a significant part of the cycle. This is the general logic of the approach; the source does not disclose the architecture details of REA and ArtCraft. The agent opens a test file in the original and in the clone, compares the results, finds a discrepancy and fixes the code. Then it repeats this thousands of times. The task suits AI because a reference is always at hand. The original program exists, which means an automatic check exists too: match or no match.

Why it went viral

There are probably several reasons. Adobe and Microsoft build their businesses on subscriptions, and any attempt to get a similar tool without a subscription draws keen interest from developers. The projects also show vividly how far the reproduction of complex software can be automated. They are a good demonstration of what coding agents can do on real, large and tangled products, not on toy tasks.

What the source says, and what it leaves out:

• Goal: recreating Adobe- and Microsoft-class software
• Method: reverse engineering and rebuilding with AI
• Source code of the originals: not used
• Coverage of the original's features: not stated
• License of the clones and the authors' legal position: not stated
• Quality and file-format compatibility: no independent measurements

The legal gray zone

There is precedent for this kind of practice. In the early 1980s, Compaq reproduced IBM's BIOS using the "clean room" method: one group of engineers described the behavior, and another group, who had never seen the original, wrote the code. In 2021, the US Supreme Court ruled in Google v. Oracle that copying Java API declarations was fair use. In the EU, the Software Directive permits decompilation for the sake of interoperability.

AI clones, however, have particular wrinkles. A model may have trained on someone else's code and could reproduce fragments of it, in which case the "cleanliness of the room" would have to be proven. User agreements often prohibit reverse engineering. Fonts, icons, templates and other resources are protected by copyright separately. Patents and trademarks do not go away either. Courts have not yet decided where compatibility ends and copying begins in cases like these.

What teams should do

If you are thinking about adopting clones like these, start with the project's license and the provenance of its code. Without an audit, it is better not to put them into production, especially at companies with compliance requirements. For personal and internal experiments the risk is lower, but check format compatibility on your own real files, not on demos.

If you are a developer, look at the methodology: "a reference program plus automated comparison" suits migrating legacy systems and writing compatible libraries. Vendors should revisit their license terms and consider how well protected their format interfaces are. For software buyers, clones offer a negotiating argument, but for now more as a market signal than as a ready replacement.