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

arXiv:2608.07364 · cs.AI, cs.CY · Submitted 2026-08-07 · Read on arXiv

Listen

Radio episode about this paper

Transcript

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.

Henrique Mohallem Paiva

Universidade Federal de Sao Paulo · Institute of Technology and Leadership

cs.AI, cs.CY

Submitted: 2026-08-07

Updated: 2026-08-10

Comments: This work has been submitted to the IEEE for possible publication. Copyright may be transferred without notice, after which this version may no longer be accessible

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 57/100

The gist: Author: Henrique Mohallem Paiva, Senior Member, IEEE (Universidade Federal de Sao Paulo / Institute of Technology and Leadership) The paper presents "a six-phase Artificial Intelligence (AI)-assisted

Key concepts

Curriculum as Code
A method where teaching materials are written as plain text files (like LaTeX and Python scripts) instead of using presentation software. This allows version control and compilation, similar to software development, making materials easier to automate and maintain.
Six-phase workflow
The paper's structured process for AI-assisted instructional design: context injection, pedagogical calibration, technical calibration, structural planning, iterative implementation, and review. It ensures the AI stays focused, follows style rules, and produces error-free content.
Tacit knowledge capture
The process of turning a professor's implicit teaching style—like sequencing and emphasis—into explicit rules that the AI can follow. This allows other instructors to replicate the same quality, making expertise transferable.
Project-based learning (PBL)
An educational approach where students learn by working on real projects. The episode notes it's a demanding test for the workflow because each lesson must connect theory to a different project context, requiring highly customized materials.

Terminology

Summary

Author: Henrique Mohallem Paiva, Senior Member, IEEE (Universidade Federal de Sao Paulo / Institute of Technology and Leadership)

The paper presents "a six-phase Artificial Intelligence (AI)-assisted instructional design architecture based on the Curriculum as Code paradigm. It integrates Generative AI with LaTeX and Python to automate the creation of reproducible, visually consistent, and technically precise materials for Science, Technology, Engineering, and Mathematics (STEM) education."

The motivation stems from the intense workload imposed on faculty in active learning environments. As the paper states: "The creation of customized instructional materials, particularly for active learning environments, imposes a heavy workload on faculty. Standard presentation tools lack robust support for complex technical content, while current AI applications often suffer from hallucinations and fail to formalize the instructional authoring process, limiting their utility for rigorous academic design."

The author identifies a critical gap in the literature: "there is little attention given to AI-assisted workflows that can systematically enforce pedagogical coherence, maintain institutional visual identity, and guarantee mathematical and technical reproducibility across an entire curriculum."

The paper investigates three research questions:

  • RQ1: How can an AI-assisted instructional design workflow be structured to effectively translate an instructor's tacit pedagogical knowledge into explicit, replicable rules while preserving pedagogical consistency?

  • RQ2: How does the integration of code-based authoring tools with Generative AI mitigate technical hallucinations and ensure the mathematical and visual reproducibility of STEM instructional materials?

  • RQ3: What is the practical impact of this automated architecture on faculty preparation time and the maintenance of institutional visual identity when deployed in a highly contextualized learning environment?

The architecture is grounded on five interrelated theoretical and technical pillars: active learning methodologies (PBL and Flipped Classroom), the state and limitations of generative AI in education, the Curriculum as Code concept, knowledge elicitation techniques, and Cognitive Load Theory (CLT).

  • Active Learning: The paper notes that the PBL model inherently adds a layer of complexity to instructional design due to the strict requirement of contextualizing theoretical concepts within practical projects. Because the architecture resolved this complex scenario, its application to traditional, lecture-based classes becomes more straightforward.

  • Curriculum as Code: This approach represents instructional materials as versionable, compilable, and reproducible artifacts through the use of programming and markup languages. Slides are written in LaTeX with Beamer, and figures are generated via Python scripts, offering three advantages: mathematical typographic precision, version control, and automatic enforcement of visual consistency.

  • Knowledge Elicitation: The paper draws on Polanyi's tacit-explicit dichotomy and Nonaka's knowledge creation framework, emphasizing that "effective instructional systems must capture not only the declarative knowledge of the domain but also the procedural and conditional knowledge embedded in the instructor's choices regarding sequencing, emphasis, and contextualization."

  • Cognitive Load Theory: The architecture incorporates CLT principles, noting that instructional materials must drastically minimize extraneous load through clear structure, eliminate redundant information, and utilize signaling cues to guide attention.

