PhotoCraft is an open-source, pure-Rust reimplementation of Photoshop. Its second commit is titled “one-shot” and adds 42,000 lines. Ten days later it had ~378,000 lines of Rust, 1,089 commits, eight releases and 36,000 GitHub stars — with more than a thousand commits carrying an AI co-author trailer. It is the clearest public look yet at what agent-built software looks like at scale: real architecture, real tests, an unusually honest roadmap — and, by its own measurement, well under half of Photoshop. This leaf reads it as a case study, not a product pitch.
PhotoCraft (github.com/storytold/photocraft) is a native raster image editor whose stated goal is 1:1 Photoshop parity — same menus, shortcuts, behaviour and file fidelity — with every feature drivable by agents. It ships under the ArtCraft brand as one of a planned family of “Craft” apps, dual-licensed MIT or Apache-2.0, and runs on macOS, Windows, Linux, FreeBSD and the browser.
egui/eframe on wgpu (Metal, Vulkan, DX12). The web build is the same Rust compiled to WebAssembly — no Electron, no Tauri, no JavaScript UI.Measured from a clone of main at commit 0c72d95 on 10 October 2026, plus the GitHub API the same day.
| Measure | Value | What it tells you |
|---|---|---|
| Age | 10 days (repo created 30 Sep 2026) | Everything below happened in under two weeks. |
| Size | ~378k lines of Rust; 25 crates, 3 apps, ~1,370 tracked files | Comparable to a mature open-source editor that took humans years. |
| Seed | Commit 2, “one-shot”: +42,241 lines across 241 files. Commit 3: +37,990 | The skeleton was generated, not grown. |
| Commits | 1,089 total; 363 on 9 October alone | Throughput no human review process reads line-by-line. |
| Agent trailers | 1,000+ Co-authored-by trailers naming Claude models; Copilot and others too | A lower bound on agent involvement — says nothing about review depth. |
| Tests | ~5,200 #[test] functions | Tests were the gate, not an afterthought. |
| Releases | v0.1.0 (2 Oct) → v0.6.0 (10 Oct), eight tagged | Signed and notarised builds on a near-daily cadence. |
| Attention | 36.3k stars, 5.2k forks; 413 open issues, 144 open PRs | Launch-hype demand, and a triage load to match. |
Lines of code and commit counts measure output, not correctness. The project says so itself: most post-release fixes “passed our tests but have not yet been validated by users”, and its first public users found 214 broken shortcuts, an immovable crop frame and panels resizing themselves — all of which counted as “live” in the menu-parity report. Agents compress the time to a plausible feature; they don't compress the time it takes real users to find out whether it works.
AGENTS.md, not the editor.Hundreds of agent commits a day would normally produce mush. What keeps this codebase coherent is a set of rules the agents read first — and, more importantly, tooling that enforces them whether or not the agent remembered.
Crates sit in layers L0–L6 (geometry and pixels up to the UI shell). A crate may depend only on lower layers, and cargo xtask layers fails the build if one doesn't. Nothing below the UI may touch egui.
Production code may not unwrap, expect, panic! or index unchecked — clippy denies it on every crate. A panic_hunt test fuzzes every command with hostile parameters. unsafe is forbidden except in one isolated tablet-input crate.
PSD rendering is checked against Photoshop-authored files and public corpora (psd-tools, ag-psd, PngSuite). Each has a pass-count floor in the test suite: raise it, never lower it.
Every engine layer must compile for wasm32, and CI checks the browser build and its size budget on each pull request. The web build can't silently rot.
cargo xtask scorecard regenerates performance budgets, corpus floors, per-area checklists and a count of settings that do nothing. CI fails if the committed copy is stale. Agents are told to prefer it to estimates.
New behaviour must be an engine command with id, label, menu path, shortcut, params doc and tests. The UI stays thin, so agents can't hide logic in widgets that the CLI and MCP can't reach.
None of this is exotic — it's the agent-legible codebase and verify-or-it's-a-prompt discipline from this branch, applied hard. The pattern worth copying: every rule that matters is a failing check, not a sentence. Prose in AGENTS.md tells the agent what good looks like; the layering check, the lints, the corpus floors and the scorecard diff are what stop it shipping anything else.
The project's docs/roadmap.md carries an “Honest parity assessment” and its generated scorecard. These are their figures, not ours — which is exactly why they're worth quoting.
| Dimension | Their measurement | Read |
|---|---|---|
| Overall | Feature surface 60–70% of what a typical user touches; “a professional could switch for daily work” 25–35%; true parity “many months” away | Broad, shallow. |
| Menu wiring | 627 of 627 menu items dispatch a command | Says nothing about behaviour — they flag this themselves. |
| PSD rendering | Floors: 146/170 own corpus, 236/309 psd-tools, 133/256 Photoshop-authored oracles | Good on simple files, weaker on complex layouts. |
| PSD round trip | 307/309 psd-tools files re-save with the same render | The strongest number — within the corpus. |
| Smart filters | Re-rendering Photoshop's smart filters matches 5 of 30 | Filter maths still diverges. |
| Performance | 3 of 56 scenarios within budget (baseline 5 Oct); layer-with-styles drag p95 535 ms vs 25 ms target | Fast on big rasters; interactive layout work still laggy. |
| Settings | 48 of 146 preferences do nothing | UI ahead of implementation. |
| AI / generative | None — deferred by decision | The feature Photoshop users most notice is absent. |
Most projects with 36k stars in ten days would let the stars speak. This one publishes the number of settings that do nothing, the scenarios that blow their budget, and the admission that “our tests miss what users hit”. A self-measuring, self-critical roadmap is the second transferable lesson: when agents can generate features faster than anyone can check them, the scorecard is what stops the menu count from becoming the story.
Because every action is an engine command, the same registry is exposed four ways: menus, a headless CLI (photocraft-cli: convert, info, run, batch), a JSON control channel to a running app, and an MCP server.
# without a root, the server has no filesystem authority at all photocraft-cli mcp \ --automation-read-root /work/project \ --automation-write-root /work/project # tools: command_list, command_run, command_batch, doc_inspect, # render_preview, ui_inspect, ui_screenshot (bridge mode)
The design choices are sensible: read and write roots are separate and opt-in, unknown tool arguments are rejected before execution, a worker panic becomes a tool error rather than a dead session, and render_preview returns a bounded PNG so an agent can look at its own work. command_batch records one history step per command — it is not an atomic transaction, so a failed step mid-batch leaves earlier steps applied.
This is the genuinely new part. Scriptable image editing isn't new (ImageMagick, GIMP's Script-Fu, Photoshop's own ExtendScript and UXP), but a layered, PSD-aware editor with a first-class MCP surface means an agent can open a designer's layered file, change a type layer, swap a smart object and export variants — and show you a preview of each.
AGENTS.md points contributors at a shared standards repo, craftrules, that “is not public” — outside contributors must ask a maintainer for the rules that govern their own PRs. The code is open-source; the process isn't entirely..kys shortcut sets and adopts an installed Photoshop's live set on first launch. The clean-room rules are explicit (behaviour and public specs only, no copied code or assets), and US case law such as Lotus v. Borland (1st Cir. 1995) has treated menu hierarchies as uncopyrightable — but leaning on a competitor's name is the kind of thing that draws legal attention. Not legal advice; watch for changes in naming.| Use it when | Skip it when |
|---|---|
| You want an agent to drive layered image edits — batch variants, type swaps, exports — through MCP or a CLI, on your own machine. | Client deliverables depend on pixel-exact PSD fidelity with complex layouts, effects or smart filters. |
| You need a free, offline, cross-platform layered editor for light work, teaching or a browser-delivered tool. | The team lives on generative fill, Adobe libraries, actions (.atn) or third-party .8BF plug-ins. |
You're studying how to run an agent-built codebase — the AGENTS.md, the xtask gates, the scorecard. | You need stable behaviour across months: v0.x with near-daily releases will move under you. |
| You'd embed a Rust imaging engine (PSD, colour management, compositor) in your own product, under a permissive licence. | You need a vendor to call when it breaks. |
For SA studios, schools and small agencies paying dollar-priced creative subscriptions, a permissive, offline editor that runs in a browser tab is worth tracking — but at today's PSD fidelity it complements Photoshop rather than replacing it, especially where files go back and forth with agencies abroad. The nearer-term fit is automation: retailers and e-commerce teams generating catalogue and promo variants from a layered template, run locally with no image data leaving the building (useful when POPIA questions come up about third-party processing). The bigger takeaway isn't the editor at all. It's proof that a small team with agents and hard, automated gates can stand up a serious codebase fast — and that the scorecard, not the commit count, is what tells you whether it's any good.
unsafe, one codebase for native and WASM.Every figure in this leaf comes from the project's own repository and the GitHub API. Last reviewed 2026-10-10.
Provenance: line, commit, trailer and test counts were measured by us from a clone of main at 0c72d95 on 10 October 2026; stars, forks, issues and releases from the GitHub API the same day. Parity, corpus and performance figures are the project's own published measurements, quoted as such — we did not build or benchmark it. Co-author trailers are a lower bound on agent involvement and don't indicate how much human review each change received.