The problem
Technical courses decay faster than they can be rewritten.
A cybersecurity course written in 2023 describes a threat landscape that no longer exists. A data visualization course built around last year's tooling teaches students to use software they will not encounter in the field. Meanwhile the traditional fix — rebuilding a course from scratch every few semesters — is slow, expensive, and produces a course that starts aging the day it launches.
The deeper problem is not writing the content. It is that most online courses are authored inside the learning management system, one page at a time, in a rich-text editor. That means:
- There is no source of truth outside the LMS, so nothing can be diffed, reviewed, or reused.
- Updating twenty lessons means twenty manual edits, so nobody updates twenty lessons.
- Content, assessment, and media drift apart until quiz questions test material the lessons never taught.
- Multimedia is a one-shot expense, so it gets made once and then quietly goes out of date.
I approached this as an engineering problem rather than a writing problem. Instead of authoring courses, I built the system that authors them.
What I built
A version-controlled course development toolkit where every artifact of a course lives in local files, and a set of scripts pushes those files into the LMS. The LMS is a rendering target, not the workspace.
data/<term>/<course>/
weekN_narration.json ← audio scripts
weekN_interactive_learning.html ← lesson template
weekN_audio/ ← generated speech
weekN_audio_urls.json ← uploaded media manifest
weekN_interactive_learning_rendered.html ← what ships
quiz_revamp.json, rubrics_revamp.json ← assessment as data
audit.md ← gap analysis for the week
Because every lesson, quiz, rubric, and narration script is a file, a course becomes something you can grep, diff, review, and regenerate. Updating a definition across twelve weeks is a search and replace plus a push, not a two-day clickthrough.
The authoring pipeline
Each weekly lesson runs through four deterministic stages:
generate audio → upload media → render lesson → publish to LMS
(idempotent upsert)
Narration is written as structured JSON (one script per lesson section), synthesized to speech, uploaded, and then baked into the lesson HTML at placeholder tokens. The publish step matches on page identity and updates in place, so re-running the pipeline is safe. Nothing is ever created twice.
That idempotency is the whole point. When a lesson changes, you rerun the pipeline. When the narration changes, you rerun the pipeline. The cost of a correction drops to near zero, which is what makes continuous currency possible at all.
Lessons students actually work through
The core deliverable is an Interactive Learning page per week, replacing the standard "here are the readings, here is the quiz" module. Each page is built from a repeatable component library hardened over the project:
- Section narration. Every section opens with an audio player so students can listen while reading, walking, or commuting. Voice, pacing, and script are authored deliberately, not auto-read from the page text.
- Roadmap strip. A visual bar of the lesson's sections so students always know where they are and how much is left.
- Think-then-reveal blocks. Questions posed before the answer is available, forcing a commitment before the reveal. This is retrieval practice, and it is the single highest-leverage thing you can add to a reading page.
- Concept cards and taxonomy grids. Abstract frameworks rendered as visual grids with miniature diagrams, so a four-part taxonomy is seen rather than listed.
- Before/after comparisons. The same data shown two ways so students feel the difference instead of being told about it.
- Knowledge checks. Multiple choice, short answer, scenario, and matching questions embedded in the flow of the lesson, not quarantined in a separate quiz.
- Self-rating checklists. Each page closes by reopening its own learning goals as "I can…" statements with explicit criteria.
- Hands-on labs. Where possible the week's exercise uses native tools students already have rather than a third-party website that may be down, redesigned, or paywalled by next term. Reducing external dependencies is a durability decision as much as a pedagogical one.
Across the project this produced 44 interactive lesson pages and roughly 117,000 words of student-facing instruction, with hundreds of reveal-style interactions — one recent lesson carries 44 individual think-then-reveal blocks in a single page.
Every component is inline-styled and sanitizer-safe, which matters more than it sounds. LMS platforms silently strip content they do not like. I documented exactly which constructs survive and which vanish, then rebuilt the fragile ones — diagrams, flowcharts, positioned charts — using techniques that hold up server-side. Validation is done by fetching the published page back from the platform and asserting on what actually arrived, not by trusting a local preview.
AI-generated video, produced as a pipeline
Video is normally the most expensive and most quickly outdated part of a course, which is exactly why it usually gets skipped or recorded once and left to rot.
For the cybersecurity course I produced 67 AI-generated explainer videos totalling just over five hours, averaging 4 minutes 35 seconds each. Short, single-idea, and — critically — reproducible: each video is generated from a script and a programmatic scene definition, so revising a video means editing text and re-rendering, not rebooking a studio.
Each video was then digested into a structured video map: per video, its duration, learning objectives, ordered narrative beats, key terms, which textbook discussion questions it supports, and suggested assessment items.
That map is the connective tissue of the course. It answers questions no traditional course can answer quickly:
- Which videos does this quiz question depend on?
- Is any learning objective taught by no video and no lesson?
- If I replace video 4.2, which quiz items, discussion prompts, and lesson sections need to change with it?
The map also drove an explicit coverage-gap list: content the videos do not carry, which the interactive lessons are then required to teach. Nothing falls between the two.
Verification, not vibes
The part I am most proud of is the quality loop, because it is the part that is usually absent.
Answers are verified before instruction is written. For every quiz and homework item, the correct answer is independently re-derived from source data first. Only then is the lesson drafted. The reasoning is simple: an interactive lesson exists to walk a student to the right answer, so a wrong answer key means the lesson teaches wrong mechanics with great production value. This process caught and corrected real errors in inherited course material.
Every assessment item is traced to instruction. A full audit checked all 120 quiz questions against the lesson text for their week, scoring whether a student who worked the lesson and the videos could actually answer the question, and whether each question's feedback pointed to a section that genuinely covers it. The audit surfaced two hard gaps and two thin spots. All four were fixed and re-verified, ending at 120 of 120 covered with accurate feedback pointers.
Assignments are audited the same way. All 22 non-project assignments, labs, case studies, and discussions were checked against the frameworks their prompts and rubrics demand. Result: 21 of 22 fully supported; one gap found — a case study asked students to explain a mechanism the lessons named but never explained — and closed.
Rubric integrity is preserved on update. Rubric updates copy existing criterion and rating identifiers forward, because regenerating them orphans student scores already recorded against them. This is the kind of failure that is invisible until it has quietly destroyed a semester of grades.
Assessment is treated as data. 36 rubrics and 48 quiz definitions live as JSON in version control, so a rubric can be reviewed in a diff before it reaches a student.
Staying current
Currency is designed in rather than scheduled.
- A maintained current-events bank collects recent, real incidents in the field, each annotated with the week it fits and the framework it illustrates, with an explicit instruction to re-verify facts before use and a note flagging which claims are contested — contested claims being their own teachable moment about evidence standards.
- Because lessons are source files, weaving a new incident into week 3 is an edit and a push.
- Because assessment is data, a question that has aged out can be rewritten and rebalanced against coverage targets in the same commit.
- Because video is generated rather than filmed, an out-of-date explainer is a script edit and a re-render.
- Each term's course lives in its own directory, so the next offering starts as a copy of a known-good course rather than a blank shell, and improvements flow forward instead of being re-derived.
Every course revamp begins with a per-week audit file: what exists today, what the assessments actually test, where coverage is skewed, and a concrete keep-rewrite-replace plan. The revamp is executed against that plan, not against intuition.
By the numbers
| Full courses rebuilt or authored | 2 complete, additional offerings in progress |
| Interactive lesson pages shipped | 44 |
| Student-facing instructional text | ~117,000 words |
| Narrated audio segments generated | 404 files across 421 scripted sections |
| Narration written | ~65,000 words, roughly 7 hours of audio |
| AI-generated explainer videos | 67, totalling 5h 07m |
| Rubrics under version control | 36 |
| Quiz definitions under version control | 48 |
| Quiz questions audited against instruction | 120 of 120 covered |
| Assignments audited against instruction | 22, all supported after fixes |
Stack
Python (standard library HTTP client with pagination and token auth), LMS REST API, Google Cloud Text-to-Speech, Remotion for programmatic video, browser-driven automation via Playwright where API tokens were unavailable, Git as source of truth, and JSON as the interchange format for narration, quizzes, rubrics, and media manifests.
One detail worth calling out: partway through, API access to one course expired and could not be reissued quickly. Rather than reverting to manual editing, I rebuilt the write path to drive the platform through an authenticated browser session — including a three-step multipart media upload and CSRF handling — and kept shipping. The pipeline did not change; only its transport did. That is the benefit of keeping the source of truth outside the system you are publishing to.
What transfers
This is a repeatable operating model for any technical curriculum that has to stay current:
- Move the source of truth out of the LMS. Everything else follows from this.
- Make publishing idempotent. If republishing is risky, nobody iterates, and the course freezes.
- Treat assessment as data, not prose in a text box. Then you can audit coverage mechanically.
- Verify the answer key before writing the instruction. Production quality applied to a wrong answer is worse than no production at all.
- Generate media from scripts. Anything you cannot regenerate cheaply is something you will not update.
- Trace every assessment item to the instruction that teaches it, and treat any untraceable item as a defect.
The result is a course that can be corrected in an afternoon, refreshed with this month's real incidents, and handed to the next term intact.