Shopify Canvas: what the AI builder does, and the work that still needs a developer

That question is a fair one, and it deserves a straight answer rather than a defensive one. Justin Musina posted it on the StartupTalky community within days of Shopify launching Canvas. His case is that the basic "I build Shopify stores" service is being compressed fast. He also accepts that complex work still needs specialists, and he treats the gaps in the launch as temporary. Nathan Vidal made a similar point on LinkedIn in August 2025, before Canvas existed: "Setup that used to take weeks now takes minutes", and agencies built on easy builds "will start disappearing entirely".

Shopify never says "the end of developers". Its own launch post does say that "anyone, whatever their design experience, coding skills, or budget, can create a beautiful, bespoke online store", and that is the line the argument is built on.

I build and fix Shopify stores for a living, so read this with that in mind. My view is that the argument is right about one layer of the work and wrong about the rest of it. Here is where I think the line falls, with Shopify's own documentation as the evidence.

What Shopify actually shipped

Two launches are getting blurred together. Canvas is the AI site builder. The new Hydrogen is the framework-agnostic part, and it is a different product for a different audience.

Canvas lays every template side by side on one workspace. You pan, zoom, click an element to change it, or ask Sidekick in chat, and the change shows live across devices, according to the changelog. It edits real theme code, not a mock-up. Shopify says it simplified the theme architecture so Sidekick can understand and change it, and that "Sidekick validates its code and reviews screenshots to inspect how its changes landed".

The new Hydrogen is the part people mean when they call this "agnostic". It works with whichever framework you choose and deploys to Oxygen, Vercel, Cloudflare Workers, Node or Deno. It is aimed squarely at developers and their coding agents. You still pick the framework, run the deployment, hold the credentials and own the code. It changes the developer's tools rather than removing the developer.

Credit where it is due

Canvas is genuinely useful, and pretending otherwise would be silly.

A merchant who wants a new landing page for a sale, a reworked hero, different typography or a tidier product template no longer has to brief someone and wait. Shopify says Sidekick made more than twenty-five million edits to themes in the first half of 2026, a sign of how much small visual work merchants want done. Ben Sehl, a director of product at Shopify, compares the two weeks it took him to build Kotn's first store with a custom store built "in twenty minutes" today. That figure is a marketing line rather than a measurement, but the direction is real.

It also costs nothing extra. The requirements page says it is available on plans that include theme customisation. For a small store paying someone for re-skins and new sections, that work now sits inside a subscription they already pay. That part of the argument holds, and I would rather say so plainly.

What Canvas can't do yet

Shopify is open about the gaps. Its own words: "We're early here and Canvas is not replacing the existing editor yet." The current limits, from the requirements page:

• It works only with themes developed by Shopify and with custom themes. "Third-party themes aren't supported."
• "You can't add or configure app blocks or app embeds in Canvas."
• Edited themes "don't receive automatic updates".
• "You can't download the theme files for a theme that you edited in Canvas."
• No per-market customisation. A Canvas-edited theme can go into a rollout as a replacement for the main theme, but it can't be edited or opened from the rollout.
• "You can't translate theme content directly in Canvas."
• It runs on desktop only.

Some of these will close. Shopify staff said on the developer forum that app extension support is planned within weeks, and before Canvas becomes the default editor. It would be a weak argument that rested on launch-week gaps, so the rest of this piece doesn't. The more useful question is what sits outside a theme editor altogether, however good it gets.

The store is mostly not the theme

Picture a mid-sized Shopify store with subscriptions, a loyalty scheme, a wholesale channel and stock coming from an ERP. The theme is what customers see. Almost everything that decides whether an order goes through, at the right price, with the right stock, and gets counted properly, lives somewhere else.

Each tab rests on Shopify's own documentation: theme app extensions, checkout and checkout UI extensions, Sidekick app generation, Shopify Functions, metafields, Google's product structured data guidance, external integrations and the B2B plan features.

Apps are how features get controlled

