Why Vibe Coding Ships Notion Clones But Not Photoshop

Scroll X on any given day and you’ll find another “I built a Notion clone with Cursor in an afternoon” brag. Codex, Cursor, Antigravity — the barrier to entry is collapsing in real time. But here’s the strange thing nobody’s talking about: the vibe-coded Photoshop doesn’t exist. Neither does the vibe-coded Premiere, or Logic, or Blender. CRUD apps multiply like rabbits. Creative software is conspicuously absent. Why?

The pattern in what AI actually ships

Look at the success stories. Notion clones. Trello clones. SaaS dashboards. Landing pages. Chat apps. They all share one thing: they live on top of well-trodden abstractions.

React component trees, REST endpoints, database CRUD. Three primitives that cover roughly 80% of what gets called “a web app” on Hacker News. Models have ingested hundreds of thousands of near-identical repos, so “build me a todo app” produces something plausible on the first try.

When ForrestKnight’s “Everything You Need to Know About Coding with AI” cleared 160K views last October, the comments weren’t full of people who shipped novel software. They were full of people who shipped faster versions of software that already existed a thousand times over. That’s productivity within a standardized abstraction layer — not conquest of new territory.

What’s actually inside Photoshop

Now picture Photoshop’s guts. Pixel-level image processing. GPU shader pipelines. Color space conversion. Layer blending math that took decades to get right. A brush engine with pressure curves and interpolation. A caching system that makes real-time preview feel instant on a 2GB canvas. And file format compatibility stretching back to the Clinton administration.

This isn’t a “lots of functions” problem. It’s a tightly coupled, performance-constrained, domain-saturated problem. A Gaussian blur isn’t a Gaussian blur — naive convolution is too slow, so you decompose into separable kernels, tile the image for multithreading, and rethink the whole thing when you move to the GPU because memory transfer dominates the cost.

Ask an AI to “build something like Photoshop” and the first wall isn’t code. It’s architecture. Electron or native? Skia or roll your own renderer? Each answer is a multi-year trade-off entangled with product vision, team skill, and target hardware. There’s no Stack Overflow accepted answer.

Code generation is not domain knowledge

This is the part worth sitting with. AI coding tools are extraordinarily good at reassembling patterns somebody else already solved. Creative software does not yield to pattern reassembly.

Adobe’s edge-refinement algorithm for selections — the thing that makes “Select Subject” feel magical — is the residue of thirty years of user feedback, hundreds of thousands of test images, and intuition baked into the code by engineers who’ve stared at hair selections since Photoshop 4. None of that lives on GitHub. It’s tacit knowledge, and tacit knowledge doesn’t get crawled.

Zen van Riel’s “Unbeatable Local AI Coding Workflow” has 200K+ views, and what it ships is — again — CRUD and automation scripts. The ceiling of vibe coding is right there in the demos. The demos themselves are the evidence.

So is creative software permanently out of reach?

Not exactly. The approach just inverts. What Adobe, Figma, and Runway are actually doing isn’t building creative software from scratch with AI — it’s embedding AI features inside creative software that already exists. Generative fill. Auto-masking. Style transfer. Each one is a single component plugged into a rigid skeleton that took decades to build. The skeleton is the moat.

For a genuinely new creative tool to emerge from vibe coding, models would need to reason about GPU shader performance characteristics, design memory layouts deliberately, and — the hardest part — develop a sense of how a feature actually feels under a user’s hand. That last one is the gap nobody’s closing this year.

The real question to ask

Don’t get too excited about vibe coding demos. Don’t get too dismissive either. The stuff that works really works. The stuff that doesn’t will keep not working for a while. The skill worth developing is the eye to tell them apart: is what I’m building pattern reassembly, or is it domain knowledge tangled with performance constraints?

If you’re building the second kind, the AI tool isn’t a wizard that builds the whole thing for you. It’s an assistant that builds parts quickly on top of a skeleton you designed. So the question loops back to you. Which kind are you actually building?