Generative AI Definition: What It Really Means for Operators in 2026

Last month I needed to generate five hundred product descriptions for a new Shopify store. I had a tight deadline and zero budget for a copywriter. I turned to the generative AI definition I’d seen in textbooks and tried to make it work.

After a few false starts I built a simple automation that takes a product title, sends it to an LLM, and returns a ready‑to‑publish description. The steps below show exactly how I did it, what broke, and what I actually paid.

Why the usual generative AI definition falls short in practice

The textbook line says generative AI creates new content from learned patterns. That’s true but it ignores the operator’s reality: you need format control, brand voice, and cost predictability. Most guides stop at “it can write text” and never mention the plumbing required to make it reliable.

When you treat the definition as a magic button you end up with random outputs, token overruns, and wasted API calls. The real work is in shaping the prompt, handling the API response, and looping the process safely.

Building a description generator with OpenAI and Make (formerly Integromat)

Here’s the concrete named example I used. I chose OpenAI’s GPT‑4o model because it balances quality and price, and Make.com for its visual workflow builder.

1. Create a free Make.com account and start a new scenario.
2. Add a “Schedule” module set to run once per day (you can change to webhook if you prefer).
3. Add a “HTTP” module configured to call the OpenAI chat completions endpoint.
4. Set the method to POST, URL to https://api.openai.com/v1/chat/completions, and add headers:
   • Authorization: Bearer your_openai_key
   • Content-Type: application/json
5. In the body, paste this JSON (replace {{product_title}} with the variable from a previous step):

   {
     "model": "gpt-4o",
     "messages": [
       {
         "role": "system",
         "content": "You are a copywriter who writes concise, benefit‑focused product descriptions in a friendly tone."
       },
       {
         "role": "user",
         "content": "Write a 120‑word description for the product titled {{product_title}}. Include two bullet points of key features."
       }
     ],
     "temperature": 0.7,
     "max_tokens": 250
   }

6. Add a “Parser” module to extract the choices[0].message.content field from the response.
7. Finally, add a “Shopify” module (or Google Sheets if you don’t have a store) to write the description back to your product list.
8. Save and run the scenario once to test. Check the output, tweak the prompt, then schedule.

That’s the whole pipeline. It took me about ninety minutes to get from zero to a working run.

What most guides get wrong about prompt engineering

Many tutorials tell you to just “be clear” or “give examples.” That advice is vague and leads to brittle prompts. I learned the hard way that you need to constrain length, tone, and format explicitly.

For instance, early prompts that said “write a description” gave me anything from a tweet to a 500‑word essay. Adding a hard token limit and a bullet‑point requirement cut the variance dramatically.

Another common mistake is forgetting to set a system message that defines the role. Without it the model drifts toward its default chat style, which sounds robotic for product copy.

How to debug when the output drifts off‑brand

When the descriptions started sounding too formal I first checked the system message. I had accidentally left it blank in a later version, so the model fell back to its default.

If the output is too long, verify the max_tokens setting and the actual token count returned by OpenAI. Make.com shows the raw response; you can add a “Set Variable” module to log the usage.

When you see repeated phrases or nonsense, lower the temperature. A value of 0.2‑0.4 works well for copy that needs consistency.

Finally, always keep a fallback: if the HTTP module returns an error, route the scenario to a manual review step instead of failing silently.

Cost breakdown and my love/hate for the tools

OpenAI charges $0.012 per 1k tokens for GPT‑4o. My average run used about 800 tokens per description, so five hundred descriptions cost roughly $4.80. Make.com’s free tier gives you 1,000 operations a month; each scenario run uses three operations (schedule, HTTP, Shopify), so I could run about three hundred descriptions before hitting the limit.

I think the $9/mo Make.com Basic plan is fair for the automation you get—it unlocks unlimited operations and premium apps. The free tier is enough for solo testing but becomes a bottleneck fast.

My gripe: the HTTP module does not let you reuse authentication across scenarios, so you have to copy‑paste the API key each time. It’s a small thing but it feels sloppy when you manage ten different workflows.

My love: the built‑in error handling in Make.com lets you set a retry policy with just two clicks. I’ve saved hours of manual reruns because a temporary network glitch no longer kills the whole batch.

Is the free tier actually usable for a real business?

If you’re just testing a concept or running fewer than a hundred descriptions a month, the free Make.com plan plus OpenAI’s pay‑as‑you‑go works fine. Once you need daily batches or want to connect to a CRM, the paid plan removes the operation ceiling and adds error‑routing options that are worth the monthly fee.

For operators who want to skip the ninety‑minute build and have a ready‑to‑go scenario, we’ve packaged this exact workflow as a blueprint. You can import it, plug in your keys, and start generating copy in under ten minutes.

We cover this in more depth elsewhere — AI meeting tools coverage.

If you’d rather skip the build and deploy a working version in an afternoon, we’ve packaged this workflow as a blueprint at deepusecase.com/vault.