AI Engineering · Curriculum Generation · EdTech
How we built the AI-powered course generation engine behind our Full-Stack EdTech Platform, and why the real engineering work started after the model finished writing.
This generate-then-validate architecture powers the AI course generator inside our Full-Stack EdTech Platform, alongside pgvector recommendations and a full DDD microservices backend.
View the Case Study"Let AI generate the courses" sounds simple. Feed a topic to a model, get back a structured curriculum, lessons, modules, sequencing, the works. It wasn't simple.
Every demo of this kind looks impressive in the first five minutes. Type a prompt, watch a full course outline appear. Then someone opens the curriculum in detail and finds this:
Every individual lesson is well written. The problem is the order, you can't teach agent-building before you've taught what a language model even is. Technically valid content, pedagogically broken structure. That gap is exactly where a good AI demo stops and a production education product has to begin.
The instinctive fix is to keep adding rules to the prompt: respect prerequisites, avoid duplicate concepts, keep difficulty progressive, avoid circular dependencies. It helps, for a while. But it rests on a false assumption, that a large language model, given enough instructions, will reliably obey structural rules every single time.
It won't, not because the model is bad, but because it's fundamentally probabilistic. It generates what's likely to be a good curriculum; it doesn't verify that it is one. No amount of prompt length changes that math. Somewhere around lesson 30 of a 60-lesson course, a dependency gets duplicated or a prerequisite gets skipped, and nobody notices until a learner hits a wall mid-course.
A prompt is a request. It has never been a guarantee. Treating one as the other is how structural bugs ship straight to learners.
For a consumer chatbot, an occasional ordering slip is a shrug. For an education platform whose entire value proposition is a coherent learning path, it's a broken product, and it doesn't show up in a demo, it shows up three weeks later in a support ticket from a paying learner who's stuck.
The architecture decision that solved this was simple to state and non-trivial to build: stop treating the AI's first output as the final output.
We split the system into two distinct responsibilities: the model generates, deterministic software validates every relationship it creates before anything reaches a learner. It's the same discipline enterprise software has always applied to user input and API payloads, we simply stopped treating AI output as an exception to that rule.
The generation side is genuinely probabilistic and stays that way, that's what makes it useful. The validation side is intentionally boring: no model calls, no sampling, no "mostly correct." A curriculum either satisfies the graph constraints or it doesn't, and that's a question ordinary code can answer in milliseconds.
System Architecture
The AI proposes; deterministic checks decide. Only flagged issues get sent back for repair, never a full regeneration.
This is the same "optimistic concurrency" instinct distributed systems use: let the fast, hopeful path run, then check its result against hard invariants before committing it. The model isn't asked to be perfect. It's asked to produce a candidate that a separate, deterministic gate can verify.
A curriculum isn't really a list of lessons, it's a directed graph. Lessons depend on other lessons, concepts build on prior concepts, modules connect (or should connect) into a coherent path. Treat it as a graph, and most structural problems stop being things you hope an AI notices, and become things you can check mathematically.
"Build AI Agents" placed at lesson 30, but its stated prerequisite, "LangChain Basics," at lesson 45. Model every lesson as a node and every prerequisite as a directed edge, then run a topological sort (Kahn's algorithm) over the graph: if a lesson's prerequisite can't be scheduled before it in any valid linear order, the sort fails outright and names the exact offending pair. No model call required.
Topological sort · O(V+E)"Vector Search" required "Embeddings." "Embeddings" required "Vector Search." A → B and B → A. A depth-first traversal that tracks the current recursion stack flags any back-edge the moment it's created, which is exactly how a topological sort fails in the first place, so in our implementation the two checks share one pass over the graph.
DFS back-edge detection"Prompt Engineering" taught twice, at the same depth, at lessons 2 and 9, the course quietly repeating itself instead of moving the learner forward. Each lesson's core concept gets embedded, and any pair with cosine similarity above a fixed threshold (~0.92) is flagged for review rather than silently allowed through. Deterministic threshold, probabilistic embedding, used only for comparison, never for the pass/fail decision itself.
Embedding similarity, fixed thresholdA clean Python → LangChain → Agents track generated alongside an unrelated Marketing Strategy → Customer Personas track, with no bridge between them. A connected-components pass over the prerequisite graph surfaces any lesson cluster that isn't reachable from the course's stated entry point, for human review, rather than letting it ship silently.
Connected componentsIt's the obvious-sounding alternative, and it's the one we deliberately avoided. An "LLM-as-judge" pass over the same curriculum is still a probabilistic process, it can miss the exact same class of error the generator missed, for the exact same underlying reason. You haven't added verification, you've added a second opinion with the same blind spots, at roughly the same latency and cost as the first call.
Graph checks don't have that failure mode because they're not making a judgment call, they're evaluating a well-defined property. A topological sort either succeeds or it doesn't; there's no confidence score to argue with. And the performance difference isn't cosmetic: a full graph validation pass over a 60-lesson course runs in single-digit milliseconds, versus the multi-second round trip of even one additional LLM call, which matters when validation has to run after every repair iteration, not just once.
When validation finds a problem, the instinct is to regenerate the whole curriculum and hope it comes out better. We don't.
Full regeneration is slow, expensive, and just as likely to introduce a new structural problem while fixing the old one, you're re-rolling the dice on every lesson to fix three of them. Instead, the validator emits a precise, scoped report, and only that report goes back to the model:
That constraint changes the nature of the AI call entirely, from "generate a good curriculum" (hard to verify) to "resolve three specific, well-defined issues" (easy to verify). The result converges on a correct output in one or two repair passes, rather than an open-ended cycle of regeneration and hope.
This generate-then-validate pipeline is the course-authoring engine behind our Full-Stack EdTech Platform, sitting alongside the pgvector-based recommendation service and the Razorpay payment flow in the same DDD microservices architecture.
We built this for an education platform, but the underlying pattern isn't education-specific, it's the pattern every serious enterprise AI system eventually needs. Anywhere AI generates something with internal structure, a compliance document, a software architecture, a training roadmap, a set of business rules, the same choice applies: trust the model's first pass, or build a system that verifies it.
Enterprise software has never trusted user input, API payloads, or database writes without validation. There's no reason AI-generated output should be the exception. The teams getting real production value out of AI right now aren't the ones with the cleverest prompts, they're the ones who stopped asking the model to be right, and started building systems that make sure it is.
Topics