AI Agents Are Reverse-Engineering Photoshop and Office: Inside the New Wave of Software Clones

The Clone Wave: Rebuilding Familiar Interfaces Instead of Reinventing Them

For two decades, the free software playbook was consistent. If you wanted an alternative to Photoshop, Illustrator or Word, you built something new: a different interface, a different file format, a different mental model. GIMP, Inkscape and LibreOffice are the products of that philosophy, and they are genuinely capable. They also ask users to relearn habits built over years.

The current wave of AI-assisted clones inverts that. Instead of designing a new interface, developers are aiming to reproduce the familiar one. Menus, keyboard shortcuts, tool palettes and layout follow the commercial original as closely as possible, with the explicit goal of shrinking the cost of switching. Many of these projects are built by individual developers rather than teams, and the quality and compatibility of the early results, by most accounts, still vary considerably.

The enabling technology is not just code generation. It is a new class of reverse-engineering toolkit that lets an AI agent interrogate a compiled binary the way a human analyst would, and do it fast enough to be part of an ordinary development loop.

REA Explained: Wiring Agents into Ghidra, Hopper and IDA

REA’s design is connective rather than magical. It wires AI coding agents such as Claude Code, Codex and Cursor into established reverse-engineering tools including Ghidra, Hopper and IDA. The workflow is direct: you supply an application’s binary, and the agent analyzes its functions, dependencies, architecture and internal behavior without access to source code. The findings can then inform recreating features or building an alternative implementation.

That integration matters because the bottleneck in reverse engineering has never been the disassembler. It is the analyst’s time. An agent that can propose hypotheses about what a function does, trace dependency chains and summarize architecture lowers the cost of the first pass enormously. Teams already comparing agent harnesses for conventional work will recognize the pattern from our AI Coding Assistants Compared: Cursor, GitHub Copilot, Claude Code, Windsurf and Replit Agent After a Month of Real Work, where the tool that wins the benchmark table is not always the one that survives a long refactor.

What REA Can and Cannot Do

The published showcase examples are modest and specific, which is a point in their favor. One reconstructs Notion’s clipboard functionality. Another recreates the sound calculations from DX-Ball. A third recovers mathematical routines from older PC-98 games. None of these is a headline-grabbing demo, and that is exactly what makes them credible: they are the kind of narrow, verifiable behaviors that real reverse engineering deals in.

The limitation is equally clear. REA does not automatically produce a perfect clone. It makes understanding existing software easier. Everything downstream, from architecture decisions to writing and testing the replacement, remains human work. Anyone who reads the project as a clone button has misread it.

There is a second, quieter risk. Agents that describe binary behavior can be confidently wrong, and the output of a disassembly-adjacent analysis is hard to sanity-check without expertise. The dynamics described in Inside Anthropic’s Push for Trustworthy AI Agents: An Engineer’s Take on Claude’s Reliability apply directly here: a model that does not hedge and does not flag uncertainty is most dangerous precisely when it sounds most certain.

ArtCraft and Brandon Thomas: Claude, Rust and a One-Month Target

The most visible test case of the approach is ArtCraft, a collection of Adobe-inspired applications built by developer Brandon Thomas using Claude and Rust. The lineup includes PhotoCraft for Photoshop-style image editing, VectorCraft for Illustrator-style graphics and FilmCraft for Premiere-style video editing. The same ecosystem also contains projects inspired by Microsoft Office, though the specific titles were not detailed in the source material.

Thomas initially aimed for complete Adobe feature parity within a month. That target drew skepticism, and reasonably so. Feature parity with a suite that has absorbed decades of engineering effort is not a calendar problem. It is a surface-area problem: color management, file format quirks, GPU acceleration paths, plugin ecosystems, undo semantics, and thousands of edge cases that users only notice when they break.

The choice of Rust is notable. It signals that the project is not purely a vibe-coded prototype and that performance and memory safety were considered from the start. But language choice does not substitute for the accumulated bug fixes that mature software carries.

The Skeptic’s Checklist

Reaction to the clone wave splits cleanly. There is genuine excitement that individuals can now attempt to recreate complex commercial software, and real interest in cheaper alternatives that look and feel like familiar tools. There is also open doubt about whether vibe-coded applications can match the reliability, performance and functionality of mature products like Photoshop and Excel. Early testers have raised concerns about bugs and missing features.

For engineers evaluating any clone claim, a practical checklist helps:

• Behavioral coverage, not screenshots. A matching toolbar proves nothing. Ask which file formats round-trip without data loss and which operations are implemented versus stubbed.
• Edge cases and failure modes. Mature software is mostly an archive of fixed bugs. Ask how the project handles corrupt input, huge files, unusual color profiles and interrupted operations.
• Performance under real workloads. Prototypes often perform well on demo assets. Test on the files your team actually uses.
• Reproducibility. Can you build the clone from a clean checkout and get identical results? An agent-driven build that cannot be rerun and audited is a demo, not a tool.
• Provenance and licensing. Know what was reverse-engineered, how, and under what terms before anything ships.

The Subscription Question

The economic argument is the loudest driver of interest. If AI-built alternatives can eventually deliver the same experience for free, why keep paying for expensive subscriptions? It is a fair question, and it deserves a more careful answer than the excitement suggests.

Cost of ownership is not only license fees. It includes retraining, plugin and script compatibility, file exchange with clients and partners, integration with existing asset pipelines, and the institutional knowledge embedded in years of muscle memory. A clone that matches the interface but breaks a critical export path can cost more than the subscription it replaces.

Legal and licensing questions around reverse engineering also remain open. The rules differ by jurisdiction, and they turn on details: whether the work involves decompilation, how interoperability is defined, whether end-user license terms prohibit the analysis, and whether any code was copied rather than independently reimplemented. None of this is settled by a GitHub star count.

What Engineers Should Watch Next

Three signals are worth tracking. First, the maturity of agent-to-tool integration: how reliably Claude Code, Codex and Cursor drive Ghidra, Hopper and IDA on real binaries, and whether their analyses can be validated rather than merely trusted. Second, reproducibility: whether clone builds are deterministic and auditable, which determines whether they can be used professionally rather than experimentally. Third, the emergence of compatibility test suites, since a clone’s value will increasingly be measured by what it passes, not what it looks like.

The practical takeaway for teams is to treat AI-assisted reverse engineering as a research and interoperability tool first. It is excellent at answering “how does this software behave and why,” and that alone can unblock migrations, format support and legacy integrations. Treating it as a shortcut to shipping a mature product replacement is where the skepticism is earned. The interesting story is not that AI can write code. It is that understanding compiled software has become a reproducible workflow, and that changes what a small team can credibly attempt.