AI-Generated Shopify Theme Blocks: The Problems That Look Finished

In the first post of this series, we ran a hands-off Shopify build with Sidekick, approving everything it proposed without correcting it. The storefront came out genuinely good. Then we asked for an add-to-cart button, and it did nothing — and after we had it regenerated, we were left holding code we couldn't fully account for.

That's where this post picks up. Because the dead button wasn't really the problem. A button that visibly doesn't work is the easy case — you can see it's broken, so you fix it. The problems that actually cost you are the ones that look finished. This is a post about those: what goes wrong silently in an AI-generated store, why it gets expensive later rather than immediately, and who this path genuinely suits anyway.

And it turns out we're not the only ones seeing it. Our previous post on this drew far more response on LinkedIn than we expected — a lot of impressions, and a lot of comments from people who build on Shopify for a living. What stood out was that the agreement clustered around two points, raised independently by people who weren't talking to each other. First: "looks right" is not the same as "works," and neither is the same as "maintainable." Second: hidden, unversioned code compounds silently and costs you later — several people echoed the "front-loads speed, back-loads cost" framing almost word for word, because they've watched it happen on real stores. That's not an agency talking its book; it's a widely shared, independently reached observation among practitioners. This post is the longer, sourced version of why both of those are true.

Two kinds of mistakes: cheap, and compounding

Not every mistake in a store is equal. Some are annoying and instantly fixable. Others sit quietly and get more expensive the longer they're there. Understanding which is which is the single most useful lens for thinking about an AI-built store — because AI is good at producing both, and it produces them at the same speed, so they're indistinguishable at the moment of creation.

The cheap mistakes. These are the ones you can fix in an afternoon, with no lasting residue:

• Copy that's wrong, off-brand, or generic
• Product data errors — wrong prices, missing details, bad descriptions
• Images that are the wrong size or in the wrong place
• Basic settings — shipping zones, tax regions, notification text
• Collection membership — a product in the wrong collection
  If Sidekick gets any of these wrong, you notice, you correct it, and it's over. There's no downstream consequence. The mistake and the fix are the same size. For this entire category, an AI-led build is genuinely fine — if the storefront copy is bland, you rewrite it, and nothing about that rewrite is harder because AI wrote the first version.

The compounding mistakes. These are different in kind, not just degree. They don't announce themselves, they're not fixed in an afternoon, and the cost grows over time:

• Generated theme code with no version history, no development theme, and no backup. The single biggest one, and the subject of most of this post.
• URL structure — decisions that are cheap to set correctly on day one and expensive to change once pages are indexed and linked.
• Collection architecture — how your catalogue is organised structurally, which everything else depends on.
• Metafield naming — the invisible schema your store's data hangs off; rename it later and things break.
• Anything that looks like it works but doesn't, or works now but won't survive a change.
  The defining feature of a compounding mistake is that nothing tells you it happened. The store looks finished. It might even be finished, today. The cost arrives later — on the day you try to change something, update something, or grow past the setup you didn't know you had. That gap between "looks finished" and "is finished" is where the real money is lost, and it's exactly where an AI-only build is most likely to leave you exposed.

The core problem: AI-generated code is custom code

Here's the fact that everything else in this post follows from, and it's from Shopify's own developer documentation: when Sidekick generates theme functionality, the result is stored as its own Liquid file in the theme's /blocks folder, wrapped in a platform-generated _blocks.liquid section.

Read that again, because it's the whole game. What Sidekick produces isn't a setting or a configuration. It's custom code — genuine Liquid, HTML, CSS, and JavaScript — sitting in your theme's files. The fact that you created it by typing a sentence into a chat window doesn't change what it is. You have custom code in your theme, and you didn't write it, and — if you're the merchant this path is aimed at — you can't read it.

Shopify is explicit about what that means for support. Its own Help Center states that assistance with customizing or troubleshooting the code for AI-generated blocks isn't supported by Shopify Support or by third-party theme developers, and that if a generated block causes problems, you might need to delete it. Shopify also says plainly that you are responsible for reviewing, testing, and ensuring the generated block functions correctly.

So the arrangement is this: the AI writes code into your theme, that code isn't supported by Shopify or by theme developers, and you're responsible for making sure it works. For a developer, that's a reasonable deal — you can read the code, so you can own it. For a merchant who generated it in a chat window and never looked at the file, it's a liability with a delayed fuse.

Why it gets expensive later: the theme update

The delayed fuse is the theme update, and this is the heart of it.

Shopify themes get new versions every few months — bug fixes, new features, performance improvements. Updating is normal, recommended maintenance. But here's what happens to your customizations when you update, per Shopify's own guidance on updating themes:

• Theme-editor customizations carry over — your settings, your section and block arrangement, your content edits. These are safe.
• Code edits carry over only if they don't conflict with the update. If they do conflict, they are excluded — left out of the updated theme — and have to be manually copied into the new version by hand.
  Now put the two facts together. AI-generated blocks are custom code. Custom code is exactly what a theme update can exclude. So the update that's supposed to be routine maintenance can quietly strip out the AI-generated functionality you depend on — and to restore it, someone has to manually re-apply code into the new theme version.

This isn't our theory. It's documented on Shopify's own developer forum: a merchant noting that upgrading the theme removes AI-generated sections because they're treated as custom code, and asking Shopify to let merchants choose which generated blocks to keep during an update. The problem is real, it's known, and there's no clean built-in solution to it yet.

