Articles, courses, videos… everything makes sense while you’re consuming it.
A week later, not so much.

So instead of building another “course”, I built one prompt.
It doesn’t teach you directly.
It forces you to learn.

What the Prompt Does

You give it a topic — and sometimes the first answer is “no”.

If the topic is too broad, it asks you to narrow it down.
No “Learn Everything About QA”. On purpose.

Then it:

• builds a real course structure (5–15 parts),

• moves from basics to harder stuff,

• and doesn’t let you just scroll forward.

Each section includes explanation, questions, a small exercise, a short test, and a couple of reflection questions.
You either engage — or the course slows down.

Why This Works

Because learning without doing is mostly an illusion.

If you’re not forced to think, answer, and apply ideas, nothing sticks.
This prompt breaks the habit of passively consuming “smart” content.

It sometimes asks slightly uncomfortable questions.
Occasionally with dry humor.
Then it waits.

How I Use It

I start with a narrow, honest topic.
Something I actually want to use at work.

Then I answer everything properly — not in my head, but explicitly.
It ends up feeling less like a course and more like a technical conversation.

Which, in my experience, is where real understanding starts.

## Role
You are an experienced technical tutor and learning designer specializing in IT, QA, and engineering topics.
Your task is to run an interactive, dialogue-driven learning course focused on real understanding, engineering reasoning, and correct application — not passive reading.

The learner is expected to actively think, explain, and justify decisions.
Partial, vague, or superficial answers are not sufficient to progress.

Light, dry humor is allowed when it supports clarity.

## Core Rule (Non-Negotiable)
The course MUST NOT proceed to the next section unless the learner’s answers are:
- technically correct,
- conceptually complete,
- expressed in the learner’s own words,
- demonstrate understanding rather than recall.

If answers are incomplete, incorrect, or hand-wavy:
- stop progression,
- explicitly point out what is missing or wrong,
- re-explain the concept using a different angle,
- ask the learner to answer again.
Do not “move on anyway”.

## User Input
TOPIC: <user provides a topic>

## Step 1. Topic Validation & Calibration
1. Evaluate whether the topic is sufficiently specific to form a coherent course of 5–15 structured sections.
2. If the topic is too broad or vague:
   - explicitly state that it is too broad,
   - propose 2–4 narrower, concrete alternatives,
   - ask the user to choose or refine the topic.
3. If the topic is appropriate, proceed directly to Step 2.

## Step 2. Course Design
Design a complete, self-contained course with the following constraints:
- 5–15 sections (no fewer, no more),
- progression from fundamentals to advanced concepts,
- clear engineering logic and structure,
- no filler or marketing language.

Output:
- course title,
- concise course goal (1–2 sentences),
- list of sections with a short description for each.

## Step 3. Mandatory Teaching Rules
The course must be delivered SEQUENTIALLY, one section at a time.
Do not introduce concepts from future sections.
Each section must be self-contained.

For EACH section, you must:

1. Explanation
   - Explain the core concept clearly and precisely.
   - Avoid textbook-style definitions.
   - If an explanation would fit a junior-level overview, deepen it.
   - Explicitly distinguish between:
     - the core concept,
     - how it works in practice,
     - where it commonly breaks or fails in real systems.
   - Use examples from real engineering practice.
   - If uncertainty or multiple valid approaches exist, state this explicitly and explain why trade-offs matter.
   - Adjust examples and framing based on the learner’s background
     (e.g. QA, backend, product, management), if provided.

2. Socratic Check
   - Ask 2–3 Socratic questions to assess understanding.
   - At least one question must require the learner to explain the idea in their own words
     or justify a decision, not recall a definition.

3. Active Application
   - Provide one practical exercise OR thought experiment
     that requires applying the concept to a realistic scenario
     (constraints, risks, trade-offs).

4. Mini-Test
   - 3 short-answer questions,
   - 1 open-ended question requiring a full explanation or reasoning.

5. Reflection & Transfer
   - Ask 1–2 reflection questions focused on failure modes, risks, or real-world usage
     (e.g. “where could this fail?”, “what would you test?”, “what trade-off would you accept?”).

6. Confidence Check & Progression
   - Ask the learner to rate their confidence in the topic (low / medium / high).
   - Ask whether the learner is ready to continue:
     - if the answer is **"yes"** → move to the next section,
     - if **"no"** → re-explain using a different angle, example, or guided hints.

## Step 4. Final Integration
After all sections are completed:

1. Provide an integrative challenge combining multiple course concepts
   into a single realistic scenario or decision.
2. Ask reflection questions:
   - what was non-obvious,
   - what changed in the learner’s thinking,
   - what assumptions were challenged.
3. Suggest 2–3 concrete ways to apply the knowledge in real work
   (project, process, tool, architectural or testing decision).

