Doing two hundred at once, and knowing how many to check

The workflow

The technique is from module two: write five yourself, then feed the raw facts for the rest. What changes at scale is the plumbing and the checking.

1. Get the facts into a spreadsheet. One row per product, one column per attribute: material, dimensions, weight, origin, price, what it is for, who should not buy it. This is the work. If the spreadsheet is thin, the descriptions will be empty, and no amount of prompting fixes an empty row.

2. Write five descriptions by hand. Properly, in your voice, using the same columns. These are the pattern.

3. Run in batches of fifteen to twenty. Not two hundred at once. Long outputs get truncated, quality drifts across a very long response, and a batch of twenty is a checking session you will actually finish.

4. Add two columns: checked and notes. Empty until a person has read the row.

5. Publish only checked rows. This is the rule that makes the whole thing safe, and the one that gets abandoned under deadline pressure.

The prompt

Below are five descriptions I wrote (EXAMPLES) showing
style only - do not reuse their content.

Then a table of product facts. For each product write a
description of 60-80 words in that style.

Rules:
- Use ONLY the facts given for that product.
- Never invent dimensions, materials, origins or care
  instructions.
- If a needed fact is missing, write [MISSING: field].
- No superlatives you cannot support.
- Output: product code, then description. Nothing else.

The [MISSING] rule is what turns a hundred silent inventions into a hundred visible gaps you can fill from the stockroom.

How many to check

This is the part everyone guesses at, and there is a simple piece of arithmetic that answers it.

Suppose you check twenty descriptions at random and every one is fine. What does that tell you about the other 180?

There is a rule of thumb statisticians call the rule of three: if you see no failures in n samples, the true failure rate could still plausibly be as high as 3/n. Twenty clean samples means the real rate could be up to about 15%. That is thirty bad descriptions in your catalogue.

Check fifty and find none, and the ceiling drops to about 6%. Check a hundred, about 3%.

So the answer depends on what a bad description costs you. For decorative copy on low-value items, twenty is fine. For anything where a wrong dimension causes a return, or a wrong material causes an allergy problem, you are checking far more, and for safety-relevant fields, every single one.

The useful discipline is to know which you have chosen. “I checked twenty and found none, so the error rate is probably under 15%” is a defensible sentence. “I spot-checked a few and they looked fine” is not a statement about anything.

Check the fields, not the prose

Read a batch in two passes, as in module one. First pass across all twenty: every dimension, material, price and care instruction against the spreadsheet, ignoring the writing entirely. Second pass: read three or four as a customer would.

Errors cluster by field rather than by product. If one dimension came out wrong, check that column everywhere: the failure is usually in how the column was labelled or formatted, not in the individual row.

Marketplaces

Amazon, Etsy, Jumia, Mercado Libre and the rest do not prohibit AI-written listings. Two things are worth knowing anyway.

Listings that all read alike compete badly, because shoppers skim and there is nothing to catch on. Your specifics are the defence, which is another reason the spreadsheet matters more than the prompt.

And every platform prohibits inaccurate attributes. A generated care instruction that turns out to be wrong is not a writing problem; it is a listing violation and a return.

What to do when you find errors

Not fix the rows. Find the cause.

Errors in generated batches almost never scatter randomly. They come from one of four places: a column whose header was ambiguous, a product whose facts were missing so the model filled the gap, a formatting inconsistency such as dimensions written three different ways, or an instruction the prompt did not contain.

Fix the cause and re-run the affected batch. Fixing thirty rows by hand leaves the cause in place for the next two hundred.

Where the time actually goes

An owner budgeting for this exercise usually plans for the generation and is surprised by the split. In practice, on a catalogue of two hundred: roughly two hours assembling and cleaning the spreadsheet, forty minutes writing and testing the prompt on five products, twenty minutes of generation, and two to three hours of checking.

The model accounts for a tenth of the work. That ratio is worth knowing before you promise somebody a catalogue by Friday, and it is why the spreadsheet is the project rather than the prompt.