AI Product Cloning: Should Makers Be Worried?

AI product cloning is getting better at reproducing software people can see and use. That gives makers a reason to reassess their advantage. It does not establish that every product can now be copied completely, or that a convincing replacement will earn the same customers.

My view: AI gives challengers a cheaper way to irritate an established market. They can expose overpriced features, offer an alternative to an unpopular subscription, and make customers ask awkward questions. The harder work begins when someone trusts the alternative with a job that matters.

Research and precision still count. But the reassuring claim that this gap cannot close in a couple of months goes too far. Some products have a substantial gap. Others have little beyond an interface and an expensive plan.

The useful question for a maker is how much of the customer's reason to pay survives after someone reproduces the visible product.

The Photoshop alternative with an unusually honest roadmap

PhotoCraft makes this argument concrete. Its official repository describes an open-source, clean-room Photoshop reimplementation in Rust, with familiar editing tools and layered PSD support. Phoronix reported on October 7 that AI agents helped create the ArtCraft alternatives.

That is a better starting point than another hypothetical weekend clone. The code exists, and the project publishes evidence readers can inspect.

Its roadmap, updated October 13, estimates roughly 76% feature breadth but about 45% readiness for real work. It labels the project alpha and reports that 22 of 25 performance budgets are missed. It also says PSDs it writes are not yet reliably accepted by Photoshop.

These are the maintainers' estimates and reported measurements, not an independent certification. The readiness percentages depend on their weighting. They should not become a universal score for AI-built software.

Still, the distinction is valuable: a large feature inventory can coexist with serious workflow gaps. The project documents the distance between implementing a tool and making it dependable.

The README also reports that opening and re-saving preserves the rendered result for 307 of 309 files in one PSD test corpus. That is a specific accomplishment. It does not settle every question about how professional files behave when exchanged with Photoshop. The README and roadmap are testing different aspects of compatibility.

For a maker, both documents deserve attention. For a buyer, the crucial test is whether the replacement preserves the work they actually need to exchange.

This story uses public repositories, documentation, and research. We have not independently tested PhotoCraft or measured customer migration.

Can AI reverse-engineer every product?

No. AI-assisted tools can inspect accessible software and help reproduce observed behavior. They cannot infer every hidden rule, obtain inaccessible customer data, or establish production reliability from an interface alone. Software inspection, feature reconstruction, and replacing a business are different achievements.

REA, or Reverse Engineer Anything, shows how the workflow is changing. Its documentation describes connecting agents to analysis tools for native binaries, JavaScript and Electron apps, .NET assemblies, and websites. Results include evidence and limitations; native analysis can depend on installed tools such as Hopper, Ghidra, or IDA.

That makes specialist investigation easier to coordinate. It does not turn the project's name into a technical guarantee.

A desktop binary gives an investigator different evidence from a SaaS dashboard. A browser can expose interactions and client-side code without revealing the service's private implementation. A working imitation might use an entirely different backend to produce similar outputs.

That can be enough to compete. A challenger does not need your original source code if they understand the customer's task and can implement a useful alternative.

But an observation leaves questions unanswered. Did the import fail because of invalid data, an account limit, or a temporary dependency? What should happen after a partial write? Which behavior is intentional, and which is a bug?

Agents can help investigate these questions. The team still needs evidence to distinguish an explanation that sounds plausible from one that is correct.

Precision means knowing what counts as correct

“Research and precision” becomes a stronger argument when we specify what the builder must learn.

Consider an illustrative reporting product. Recreating its dashboard may be straightforward. Matching its numbers requires knowing how it handles refunds, currencies, attribution windows, and late-arriving events. Two systems can display identical charts while disagreeing about revenue.

Customer research determines which disagreement matters. A founder who has watched buyers reconcile a report understands something a screenshot cannot disclose: which number the buyer must defend to someone else.

Precision also requires a way to verify the answer. In compiler engineering, that can mean comparing outputs with a trusted compiler. In reporting, it can mean a reconciliation fixture whose expected result a domain expert has checked.

Anthropic's February 2026 compiler experiment demonstrates why this matters. Nicholas Carlini reported that 16 agents produced a roughly 100,000-line C compiler over nearly 2,000 sessions, at just under $20,000 in API costs.

The result could build substantial software, including Linux 6.9. Yet Carlini documented inefficient generated code, dependencies on existing tooling for some stages, and failures to compile some projects. He wrote: “It's not yet a drop-in replacement for a real compiler.”

He also explained how much work went into tests and feedback. When agents struggled with the kernel, he used GCC as a known-good comparison to isolate errors.

