Compositor: AI makes clean-room development cheaper

Compositor is not Photoshop, but the signal is serious

I would not describe Compositor as a proven Photoshop clone: the available materials do not demonstrate that level of completeness or compatibility. Robbie Tilton’s Compositor project page sparked discussion about rapidly building a clean-room graphics editor with AI. As of September 2026, the key takeaway is not that “Photoshop is finished in days,” but that moving from a specification to working code has become dramatically cheaper.

The strongest quantitative evidence for that claim does not come from Compositor, but from the MirrorCode report. In that case, a frontier model reimplemented a Go toolchain of roughly 16,000 lines in 14 hours for $251; Epoch AI estimated comparable human work at two to 17 weeks. Those figures are striking, but a constrained toolchain and a mature graphics suite belong to very different weight classes.

A Photoshop-class system requires more than recreating features. It means rebuilding architecture, interface behavior, asset handling, performance, and countless undocumented edge cases. That is why ProjDevBench and Vibe Code Bench evaluate delivery of whole projects rather than isolated task fixes. Even so, they do not establish that an autonomous system can assemble a complete replacement for a mature product.

Clean-room is not a magic phrase either. Developers must work from an independent specification rather than original code and preserve a demonstrable separation. If a model has seen a protected implementation, or if the prompt effectively asks it to replicate distinctive decisions, the legally clean room quickly becomes a room with fingerprints.

Value shifts from writing code to knowing the product

Engineering is not disappearing, but its cheaper layers are being compressed. AI accelerates project scaffolding, boilerplate, tests, refactoring, and iterative fixes. What becomes expensive is an exact behavioral specification, compatibility validation, performance tuning, and deciding which similarities are technically necessary and which create legal risk.

For open source, this is a real shift: a small team can test a niche alternative faster and reach a working prototype sooner. For owners of mature software, defensibility moves away from the sheer volume of written code toward product quality, ecosystems, and accumulated behavioral detail. Yet a prototype is still not the same as a dependable tool for daily work.

Code is becoming the inexpensive part of a copy. Two things remain costly: an exact specification of behavior and a provable boundary between compatibility and appropriation.

Obsidian’s latest updates show how extensible software can quickly add advanced features through CLIs, plugins, and local workflows. That same momentum helps explain why open-source projects are increasingly challenging established creative tools.