2608.07364-Curriculum as Code: An AI-Assisted Architecture for Instructional Design in STEM Education

Introduction to the show: ident: Paper Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Next we'll be talking about the paper "Curriculum as Code: An AI-Assisted Architecture for Instructional Design in STEM Education".

Jane: The paper was written by Henrique Mohallem Paiva from Universidade Federal de Sao Paulo and Institute of Technology and Leadership.

Tom: Stay tuned as we take you through the paper and discuss its implications.

Title and Authors: Tom: So we finally get to the paper we've been teasing. It comes from Henrique Mohallem Paiva, a senior member of the IEEE. He works in Brazil, split between the federal university in São Paulo and a private technology institute called Inteli.

Jane: And that phrase in its title sets up the whole philosophy. Curriculum as code means you write your slides in LaTeX, you generate your figures through Python scripts, and you keep everything as plain text files you can version and compile. No more wrestling with a presentation editor.

Lu: Honestly, that framing is native to engineering faculty. They already live in a world of source files, compilers, and version control. So authoring a course that way isn't asking them to learn a new mental model. It's applying the one they already trust.

Tom: Right, and once the curriculum is code, you can build automation around it. An eye can write chunks of that code, and the instructor can review the result the way they'd review a colleague's contribution to a shared repository. That's the central bet the paper makes.

Meng: I also like that the title says eye-assisted rather than eye-generated. That one word tells you the human stays in charge. The machine drafts, the professor owns the final material.

Jane: Exactly. And the paper spends a full academic year testing whether that assisted workflow holds up in a project-based learning environment. That's about the most demanding case you can pick, because every class runs a different project and the theory has to anchor to each one.

Lalam: That's the bigger story. Plenty of people can get an eye to write generic content. Getting it to render complex math correctly inside an institution's visual identity, while keeping a specific instructor's teaching style, is a completely different league of problem.

Jane: And that's why this architecture matters beyond the classroom. If you can formalize the invisible judgment a professor uses when designing a lesson, the same structure could apply to training materials and technical documentation, anywhere accuracy and consistency are non-negotiable.

Tom: So the title promises a structured workflow that turns prompt engineering into a repeatable process. The big question is whether the evidence supports that promise. Now we should look at what the paper's abstract says about the year-long test.

Summary: Jane: So we've set up the promise, and the abstract delivers the verdict. The author built a six-phase workflow — context injection, pedagogical calibration, technical calibration, structural planning, iterative implementation, and review — and ran it for an entire academic year. The whole design is about discipline: what the model sees, when it sees it, and how the output gets checked.

Tom: Six phases sounds heavy, but the logic is straightforward. Compress the source material so the model's attention stays focused. Show it examples of the instructor's style. Lock in the institutional formatting rules. Plan the lesson before generating any code. Then implement section by section, and finally review with both an automated agent and a human.

Lu: The deployment was serious. The first-year common core spans four modules, each with six classes running different projects. That's twenty-four distinct project contexts just in that first year, plus four advanced modules in the second and third years.

Meng: The workload number jumps out at me. Building one customized deck used to run about eight hours of manual work. With the pipeline, the human time dropped to roughly two hours per lesson. That's a seventy-five percent cut.

Jane: But those two hours are still genuine teaching work. The author is careful to say the saved time isn't spent idly. The instructor reviews the structural plan, checks pacing, and does the final pedagogical pass. What got automated is the LaTeX coding and the Python figure generation.

Tom: And the student evaluations stayed high. Across more than six hundred voluntary responses, ratings ran from 8 point 5 to 9 point 9 out of ten. A couple of modules are still being taught this term, so their numbers are pending, which is refreshingly honest.

Lalam: What convinces me is the scale. Twenty-eight project contexts, eight modules, six different professors delivering the material, and the architecture held together. That's field evidence, not a demo.

Lu: The peer review part matters too. Two independent professors checked the first-year materials before they reached the classroom. So the quality gate wasn't just the author's own opinion.

Tom: And the strongest claim is that no conceptual or mathematical hallucinations appeared across all of those contexts. That doesn't happen by accident. It comes from the workflow design, which is exactly what the paper proposes as an improvement over business as usual.

Improvements: Tom: We've seen the results, so now the interesting question. What does the paper say we should actually do differently? The central argument is that the structure of the workflow matters more than the wording of the prompts.

Jane: That's a direct challenge to the prompt-engineering trend. The author observed that the exact phrasing had only a secondary impact compared to the architecture. Even the model choice fell into that category — Gemini handled generation, DeepSeek did the independent review, and the pipeline still carried the weight.

