Version One Is Cheap Now. What ArtCraft's AI-Built Clones Teach Software Engineers

On September 30, 2026, a GitHub organization called storytold created a repository named PhotoCraft, an open-source reimplementation of Photoshop in Rust. FilmCraft (Premiere Pro) and PdfCraft (Acrobat) were created the same day. A week later came WordCraft and GridCraft, the Word and Excel equivalents. By mid-October, the organization listed more than a dozen "Craft" apps, including clones of Lightroom, Illustrator, After Effects, InDesign, PowerPoint, AutoCAD and Pro Tools.

They are not mockups. On October 15, PhotoCraft's main branch held about 560,000 lines of Rust across 2,372 commits. Its README describes PSD files that open, edit and save, with layers, masks, adjustment layers, CMYK and Lab color, and 16- and 32-bit documents. Most of the code was written by Claude Opus 5.5 agents running in parallel.

The project is led by Brandon Thomas, founder of Storyteller.ai and FakeYou. When it reached Hacker News before he was ready, he wrote: "These are still super early alpha." In the same comment: "Everything can be open source multiplatform Rust now."

I read through the repositories for three questions: how this was built, how far along it really is, and what it means for people who build software for a living. The short version: version one of software is becoming cheap. The last 20%, the part businesses actually pay for, is not.

How the Craft apps are built

The most interesting files in these repositories are not the Rust sources. They are the instructions written for agents.

PhotoCraft's AGENTS.md opens with "guide for AI agents and contributors" and sets out a small number of hard rules. Four of them explain most of what the project could achieve in two weeks.

Everything is a command. Every user-visible behavior is a command in the engine with an id, label, menu path, shortcut and tests. In the file's words: "The UI, CLI, control channel and MCP all dispatch commands by id." This one decision makes the work easy to parallelize. An agent can add a menu item by adding a command module, without touching a shared UI file. It also means the finished app can be driven by other agents through MCP, which matters later in this post.

Clean-room rules. "We studied Photoshop and other proprietary editors for behaviour and look only. Never copy their code, shaders, profiles or assets." WordCraft's AGENTS.md goes further: Word may be "observed" black-box on the dev machine, but agents must never read, disassemble or copy anything inside it, and must never copy GPL code from LibreOffice or AbiWord. Whether instructions like these make an AI-produced reimplementation legally clean is still unsettled. Simon Willison's analysis of the chardet rewrite covers the open questions well.

Tests against external oracles. "Tests are the gate. Every change comes with tests." PhotoCraft checks its output against Photoshop-authored reference files kept in a separate corpus repository, plus the public psd-tools and ag-psd test sets. FilmCraft's CLAUDE.md runs ffmpeg "only as external test oracles / fixture generators — never linked or shipped." Agents can produce code quickly, but someone has to decide what "correct" means. Here, that decision lives in the oracles.

Mechanical rules for parallel agents. Each agent uses its own Cargo target directory and edits only files it owns. If another agent's half-finished edit breaks the build, the rule is "wait and retry; don't fix their files." Manifests are written atomically because "one broken manifest breaks everyone's build." Because "sessions can end abruptly (crashes, context limits)," each agent appends to a dev log, so the next agent can pick up where it stopped.

PhotoCraft's own parity document records a single session that "landed ~70 menu items + major subsystems in a handful of wall-clock hours using 8 parallel agents." Its ROADMAP.md expresses every estimate in "Opus 5.5 agent wall-clock hours," calibrated from the repository's 1,004 merged PRs. The repository's generated credits file attributes 736 of 1,302 commits (as of October 10) to Claude Opus 5.5, and 248 to Brandon Thomas's own account. A commit can credit both a human and a model, so the two counts overlap.

The speed is real, and it puts pressure on everything around the code. PdfCraft's CLAUDE.md notes that main took "396 commits in the three days to 2026-10-12, and most open PRs are conflicting at any given time."

My main takeaway from this section: the harness built this software as much as the model did. A command registry, oracles, layering enforced at build time, and rules for how agents share a repository are what make eight agents productive instead of chaotic. I made the same argument at a smaller scale in The Bottleneck Moved to Review. ArtCraft shows it at the scale of a whole application suite.

How far along they really are

The project is unusually candid about this, and its documents distinguish between two kinds of progress.

Breadth is how many of the original app's menus, tools and functions exist. Agents are very good at breadth. PhotoCraft has wired all 628 Photoshop menu items it tracks. GridCraft's README reports 513 of Excel's 523 worksheet functions.

Readiness is whether someone can do their real work in it. The project estimates readiness separately and much lower:

PhotoCraft's README states the gap directly: "it is not yet a Photoshop replacement for daily professional work… Every Photoshop menu item is wired to a command… but that measures wiring, not behaviour."

