Why Nobody Has Vibecoded a Real Photoshop Yet: The Founder Lesson About Productized Depth vs LLM Thinness
Four years into the GPT era, two years into Claude Code, eighteen months into Cursor as a daily driver for serious development work – and nobody has shipped a real Photoshop competitor built primarily with LLM assistance. No real Figma replacement. No Excel that could replace the one finance teams actually live in. The observation is not new. A recent thread on Hacker News surfaced it again, 226 upvotes and 300 comments of developers either nodding along or arguing at the margins. But the argument itself has not changed because the underlying structural fact has not changed.
The question worth asking is not “when will someone vibe-code a Photoshop.” The question is why the gap between demo-grade and daily-driver grade keeps staying wide, and what that tells founders about where AI-assisted development is actually leverage versus where it is a trap.
What “Real Photoshop” Actually Means
When I say “real Photoshop” I do not mean a photo editor that demos well in a 60-second screen recording. I mean the software that a retoucher uses for six hours straight on a commercial shoot deadline, or that a prepress operator uses to prepare files for a print run with specific ink limits, or that a game studio uses to batch-process 4,000 texture exports through a scripted action set.
The depth list that makes Photoshop actually Photoshop is long and mostly invisible:
- File format compatibility: PSD, PSB, TIFF with layers, DNG, RAW from hundreds of camera bodies, PDF with bleed marks, EPS, HDR formats. Each with version-specific quirks going back twenty years. A missing ICC profile embed in a print export costs someone a commercial print run.
- Color science: ICC profile management, CMYK separations, Lab color, soft-proofing for specific output devices, spot channel handling. This is not a feature. It is a discipline with decades of standardization work behind it.
- Undo architecture: A non-linear undo tree with history states that persist across save cycles, history brushes that let you paint back to arbitrary prior states, snapshots. The data model behind this is not trivial.
- Plugin ecosystem: NIK Collection, Topaz, Nik Silver Efex, hundreds of third-party actions and filters that creative professionals have integrated into production workflows over years. A new app that cannot run these is not a replacement – it is a fork that requires retraining.
- Performance under real load: A 500MB layered PSD with 200 layers, smart objects, linked assets, adjustment layers, and masks. Scroll performance, brush responsiveness at 100% zoom, real-time compositing. This requires serious GPU pipeline work.
- Accessibility: Screen reader support, keyboard navigation for users who cannot use a mouse. Not optional in many enterprise contexts.
- Locale handling: Right-to-left text composition, Arabic and Hebrew font shaping, CJK character support for type layers. A global creative tool has to handle all of this.
- Scriptability: ExtendScript, JavaScript, Actions. Entire studio pipelines are automated through Photoshop scripting. A replacement with no scripting API is a dead-end for any team that automates anything.
- File recovery: Auto-save, recovery from crash states, the ability to recover unsaved work. The moment a professional loses three hours of work because the app crashed and had no recovery, they move back to Photoshop.
- Accumulated edge cases: Thirty years of reported bugs and strange behaviors that users have developed workarounds for. Some of these workarounds have become workflows. The “bugs” are now features in the minds of long-time users.
LLMs can scaffold a Photoshop-like interface in an afternoon. Layers panel, toolbox, canvas, crop tool, basic filters. It will look right in the demo. It will fall apart the moment someone with real production requirements sits down with it.
What LLMs Actually Ship Well
This is not a piece about LLM limitations as a counsel of despair. The flip side of the Photoshop observation is that there are large categories of software where AI-assisted development is genuine, sustained leverage – not just demo leverage.
Internal tools are the clearest example. An internal dashboard that your operations team uses for thirty minutes a day to review reports, approve requests, or manage a queue – the depth requirements are low, the user base is small and trained, and the tolerance for rough edges is high. An LLM-assisted team can build and iterate on this kind of tool faster than any other approach. The productivity gain is real and compounding.
Narrow-scope SaaS fits the same pattern. A tool that does one specific thing for a specific audience – invoice generation for a specific vertical, a compliance checklist tool for a specific regulatory framework, a booking flow for a specific service type. The surface area is constrained. The edge cases are few and discoverable. The integration requirements are known upfront. These are ideal candidates for AI-assisted development because the gap between MVP and production-ready is manageable.
Prototypes and founder validation tooling also fit. The jobs of a prototype are to test assumptions, get user feedback, and de-risk investment decisions before you commit serious engineering time. None of those jobs require production-grade depth. An LLM-built prototype that works for 20 test users for two weeks has done its job perfectly even if it would fall apart at 10,000 users.
Thin wrappers on existing platforms are another strong category. A plugin for an established platform (WordPress, Shopify, HubSpot) that extends existing functionality in a bounded way. The platform handles the hard parts – authentication, data model, extension APIs, upgrade compatibility. The plugin sits on top. The gap between LLM-drafted and production-ready is smaller here because the hard architectural decisions have already been made by someone else. This is a significant part of what we build at Wbcom Designs, and it is where I have seen the most consistent productivity gains from AI-assisted development.
The Dwell-Time Axis
The most useful frame I have found for thinking about this is dwell time: how many hours per day does a real user spend inside this product?
A professional uses Photoshop for six to eight hours on a heavy day. A developer lives inside their IDE for eight hours. A finance analyst lives inside their spreadsheet for the same. An accountant uses their accounting software for most of their working week. These products accumulate an extraordinary number of interactions per user. Each interaction that produces a surprising or wrong result is friction. Over thousands of interactions per month, those friction points compound into either trust or abandonment.
High dwell-time products therefore need to be right in a much higher fraction of cases. The tolerance for edge case failures is much lower. The expectation of consistency is much higher. The muscle memory a user builds over years of daily use is a real asset – and a real switching cost. A new tool that handles 95% of cases correctly but fails on the other 5% in unpredictable ways will not replace an existing tool that handles 99.5% of cases correctly, even if the new tool has a better default interface.
Low dwell-time products – tools you touch for five or ten minutes when you need a specific thing done – have a much more forgiving tolerance profile. The cost of a 5% failure rate is much lower when a session is ten minutes long. The user has not built months of muscle memory. The switching cost is near zero.
The depth requirement of a product scales almost linearly with its dwell time. Vibecoding a low-dwell-time tool is a genuine productivity win. Vibecoding a high-dwell-time tool is building a prototype you will later have to throw away or rebuild at great cost.
Where Vibecoding Is Genuine Leverage
To be concrete about this, here are the categories where AI-assisted development has delivered durable, compounding leverage in my experience building and maintaining over 60 WordPress plugins and running a development agency:
Prototypes and MVPs: Build fast, test assumptions, throw away or keep based on validation. The goal is learning, not durability. LLMs are excellent at this.
Internal tooling: Dashboards, admin utilities, internal workflows that your team uses. Low user count, high tolerance for rough edges, fast feedback loops with the actual users. This is where I have seen the highest ROI from AI-assisted dev work on non-product code.
Narrow SaaS with bounded scope: One problem, one audience, constrained integrations. The depth requirement is proportional to the complexity you take on. If you keep the scope genuinely narrow, you keep the depth requirement manageable.
Platform extensions: Plugins, apps, extensions that sit on top of established platforms. The platform handles the hard architectural problems. You build on a known foundation. The gap between LLM-drafted and production-ready is narrower here than anywhere else. The broader context on when agentic coding becomes a trap is worth reading before you commit to this approach for anything at scale.
Founder validation tooling: Tools you build specifically to answer a question before you invest real development time. The job is to produce signal, not to survive production load. LLMs are perfect for this.
Where It Is a Trap
The trap category has a consistent shape. If you can answer yes to more than one of the following: “Do users spend hours in this daily?”, “Does it read or write a file format with a long compatibility history?”, “Do multiple users edit shared state simultaneously?”, “Does the value proposition depend on handling edge cases correctly?” – you are likely building something where LLM-assisted development will give you a fast start and a painful reckoning.
Productivity software that replaces existing tools professionals rely on: IDEs, spreadsheets, design tools, document editors. The dwell time is high. The user expectation is set by years of using the incumbent. The edge case surface is enormous and has been mapped by decades of bug reports.
Anything multiplayer with real-time shared state: Collaborative document editing, shared design canvases, multi-user code editors. The operational transformation or CRDT logic required to make real-time collaboration work correctly at scale is genuinely hard. LLMs can generate the scaffolding but cannot substitute for the deep understanding required to get the conflict resolution right under all conditions.
Anything with file format compatibility burden: If your product needs to open files created by the incumbent tool, you inherit decades of format quirks. PSD files created in Photoshop 5.5 that were saved with certain plugin metadata, Excel files with VBA macros from 2003, Word documents with revision tracking enabled. Every version of these formats has edge cases. Getting compatibility right is archeology, not engineering.
High-stakes transactional systems: Billing, inventory management, accounting. The cost of a bug here is not a poor user experience. It is money either lost or reported incorrectly. The audit requirements, the reconciliation workflows, the error-handling paths – these are where depth earns its keep.
A Four-Axis Test for Any Idea
Before committing to build anything with AI-assisted development as the primary approach, run it through these four axes:
| Axis | Low (AI leverage) | High (Craft required) |
|---|---|---|
| Dwell time | Under 20 min/day | Over 2 hours/day |
| File ecosystem | Own format only | Must read/write incumbent formats |
| Multi-user state | Single-user or async | Real-time shared state |
| Edge case surface | New problem space | Mature problem with known edge cases |
Score each axis. If three or four axes land on “high”, you are building something where vibecoding will give you a prototype and then leave you with a multi-year engineering problem to close the gap to production quality. That engineering problem does not go away because you started with AI assistance. It is still there. You have just deferred encountering it.
If two or fewer axes land on “high”, you are likely in territory where AI-assisted development can take you from idea to production with manageable rework. This is the zone worth investing in.
Understanding the broader economics behind this – including how agency pricing shifts when you can build faster but the hard problems stay hard – connects directly to how AI has changed the economics of agency work without changing what the hard problems actually cost.
The Contrarian Point: Boring Craft Is Now More Valuable
Here is where the observation lands for me as someone who builds software products professionally.
The proliferation of vibecoded demo-grade apps has not reduced the value of the boring craft that makes real products work. It has increased it. The gap between a demo that looks like it works and a product that actually works at the depth professionals require has not narrowed. If anything, the demo gap is now easier to cross than ever, which means the distance between demo quality and production quality is more visible.
Understanding file format internals. Building undo systems. Writing real-time collaboration engines. Managing color profiles correctly. Handling locale edge cases. Making performance work at scale under concurrent load. These are moats that AI cannot cross. They are not crossed by generating more code. They are crossed by accumulated understanding – of the problem domain, of the failure modes, of the constraints that the systems downstream of your software impose.
The incumbents in high-dwell-time categories are not under threat from vibecoded competitors because those competitors cannot afford to accumulate the depth that the incumbents have. Not because they lack ambition, and not because the LLMs are not good enough at generating plausible code. But because the depth required is not primarily in the code. It is in the understanding of what the code has to do, in edge cases that have been discovered through years of production failures, in the decisions about what to sacrifice when two requirements are in conflict.
The founders who will benefit most from the vibecoding era are not the ones trying to vibe-code a Photoshop replacement. They are the ones who use AI-assisted development to ship real value in the domains where depth is achievable and dwell time is low – and who understand clearly which category their idea sits in before they commit to building it.
The boring craft is the moat. It always was. LLMs just made it more visible by flooding the market with everything that is not the moat.
If you are building software products and want to think through where AI-assisted development is leverage versus risk in your specific context, the services team at Wbcom Designs works on exactly this kind of architectural decision with agencies and SaaS founders. Reach out if the four-axis test surfaces questions you want to think through with someone who has run this calculus in production.