A collection of Adobe-style applications built with AI assistance has been circulating online. Meanwhile, developers have been bringing games such as Halo and GTA into web browsers, experimenting with crossovers between unrelated games, and getting Windows-only software to run on Macs.
Some of these projects are surprisingly capable. Others are rough prototypes, emulator wrappers or short demos that reveal little about how well the software works. What interests us is the amount of reverse-engineering work that can now be handed to a coding agent and left to run.
The term Reverse Engineer Anything (REA) has started to catch on. There's even an open-source toolkit with that name. It describes several related techniques, rather than one method for cloning any application.
What is actually being recreated?
PhotoCraft is part of ArtCraft, a collection of applications modelled on Adobe's creative software. PhotoCraft has familiar editing panels, layers, masks and brushes, with support for PSD files. Its maintainers describe it as a clean-room implementation in Rust based on public specifications and observed behaviour. They aren't claiming to have recovered Photoshop's source code.
Games offer another set of examples. Kotaku tested browser-playable versions of Halo: Combat Evolved, Call of Duty: Black Ops, GTA: Vice City and Skate 3. A separate GTA V browser project reportedly used WebAssembly, although the site became inaccessible shortly after appearing.
Then there are clips combining Minecraft-, Call of Duty- and Skate-like mechanics. Making a crossover that feels like several existing games is different from faithfully reproducing any one of them. The same goes for making Windows software work on a Mac: a native rewrite, compatibility layer and emulator might look similar to the person using them, but they're different technical achievements.
That distinction gets lost when every project is described as an AI-built clone.
How the process works
Reverse engineering itself isn't new. The NSA's open-source Ghidra can disassemble an executable, trace relationships between functions and produce approximate pseudocode. It gives an engineer clues about how compiled software works. It does not restore the exact original source code.
Agents can now work through much of that investigation. An agent examines functions and assets, makes a guess about how part of the program behaves, writes replacement code, runs a test and revises the result. Tools such as REA make it easier to connect coding agents to decompilers and other analysis software. For a clean-room alternative like PhotoCraft, the process may instead start with documentation and observations of the original interface.
The difficult part is checking whether the new code actually behaves like the old code. A plausible-looking function can still be wrong in ways that don't show up until much later.
For web apps or clean-room builds, observation and public documentation may take the place of binary analysis.
Developer Maurice Heumann gave a useful account of this in an October 9 post. He describes spending three months orchestrating agents to reconstruct an unnamed first-person shooter. Early attempts produced code that looked credible but behaved incorrectly. He eventually introduced automated checks that compared reconstructed functions against the original binary. He reports reconstructing 99% of functions, with 83% matching byte for byte, at an estimated cost of 600–700 billion tokens. These are his own figures, and the code isn't public.
The lesson is that giving an agent more time only helps if it can tell when it's wrong. Automated testing is what makes a long-running process useful. And three months of work is hardly an overnight clone.
What if there is no executable?
Downloaded software provides plenty to inspect: compiled code, assets and local behaviour. With a web application, much of the implementation stays on the server. But an agent can still study the product from the outside.
It can interact with screens, try different inputs, record outputs, follow user workflows and compare its own implementation against the original. Given enough experiments, it may be able to produce something that serves the same purpose without knowing how the original backend works.
There are limits. Proprietary datasets, external partnerships, complicated infrastructure and uncommon edge cases may be difficult or impossible to reproduce from observation alone. But software companies should distinguish between protecting their source code and protecting the experience customers pay for. The latter can often be imitated without access to the former.
The demos aren't enterprise replacements
The ArtCraft projects are a good example of the current gap. PhotoCraft is labelled early alpha. An independent hands-on test found familiar interfaces but substantial weaknesses in editing tools and video workflows. Looking like Photoshop in a screenshot is much easier than replacing it for a working creative team.
A business buying Adobe is also buying file compatibility, frequent updates, support, collaboration, plugins and a vendor willing to stand behind the product. Security and procurement teams aren't likely to approve an unvetted alternative simply because someone recreated the interface for free.
There are legal differences as well. Building an independent application with similar features isn't the same as distributing copyrighted code or game assets. Licences, trademarks and anti-circumvention rules can further complicate projects based on existing games. Some of the most striking demonstrations may never become products people can legally or comfortably use.
So we wouldn't read these projects as evidence that Adobe or major game publishers are about to lose their customers. They do, however, show where the cost of reproducing software is heading.
What does your software have beyond its features?
The nearer-term exposure is probably greatest for products with a narrow set of features, a relatively simple interface and little proprietary information behind them. A downloadable utility or specialised desktop application may be easier to reproduce than its developer expects. Shipping an executable also puts more of the implementation in a potential competitor's hands.
Moving the code to a server isn't a complete defence. If most of the value is in an observable workflow, someone may be able to build a substitute without copying the implementation.
Other parts of a software business are harder to recreate: proprietary data, integration into customers' operations, communities and partner networks, support, reliability, and the ability to handle difficult cases at scale. None of these is permanent protection, but they matter when a buyer decides whether to replace an existing product.
One useful exercise is to imagine a competitor with access to your software, its documentation and several coding agents for 90 days. Assume they can recreate most of your standard features. What would still be difficult for them to offer? What would make customers reluctant to switch?
Reverse engineering is becoming cheaper and less dependent on specialist labour. That doesn't make every software product replaceable. But it puts more pressure on companies whose main defence is that building the same features used to be difficult.