Why AI courses teach the prompt formula but never teach you to fix a prompt that failed

In short: the prompt formula — role, task, context, format — is free. Any ten-minute video hands it to you. The trouble starts one step later: you wrote a prompt by the book, hit send, and the answer came back as mush. At that point nobody teaches you anything. You rewrite at random until you like something. That is not a skill, that is a lottery. Below is a method: name the symptom, make a diagnosis, make exactly one edit, compare. Plus the order in which to dig: context → task → format → role. The prompts in this article are real ones — press Run and watch the difference with your own eyes.

What's wrong with the formula

The formula isn't lying to you. Role, task, context, format really are the four knobs that shape an answer. We cover the basics in what a prompt is and how to write one, and you need them. But the formula answers one question: how do I write a prompt from scratch? In real work you almost never write from scratch. You sit in front of a prompt that already follows every rule and still produced garbage.

Here the formula goes quiet. It doesn't tell you which of the four knobs is at fault. It doesn't tell you whether to turn one or all four. It doesn't tell you how to know whether the new answer is better or merely different. The formula is a blueprint. What you need is a repair manual.

It's the difference between "here's a diagram of the engine" and "the car won't start — what do you check first?" The first can be learned in an evening. The second is a profession. And the second is almost absent from the training market.

Students are asking for exactly this — verbatim

On 17 July 2026 we pulled data from Udemy (through the internal API behind their course pages) and from Coursera's review pages. We deliberately read the minority — the people who left low ratings. The densest cluster of complaints turned up on courses with prompt engineering right there in the title. People came for the skill named on the tin and didn't get it. Verbatim, with authors and stars:

"There is nothing teached about creating a good prompt. It is just an overview of types of prompts" — Geralt O., 01.07.2026, 2★ (Prompt and Context Engineering 101, Mike Wheeler).

"No specific guidance on prompt engineering… what to avoid while asking, how to organize your thoughts, how to give feedback to AI based on its answers etc." — Bharat Ram A., 05.06.2026, 1.5★ (Wheeler).

"i thought it would go deeper in prompts and have more examples and sessions to master or enhance our current prompts" — Manuel L., 15.06.2026, 2★ (Prompt Engineering for Everyone).

"Too much background on ChatGPT. Get me to how to prompt GPT" — Mark R., 16.09.2025, 1.5★ (Academind).

Stop on Bharat Ram A. He lists three things, and the third is "how to give feedback to AI based on its answers." That is debugging, described in his own words by a man who went looking for it and came back empty. Manuel L. asks to "enhance our current prompts" — that is, to fix something already written that works badly. Different people, different courses, one hole.

Alongside them sits the quote that shows what happens when nothing is checked at all:

"you send your assignments and immediatly you got your results: 100% correct. I am still speechless. I put all that effort in and have no idea whether I my answer was correct or not" — Shinysheep, 21.09.2023, 1★ (Prompt Engineering, Vanderbilt).

And in the same row: "quizzes give unhelpful feedback for incorrect answers and just say 'watch the video again'" — Cory Covino, 04.05.2024, 2★ (IBM). "All the coding is done in the labs for you. You won't have to debug anything or figure anything out, just press shift-enter" — Cornelius Griggs, 1★ (Generative AI with LLMs).

Griggs puts it most precisely without meaning to. "You won't have to debug anything" describes a learning product with debugging surgically removed. The exercise runs, it feels like practice, and nothing was ever at stake.

One more, from a different course, that closes the circle: "Didnt meet expectations, only theory is discussed which we already know" — Aditya Nagavolu, 19.11.2023, 1★ (Generative AI for Everyone). The theory people already know is the formula. What they don't know is what to do when it fails.

Why the hole exists: it's architecture, not laziness

It's tempting to blame lazy instructors. That explanation is worse than the truth. The truth is structural.

There is exactly one way to check a prompt: run it on a model and look at the answer. No other method exists — you can't judge a prompt by looking at it, any more than you can judge code without running it. And a video platform has no model inside the lesson. So there's nothing to check with. What's left is a keyword autograder, and it awards "100% correct" — precisely the thing that left Shinysheep speechless.

