A Photoshop Clone at 45% Parity Is a Better Map of an Editor Than Any Launch Post

Early October, a developer named Brandon Thomas published seven applications under the project name ArtCraft, each one aimed at a program Adobe sells: Photoshop, Lightroom, Premiere Pro. The count is thirteen now. They are written in Rust, and most of the code came from Claude Opus 5.5, according to the German report that sent me down this path. The Photoshop rebuild alone, PhotoCraft, collected tens of thousands of GitHub stars within days.

Thomas gave the whole thing a line on Reddit: "Software is over."

The interesting number is not the star count. It is 45.

That came from the project's own parity document in mid-October: PhotoCraft is roughly 45% fit for real work, and full equivalence would take another 2,300 to 4,100 hours of agent time. The repository already held around 2,400 commits by that point. The README says outright that this is not yet a replacement for Photoshop in professional use, and that binding every menu item to a command measures the wiring, not the behavior.

It is easy to read that as a self-own. I read it as the most useful public measurement of an image editor anyone has published, because it accidentally shows which 55% is expensive.

A clone has an answer key

Golo Roden, who wrote the heise commentary, makes the sharpest point in the whole discussion: agents are strongest where their output can be checked mechanically, by tests or by a compiler. PhotoCraft is written in exactly the language and test setup that rewards that, with more than 1,700 tests, some of which compare its render of a file directly against what Photoshop produces from the same file.

And then he adds the part people skip. This project is the ideal case for an agent because the target already exists in exact form. Photoshop has shipped since 1990. Its behavior is observable in any situation, its file format is publicly specified, and for any question about how a file should look after a given operation, the original supplies the correct answer.

When you work under those conditions you never have to decide what is right. You only have to determine whether the output matches, and that check can be automated almost completely. Which is why the result looks so spectacular, and why it says almost nothing about making software that has no original to compare against.

The same logic runs through AI image tools, and it is worth being blunt about. Adding a slider labeled "inpainting" is now a week of work, because the answer key exists: a masked region, a plausible fill. Nobody has to decide whether local edits should preserve grain, whether the fill should inherit the surrounding noise profile, or what happens to a selection that crosses a sharp edge. Those are decisions, and decisions do not come with tests until someone writes them.

Wiring is not behavior

The 45% figure names its own gaps, and they are the boring ones. Typography depth and professional workflow are listed as the largest holes in the README, and the project's own gap list says results still deviate from Photoshop's output on about a quarter of the reference files Adobe's original produced.

Anyone who has handed a file to a print shop knows why that quarter matters more than the other seventy-five percent. Roden mentions ten years of working with printers on books, brochures and shirts, and how much goes wrong with color and type in that handoff. Adobe's applications carry a pile of options for exchanging files with a print house that most other graphics programs have never heard of.

PhotoCraft claims CMYK documents and ICC color management, soft proof included, which is a preview of how the image will look once printed. Whether that holds up when a real printer opens the file is a different question, and the project does not claim it does.

So here is the split the parity number reveals. The visible surface of an editor, every tool, menu and panel, is now cheap to reproduce. The invisible surface, which is the accumulated set of decisions about what a file must survive between the person who made it and the person who prints, ships or approves it, is not cheap at all. That surface has no answer key, because it was assembled from decades of arguments with clients.

What this means if you generate images

The practical lesson for anyone using AI image tools is not "open source is catching up" or "Adobe is doomed." It is that feature counts have stopped carrying information.

A tool can list every capability its competitor has and still fail on the first file that has to leave your machine. Gradient banding in a smooth sky after a profile conversion. Shadow detail crushed to black in a proof. Type that looked fine at 1600 pixels and falls apart at 300 dpi. A layered file that round-trips once and comes back with masks merged. None of these show up in a feature comparison. All of them show up in a client email.

So the test worth running on any tool that claims to replace what you already use is not a checklist of buttons. It is one file that you actually delivered, pushed through the new tool end to end, then compared against the version you sent. If the tool cannot reproduce the outcome, the menu does not matter.

A workable version, in order:

• Take a real deliverable with a person's name on it, not a test image.
• Convert it to the print profile you actually use, then check a smooth gradient and a deep shadow for banding and blocking.
• Soft proof against the printer's ICC profile and compare it to the proof you approved.
• Round-trip a layered file and confirm masks, adjustment layers and blend modes survived.
• Export at delivery size and rasterize type, then read the small copy at 100%.
• Send the result through whatever spec the print house gave you, and see what they say.

That sequence costs an afternoon and settles more than any announcement. It also explains why the project's honest self-assessment is 45% and not 90%: the remaining work is not more code, it is more contact with the people who use the files.

The same shift happens on the buying side. Once a polished image or a smooth clip stops being rare, what people pay for moves away from production and toward judgment, delivery and the ability to guarantee an outcome, which is the pattern we looked at in what clients pay for after video commoditizes. A feature list cannot promise an outcome. A tested handoff can.

The grievance underneath is real

It would be cheap to write this off as hype, and wrong. Thomas has said he built the thing because he kept hitting Adobe's cancellation fee. That irritation is legitimate, and a subscription model that punishes people for leaving is exactly the kind of thing a clone should exist to pressure.

But "software is over" draws a giant conclusion from the one case where the hardest part of the job was already finished by someone else. That is the pattern I keep seeing in these announcements. The demo is a copy of something with a known answer, and the conclusion is drawn as if inventing were the same activity.

Copying got cheap. Deciding what the copy has to survive did not. When the next tool claims parity with the editor you use, the useful question is not how many features it has. It is which decisions it inherited, and which ones it made for itself. If it only inherited them, your files will find the same wall the clone found at 45%, and they will find it in front of a printer.