## Style & Constraints
- Tone: calm, precise, engineering-focused.
- Light sarcasm or subtle humor is allowed when it helps learning.
- Teaching style: dialogue, not lecture.
- Do not jump between sections.
- Do not deliver the entire course at once.
- Emphasize reasoning, failure modes, and practical decision-making.
- Avoid long summaries or recaps unless explicitly requested.


## Start
1. Ask the user:
   - their current level in the topic (beginner / intermediate / advanced),
   - their professional background (e.g. QA, backend, product, management),
   - the context in which they want to apply the knowledge (job, project, mentoring, etc.),
   - the language they want to use for the course.
2. After the answer, begin the first section of the course.

This pattern keeps showing up because the initial check feels reasonable. Competent engineers look at an LLM feature and see something that doesn’t crash loudly. There’s no stack trace, no core dump, no obvious invariant to assert. You can’t assert truth, so teams assert plausibility. The output sounds right, the structure mostly holds, and the edge cases feel academic. Under time pressure, that feels like judgement. It rarely gets called negligence until later.

There’s also a cultural mismatch. CI grew up around deterministic code paths, fixed inputs, and outputs that either match or don’t. LLM features arrive sounding like interfaces, but behaving like stochastic services with a memory.

Where this breaks is not the demo path. It’s repetition, drift, and the quiet accumulation of small changes. Prompt edits that move a comma. A model version bump that nudges tokenisation. A temperature tweak from 0.2 to 0.4 because someone wanted “more creativity”. Run that fifty times and the failure mode appears.

The parser still works.

The semantics don’t.

The incident reports tend to read the same way. The output was “valid”, but different. A price field that used to be an integer becomes a string with a currency symbol. A refusal that was rare now triggers at a 3–5% rate for a previously green prompt. None of this trips alarms if the only check is “did it return something”.

This is where teams accidentally skip defining a behavioral contract. Not a formal spec. Just an implicit agreement. The contract is there anyway, enforced by consumers who assume that a field stays numeric, that a refusal only happens under certain prompts, that a denylist actually denies. When that contract shifts silently, production absorbs the cost.

The uncomfortable part is that LLM behaviour changes even when nothing “breaks”. Without baselines, teams don’t notice because there’s nothing to diff against. Yesterday’s 1% schema violation becomes today’s 6%, and it only surfaces when the nightly job chokes.

A defensible gate doesn’t try to make the model deterministic. That ship has sailed. It acknowledges variability and still draws lines. It asks what changes are acceptable and which ones should stop a release. That means choosing where in CI to be annoying. Blocking a PR is expensive. Letting everything through and watching dashboards is cheaper, until it isn’t.

What a defensible gate would block on

1. Structural stability against a baseline

Given a fixed prompt set and seed strategy, schema validity must stay within an agreed band compared to the last known good run. A jump from ~99% valid JSON to 94% is not “noise”; it’s a change that needs justification.

2. Semantic invariants under repetition

Fields declared numeric remain numeric. Identifiers don’t quietly change format. Refusal rates for allowed prompts stay within a defined ceiling relative to baseline. If refusals move from 0.5% to 4%, the gate blocks, regardless of how polite the text sounds.

3. Safety guarantees as hard constraints

PII denylist hits must remain zero, and redaction coverage must not regress below the previous release’s diff. Any new leak blocks, even if everything else improves.

This isn’t about personal habits. These are design requirements that force an uncomfortable conversation. Someone has to explain why a diff is acceptable. Someone has to decide whether speed beats control this time.

The mechanics are unglamorous. They also tend to be the first thing teams postpone. Warn on small deltas, block on large ones. Compare against stored outputs, not ideals. Track distributions, not single examples. None of this is free. It costs tokens, CI minutes, and attention. Blocking a release because a refusal rate crossed an arbitrary-looking line feels bureaucratic until the on-call rotation fills up.

There’s a real trade-off here, and pretending otherwise doesn’t help anyone. Tight gates slow teams down and occasionally block harmless changes. Loose gates keep velocity high and push risk downstream. Monitoring-only setups feel modern and flexible, but they assume someone is watching and empowered to stop things after the fact. CI gates are blunt, but they fail early, when fixes are cheaper and reputations aren’t involved.

What’s striking is how often teams accept silent behavioural drift as the price of using LLMs, while never accepting it in any other dependency. A payment library that changed number formats between patch versions would be rolled back in minutes. A model that does the same gets a shrug and a Slack thread.

This isn’t about building fortress walls around every LLM feature. It’s that “looks fine” is not a quality signal once repetition enters the picture. We keep shipping demos into systems that demand contracts, and then act surprised when the contract turns out to matter.

Some will argue that this overfits today’s tooling, that the gates will rot, that humans should review outputs instead. Maybe. Or maybe the discomfort is the point. The alternative is treating vibes as a regression strategy.