This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/why-fix-not-report. The canonical URL points back there.
Key takeaways
- Other tools tell you what's wrong. This one has already written the fix — you just approve it. This post is the reasoning behind that sentence, and the argument against the two more obvious designs.
- A list of problems is not progress. A scan that returns a few hundred issues has converted one unknown into a few hundred small writing jobs and moved all of them to you. The finding was never the hard part.
- Silent automation is worse, for a specific reason: it takes the work and hands you the risk. Catalogue copy is not a thing you want changed while you aren't looking.
-
The approval is where the design lives. The change arrives written and scoped —
Only this product will be updated — all others left untouched.— and still doesn't run until you press a button. - What this post does not establish: this is an argument about design, not a measurement. We have no data showing this workflow produces better catalogues than an audit tool does.
Finding the problem was never the expensive part. Deciding and typing was.
See what "already written" looks like
Arvio is an AI store operator: it reads your live catalogue, drafts the change, and shows it to you before anything is written.
The report problem
Run any catalogue scan and you get a number. A few hundred products with thin descriptions. Some number with no product type — we ran exactly that count on a real catalogue. Some quantity of empty categories and absent SKUs.
That number feels like progress, and for about a day it is. You didn't know, and now you do. The trouble starts the moment you try to act on it, because the report has performed a conversion that nobody names out loud: it turned one vague worry into several hundred specific small jobs, and assigned every one of them to you.
And they are not jobs that a list helps with. If the finding is "this description is thin," the work isn't locating it — the report already did that. The work is deciding what the description should say instead, and typing it — once per product, all the way down the list. The report is complete and accurate and has not moved you a single product closer to done.
This is the part we'd expect to strand people, and it's not a failure of the tool: a scan that returns the same count next month is working exactly as designed, on a problem it was never able to touch. (We're reasoning about where the work lands, not reporting what anyone did — we have no data on how often these get re-run or abandoned.)
The asymmetry is the whole thing. Finding is cheap and automatable. Deciding and typing is expensive and wasn't automatable — until recently, which is what changed.
Why we didn't just automate it
The obvious response is to close the loop: if the tool can find the thin description and can also write a better one, let it write and be done. No list, no queue, no backlog of anything.
We didn't build that, and the reason isn't timidity about what the writing is worth.
It's that catalogue copy is customer-facing, permanent by default, and worth different amounts per product. A rewrite that's fine on a serving tray is a problem on the product where the wording was negotiated, or the one with a compliance constraint, or the one being discontinued next week. The tool cannot know any of that. It can see that a field is thin. It cannot see that the thin description was deliberate.
So full automation doesn't remove the risk. It relocates it — to a place where you find out about it later, from a customer, or not at all. The economics are bad in an asymmetric way: the upside of an unattended rewrite is a slightly better description, and the downside is wrong text live on your store for an unknown number of days. You would not take that trade on a product that matters, which means you would not enable it, which means the feature is useless precisely where the catalogue is valuable.
And there's a second cost that's easy to miss: a change you didn't see is a change you can't learn from. If the tool quietly rewrote every thin description you had, you have no idea whether it's any good at it. The approval isn't only a safety mechanism. It's the only moment where you find out what the thing actually does.
The third position
Between "here's a list, good luck" and "I changed it, hope that's fine" there's a position that only became available once drafting got cheap:
Do the work. Don't do the deciding.
Concretely, that means a change arrives in a particular shape. The draft is written — not suggested, not described, written, and sitting in an editable box. In the run we recorded, a product whose entire description read Solid acacia, finished by hand. Hand wash and dry immediately. came back with a replacement already drafted: "Crafted from solid acacia wood and finished by hand, this round tray brings warm, natural grain to any table…" — 62 characters of stored text replaced by 364, before anyone had agreed to anything. The scope is stated in narrow terms before you commit to it. In that run, the confirmation card says it in a sentence:
Only this product will be updated — all others left untouched.
Then nothing happens until you press the button. And afterwards, the result card carries the way back:
This action can be undone. Let me know if you'd like to revert it.
Take any one of those away and the thing stops working. If it isn't written, you're back to a list. If the scope isn't stated, you can't agree to it without checking the whole catalogue yourself. If you can't refuse it, your judgment is out of the loop precisely where the tool has none. And if you can't undo it, you won't press the button the first time.
If you want to see that sequence on screen rather than described, we published the whole run, screen by screen. The wider tour of what the thing does is over here.
One approval per change, and a diff you can read first
Three designs, side by side
| Audit / report | Silent automation | Written, then approved | |
|---|---|---|---|
| Who finds the problem | The tool | The tool | The tool |
| Who writes the fix | You | The tool | The tool |
| Who decides it ships | You | Nobody | You |
| What you hold afterwards | A list of jobs | Changes you didn't individually read | A change you read and accepted |
| Cost of a bad call | — | Live wrong text, found later | Reject it, or undo it |
| What you learn about the tool | Nothing | Nothing | Whether it's any good |
The last row is the one people don't anticipate. After ten approvals you have a real opinion about whether the drafting is worth having, because you read ten drafts. Neither of the other two columns gives you that at any point.
Where the boundary belongs
"Keep a human in the loop" is easy to say and usually means nothing, because it doesn't specify where. Put the human too early and you've built an audit: they do the work. Put them too late and the decision has already been made for them; a log they can read afterwards is a different thing from a choice they got to make.
The rule we landed on is about reversibility, and it's not specific to catalogues:
Automate up to the last irreversible step. Stop there, and make that step cheap to refuse.
Drafting is reversible — a draft you don't like costs nothing, you just don't press the button. Writing to a live storefront is not reversible in the same way; there is an interval where the wrong thing is public. So the boundary goes between them. Not because writes are scary, but because that's the first point where a mistake acquires a duration.
This also explains why the answer isn't "add a confidence threshold and auto-apply the easy ones." Confidence measures whether the model thinks the copy is good. It has no access to the thing that actually determines whether a change is safe — whether this product matters, and why it currently reads the way it does. Those aren't the same question, and only one of them is yours to answer.
What this argument doesn't prove
- It's an argument, not a measurement. We have no comparative data showing this workflow produces better catalogues than an audit tool does.
- Approval is a real cost. Per-change review does not scale to infinity, and if you have hundreds of thin descriptions you will be pressing a button a lot. We think it beats writing hundreds of descriptions. That's a judgment, not a finding.
- Some jobs genuinely want the other designs. If you already know the exact values you want in a column — a tag migration, a vendor rename — that's a spreadsheet operation, and a report plus a batch update is the right shape for it. If a field is truly low-stakes and uniform, automate it and don't look.
- We're describing two designs we didn't build, in their plainest form. Real audit tools and real automation products carry mitigations we haven't credited here — previews, dry runs, staged rollouts, per-field rules. The comparison is between the three shapes, not a claim about any particular product's worst case.
- We're describing our own product's design, so read this as reasoning you can check against the recording, not as a neutral survey.
FAQ
Isn't this just an audit tool with extra steps?
The opposite, in the one place it matters. An audit ends by handing you the writing. This ends by handing you a decision, with the writing already done. Same finding, and everything expensive after the finding lands in a different place.
Why not let it run unattended on the obvious cases?
Because "obvious" is a property of the copy, and the risk is a property of the product. The tool can see that a description is thin. It can't see that the wording was negotiated, or that the item is being discontinued. Those don't correlate with how confident the model is.
What if I already know exactly what I want in every row?
Then you don't have this problem, and you shouldn't reach for this. Knowing the value already means the only work left is applying it, which a spreadsheet operation does perfectly well. What this is for is the other case: where the decision doesn't exist yet, and somebody has to work out what this particular description should say.
Doesn't approving every change defeat the point?
It would if approving were as expensive as writing. It isn't — reading something already written and deciding yes or no is a smaller job than composing it from nothing. That gap is where the saving lives, and it's real even though approval is not costless.
What if I trust it after a hundred changes?
That's the right instinct and you'd have earned it by reading a hundred drafts, which is exactly the thing the other two designs never let you do. We're not claiming the approval step should be permanent for everyone forever — only that it's where you start, and that removing it should be a decision you make with evidence rather than a default you never saw.
Do you have data showing this works better?
No. This post is a design argument. The measurable claims we do have are about the interaction — what appears on screen, in what order — and those are in the walkthrough.
On-screen strings quoted here are from one recorded run on our own demo store, 2026-09-21, reproduced with the full sequence in "What It Looks Like When the Fix Is Already Written". Last updated: 2026-09-21.
Arvio: AI Store Operator — install it on the Shopify App Store. It writes the change and waits for you.
Originally published at https://arvio.a.xyz/blog/why-fix-not-report. More Shopify bulk-editing writeups are on the Arvio blog.
Top comments (0)