Then comes the detail that settles the question. Vanderbilt's Prompt Engineering Specialization requires a paid ChatGPT+ subscription to complete the assignments. The course sends the student outside, into another tab, to find a model. Coursera student economics work out like this: Coursera Plus at €50/month (or €343/year with a 14-day refund window), plus a model subscription — roughly €70/month to watch videos and receive an automatic 100%. On the exact price of that model subscription we'll be straight: we couldn't get it from a primary source, every OpenAI domain returned 403, so we're not printing a number. The €50 for Coursera Plus comes off their own page.

The moment the model lives outside the course, the course stops seeing your work. It doesn't know what prompt you wrote, what came back, or why it came back bad. You cannot teach debugging blind. So the course teaches the formula — the only part that fits on a slide.

And that's where a complaint that looks like it's about something else comes from:

"why read straight from the slide? I can do that. This was not a helpful course at all" — Janie I., 02.07.2026, 1★ (Justin Barnett).

"I can do that" isn't a verdict on a bad lecturer. It's a statement that only the formula fits on a slide. Debugging doesn't fit on a slide, because it's made of a live answer that nobody can predict in advance.

Debugging is diagnosis, not rewriting

The beginner's move looks like this: answer is bad → select the whole prompt → write it again, longer and prettier. Sometimes it works. Why it worked is unknowable, and next time you start from zero again.

The engineering approach is different, and it has four steps.

1. Symptom. Name what's wrong in words you can check. Not "bad" but: invented a fact; ignored the format; too generic; parroted my own input back; answered a different question; fell apart on a long text. Until the symptom has a name, there's nothing to treat.
2. Diagnosis. Every symptom has a typical cause. It's a hypothesis, not a verdict — but it tells you where to dig first.
3. One edit. Change exactly one thing. One.
4. Comparison. Run again and compare against the previous answer on your own criterion. Not "I like it more" but "did it improve on the specific thing I was treating?"

Repeat until the symptom is gone. Usually that's two or three laps, not twenty.

The one-screwdriver rule

The most underrated step is the third. Change one thing at a time.

Edit five things, the answer improves, and you don't know which edit did it. Worse: perhaps four edits were neutral, one was actively harmful, and the fifth outweighed it. You carry the whole bundle into your next prompt, harmful edit included, and a month later you own a two-page wall of text where half the lines work against you.

We didn't invent this. It's the base rule of any debugging — the same as changing one variable at a time in an experiment. It's just that with text the temptation to turn every knob at once is far stronger, because an edit costs one second.

A caveat against ourselves. The rule has a price. One edit per lap is slow, and on real work you will cut corners. The honest compromise: the one-screwdriver rule is mandatory while you're still finding the disease. Once the diagnosis is clear and you're polishing, batch your edits — the risk is small by then.

Second piece of honesty: models are non-deterministic. A single run is a sample of size one. The answer got better after your edit? Maybe the edit had nothing to do with it and you got lucky. Which is why a comparison deserves at least three different inputs, not one favourite.

The order of hypotheses: context → task → format → role

Once the symptom has a name, the question is which knob to touch. We have an order, and it isn't arbitrary: most common cause first, rarest last; biggest miss first, cheapest last.

1. Context first. The overwhelming majority of bad answers are answers to a question with no facts in it. The model doesn't know your product, your audience, your constraints, your numbers, your names, your past decisions. It fills the vacuum with averaged filler — because averaged filler is the correct answer to a context-free question. If the output is watery, generic, applicable to anyone, context is almost always the culprit, and no amount of role-play will cure it.
2. Task second. Check that you're asking for one action rather than three, and that the verb is checkable. "Analyse" is not a verb; anything can hide under it. "List five risks, one line each" is a verb. If the model answers a different question, or answers half of yours, the task is at fault.
3. Format third. Cheap to fix, and you see the result instantly. If the substance is right and the shape is wrong, fix format and touch nothing else. The move that works: paste a sample of the output you want, two or three lines. A sample beats a description every time.
4. Role last. Role mostly moves tone and vocabulary. "You are an experienced marketer" adds zero facts about your market — it's the one line everybody writes first and it decides almost nothing. Reach for role when everything else is in place and you simply don't like the voice.

Why this order? Because it tracks how much information you're adding. Context adds facts — the maximum. Task adds precision of goal. Format adds shape. Role adds style. Most people do it backwards: they agonise over the role, then feel betrayed by the filler.

The table: symptom → diagnosis → one edit