The achievement deserves respect. So does the verification work that made it possible. Faster implementation increases the value of knowing what to test.

That is why testing beyond AI benchmarks belongs in a product discussion. A successful demonstration answers a narrower question than dependable use.

A clone can pressure you before it replaces you

Your instinct about “pissing off the market” is commercially useful. A challenger can force a pricing conversation long before it matches an incumbent's entire product.

Imagine a small studio that needs basic editing and dislikes a subscription. It may accept missing capabilities that would disqualify the same alternative for an agency exchanging complex files daily. This is an illustrative comparison, not evidence that either group has switched to PhotoCraft.

The challenger can target the easier job first. It can also offer a different advantage, such as local operation or an interface built around agent control.

Makers who point to every missing feature risk answering the wrong objection. A buyer comparing alternatives may care about only a few of them.

This is the weakness in “makers aren't worried.” We have no evidence that makers share one attitude, and plenty of reasons their exposure would differ. A generic utility with easy exports faces a different threat from a system embedded in a difficult operational process.

A capable newcomer with domain experience and an existing audience is especially worth watching. AI lowers their implementation costs while they bring some of the research and distribution themselves.

The relevant gap is the distance to that buyer's acceptable outcome. It may be much smaller than the distance to full feature parity.

Product age is not protection

A long development history can contain useful knowledge. It can also contain decisions customers would happily abandon.

A billing system might have years of tested recovery behavior. A bloated productivity app might have years of menus. Both took time to build. Only one necessarily makes the customer safer or more effective.

A maker's advantage is stronger when they can identify an outcome their accumulated knowledge improves. Examples include preserving files across applications, resolving ambiguous customer inputs, or recovering an interrupted operation without losing work.

These examples are decision criteria, not measured claims about every incumbent.

AI also helps newcomers gather evidence. Public documentation, customer interviews, and compatibility tests can accelerate learning. Experienced builders can supply the judgment a novice lacks.

The comforting idea that research is permanently beyond AI is therefore weak. The better claim is that meaningful research requires access to relevant evidence and a sound method. Producing code does not automatically supply either.

The same reasoning applies to running a product. Our explanation of why AI agents fail even with a smart model examines the broader system around model capability. A founder needs to evaluate the whole customer workflow.

A practical test of your exposure

Use your next competitor review to compare customer tasks rather than screenshots. The table below is an editorial framework, not a validated scoring model.

Ask about the customer	Evidence to examine	What would make the challenger credible?
What job keeps them paying?	Renewal reasons and observed usage	Completing that job at acceptable quality
Which failure would make them leave?	Support cases and incident records	Passing representative failure and recovery tests
What would switching require?	Real exports and integration dependencies	A migration rehearsal that preserves required data
Who would consider a simpler alternative?	Customer interviews and lost deals	A clear offer for that specific group
What improves through continued use?	Checked outcomes and resolved exceptions	A repeatable way to acquire comparable knowledge

Start with one customer task and write down its acceptance conditions. Include an ordinary case and a failure that matters. Keep sensitive customer data out of any shared comparison; use authorized, representative examples.

For an AI-enabled service, include what happens when the system misunderstands the request. Our AI agent safety checklist covers permission and approval boundaries that a feature list can miss.

This review may uncover a durable advantage. It may also reveal that customers tolerate your product because the alternatives have been inconvenient.

Either finding is more useful than arguing about whether your interface can be cloned.

The gap has no fixed expiry date

The evidence here cannot tell us how long a particular clone will take to become dependable. PhotoCraft's estimates describe one project's current assessment. Anthropic's compiler experiment describes a particular model, task, and testing environment.

Even productivity evidence needs its date and scope. METR's July 2025 study found that 16 experienced open-source developers took 19% longer on the studied tasks when AI was allowed.

That is easy to misuse as reassurance. In a February 2026 update, METR said later results suffered from selection effects, including developers unwilling to work without AI. The researchers believed tools were likely providing more speedup, while cautioning that the data weakly established its size.

Neither study measures how long it takes to displace a software company.

The warning for makers is specific: do not turn today's limitations into a permanent defense. Watch whether a challenger is closing the failures that matter to your customers, and whether customers are beginning to trust it with real work.

Your strongest thesis is that AI makes entry cheaper while dependable substitution still requires research and precision. It leaves room for both a substantial engineering gap and a challenger who wins before closing all of it.

Makers should take that seriously. A working alternative can make customers reconsider what they are paying for. The response is to make the reason to stay demonstrable.

ThePromptBuddy's bi-weekly newsletter brings practical prompts, model insights, and tool reviews to AI professionals. Join free for help judging what the next impressive demo can do in your own workflow.