AI Moat After PhotoCraft: Clone-Test Your Own Product Before Agents Do

PhotoCraft rebuilt Photoshop's menus in a week; its README says behaviour lags far behind. Audit what a clone of your product could copy and what it would lack.

Russell WinslowOctober 7, 202615 min read

All articles

An AI moat audit starts with one line through the product: what a clone can see, and what sits behind the glass.

THE FIELD GUIDE

Go deeper. Build your own.

PhotoCraft, Raymond and Naval: what the README says, Oct 6 to 7
Run the clone test on your own product
Where a clonability audit misleads you

Seven repositories appeared under one GitHub organization between Sep 30 and Oct 1, 2026, each aimed at a different Adobe app. Within a week the Photoshop one had more than 18,000 GitHub stars (18.4k when read Oct 8), a famous programmer declaring closed source dead, and a README politely explaining that it is early alpha.

Both reactions are useful, and neither answers the question your board will ask on Monday: what is our AI moat when a determined developer with coding agents can rebuild the visible parts of an app in days? The honest answer differs by capability.

Some of what you sell is visible in the interface and can be rebuilt from observed behaviour. Some of it sits behind the glass: a running service, customers’ data, signed contracts, an audit history. Agents copy the first kind quickly and the second kind barely at all.

So run the clone test on yourself. List every capability, tag it visible-in-UI or behind-the-glass, estimate who could rebuild it and how fast, write down what a clone would still lack, and move next quarter’s investment toward the second column. Then add two rules for your own agents’ rebuild work: a clean-room provenance log and an honest way to state parity.

PhotoCraft, Raymond and Naval: what the README says, Oct 6 to 7

PhotoCraft describes itself as “an open-source, clean-room reimplementation of Adobe Photoshop in pure Rust,” licensed MIT and Apache-2.0, from the team behind ArtCraft. It has six sibling “Crafting Apps” aimed at Illustrator, Premiere, Lightroom, Acrobat, After Effects and InDesign, and the seven repositories were created between Sep 30 and Oct 1, according to OrcaRouter’s read of the GitHub metadata. GIGAZINE covered the set on Oct 5 (GIGAZINE).

GitHub repository page for storytold/photocraft, described as an open-source, clean-room reimplementation of Adobe Photoshop in pure Rust, showing 17.5k stars, 2.3k forks and Apache-2.0 and MIT licenses Screenshot: GitHub, “storytold/photocraft: An open-source, clean-room reimplementation of Adobe Photoshop in pure Rust” (repository page, Oct 7, 2026), captured Oct 7, 2026.

The capture shows 17.5k stars and 2.3k forks; the GitHub API read 18,361 stars and 2,423 forks at about 03:35 UTC on Oct 8, and both are snapshots of a number moving by thousands a day.

On Oct 6, Eric S. Raymond posted that the project meant “Adobe just got nuked. And closed source is dead, dead, dead,” and speculated that the team had decompiled Photoshop. His post reached millions of views, by the tallies in TechFounderStack’s Oct 7 roundup and explainx’s coverage, which give different totals.

The decompilation theory is disputed: a reader-added context note on the post reportedly pushes back, and the README says the code was built “from public specs and observed behaviour only.” That clean-room claim is the project’s own and has not been independently checked.

Naval followed on Oct 7 with “Models are the last moat in software… Expect more software to retreat to the server and resist ‘distillation,’” as TechFounderStack quotes it.

Now the part the threads skipped. The README's status box is blunt:

PhotoCraft README status box stating the project is in early alpha, is not yet a Photoshop replacement for daily professional work, lists gaps in generative features, about twenty missing tools, typography and plug-in compatibility, and says menu wiring measures wiring, not behaviour Screenshot: GitHub, “storytold/photocraft” README status section (repository page, Oct 7, 2026), captured Oct 7, 2026.

PhotoCraft “is in early alpha” and “is not yet a Photoshop replacement for daily professional work.” The biggest gaps it names are generative features, “about twenty missing tools,” depth in typography and pro workflows, and plug-in compatibility. Every Photoshop menu item is wired to a command, “but that measures wiring, not behaviour.” The project’s own parity tooling reported 625 of 625 menu items wired on Oct 3, per OrcaRouter, while WebProNews, reading the project’s own roadmap, estimated Photoshop parity “below 50 percent,” as TechFounderStack reports it.