• Watery, generic, fits anyone. Diagnosis: no context. Edit: paste five concrete facts — who reads it, what the product is, what the constraint is, one number, one example. Change nothing else.
• Invented a fact, a link, a quote. Diagnosis: you asked for something the model doesn't have. Edit: either put the data in the prompt, or explicitly permit "I don't know." The line "if you don't have the data, say so — do not invent it" is cheap and catches a lot. More on this in why AI hallucinations happen.
• Ignored the format. Diagnosis: the format requirement drowned in the middle, or conflicts with the length you asked for. Edit: pull format into its own block at the end and show a sample output.
• Answered a different question. Diagnosis: two actions in one task, and the model picked one. Edit: leave one verb. The second action becomes a second prompt.
• Parroted my input back. Diagnosis: no transformation verb. "Here's the text, take a look" isn't a task. Edit: say what to do to the text — shorten, restructure, find contradictions.
• Wrong tone, "this isn't my voice." Diagnosis: you described a style instead of showing one. Edit: paste your own paragraph and ask it to match. "Write in a friendly but professional tone" does nothing; a sample does.
• Fell apart on a long text. Diagnosis: the instruction got lost inside the data. Edit: separate with markers (---TEXT--- / ---TASK---) and repeat the task after the text, not only before it.
• Too long, endless preamble. Diagnosis: you never forbade it. Edit: one line — "No preamble, no closing summary. The list only."

Notice: in six cases out of eight the fix is not "rewrite the prompt" but add or move one thing.

See it yourself: a bad prompt, one edit, the difference

Now the part a video platform physically cannot offer. Every block below has a Run button: press it right here and watch a live answer come back. Order matters — run them in sequence and compare.

Step 1. Run a deliberately bad prompt

This is a real prompt written "by the formula": there's a role, there's a task, there's politeness. Run it and look at what comes back. Odds are you'll get text that would suit any company on earth.

You are an experienced marketer. Write an email to our customers about the launch of our new product. Make the text professional, modern and engaging.

What to look for. Is there a single claim in that answer you couldn't move into another company's email untouched? Usually not. Symptom named: filler. Diagnosis, by our order: context.

Step 2. One edit — context only

Same task, same tone, same role. We change exactly one thing: we add facts. Role untouched, format untouched — so we can honestly see what context alone buys.

You are an experienced marketer. Write an email to our customers about the launch of our new product.
Make the text professional, modern and engaging.

CONTEXT:
- Product: a shift scheduler for coffee shops with 3-15 staff.
- Readers: coffee shop owners who have used our inventory app for six months.
  They trust us, but they were not looking for a new button.
- What is new: shifts are now built automatically, taking staff time-off
  requests into account. Before, the owner assembled the rota in a spreadsheet.
- Honest limitation: single location only, we do not support chains yet.
- Price: included in the current plan, no extra charge.
- What the reader must do: switch on the Shifts section in their account.

What to look for. The answer got specific — and is probably still long and still opens with a preamble. That's fine: we treated context only. Note that "professional, modern and engaging" survived untouched as an unverifiable requirement, and did nothing.

Step 3. Another edit — task and format

Now we fix length and shape. We drop the role entirely, to test the hypothesis that it contributes nothing. And we replace "engaging" with something checkable.

Write an email to customers announcing a new feature.

CONTEXT:
- Product: a shift scheduler for coffee shops with 3-15 staff.
- Readers: coffee shop owners who have used our inventory app for six months.
  They trust us, but they were not looking for a new button.
- What is new: shifts are built automatically, taking staff time-off requests
  into account. Before, the owner assembled the rota in a spreadsheet.
- Honest limitation: single location only, we do not support chains yet.
- Price: included in the current plan, no extra charge.
- Reader action: switch on the Shifts section in their account.

FORMAT:
- Subject line: 45 characters max. Banned words: revolutionary, unique, innovative.
- Body: 120 words maximum.
- Structure: line one - what changed; line two - what it saves;
  then the limitation stated plainly; one action at the end.
- No preamble, no "we are excited to announce", no farewell paragraph.

Then, on a separate line: three reasons this email might go unopened or deleted.

What to look for. Compare all three answers. You have just run a proper debugging session: symptom named, hypothesis raised, one edit made, results compared. You also ran a small experiment on role — compare the voice of answers two and three and decide for yourself whether "you are an experienced marketer" earned the place every course gives it.