The proposed solution is a structured six-phase pipeline that replaces ad-hoc prompt engineering with a systematic workflow, drawing an analogy to CI/CD pipelines in software engineering. The six phases are:

  1. Phase 1: Context Injection and Scoping. The pipeline ingests a foundational document (e.g., Project Charter in PBL). The LLM generates a concise three-paragraph summary, using a deliberate forgetting mechanism [that] prevents context window overflow and attention dilution, reducing the likelihood of hallucinations focus loss when generating complex code in later stages.

  2. Phase 2: Pedagogical Calibration. Utilizing few-shot prompting with previously validated teaching materials, the AI is trained on the desired pedagogical style, including constraints on cognitive load limits, time per slide, and anchoring theory to practical applications.

  3. Phase 3: Technical Calibration. The AI is injected with the specific syntax rules, required packages, and custom class calls required by the institution, ensuring adherence to visual identity and typographical standards.

  4. Phase 4: Structural Planning. The AI generates "a comprehensive lesson plan (a structural skeleton) aligned with the predefined learning objectives... The output is strictly a hierarchical outline defining sections, subsections, and the sequence of theoretical blocks and active learning exercises." No code is generated in this phase.

  5. Phase 5: Iterative Implementation. This phase operates as an algorithmic 'while' loop. Content generation is heavily segmented; the AI is fed the structural skeleton from Phase 4 alongside the condensed context summary from Phase 1. It then iteratively generates the LaTeX code and the corresponding Python scripts... section by section.

  6. Phase 6: Review and Curation. "The final stage introduces a dual-layer validation process. Initially, the generated code and text undergo an automated review by a secondary, independent AI agent tasked with identifying syntax errors or pedagogical deviations. Following this automated curation, the primary instructor acts as the human-in-the-loop validator, compiling the code and approving the final material."

A critical design choice is that the restriction of the human-AI interface entirely to plain text, Markdown, and pure source code... is highly precise and mathematically unambiguous.

The validation was conducted over a one-year academic period at the Institute of Technology and Leadership (Inteli) in São Paulo, Brazil, an institution operating strictly under a Project-Based Learning (PBL) paradigm structured in quarterly modules (trimesters). The institution offers Business Administration and four computing programs (Computer Engineering, Computer Science, Information Systems, Software Engineering).

The validation had two scenarios:

  1. First-Year Common Core (High-Scalability Scenario): The architecture was deployed across four consecutive quarterly modules (IN01–IN04), serving six distinct classes, each with a different practical project per module — the pipeline was subjected to a high-variability stress test, adapting the theoretical materials to 24 distinct project contexts throughout the year. Materials were generated by a single instructor, formally reviewed by two independent peer professors, and deployed by six different professors.

  2. Advanced Years (Specialization Scenario): Applied to four single-quarter specialized modules (SE05, AD06, CS11, SE12) to test handling of highly specialized and dense technical constraints.

The core generative tasks used Gemini Pro family models (versions 2.5 to 3.1), while DeepSeek 3 was employed for the automated review/curation stage.

The deployment was associated with a strictly quantifiable reduction in material preparation effort. Traditionally, developing customized PBL slide decks required an average of eight hours of continuous manual effort per instruction. With the proposed pipeline... the active human-in-the-loop workload dropped to an average of two hours per instruction, yielding an estimated 75% reduction in preparation time. The remaining time is spent on Phase 4 planning (30 minutes) and Phase 5/6 oversight (90 minutes), focused on pedagogical adjustments and didactic pacing rather than syntax troubleshooting.

  • Python scripts generated for data visualization invariably executed without compilation errors on the zero-shot attempt.

  • LaTeX generation achieved extremely high rates of both semantic content fidelity and syntactic compilation success.

  • No conceptual or mathematical hallucinations were identified during the human-in-the-loop review across the 28 project contexts.

  • The few compilation errors were minor syntactic anomalies, the most common being mismatched bracket closures, easily caught by the automated review agent.

  • Peer reviewers consistently reported a complete absence of conceptual or mathematical hallucinations, confirming the accuracy of complex calculations. Revisions were limited to minor didactic enhancements, such as expanding intermediate calculation steps or refining theoretical boundaries of physical constants.

Based on over 600 voluntary student evaluations rating the statement The provided material is of high quality and understandable on a 0–10 scale, the materials received consistently high ratings:

Module Assessment (mean ± std) n

IN01 8.5 ± 0.5 219

IN02 9.1 ± 0.5 207

IN04 9.5 ± 0.3 118

SE05 9.8 ± 0.8 29

AD06 9.8 ± 0.5 18

SE12 9.9 ± 0.6 13

(IN03 and CS11 were generated and validated but their classroom deployment was pending at the time of writing.)