How long it took depends on who is counting. Claims run from “a handful of wall-clock hours” for about 70 menu items with eight parallel agents, quoted from a planning note by OrcaRouter, to four weeks with two committers, as a commenter in a Hacker News thread put it.

Press reports, citing the developer, credit Claude Opus 5.5 for the build. None of those figures is verified here, and none needs to be for the lesson to hold: the visible surface of a large desktop app was stood up fast, and the behaviour behind it was not. This article draws no conclusion about clean-room status, which is a question for counsel, and says nothing about Adobe as an investment.

The strongest counter-arguments in the week’s commentary were operational, not technical. Between them, TechFounderStack and explainx cover three: the last 20% and the ecosystem around it (plug-ins, brushes, presets, color accuracy, print workflows, performance on enormous files); accountability, because enterprises buy support, licences, audits, liability and insurance, and a repository cannot sign an SLA; and server-side data, which is Naval’s own point about retreat to the server.

Even the sibling projects concede it. OrcaRouter quotes PrintCraft’s roadmap saying Adobe’s cloud and AI assistant have “no clean-room equivalent.” TechFounderStack also cites investor Einar Vollset’s acquisition criteria, which favour network effects, closed-loop data and operational switching costs over code.

Run the clone test on your own product

The precise version of the week’s claim is narrower than “code is free.” What got cheap is software whose value is visible in the interface. A clone can watch your product, read your public docs and rebuild what it sees.

It cannot watch your uptime history, your customers’ data, your signed contracts or the audit trail a regulator will ask for. The clonability audit makes that split explicit, one row per capability.

Step 1: List capabilities, not features

Write one row per thing a customer would miss if it vanished: a capability, not a menu item. “Export” is one row even if it has nine formats; “audit log” is one row even if three teams own pieces of it. Twenty to thirty rows covers most products.

Pull the list from your pricing page, your security questionnaire answers and your last five lost-deal notes, because those three sources name what customers actually pay for. The pricing page’s role as a contract with buyers is covered in the never-paywalled controls piece; here it is an inventory source.

Step 2: Tag each row visible-in-UI or behind-the-glass

Visible-in-UI means someone could rebuild it from observed behaviour, public specs and your documentation. Behind-the-glass means the value depends on something a clone cannot observe or download:

a server-side service, or live or proprietary data
integrations and identity (SSO, SCIM, customers’ existing configurations)
an audit trail and the evidence it holds
SLAs, certifications, insurance and someone contractually on the hook
approval workflows that encode a customer’s own policy
support, and the accountability that comes with a named vendor

Some rows split. Team permissions have a visible role editor and an invisible mapping to every customer’s identity provider. Tag the row by where its value lives, and note the split in the next column.

Step 3: Give each row a rebuild time class

Estimate who could rebuild the capability and in what time class: hours, days, weeks, quarters, or not by code. The “who” matters as much as the time. “One developer with agents” is a different threat from “a funded team” and from “nobody, because it takes a company.”

Be uncomfortable here. If the honest answer for your flagship editor is “days,” write days.

Use the same five definitions across the whole audit so the rows compare:

Hours: a single agent session from public docs could produce something a user would mistake for yours in a demo.
Days: one developer running agents in parallel, the shape the PhotoCraft planning notes describe as OrcaRouter quotes them.
Weeks: a small team, plus test data or partner access a stranger would have to request.
Quarters: a funded team, a running service and some operating history before anyone trusts it.
Not by code: it takes a company, a contract or the data itself, and no amount of engineering closes the gap.

Step 4: Fill in the audit