Step 4. The diagnosis drill

The hardest skill is naming a symptom on someone else's work. Here the model invents a case for you and grades your diagnosis strictly. There will be no automatic "100% correct."

Examine me on prompt diagnosis. Rules:

- You give me ONE case: the task, the full prompt, and the model's bad output.
  Invent the case yourself: realistic, from office work. Write the bad output
  yourself too - exactly as bad as it would really be.
- I name the symptom in one term and say what I would change FIRST.
- You grade strictly: is the symptom right, is the hypothesis right,
  which hypothesis would have been stronger than mine and why.
  If I propose changing several things at once, call that out separately.
- Do not agree out of politeness. If I am wrong, say so plainly.
- Then the next case, harder. Five cases in total.

Start with the first case. Do not explain theory up front.

What a prompt cannot fix

Half of debugging is realising early that the prompt isn't the problem. Otherwise you polish wording in a layer where nothing is broken.

• Missing data. No phrasing retrieves a fact the model was never given. If you need the numbers from your spreadsheet, paste them; don't beg for them.
• The task isn't solvable with text. "Calculate exactly", "check the current website", "guarantee" — that's not about wording, that's about tools. Here you cross into AI agent territory.
• No definition of "good". If you can't say why answer A beats answer B, you aren't debugging — you're shuffling variants until you get tired. The criterion is the part of the prompt that lives in your head, and it needs writing down too.
• Wrong model. The same task behaves differently across them — see our comparison of ChatGPT, Claude and Gemini. Before you edit a prompt twenty times, try the same prompt on another model: that's one edit, not twenty.

A version log: boring, and decisive

Start a file. Three columns: what the prompt said, what you changed, what happened to the answer. One line per debugging lap.

It sounds like bureaucracy. It's the only thing that turns your runs into knowledge. A month later you'll open that file and see that "sample output instead of a format description" worked eleven times out of twelve, while "you are a world-class expert" scored zero. That's your own statistics, and it beats any list of 500 ready-made prompts. Treat our prompt examples as raw material; the log is what turns raw material into your tool.

Side effect: in a month you have a portfolio. Not a certificate that 698,444 other people also hold, but a dozen dissected cases with before and after. In an interview those are different weight classes.

How to test a course — including ours

Our audit boils down to four questions. Ask them of any training.

1. Where will I run the prompt? If the answer is "another tab, separate subscription", the course never sees your work and cannot dissect it. See Vanderbilt and its ChatGPT+ requirement.
2. Who grades my prompt? A keyword autograder will hand you "100% correct" and zero information. That is the Shinysheep case exactly.
3. Is there a lesson where a prompt fails? Open the syllabus and look. If there isn't one, the course is about a formula.
4. When was the content actually updated? Not by the date on the card — by reviews from the last month.

Honest notes on our data. The share of negative reviews (≤3.5★) on Udemy is 9.61% for Generative AI for Beginners and 10.36% for the Complete AI Guide; for Prompt and Context Engineering 101 (the worst rating in our sample, 4.31) it's ≥4.00%. On Coursera it's 1.5–3.5%. Meaning the overwhelming majority of students are satisfied, and we deliberately read the minority. Not to prove the courses are bad: a happy student writes "great course", while an unhappy one names the exact lesson that was missing. Second caveat: Coursera's star filter runs client-side, so the quotes we could reach come from the default page any visitor sees. We didn't fish them out of a deep 1★ filter — but we also can't claim we saw every review.

And a caveat about us. Our sandbox has a hard daily cap on runs. Which means the method above matters more than the button. The button lets you see the difference; the method lets you fix prompts where there is no button — in your own work chat.

The takeaway

The prompt formula is what fits on a slide, which is why it's sold to millions. Debugging doesn't fit on a slide, can't be checked without a live model inside the lesson, and so it's sold almost nowhere — while students ask for it verbatim, review after review. The hole in the market sits exactly there, and it's also the fastest way to get better than most people holding a certificate.

Remember the four steps: symptom → diagnosis → one edit → comparison. And the order of hypotheses: context, task, format, role. Start with the basics in what a prompt is; see what the market for this "profession" turned into in prompt engineer: what it pays and whether it still exists; learn to catch the model inventing things in AI hallucinations. And if you want it systematically, with failures dissected on purpose, there's our prompt engineering course.