AI for Shopify: what merchants use it for

Five stores, their first messages, lightly trimmed. None of them asked for a description generator. All of them asked for a job with a scope and a rule.

Each one is a scope ("all draft products", "products missing SEO fields", "active products") plus a rule ("in cm", "cheap to most expensive", "remove anything that mentions a country"). Each one is a few hundred rows in the admin, which is past the point where a person does it by hand and short of the point where it is worth building a spreadsheet. None of them start in a file. They start as a sentence, because that is how the person thinking about the store thinks about it.

And each one is a write the merchant cannot see by eye at that size. Two questions came up in every first conversation, in almost these words: "How many products are you applying this change to?" and "Is this change for all of my items?" The tool has to answer those before it writes, in the first line of the preview, or the merchant is approving a count they had to guess.

The fifth request is different in kind: it says "do not make changes yet". That merchant had been through a bad bulk edit before. The distinction they were drawing, between looking and changing, is the one that the rest of this page is built on.

Reads are questions: how many, which ones, show me, audit this. They change nothing and need no approval. The image-compliance audit above is a read: every active product, every image checked by a vision model for promotional text, watermarks and supplier logos, and a report with totals and the first flagged rows. A read on a large catalog takes longer and costs more than a read on a small one, and the estimate is shown before it runs; it never writes.

Writes go through a plan. The tool reads the products in scope, builds one row per change with the current value and the new value, shows the count, and waits. Approval is a signature on the exact rows shown; if the rows would change (another job ran, an order took stock), the approval is void and the preview is rebuilt. After the write, every row is read back from the store and compared to what was intended. Rows that did not match are listed.

The previous values are saved per row at write time. Revert is a new job built from them, with its own preview, approved like any other write. What cannot be reverted is creation and deletion, because there is no before for a thing that did not exist, and the preview says so before those jobs run.

After a few hundred conversations the requests sort into a short list. Each row links to the case that walks through it, with the instruction as written and what the preview showed.

Most bulk edits do not need a language model. A percent on a price is arithmetic. What needs a model is the text that has to be different per row: an alt text that names the product in this image, a meta description that summarises this product, a title rewritten to a pattern with exceptions. That is the job where "AI" is the feature rather than the interface.

The rule that keeps generated text safe is the same as for any write: it is previewed per row, and it is generated from the product's own data. An alt text is written from the product the image belongs to, not from the picture and not from the internet. A meta description is written from the description, and a product with no description gets an empty row and a note, not an invented paragraph. Facts the product does not carry (a material, a barcode, a country of origin) stay blank.

Read the generated rows the way you would read a junior copywriter's first batch: the first twenty carefully, then a sample. Exclude the ones that read wrong before approving; the rest write. A tool that generates text and writes it without showing it is the one to be afraid of.

The preview is the whole safety model, so its shape matters. Five things it should show, in this order.

Facts that are not in the product data are not invented: a barcode, a material the tags do not mention, a description for a product with no data at all. The field stays blank, and the report says which rows were left blank and why. A made-up barcode is a worse problem than a missing one.

A supplier feed with the values already in columns is a spreadsheet job. A migration between platforms is a spreadsheet job. The tool is for the change that starts as a sentence, and it says so when the request is a file job, rather than doing a slow version of what Matrixify does well.

Very large jobs are better run as several scoped jobs, by vendor or by collection, with separate history entries. Not because of a cap, but because the preview for a whole catalog is a table nobody reads end to end, and the revert for a whole catalog is a bigger thing to approve than the revert for one vendor.

Judgement calls stay with the merchant. "Make the names more professional" becomes a concrete map (Color 1 is Black, Color 2 is White) that the merchant edits before the rename runs. The tool proposes; it does not guess that Color 3 is Navy on its own.

The category is new enough that the listings all sound alike. These checks separate a tool that proposes from a tool that writes. Run them on a test store or on ten products before the real catalog.

It is not autonomy. The tools merchants keep using are the ones that do exactly what was said and nothing else, show it first, and stop. A tool that "optimises your catalog" on its own schedule is a tool that changes prices while you sleep, and there is no version of that merchants want once they have seen the first surprise.

It is not a replacement for a file when the values are in a file, or for a scheduler when the job is on a calendar. It is the layer for the request that arrives as a sentence and needs a preview before it touches the store. That is a large share of the requests, and it is the share nobody had a good tool for.