Here's why that's catastrophic specifically for the AI-only merchant, and merely annoying for a developer:

A developer keeps a development theme, uses version history, and takes a backup before updating — Shopify's own guidance is to save a copy of any customized code before you update. When an update excludes their custom code, they have the original saved, they can read it, and they can re-apply it. Annoying, an hour's work, done.

The merchant who built with Sidekick has none of that. No dev theme, because they were working in chat. No version history, because they never set one up. No backup of the code, because they never knew it was code. And critically: they can't read it. After a full build, their theme might contain forty generated block files. When an update breaks something, they can't tell which of the forty matters, what it was supposed to do, or how to restore it. They didn't write it, they never read it, and the only entity that "understood" it was a chat session that doesn't persist that context in a form they can act on.

That's the compounding cost made concrete. The build felt free and fast. The bill arrives, months later, on the day a routine theme update quietly removes functionality the merchant can't rebuild.

What goes wrong silently

The theme update is the big one, but it's part of a wider pattern: AI-generated stores fail in ways that don't surface until something forces them to. From what's documented and what we saw in our own run:

• Controls that render but don't work. Our dead add-to-cart button is the example — it looked correct and did nothing. Shopify's community and developer forums document a related, subtler version reported in May 2026: AI-generated add-to-cart blocks where the item is added but the cart doesn't visually update until the page is refreshed — the kind of bug a merchant would never catch in casual testing, reproduced on more than one theme. A proper quick-add on product cards, per the same forums, actually requires schema added to the product-card snippet plus further Liquid and JavaScript — edits that go beyond what block generation does on its own.
• Desktop-fine, mobile-broken. Generated layouts that look right on the screen they were built on and break on the one most of your customers actually use. Shopify's own guidance (linked above) explicitly tells you to preview generated blocks on both desktop and mobile, and warns that AI-generated code may not meet accessibility or performance best practices — guidance the target merchant doesn't know to follow.
• Silent performance drag. Generated code isn't always written for speed; extra CSS and JavaScript can slow a store measurably. Shopify itself flags performance as something you're responsible for checking. Slow doesn't look broken. It just quietly costs conversions, and nobody connects the two.
• The same prompt, different results. Generation isn't deterministic — the same request can produce different code on different runs. Which means "it worked when I tried it" isn't a guarantee it'll work the same way next time, or be consistent across your store.
  None of these throws an error at build time. Every one of them looks finished. That's the whole problem — the AI-built store passes the only test its intended user knows how to run ("does it look right?"), and fails the tests they don't ("does it work, on every device, after an update, at speed?").

Who should do this anyway

This is the part that matters, because the honest answer isn't "nobody." It's "it depends entirely on who you are and what you're building" — and Sidekick is good technology for the right person.

An AI-only build is a reasonable path if:

• You have no budget for a developer and you need to launch now. A real, good-looking store today beats a perfect store you can't afford. That's a legitimate trade, and we'd rather you launch on Sidekick than not launch at all.

• You're running a simple store — a straightforward catalogue, standard theme, no custom functionality, no added blocks that need to survive updates. If you never generate custom code, most of the compounding risk in this post never applies to you.

• You treat it as a starting point, not a finished asset — something to get going with, knowing you'll bring in help when you grow past it.
  Think hard before an AI-only build if:

• You're generating custom functionality — the moment you're creating blocks, buttons, and features, you're creating custom code you'll have to own and maintain.

• You're building something you intend to run and grow for years. The compounding costs are, by definition, a long-term problem. The longer the store's life, the more updates it'll go through, and the more the "code I can't maintain" problem bites.

• The store is your primary revenue and downtime or a broken checkout is a real loss, not an inconvenience.
  The dividing line isn't "AI good" or "AI bad." It's the split we opened with: if your build only ever involves the cheap, fixable category — copy, products, images, settings — an AI-only build is genuinely fine, and Sidekick does it well. The moment it crosses into the compounding category — custom code, structure, anything that has to survive a change — you're accumulating a liability, and the person best placed to manage that liability is someone who can read what was written.

The honest position

Sidekick is good technology, and this two-part series has tried hard to say so plainly — the storefront it built genuinely looked good, and for a merchant with no budget and a simple store, it's a real and reasonable option.

But "looks finished" and "is finished" are different claims, and the gap between them is exactly where an AI-only build hides its costs. The mistakes that are cheap to fix, AI makes cheaply and you fix cheaply. The mistakes that compound — generated code with no backup and no one who can read it, structure set wrong on day one, functionality that won't survive a theme update — those you don't see until they've already cost you.

When someone says "but I can do the same with AI," the honest answer is: sure, and so can we. If we both open a store in the same niche tomorrow, do they perform the same? The tool is identical in both hands. The variable is whether the person running it can tell a finished store from one that only looks finished — and can read the code when it matters. That's expertise, and it's true well beyond Shopify.

If you've already run an AI build and haven't hit these consequences yet, that's not evidence you dodged them — it usually just means you haven't updated your theme yet. And if you're weighing an AI-only build against bringing in help, get in touch. We'll give you a straight read on which category your build actually falls into — and if Sidekick is genuinely all you need, we'll tell you that too.

This is the second of two posts on building a Shopify store with AI. The first covered the hands-off build run itself — what we fed Sidekick, what came back, and the moment it stopped working.