Paper Overview
AI-assisted curriculum personalization is cheaper than it used to be, but the design choices are harder. The paper argues that “personalized learning” is too vague on its own, and that instructors need a clearer way to decide how much personalization a course should carry.
It proposes a continuum framework for distributing decisions among students, AI agents, and instructors. Moving right along the continuum deepens personalization and increases:
- student autonomy
- instructor oversight
- ambiguity tolerance
- assessment complexity
while decreasing predefined structure, reproducibility, and comparability of student work.
The framework is grounded in three CS course deployments:
- Thematic variants (left end - my focus)
- Personalized paths (middle)
- Open-ended projects (right end)
Contributions:
- Organize the design space for AI-assisted personalization as a formal continuum.
- Show how roles and complexities shift along that continuum.
- Offer practical reference points for instructors choosing a degree of personalization.
Continuum Context
| Variant | Instructor constraint | Student agency | Agent/tool artifacts | Challenges |
|---|---|---|---|---|
| 1. Thematic variants | Fixed concept sequence, stable project requirements, shared task structure | Domain, theme, code examples, or dataset choice | Bounded variants from templates, specs, examples, and style guides | Personalization stays mostly surface-level |
| 2. Personalized paths | Shared objectives, checkpoints, rubrics, and course outcomes | Project direction and implementation choices | Personal guides, next steps, scaffolds, progress evaluation, feedback | Scope creep, over-helping, uneven feedback without review |
| 3. Open-ended projects | High-level concepts, evaluation criteria, critique, expectations | Problem framing, architecture, module design, expectation alignment | Guidance for proposals, modules, checkpoints, feedback, code review | Comparability, coherence, and claim interpretation get harder |
Pedagogically, the continuum builds on differentiated instruction and Universal Design for Learning (UDL). Technically, it uses a curriculum-as-code workflow: course materials live as markdown in a version-controlled repo, with role suffixes (e.g. *_rubric.md) and agent instruction files such as AGENT.md / CLAUDE.md. Cursor was the primary IDE across deployments.
Section 5.1 — Deployment 1: Thematic Variants
Setting
The first deployment was a sports-themed Python and AI course for pre-college students.
- Students chose a sport domain at the start of the course.
- Tasks and outcomes stayed fixed.
- Examples, datasets, and variables were reframed around the chosen sport.
- Instructors prepared variants for five sports: football, soccer, baseball, basketball, and volleyball.
- Intake surveys showed no interest in volleyball, so that variant was removed — demand-driven pruning without restructuring the curriculum.
Because only the theme varied, this deployment sits at the left end of the continuum.
How it was built
Instructors created one shared template for a single sport, then instantiated variants for the remaining sports from that template. The same coding concepts ran across all variants; only examples, data, and instructions changed.
Figure 2 shows the same weighted player-rating pattern for baseball and football, with sport-appropriate stats:
# Baseball
player_name = "Shohei Ohtani"
batting_avg = 0.304
home_runs = 44.0
rbis = 95.0
score = (
(batting_avg * 100)
+ (home_runs * 1.5)
+ (rbis * 0.5)
)
print(f"{score:.1f}")
# Football
player_name = "Patrick Mahomes"
passing_yards = 5250.0
touchdowns = 41.0
completions = 435.0
score = (
(passing_yards * 0.01)
+ (touchdowns * 2.0)
+ (completions * 0.05)
)
print(f"{score:.1f}")
Detailed guides reduced time spent searching so students could spend more time coding. Instructors gave real-time in-class feedback to reinforce concepts and support code improvement. Students were encouraged to use Cursor agents in ask mode — guided through the coding process without having the agent write code for them.
Curriculum-as-code materials
Shared, inspectable source files included:
- project specifications, guides, rubrics, and feedback notes
- survey instruments, personas, and paths
- outcomes, style guides, local instructions, and previously released materials
File-role suffixes made artifact purpose clear to both instructors and agents. That shared structure is what let the agent’s role shift across later deployments without changing the underlying workflow.
Iteration and outcome
After week two, instructors collected feedback on preferences and the curriculum-as-code approach, then adjusted later weeks. Where students struggled, instructors identified gaps and used agents to produce extra instruction and examples. They also reinforced concept transfer by linking prior lessons to current tasks.
Honest takeaway: personalization here was largely superficial — thematic framing changed, but underlying tasks and outcomes did not. Instructors still observed that domain theming made the curriculum feel more relevant and appeared to increase engagement.
Where 5.1 Sits Relative to Later Deployments
Deployment 2 (personalized paths) releases more agency over time while keeping shared instructor contributions:
| Unit | Instructor | Student | Agent |
|---|---|---|---|
| 1 | Python foundations | Personalized examples | Concept guides |
| 2 | Simulated organization | Department/path focus | Path variants and guidelines |
| 3 | Capstone expectations | Project goals and requirements | Scaffolds, feedback, next-step guides |
Deployment 1 keeps structure almost entirely fixed and only swaps theme. That makes it the safest entry point on the continuum: high comparability and reproducibility, lower student ambiguity load, and a bounded agent role (generate and maintain thematic variants from templates).
My Focus / Contribution Angle
For this paper, my contribution centers on Deployment 1 / Section 5.1:
- Document how thematic variants work as the leftmost continuum point.
- Show the template → multi-sport instantiation pattern with concrete code examples.
- Clarify what the agent is allowed to change (theme, examples, data framing) versus what stays instructor-owned (concepts, tasks, outcomes).
- Capture the practical lesson: surface-level personalization can still raise engagement without exploding assessment complexity.