Most Shopify features a merchant cares about are switched on by an app, not designed into a theme. That makes the app layer a design problem in its own right. Which review app, which subscription app, whether the bundle logic belongs in an app or a Function, and what each one adds to page weight are choices that shape the store far more than the colour of a button.

When a store outgrows its apps, the next step is code: a custom app, a Function, or a checkout extension. Sidekick's own app builder can't reach any of those surfaces, by Shopify's design. That boundary is written into Shopify's own documentation, and it is a reasonable one.

What needs changing in a theme beyond the look

Even inside the theme, a lot of the work isn't visual. These are the things I check on a theme that has been reworked, whoever reworked it:

• Structured data. Product markup has to stay valid after every edit, because Google uses it for price, stock and ratings in results. Canvas pages say nothing about structured data, so nobody yet knows whether Sidekick edits keep it intact.
• Speed. Shopify's Theme Store asks for an average Lighthouse performance score of at least 60 across home, collection and product pages (Theme Store requirements). Google's thresholds are an LCP of 2.5 seconds or less, an INP of 200 ms or less and a CLS of 0.1 or less (web.dev).
• Accessibility. The same requirements ask for an accessibility score of at least 90, with keyboard access, visible focus states, 4.5:1 contrast and 24 by 24 pixel targets. WCAG 2.2 added target size and accessible authentication among its nine new criteria.
• The update path. A Canvas-edited theme stops receiving automatic updates. The vetted baseline it started from, and any fixes Shopify ships later, no longer arrive on their own.
• Version control. You can't download the files of a Canvas-edited theme, which breaks the usual workflow of keeping a theme in Git, reviewing changes and rolling one back.
• Content models. Sections that pull from metafields, filters that depend on consistent product data, and templates that change by product type all depend on the data underneath being designed first.

None of that shows up in a preview, and all of it turns up later in search results, conversion figures or an accessibility complaint.

Conversion is planned before it is designed

The Baymard Institute puts average documented cart abandonment at 70.22% across 50 studies. Look at the reasons shoppers give for leaving at checkout, and very few of them are about how the store looks.

Delivery charges, delivery promises, account rules, the number of form fields and errors are business, checkout and policy decisions. Baymard reckons the ideal checkout has 12 to 14 form elements against a US average of 23.48, and that large sites "can gain a 35.26% increase in conversion rate through better checkout design". Its 2025 benchmark rated only 2% of leading US and EU desktop sites "good" at checkout, and found that 62% don't make guest checkout prominent.

Getting some of that back starts with planning, not pixels: reading the funnel, working out which step loses people and why, deciding what the delivery promise is, then designing the page around those decisions. I have written up how to find where your checkout loses people separately. Canvas can style the page that comes out of those decisions. Making them is a different job.

Shopify's own team says the hard part is judgement

The most honest line in Shopify's launch post comes from Austin Knight, who works on design there:

"Getting Sidekick to write code was easy, but guiding it to make good design decisions took a great deal of time and attention."

That is the point the "RIP" argument skips. Writing theme code was never the scarce part of the job. Knowing what the store needs to do, which trade-offs are worth making, and what will break further down the line is. Canvas makes the cheap part cheaper still, which is good for everyone, and leaves the judgement exactly where it was.

Who can run on Canvas alone

This is how I would split it today. It will move as the gaps close, so treat it as a reading for October 2026.

Where that leaves Shopify developers

Some work is going. A developer whose whole offer was re-skinning themes and building landing pages for small stores is competing with a free tool now, and Musina is right about that. Nobody has published data on whether demand or rates have actually fallen since the launch, so anyone quoting a number is guessing.

The rest of the job was never the visual layer. It is choosing and wiring apps, building checkout extensions and Functions, designing product data, connecting the ERP, keeping a theme fast, accessible and valid once it no longer gets updates, and planning a checkout around why people leave. Shopify's own documentation sends that work to developers and Partners, including in the week it launched Canvas.

Canvas gives merchants control of how their store looks. Ecommerce development has always been about how the store works.