Capability	Visible-in-UI or behind-the-glass	Who could rebuild it, and time class	What a clone would still lack	Where next quarter’s investment goes
Editor UI (canvas, tools, menus)	Visible-in-UI	One developer with agents; days	Years of edge-case behaviour, performance on customers’ largest files	Hold steady; fund performance on real customer files only
Export formats (PDF, PNG, DOCX)	Visible-in-UI (public formats)	Small team with agents; weeks	A regression corpus of customers’ real documents and their fidelity history	Grow the regression corpus, not the format count
Cloud sync	Behind-the-glass	Funded team; quarters	A running service, conflict-resolution history, an uptime record	Publish sync reliability targets and a status history
Team permissions	Split: editor visible, rules behind	Small team; weeks for the editor	Customers’ role mappings and identity-provider wiring	Admin migration tooling and SCIM coverage
Audit log	Behind-the-glass	Small team; weeks to build, years to accumulate	Customers’ historical records and retention attestations	Signed, exportable audit records
SSO	Behind-the-glass (integration)	Small team; weeks per identity provider	Tested provider configurations per customer	Certify the next two identity providers customers ask for
Support SLA	Behind-the-glass (contract)	Not by code; it takes a company	A signed contract, on-call staff, incident history	Response-time reporting customers can audit
Proprietary data model and customer data	Behind-the-glass	Not by code	The data itself and the integrations writing into it	Data portability and APIs customers build on

Every row above is illustrative, for a hypothetical document-editing product. The filled example to copy is the first: the most visible capability, the shortest time class, and an investment column that deliberately stops adding surface.

Illustrative horizontal bar chart of 24 capabilities in a hypothetical product by clonability class: 9 rebuildable in hours to days, 6 in weeks, 4 that take weeks to build and years to accumulate, 2 in quarters, and 3 not by code Illustrative: a 24-capability product sorted by rebuild time class. Most of what a customer sees sits in the two fastest classes.

Step 5: Move next quarter’s investment, with numbers

Here is the worked scenario, every number illustrative. A product team audits 24 capabilities. Fifteen are visible-in-UI, nine of them in the hours-to-days class and six in weeks; the other nine sit behind the glass. The team’s draft roadmap for next quarter holds 60 points of planned work, and 42 of them, 70%, land on visible-in-UI rows: a redesigned toolbar, two new export formats, a dark theme.

After the audit, the team keeps the work customers asked for by name and moves the rest. The new plan puts 24 points, 40%, on visible rows and 36 points, 60%, on behind-the-glass rows: signed audit export, two more identity providers, a public sync status history, and a migration tool for customers’ existing roles. Nothing in the new plan is glamorous. All of it is something a weekend clone would have to build a company to match.

The audit also tells you what not to spend on. A row in the “days” class with nothing in its “still lack” column is a feature you maintain, not one you defend. The question of what you own versus what you rent as a buyer of models and harnesses is different and lives in own the loop, rent the model; this register is the builder’s side of the same coin.

Step 6: Keep a clean-room provenance log for your own agents

The week’s other lesson points inward. Your agents rebuild things too: a competitor’s import format, a library you are replacing, a port of an internal tool. Write down what they were allowed to read, before the work starts, and keep the record after it ends. An illustrative log entry:

rebuild: csv-import-compat
purpose: import files exported by a competitor's product
allowed_inputs:
  - public format specification (link, version, date read)
  - observed behaviour from our own licensed account (recordings stored)
  - licensed vendor documentation (licence reference)
banned_inputs:
  - decompiled or disassembled binaries
  - proprietary assets (icons, shaders, fonts, sample files)
  - leaked, scraped or otherwise unlicensed source
sessions:
  - id: rb-0412
    agent: coding agent, standard serving
    touched: [crates/import/csv_compat.rs, tests/import/fixtures/]
    inputs_used: [format spec v3, behaviour recordings 1-6]
  - id: rb-0413
    agent: review agent
    touched: [review notes only]
    inputs_used: [diff of rb-0412]
logs_kept: full transcripts, 24 months, ops/provenance/
reviewer: named engineer, signs off before merge

Require the log for any agent task whose brief mentions another company’s product, file format or behaviour, and for any port of code your team did not write. The cost is a few minutes per rebuild. The alternative is reconstructing, months later and under pressure, which session read which document.

The log does not decide anything legal; it preserves the facts someone would need to decide it. A transcript showing which inputs each session read is also the same evidence an incident review starts from, which is why fleet replay treats session records as the record, not a nice-to-have.

Step 7: Adopt the parity-honesty rule

PhotoCraft’s README models the rule better than most vendors do: it reports a perfect wiring score and then says what that score does not measure. Make that mandatory for every parity claim your team publishes, in a README, a sales deck or a migration guide. Each claim names its measuring tool and says which kind of parity it measured:

claim:        "full menu parity with <reference product>"
measured_by:  <script or tool name and version>
measures:     wired (command exists)  |  behaves the same (output matches)
sample:       <what was compared, how many cases, on which files>
as_of:        <date>
gaps_known:   <the list you would want a buyer to read>

“Wired” means a command exists behind the menu item. “Behaves the same” means the output matches on a defined set of inputs. A claim that does not say which one it measured gets rewritten before it ships.

Diagram of the clonability audit: a product splits into visible-in-UI capabilities, rebuildable from observed behaviour, and behind-the-glass capabilities; each leads to what a clone would still lack, and both feed next quarter’s investment, weighted to behind-the-glass The audit in one picture: split the product, write what a clone lacks, and let that column steer the roadmap.

Step 8: Re-run the audit on a calendar and on events

Re-run the audit every quarter and whenever one of these happens: an open-source rebuild of a product in your category appears, a customer asks in a renewal why they should not switch to one, or your own agents finish a rebuild of something you assumed was hard. Move rows between time classes when the evidence says so, and date every move.

The most useful re-run is the one triggered by your own fleet. If your agents rebuilt an internal tool in a day that you had filed under “weeks,” assume a stranger’s agents can do the same to the visible half of your product, and move that row before a competitor’s README moves it for you.

Where a clonability audit misleads you

What breaks	Signal you would see	First action
Every row tagged behind-the-glass	The audit has no visible-in-UI row in the days class	Timebox one engineer with agents to rebuild the top visible row; re-tag from the result
A behind-the-glass row is actually exportable	A rival imports customers’ data in one click through your own public API	Re-tag the row; invest in what the export cannot carry (history, integrations, attestations)
The roadmap ignores the audit	Next quarter’s plan still puts most points on visible rows	Bring the investment column to planning; require a reason for each visible-row item
Provenance gaps in a rebuild	A merged rebuild has no session list or input record	Freeze further merges on that rebuild until the log is reconstructed or the work redone
A banned input slipped in	A file or snippet traces to decompiled code or leaked source	Quarantine the branch, preserve the transcripts, and bring in counsel before anything ships
Parity claimed without a tool	A deck or README says “95% parity” and names no measurement	Rewrite the claim with the parity-honesty fields or remove it
The audit goes stale	The audit date is older than a quarter, or predates a rebuild in your category	Re-run it that week; date every row that moves

Operational evidence is the part of a fleet nobody can fork

The pattern under the PhotoCraft week is that code which can be watched can be rewritten, and what cannot be watched is what you accumulated by operating: approvals that encode customers’ policies, identity wired into their directories, audit trails, kill switches that have been tested, meters that show who spent what. That is the thesis behind agentic ops: when agents do more of the building, the durable asset is the operating record around them, and a weekend clone starts with an empty one.

Two neighbors cover adjacent decisions. Whether to buy or build an agent platform in the first place is argued in the OpenClaw vs AutoClaw piece. In this batch, the mode-to-model assignment table covers the buyer’s side of lock-in, and steer-or-handoff routing covers how a person works with the fast agents that made this week’s rebuilds possible.

FAQ

What is an AI moat for a software company?

It is whatever stays hard to copy when coding agents make rebuilding interfaces cheap. Visible features can be reproduced from observed behaviour. Running services, customer data, integrations, audit history, certifications and signed support commitments cannot, because they come from operating a business over time. Audit capabilities one by one to find yours.

Is PhotoCraft a Photoshop replacement?

Not by its own account. The README calls PhotoCraft early alpha and “not yet a Photoshop replacement for daily professional work,” naming gaps in generative features, about twenty tools, typography and plug-in compatibility. Its perfect menu score measures wiring, not behaviour, and WebProNews, reading the project’s roadmap, put Photoshop parity below half.

How do you measure feature parity with a clone?

Name the tool that measured it and say what it measured. Wiring parity counts commands that exist behind each menu item. Behavioural parity compares outputs on a defined set of real inputs. Publish the sample, the date and the known gaps, and treat any percentage without those fields as marketing.

AI Moat After PhotoCraft: Clone-Test Your Own Product Before Agents Do

PhotoCraft, Raymond and Naval: what the README says, Oct 6 to 7