← All articles AI · Instructional Design

The Course Production Pipeline: How I Combine Instructional Design and AI Without Losing Quality

9 Jul 2026 8 min read

Most conversations about AI in education are stuck on the wrong question: "Can AI create a course?"

Yes, it can. In about twenty minutes. And that's exactly the problem — because what it creates in twenty minutes is content, not learning. The real question worth answering is: where does AI belong inside a serious course production process, and where does it not?

After building AI-assisted production pipelines for learning content, I've landed on an answer that I'll lay out in full here. It comes down to a hard boundary: humans design the architecture, AI produces inside it.

Why "AI-generated courses" fail

When you ask a language model to create a course on any topic, it produces something that looks remarkably like a course: modules, lessons, quizzes, even learning objectives. The structure is grammatical, so to speak.

But look closer and you'll find three failures, every time:

1. Objectives that describe topics, not behaviors. "Understand the fundamentals of marketing" is not a learning outcome — it's a table of contents entry. You can't observe "understanding," you can't practice it, and you can't verify it happened.

2. No designed forgetting-resistance. Human memory doesn't respond to exposure; it responds to retrieval, spacing, and application. Generic AI output arranges information logically — but logical arrangement is for reference material, not for learning. A well-designed course sequences practice, not just information.

3. Uniform difficulty. Real learners arrive with uneven prior knowledge and get stuck at specific, predictable points. Designing for those friction points is the craft of instructional design. AI can't predict them because they aren't in the text — they're in the learners.

None of this means AI doesn't belong in course production. It means AI can't be the architect.

The pipeline: five stages, one boundary

Here's the structure I use. The boundary between human and machine work sits between stages 2 and 3.

Stage 1 — Outcome mapping (human)

Before anything else, decompose the course into atomic units, where each unit maps to exactly one behavioral outcome. The test I use: the outcome must fit in one sentence with one verb, and it must describe something the learner does, not knows.

Weak: "Learn about pricing strategies"
Strong: "Price a new product using value-based anchoring"

This stage is slow, and it should be. It's where all the quality lives.

Stage 2 — Constraint specification (human)

Turn each atomic unit into a production spec: the outcome, the audience and their prior knowledge, the one practice activity that exercises the outcome, the checkpoint that evidences it, tone, length, and format constraints.

This is the step almost everyone skips, and it's the step that changes everything. A language model given a topic will invent a structure. A language model given a spec will fill a structure. The difference in output quality is not incremental — it's categorical.

Stage 3 — Constrained generation (AI)

Now, and only now, AI enters — and it's genuinely excellent here:

For larger projects I run this as a multi-agent system: separate agents for drafting, for reviewing against the spec, and for consistency checking across units. Each agent has one job and a narrow definition of success — which is, not coincidentally, the same atomic principle the course itself is built on.

Stage 4 — Human review at the friction points (human)

Not a full rewrite — a targeted review. I check the three places AI output reliably fails: the practice activities (are they actually doable and actually aligned to the outcome?), the transitions between units (does the sequence build?), and the examples (are they real-world plausible or plausible-sounding?).

Stage 5 — Instrument and iterate (human + data)

Ship, then watch where learners stall, quit, or fail checkpoints. Those friction points feed back into Stage 1 of the next revision. The pipeline is a loop, not a line.

What this changes in practice

The honest pitch for this approach isn't "AI makes courses cheaper." It's this: the pipeline moves human effort to where it's irreplaceable.

In a traditional process, a designer spends most of their time on production mechanics — writing, formatting, generating variations. Architecture gets whatever hours are left. This pipeline inverts that: production is largely automated, so the designer's time concentrates on outcome mapping, constraint design, and friction-point review — the work that actually determines whether anyone learns anything.

Faster production is real (in my experience, dramatically so). But speed is the side effect. The point is that quality stops depending on heroic effort and starts depending on system design — which means it survives scale, team changes, and deadline pressure.

Where to start

If you're building learning products and want to move toward this model, don't start by buying AI tools. Start here:

1. Take one existing course and rewrite every module objective as a one-verb behavioral outcome. Most won't survive the rewrite. That's the finding.

2. Pick the three units where learners struggle most and write full constraint specs for them.

3. Regenerate just those three units with AI working inside your specs. Compare against the originals — not for polish, but for whether the practice activities changed.

That comparison will tell you more about AI's real role in learning design than any tool demo.


I design learning systems and AI-assisted course production pipelines. If you're building courses or educational products and wrestling with where AI fits, my messages are open — I'm always happy to talk shop.