# Thirteen Adobe and Office clones written with Claude: we built and ran all of them
In the first two weeks of October 2026 a GitHub organisation called `storytold` went from a few old Unreal Engine plugins to the most talked-about open-source project of the month. Brandon Thomas, founder of the ArtCraft studio, published Rust rewrites of Photoshop, Illustrator, Premiere Pro, Lightroom, After Effects, InDesign and Acrobat, then, a week later, of Word, Excel, PowerPoint, a CAD tool and an audio editor. Almost all of the code was written with Claude Opus 5.5. PhotoCraft, the Photoshop one, passed 59,000 stars in fourteen days.
The headlines went two ways: "Adobe is dead" on one side, "it's a pile of AI-generated screenshots" on the other. Neither is very useful if you have to decide whether to use this, build something similar or explain it to a client. So we did the boring thing. We cloned all thirteen apps, built them from source on a Mac, ran them, fed PhotoCraft a few hundred real PSD files, measured memory, and connected to the MCP servers. This article is what we found.
## What happened, in order
- **30 September:** the first repositories appear: PhotoCraft, VectorCraft (Illustrator), FilmCraft (Premiere), LightCraft (Lightroom) and PdfCraft (Acrobat). EffectCraft (After Effects) and DesignCraft (InDesign) follow on 1 October. All are dual-licensed MIT / Apache-2.0.
- **2–3 October:** the announcement goes up on Reddit. The r/SaaS post collects a few thousand votes. In it, Thomas promises 100% feature parity with Adobe within a month.
- **6 October:** Hacker News. Thomas explains the motive: he'd been bitten by Adobe's "dark pattern cancellation fee" one too many times. He also revises the promise: 99%, in months rather than years. The context matters here. In March 2026 Adobe agreed to a $150 million settlement with the US Department of Justice, $75 million in civil penalties and $75 million in free services, over hidden early-termination fees and a hard-to-cancel subscription. The case had been filed in June 2024. Adobe denied wrongdoing.
- **7–9 October:** WordCraft, GridCraft and DeckCraft (Word, Excel, PowerPoint), CadCraft, SoundCraft and FigCraft (Figma) appear.
- **9–13 October:** the story goes mainstream. Yahoo Tech, Gizmodo, TweakTown, t3n and others write about it, with titles ranging from impressed to sceptical. Fabio Akita publishes a long analysis on 13 October whose short version is that Adobe is not dead.
As of today, 14 October, Adobe hasn't said anything publicly about the project, and there's no known lawsuit or cease-and-desist letter. So the "scandal" is a viral phenomenon, not a legal dispute. At least for now.
## What is actually in the repositories
Stars say little, so we looked at what's in Git. The numbers below come from our clones on 14 October.
| App | Replaces | Created | Lines of Rust | `#[test]` functions | Open issues |
|---|---|---|---:|---:|---:|
| PhotoCraft | Photoshop | 30 Sep | 540K | 8,065 | 992 |
| VectorCraft | Illustrator | 30 Sep | 446K | 6,576 | 214 |
| FilmCraft | Premiere Pro | 30 Sep | 401K | 3,402 | 500 |
| PdfCraft | Acrobat | 30 Sep | 380K | 3,759 | 510 |
| EffectCraft | After Effects | 1 Oct | 378K | 3,429 | 298 |
| LightCraft | Lightroom | 30 Sep | 248K | 3,372 | 352 |
| FigCraft | Figma | 9 Oct | 204K | 2,092 | |
| WordCraft | Word | 7 Oct | 199K | 2,030 | 413 |
| CadCraft | CAD | 7 Oct | 184K | 2,018 | |
| DesignCraft | InDesign | 1 Oct | 146K | 1,575 | 241 |
| DeckCraft | PowerPoint | 7 Oct | 142K | 892 | 185 |
| GridCraft | Excel | 7 Oct | 134K | 1,611 | 354 |
| SoundCraft | audio editor | 7 Oct | 97K | 1,063 | |
That's about **3.5 million lines of Rust in two weeks**, with about 40,000 test functions. Across the 13 repositories there are 15,840 commits, and 7,985 of them carry a `Co-Authored-By: Claude` trailer, mostly Opus 5.5. That's a floor rather than an exact figure, because squash merges from outside contributors don't always keep the trailer. PhotoCraft alone has around 1,990 merged pull requests and 620 open ones. It's not one person typing. It's one person, a handful of regular contributors and many parallel agent sessions, with Git as the coordination layer.
The code isn't a pile of screenshots either. PhotoCraft is split into 24 crates with layering enforced at build time: geometry and colour at the bottom, then the document model, then algorithms, compositors, file formats, the engine, and the user interface on top. The rules in `AGENTS.md` are stricter than in many human projects: no `unwrap` or `panic` outside tests, no `unsafe` except in one isolated crate for pen tablets, every crash fix comes with a regression test, and pixel code is tested at 8, 16 and 32 bits.
## We built them on a Mac
The test machine was a Mac Studio with an M3 Ultra and 96 GB of RAM, running Rust 1.99. We built each app's desktop binary and CLI in release mode, with no changes to the code.
All 13 compiled on the first try, with no changes. A release build takes between 30 seconds and 3.5 minutes per app on this machine. Then we gave each one a real task from the command line, using our own files where we had them:
| App | Build | What we tested | Result |
|---|---:|---|---|
| PhotoCraft | 3:00 | 360 public PSD test files, a 96 MP document | 359 open, save and reopen; 4.5 GB peak RAM (details below) |
| PdfCraft | 2:43 | its `check` command on 300 real PDFs from our own archive | 298 OK; the 2 failures were broken files (0 and 13 bytes) |
| WordCraft | 0:56 | 30 real .docx files to PDF | 30 of 30; 10 more ".docx" files turned out to be renamed PDFs and were correctly rejected |
| GridCraft | 0:29 | 19 real .xlsx files, recalculating every formula | 10,904 of 10,904 formulas match the values Excel saved; 4 files lose some package parts when re-saved |
| FilmCraft | 1:56 | export the demo project to H.264 | 26.8 s of 1080p in 17.7 s; plays in macOS |
| EffectCraft | 2:19 | render one 1080p frame of the demo | 70 ms |
| LightCraft | 0:52 | render a 12 MP JPEG | 0.8 s |
| VectorCraft | 3:27 | SVG to PNG and PDF | correct output |
| DesignCraft | 1:01 | sample layout to PDF and PNG | 4-page PDF, correct output |
| DeckCraft | 0:39 | .pptx to PDF, sample slide to PNG | correct output |
| FigCraft | 0:55 | SVG import and render | correct output |
| CadCraft | 0:44 | DXF to DWG and PNG | correct output |
| SoundCraft | 0:27 | bounce the demo session to WAV | 56 s, 24-bit / 48 kHz, −19.4 LUFS |
These are smoke tests, not a review of each app. They say the apps exist, start, read real files and write files that other software opens. They don't say how well they behave in a working day, which is the question the project's own parity document answers further down.
For PhotoCraft we went further.
**PSD files.** PhotoCraft ships a script that downloads public test corpora at fixed commits: the test files of psd-tools (a Python library) and ag-psd (a JavaScript one), PngSuite and a set of Affinity files. We opened every PSD in them with `photocraft-cli`, flattened it to PNG, saved it back to PSD and reopened the result. 308 of the 309 psd-tools files and all 51 ag-psd files (360 in total) open, save and reopen without an error. The one that fails is a group divider with an unusual blend mode. Opening without an error isn't the same as rendering exactly like Photoshop, and we didn't measure pixels against Photoshop. The README says "the render is kept for 307 of 309 files", which is consistent with what we saw.
**The interface.** The app opens with Metal, the GPU canvas works, and layer effects (bevel, glow, shadows, overlays, stroke) render on live text layers. The menus, panels, toolbar and keyboard shortcuts are clearly modelled on Photoshop. A detail that shows how far the imitation goes: Photoshop uses ⌘H and ⌘M for its own commands, which macOS normally reserves for Hide and Minimize, so PhotoCraft keeps Photoshop's meaning and moves Hide and Minimize to ⌃⌘H and ⌃⌘M. It says so in its log at startup.
**Memory.** We created a 12,000 × 8,000 pixel document (96 MP), added noise, a 20 px Gaussian blur and a Curves adjustment layer, and saved it as PSD, all from the CLI. It took 3 seconds and peaked at **4.5 GB of RAM**. At 4,000 × 3,000 it was 0.5 seconds and 866 MB. It works, but at roughly 47 bytes per pixel on a single layer, which matches open issues about memory on large files. For scale, the raw pixels of one 96 MP 8-bit RGBA layer are about 384 MB.
## The interesting part: every action is a command
If you only look at screenshots, you miss the architecture, which is the most reusable idea in the project. In PhotoCraft every menu item, tool and dialog runs a command from a single registry. Our build has **909 commands**. The UI calls them, and so do the CLI, a JSON control channel and an MCP server.
The MCP server is where it gets clever. It doesn't expose 909 tools. It exposes **25**: `command_list`, `command_run`, `command_batch`, `doc_open`, `doc_save`, `doc_render_preview`, `ui_screenshot` and a few more. The whole tool schema is about 25 KB of JSON. The agent asks for the command list when it needs it, and runs commands by ID. For comparison, Akita measured the tool catalogue of another popular MCP server, REA (for reverse engineering), at about 2.3 MB of JSON, which an agent pays for in tokens on every session.
The same idea shows up in the other apps: VectorCraft, LightCraft and the rest each have their own `mcp` subcommand. File access is closed by default: the headless MCP server can only read and write in the folders you give it with `--automation-read-root` and `--automation-write-root`. The control channel of the desktop app listens only on loopback and requires a token.
This is the part we'd copy into a client project, regardless of what happens to the clones. If an application has one command layer that the UI calls too, an AI agent can use everything the user can, with no separate "AI integration" that drifts away from the product. And you can test every feature without a UI.
## The parity numbers, read carefully
PhotoCraft has a document that's more honest than the headlines: `docs/target-app-parity.md`. It measures the app against Photoshop 2026 and is updated every few days. The version from 10–13 October says:
Two numbers matter. **Feature breadth is about 76%**: three quarters of Photoshop's menus, tools, panels and formats exist in some form. **"Ready for real work" is about 45%**: whether a professional could replace Photoshop with it today. The gap between them is where all the hard work in an editor lives: colour management, PSD files written by Photoshop that need to go back into Photoshop intact, performance on large files, stability on real machines, plugins.
The document is also honest about its own history. On 3 October it estimated 82% and 140–220 agent-hours to 95%. A week later it called that estimate "far too optimistic": about 1,230 issues had been filed since the first release, most of them against features already counted as done. The new estimate is 2,300–4,100 agent-hours to full parity. That's roughly 15 times the original estimate, after one week of real users.
That's the most useful lesson for anyone estimating AI-built software. An agent gets you to "the feature exists" very quickly. "The feature works on users' files" is a different curve, and you only find out how steep it is when the users arrive.
## Clean room or not?
Thomas calls the apps a clean-room reimplementation. In the classic sense, a clean room means two separate teams: one studies the original and writes a specification, the other writes code from the specification without ever having seen the original. Here there's one developer and a model trained on enormous amounts of public code and documentation, so the classic definition doesn't fit.
What the repository actually contains is more nuanced. The contribution rules forbid copying code, shaders, icons, ICC profiles or other assets from proprietary software, and require matching behaviour "by observation and public specs". The PSD format has a specification that Adobe itself published. On the other hand, the parity document says the target was measured by inspecting a Photoshop 2026 installation without launching it: the document types in `Info.plist`, the default keyboard shortcuts file, the plugins' read/write flags and strings in the main binary. That isn't source code, but it's more than "public specs", and Adobe's licence terms restrict reverse engineering beyond what the law allows.
On the questions that tend to matter in court, precedent leans towards the clones. In the US, *Lotus v. Borland* (1995) held that a program's menu command hierarchy is a method of operation, not protected expression, and *Google v. Oracle* (2021) treated reimplementing an API as fair use. In the EU, the CJEU ruled in *SAS Institute v. World Programming* (2012) that a program's functionality, its programming language and its file formats aren't protected by copyright. The real risk is elsewhere: the overall look and feel, icons that look too similar, and the trademarks. The apps don't use Adobe or Microsoft names or logos, which reduces that risk. This isn't legal advice, and the answer depends on the jurisdiction, but "Adobe sues and wins easily" is far from obvious.
## Security: what we'd do before using them
Three things worry us more than the copyright question.
1. **The pace of change.** PhotoCraft merged about 2,000 pull requests in two weeks, many from new contributors, with agents involved on both sides. Nobody reads that much code carefully. If you use the apps, pin a commit or a release, don't run `main`.
2. **Untrusted files.** An image or PDF editor parses complex formats from unknown sources. Rust removes a whole class of memory bugs, and the projects forbid `unsafe` almost everywhere, which helps. But logic bugs, decompression bombs and unbounded allocations remain. Our 96 MP test shows how quickly memory grows. Don't use them on a server that processes files uploaded by users.
3. **Agents with file access.** The MCP servers do the right thing by default (no file access without explicit folders, loopback-only control channel with a token). Keep it that way: give the agent a working folder, not your home directory.
The macOS releases are signed and notarized by Apple, which confirms who built them, not what's in them. We built from source, at a commit we recorded, and kept a private copy of the repositories in case they disappear.
## What it means
It doesn't mean Adobe is dead. Most of the value of Creative Cloud isn't in a binary you can copy: colour science, camera profiles, licensed palettes and fonts, generative cloud features, integration with print shops and agencies, and twenty years of PSD files that have to open exactly the same. Akita makes the same point at length.
But three things have changed and won't go back:
- **The cost of a credible first version has collapsed.** 3.5 million lines of structured, tested Rust in two weeks is a fact, not a demo. For internal tools and niche products, "we'd need a team for a year" is no longer automatically true.
- **The last 50% hasn't got cheaper at the same rate.** The project's own numbers show it: from 76% breadth to 45% readiness, and an estimate that grew 15 times after one week of users. That's where engineering, testing on real files and product decisions still live.
- **"Agent-ready" is becoming an architectural requirement.** A single command layer, used by the UI, the CLI and an MCP server with a small tool surface, is the pattern we'd recommend today for any new application that agents are expected to use.
If you'd like a second opinion on what AI can realistically build for your product, and on what will remain your team's job, [get in touch](/contact).