The oracle numbers show the same gap. Against Photoshop-authored reference files, PhotoCraft's renders matched in 188 of 258 cases (73%), and smart-filter re-renders matched in 5 of 30 (gaps.md). The roadmap lists why the app is still alpha: "953 issues are open (2026-10-13), 22 of 25 performance budgets are missed, and PSDs we write are not yet reliably accepted by Photoshop."

The project's estimates are not always consistent with each other. PhotoCraft's parity document still contains an older estimate of 140–220 agent-hours to reach 95% functionality. The current roadmap estimates 1,100–1,800 hours to beta and 2,300–4,100 hours to full parity. I read that as honest recalibration, not deception. The first estimate counted features. The later one was calibrated on a thousand merged PRs.

Public reaction split along the same line. On Hacker News, one user reported that PdfCraft "works well enough for me that I cancelled my subscription." Another reported "editing a PSD with a smart object and the result was completely broken." On Privacy Guides, the concern was the review process: "~440k lines written in 11 days, mostly AI-co-authored, with no independent audit."

Thomas expects that 99% parity "will take a while, but I'm sure it'll be measured in months and not years," and adds: "It's measurable." I agree with the last part, and I think the project's own documents are the best way to measure it. Even if they reach full parity much later than he expects, building something this large in two weeks changes what anyone can assume about the cost of software.

What commercial users still depend on

If version one now costs weeks, why would any business keep paying Adobe or Microsoft? The Craft apps' gap lists answer that better than any analyst could, because they describe what is still missing in the project's own words.

Compatibility with the files people actually receive

WordCraft's top-ranked gap (gaps.md) is "DOCX never tested on real-world files." Its stated impact: "Everyone: the files people receive are the files that break." The same list notes that "Aptos has no metric-matched substitute," so page counts and line breaks differ from Word. That matters for forms, legal documents and academic work. GridCraft's gap list says its XLSX output is "not proven in Excel or on real files."

This failure mode is old. Munich's LiMux project ran Linux and open-source office software across the city administration for over a decade. The EU's Open Source Observatory records that the city moved away from it "definitively in 2017, following issues with interoperability and replacement as well as weak political backing." Politics played a role, but compatibility complaints came up again and again.

The best counterexample I found makes the same point. Schleswig-Holstein, a German state, decided in 2024 to move its administration to LibreOffice. In its December 2025 update, the state reported LibreOffice on nearly 80% of workplaces outside the tax administration, saving more than €15 million in license costs. The remaining 20% still depend on Microsoft Office "where specialized procedures create technical dependencies" (my translation of "Fachverfahren technische Abhängigkeiten bedingten").

That 20% is the business. The general-purpose clone works. What remains is the integration with one organization's own systems and processes.

Reliability, data safety and security

Alpha software loses data, and that is not a criticism of alpha software. GridCraft has an open issue titled "CRITICAL: Opening a second workbook silently discards the first — unsaved work lost." Its local control server, the feature that makes it drivable by agents, has an open issue saying it "has no auth." PhotoCraft has an open issue to "add dependency vulnerability and SAST gates to CI."

None of this is unusual for a two-week-old project. AI-generated code just reaches this stage faster, and in much larger amounts, than any team can review. Veracode's 2025 GenAI code security report, which is vendor research, found that "45% of code samples failed security tests and introduced OWASP Top 10 security vulnerabilities." Producing code is no longer the slow part. Trusting it still is.

Ecosystems and liability

Professionals depend on more than the application. WordCraft has "no VBA execution (macros preserved only), no Office add-ins, no cloud storage, no real-time co-authoring." PhotoCraft cannot host Photoshop's .8BF plug-ins or UXP panels. FilmCraft cannot open .prproj files yet. Each of these is someone's daily workflow.

Enterprises also pay for someone to blame. When Adobe brought Firefly to enterprises in 2023, its pitch included the option to "obtain an IP indemnity from Adobe for content generated by certain Firefly-powered workflows." Microsoft's Copilot Copyright Commitment promised: "we will defend the customer and pay the amount of any adverse judgments or settlements." Neither of those is a feature. They transfer risk, and a Rust clone cannot offer that.

Version one is cheap. Fit is not.

I don't think the lesson is that Adobe is safe. Investors clearly worry about the opposite. In February, Fortune reported that a set of industry-specific plug-ins for Claude Cowork, which Anthropic "had billed as a relatively minor product update, triggered investor anxiety" and a sell-off in software stocks. Thomas framed his own project as part of a larger shift: "It's not just SaaSocalypse."

My reading is narrower and, I think, more useful for engineers. Implementing a known product is becoming a commodity. What stays expensive is making software fit a specific business and keep working there. That includes:

• the integration with the 20% of workflows that depend on one organization's own systems
• the migration of years of existing files and data without silent loss
• the domain rules that exist only in the heads of the people doing the work
• the compliance evidence, support and accountability when something breaks

Ink & Switch's essay on malleable software describes the opportunity: communities are "not well-served by one-size-fits-all applications they have no control over." The authors also add a caveat that I think gets missed in the excitement: "AI code generation alone does not address all the barriers to malleability." Generating code was never the only obstacle. Deciding what to build, connecting it to everything else, and maintaining it were always the larger costs.