A critical observation from the validation phase is that the exact phrasing of the prompts or the specific foundational model used (e.g., Gemini or DeepSeek) had a secondary impact on the final quality compared to the structure of the workflow itself. The author argues for a paradigm shift towards instructional architecture: The strength of this architecture lies in its constraints: the drastic pruning of context, the isolation of structural planning from code generation, and the iterative loop that implements one section at a time.

  • The instructor transitions from being a manual formatter of slides to acting as an architect and engineer of instructional design.

  • The architecture is entirely adaptable to any instructional methodology.

  • It natively supports internationalization: because content is code-based, "utilizing the LLM to translate entire modules for exchange students proved trivial... the compiled LaTeX code automatically accommodates text expansion or contraction, maintaining perfect visual consistency across different languages."

  • Generative models are subject to behavioral drift following systemic updates by their providers, occasionally requiring minor recalibrations in the prompt instructions.

  • Minor syntactic anomalies (e.g., bracket mismatches) still occurred.

  • Advanced modules had smaller class sizes and single-instructor deployment.

  • The primary limitation: although the generated materials were deployed across multiple courses and utilized by various professors, the authoring process was conducted by a single instructor within a single institution.

Future research should focus on replacing the manual web-based AI interface with fully automated orchestration via APIs, deploying specialized agents for each specific phase, and Integrating this agentic pipeline with Git repositories would enable a CI/CD-inspired workflow for educational content development. Additional avenues include adaptive learning variations and accessible versions for visually impaired students.

The paper concludes that the proposed approach successfully transcends the ephemeral and error-prone nature of ad-hoc prompt engineering, and that the deliberate segmentation of tasks, combined with strict context pruning and the use of precise code-based tools like LaTeX and Python, effectively mitigates the well-documented limitations of Large Language Models. One of the main contributions is the systematization of the instructor's tacit pedagogical knowledge, translating individual teaching practices into explicit, replicable computational rules, allowing institutions to reduce faculty workload while preserving instructional quality.

Improvements for AI systems

Improvement to AI systems What the improved system can do

Automatic context pruning and distillation Compress long source documents (e.g., project charters, textbooks) into concise summaries before generation. This prevents context-window overflow and attention dilution, enabling consistent focus and low hallucination rates when generating long, code-rich teaching materials.

Phase-separated generation with structural planning first Generate a hierarchical lesson outline in an isolated planning phase, then generate content section-by-section using that skeleton. This ensures logical coherence, alignment with learning objectives, and allows sections to be reordered or modified without regenerating the whole module.

Few-shot calibration using validated exemplars Ingest previously approved teaching materials and institutional style guides to learn the instructor's didactic style, cognitive-load constraints, and technical syntax requirements. The system can then produce materials that match a specific pedagogical style and institutional visual identity.

Constraint injection per phase Explicitly restrict what the model may output at each stage (e.g., no code during planning, no extra context during implementation). This reduces irrelevant content, minimizes errors, and enforces typographic and formatting standards.

Iterative segment-by-segment generation loop Generate one slide/section at a time, feeding the previously generated segment back as context. This dramatically reduces syntax errors (e.g., bracket mismatches) and lets a human intervene on didactic pacing without debugging an entire document.

Dual-layer review with an independent AI agent Add a secondary AI model that checks generated code and content for syntax errors, factual deviations, and pedagogical misalignment before human review. This frees the instructor to focus on high-level pedagogical adjustments rather than troubleshooting, cutting preparation time from 8h to 2h per instruction.

Compilation/execution feedback for validation Connect the system to LaTeX compilers and Python interpreters, using compile/run errors as signals for automatic correction. This leads to zero-shot execution of data-visualization scripts and highly reliable mathematical typesetting and reproducibility.

Pure text/code-based interface Restrict inputs and outputs to plain text, Markdown, and source code only. This makes every output diffable and versionable, eliminates ambiguity in mathematical notation, and enables automated validators to run on the raw content.

Drift monitoring and recalibration Version prompt configurations and run regression checks when the underlying model updates. The system maintains output quality and institutional compliance even when the provider changes model versions (e.g., Gemini Pro 2.5 → 3.1).

Agentic orchestration integrated with CI/CD and Git Modularize the pipeline into specialized agents (context distiller, calibrator, planner, generator, reviewer) coordinated via APIs and connected to a Git repository. This enables fully automated curriculum generation, full traceability of changes, and a CI/CD workflow for educational content.

Tacit-knowledge systematization Interactively elicit an instructor's implicit rules about sequencing, emphasis, and contextualization, converting them into explicit, reusable configuration files. The system preserves pedagogical consistency across multiple courses and different professors.

Language and accessibility adaptation Use the code-based representation to generate translated and accessible versions of the same materials. The system can produce entire translated modules for exchange students while preserving visual layout, and can generate accessible variants for students with visual impairments.

Related papers