Lu: The design choices all serve one goal. Phase one deliberately compresses the full project charter into a short text summary, so the model's context window never floods. And phase five generates one section at a time rather than the whole deck, which basically eliminates token exhaustion.

Meng: There's also the discipline of keeping the interface purely text-based. Markdown and source code only. That avoids the formatting glitches you get when a model tries to emit rich text or document files directly.

Tom: And the institutional layer deserves attention. A custom Beamer class with the university's colors and fonts gets injected during calibration, so every slide comes out visually consistent without anyone touching the layout. That alone saves hours of fiddling.

Jane: The bilingual work shows exactly why that pays off. They generated English versions for exchange students, and the formatting held perfectly. Change the language in a WYSIWYG tool and your text boxes overflow. In LaTeX, the text reflows inside the template and the look stays intact.

Lalam: For me, the most important improvement is the capture of tacit knowledge. The calibration phase feeds the model examples of the instructor's previous materials, so the output retains their teaching signature. The sequencing and emphasis, the way they connect theory to practice.

Tom: And because that knowledge becomes explicit rules, other professors can run the pipeline and get the same quality. That's why six different faculty members could teach from these decks. Which naturally raises the question of what problem originally motivated this design, and that's exactly what the first page lays out.

First Page: Jane: So we've talked about what the paper proposes, but the opening pages show why it was needed. Active learning, particularly project-based learning, has shifted the instructor's role from transmitting knowledge to facilitating learning. That demands materials customized to each project and designed to build student autonomy.

Tom: But the author points out that the tools haven't kept pace. Presentation software handles general documents well enough, yet it's genuinely weak on complex mathematical notation and algorithmic pseudocode. That's where instructor hours evaporate.

Lu: And he cites a specific pain point behind that. Instructors end up spending enormous effort manually adjusting formatting and keeping slides consistent, which steals time away from actual instructional design. The tooling fights them.

Meng: The literature gap is just as clear. Most generative eye research in education targets the student side. Intelligent tutoring systems and personalized learning paths get the attention, while the instructor-facing side of producing rigorous materials stays underexplored.

Tom: The three research questions capture that gap precisely. How do you translate tacit teaching knowledge into explicit, replicable rules? How do code-based authoring tools combined with eye reduce hallucinations and ensure reproducibility? And what's the measured impact on preparation time and institutional visual identity?

Jane: I appreciate that the third question demands real-world measurement. It's not asking whether an eye can write a slide. It's asking whether a professor actually saves hours while the institution's look stays consistent across an entire curriculum.

Lalam: And the intro makes a clever argument for the setting. The PBL environment is the hardest possible case because every lesson has to anchor theory to a different project. If the architecture works there, the author argues, traditional lecture courses become the comparatively easy case.

Tom: So the first page sets a genuinely high bar. The rest of the paper claims the architecture clears it. We should close by weighing whether that claim actually holds.

Conclusion: Tom: So let's pull it together. The paper gives us a six-phase architecture for eye-assisted instructional design, grounded in the idea that curriculum should be code. Teaching materials live as source files, and the compilation and version control that software engineers take for granted apply directly to them.

Jane: And it backs that idea with a year of field data. Eight modules, twenty-eight project contexts, six professors delivering the materials, and a seventy-five percent cut in preparation time. The numbers are specific, which makes them checkable.

Lu: The quality held up through all of it. Student ratings between 8 point 5 and 9 point 9, peer reviewers reporting no conceptual or mathematical errors, and materials that transferred cleanly across instructors and even across languages. That last part is remarkable.

Meng: The lasting contribution is the role shift, I think. The professor stops being a manual formatter and becomes an instructional architect. The eye handles the laborious coding, the human handles the design decisions.

Tom: And that role shift changes what institutions can do. When teaching knowledge becomes explicit rules in a pipeline, a department isn't dependent on one person's private expertise anymore. The materials carry the craft forward.

Lalam: And the bigger picture points to a future where course materials are built like software. Stored under version control and validated by automated agents, then tailored to individual learners. The architecture in this paper is a first step toward that.

Jane: The study has honest limits, though. One institution, one person operating the pipeline. The author says so himself, which means the real test is multisite work with different faculty running the whole thing.

Lu: But even with those limits, the core claims stand on their own. The workload dropped dramatically and the hallucinations stayed out of the final materials. The visual and pedagogical consistency held steady across everything.

Tom: And the paper sketches where it goes next. Agent-based orchestration through APIs, a full CI/CD pipeline for educational content. Those are rich threads for someone to pull.

Jane: That's a good place to leave this one. It answered its research questions and pointed at the next ones. We'll pick up a fresh paper next time.

Tom: See you then.