The Craft apps point toward one version of this future. An open, command-driven Photoshop or Excel that any company can fork is a better foundation for customization than a closed product. A design studio could add its own export pipeline, a law firm its own document checks, an accounting team its own spreadsheet functions. The value then sits in the customization and in the confidence that it works on that customer's real files. A generic feature count does not capture it.

What software engineers should do now

If agents can implement most of a known specification, then the engineer's job shifts toward the parts agents cannot do alone. I see three.

Find the real requirements. The Schleswig-Holstein 20% was not in any feature list. Someone had to find it by talking to the people who do the work. a16z's piece on forward deployed engineers describes the same pattern from the startup side: "forward deployed teams — technical or not — are closest to the customer," and even OpenAI and Anthropic "have been hiring forward deployed engineers and solutions engineers." I think most engineers, not only those with that title, will need part of that skill: understanding the business well enough to tell a customer what they actually need, not only what they asked for.

Own the definition of correct. In ArtCraft, the oracles and the corpus define "correct." The agents do the rest. That is now the highest-leverage engineering work in an AI-assisted project: choosing the reference files, writing acceptance tests from real workflows, and deciding which metric is honest. "Menu items wired" was easy to raise. "Photoshop can reopen our files" is the number that matters. Google's 2025 DORA report says it plainly: "AI doesn't fix a team; it amplifies what's already there," and without "strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability."

Control the loop and its risks. Someone has to decide how many agents run, what each one owns, what they may touch, how they are reviewed and when a human signs off. Developers are right to stay skeptical while doing it. In the 2025 Stack Overflow Developer Survey, "more developers actively distrust the accuracy of AI tools (46%) than trust it (33%)," and the most common frustration was "AI solutions that are almost right, but not quite." Productivity evidence is also moving. METR's 2025 study found experienced open-source developers 19% slower with AI. Its February 2026 update now suggests a speedup, while calling its own new evidence weak. Neither result removes the need to measure your own loop.

This is not a smaller job than writing code. It is harder, because most of it happens before and after the code exists. I wrote in AI Can Write the Code. But Code Was Writing Us. about what we risk losing when we stop working through implementation ourselves. That concern still holds. The way through it, I think, is to stay close to the system's real behavior: its files, its users and its failures.

Next, agents will use the software too

There is one more reason the "everything is a command" design matters. The users of software are starting to include agents.

Computer-use agents are not new. Anthropic released computer use in public beta in October 2024 and called it "still experimental—at times cumbersome and error-prone." OpenAI's Operator and ChatGPT agent followed in 2025, and Claude for Chrome launched as a pilot that August.

What changed between August and September 2026 is that three large companies shipped always-on, consumer-friendly versions within seven weeks:

• Grok Bot (xAI, early beta August 11): AI "teammates" that work from "a persistent cloud computer" with a browser, command line and files, according to xAI's documentation.
• Muse (Meta, September 8; Mac app September 18): on a Mac it can "interact with your files, messages, calendar, notes, and mail, all within their native applications," and it will "always ask for your approval before it performs sensitive actions" (TechCrunch).
• Dots (OpenAI, September 29): always-on agents that each have "their own cloud computer," which users can watch while a task runs, available to ChatGPT Pro and Business Premium users (9to5Google).

These are the first computer-use agents that ordinary users are likely to keep running in the background, not just try once. They also come with honest warnings. xAI's security documentation says its defenses "reduce, but do not eliminate, risk from malicious content," that its automatic action review "does not review every side effect," and that "teams without a policy default to allow-all" network access. When Anthropic launched Claude for Chrome, it reported a 23.6% prompt-injection attack success rate under targeted attack, reduced to 11.2% with its mitigations. Lower, but far from zero.

For engineers, I see two practical consequences.

Build for agents as users. An app that exposes its actions as typed commands through a CLI or MCP is easier for an agent to drive reliably than one it has to operate by clicking pixels. ArtCraft did this from the first commit. I described the web version of the same idea in I gave my website tools for AI agents with WebMCP.

Get familiar with these agents now, in low-stakes settings. Use them on tasks where a mistake costs little. Give them their own accounts and sandboxes rather than your real credentials, and watch where they fail. Teams that already understand how these agents behave will be ready when customers start asking for workflows that agents run.

What I am taking from this

ArtCraft did something that would have sounded impossible two years ago, and it published its gaps honestly enough that we can learn from both. The progress is real, and so are the gaps.

If you want to act on this in the next week, I would start small:

• Pick one workflow you own and write down how you would know an agent-built version is correct: which reference files, which acceptance tests, which metric.
• Expose your tool or service through a CLI or MCP interface with typed commands, before an agent has to click through it.
• Try one computer-use agent on a low-stakes task in a sandboxed account, and note every place it needed you.