Further study and how this course was designed

Course home · Learning map · Engineering foundations

This page lists public course sites and research papers you can read after the weekly work is done, and explains where this course’s teaching methods come from. Everything here is optional.

You will be able to: find a trustworthy next resource for a topic you want to go deeper in, tell a published course from one still in progress, and explain why each teaching routine in this course exists.

Predict first: two well-known courses both care about understanding. One forbids generative AI on its coursework; the other allows AI-written code that you can validate and explain, and checks this orally. Which one is this course’s AI policy closer to, and does that mean we copied its rules?

Check your prediction

Closer to the second (Stanford CS329Z), and also to MIT 6.1040: this course allows AI tools from week 1, requires you to understand and verify everything, and checks understanding through your individual explanation. But the rules are our own: the course guide is the authority, and the table in AI policies differ shows how different the rules at MIT and Stanford are.

On this page

How to use this page

  • Optional, always. Nothing on this page is a prerequisite, an assignment, or assessed. If a lecture’s prerequisite check fails, use Engineering foundations first; it is shorter and written for this course.
  • Reviewed 17 October 2026. Each course entry says what was public that day: Published (real material online), In progress (running now; the entry says what is not released yet), Archived (an older, stable copy), or Unverified (we could not confirm it). Anything announced but not yet released is marked planned.
  • No affiliation. EASS is not affiliated with MIT or Stanford, and this course is not equivalent to any of their courses. Our activities are original; where one was inspired by a course site, this page says so.
  • Respect licenses. Follow each site’s license and policies, and do not copy coursework or solutions. Two repositories listed below have no license: read and link them, but do not copy from them.
  • Read with a question. Before opening a source, write the one question you want it to answer, and stop when it is answered. Each entry’s Read for line suggests where to start.

How this course was designed

Each recurring routine in the lectures comes from published research on how people learn to program. The table names the routine, the primary source, and where you meet it.

Design choice Evidence (primary source) Where you meet it
Predict → Run → Investigate → Modify → Make (PRIMM) Sentance, Waite & Kallia (2019), doi:10.1080/08993408.2019.1608781. The study was with school pupils, so we apply it by analogy. “Predict first” in every lecture; “Investigate” questions after demos; the hands-on lab
Worked examples, then faded practice Sweller & Cooper (1985), doi:10.1207/s1532690xci0201_3; Atkinson et al. (2000), doi:10.3102/00346543070002181; Renkl & Atkinson (2003), doi:10.1207/S15326985EP3801_3 Recipe Box live demos first, then the same steps in your own domain; the practice ladders in Engineering foundations
Self-explanation Chi et al. (1989), doi:10.1207/s15516709cog1302_1 “Explain after” prompts; the individual technical discussion
Subgoal labels Margulieux, Guzdial & Catrambone (2012), doi:10.1145/2361276.2361291; Margulieux, Morrison & Decker (2020), doi:10.1186/s40594-020-00222-7 The five labels on live-demo steps (learning map)
Retrieval and spacing Roediger & Karpicke (2006), doi:10.1111/j.1467-9280.2006.01693.x; Cepeda et al. (2006), doi:10.1037/0033-2909.132.3.354; Dunlosky et al. (2013), doi:10.1177/1529100612453266 “Warm-up from earlier classes”; quizzes with hidden answers
Parsons problems Ericson, Margulieux & Rick (2017), doi:10.1145/3141880.3141895 Text-only “put these lines in order” items in early lectures
Tracing before writing Lister et al. (2004), doi:10.1145/1041624.1041673; Lopez et al. (2008), doi:10.1145/1404520.1404531 “Trace it” tables that follow one request or one state change
Explain in plain English Murphy et al. (2012), doi:10.1145/2361276.2361299 One “Explain it” item per quiz; the three-level self-rubric in Individual understanding
Peer instruction Porter, Bailey Lee & Simon (2013), doi:10.1145/2445196.2445250 Vote, discuss with a partner, vote again (instructor notes)
Hypothesis-driven debugging Michaeli & Romeike (2019), doi:10.1145/3361721.3361724; Loksa et al. (2016), doi:10.1145/2858036.2858252 The debug log and “hypothesis before assistant”
Guarding against an “illusion of progress” with AI Prather et al. (2024), doi:10.1145/3632620.3671116 Hypothesis before assistant; read the diff and run the check before you keep a change; the AI-use note

An honest limit: no learning gain has been measured for this course. The studies above involved different students (some of them school pupils) and different settings, so they are reasons for our choices, not guarantees.

Some activities were also inspired by public course sites. The activities and wording are original; the table credits the idea.

Activity in this course Inspired by Where you meet it
Purpose and operational principle in your product sketch Concept design in MIT 6.1040 Software Design, Fall 2026 (schedule) Lecture 1 lab, product sketch
A three-line forecast before delegating to an assistant MIT 6.S950 Agency with AI, Lab 1; Missing Semester 2026, Agentic Coding Lecture 1, working with an assistant
An “undo without panic” Git drill MIT 6.102, Git 2: disaster recovery; Missing Semester 2026, Version Control Lecture 1, Break it on purpose
Writing test partitions down before testing MIT 6.102, Testing Lecture 2 tests; the engineering studio
A written debugging method with a debugger MIT 6.102, Debugging; Missing Semester 2026, Debugging and Profiling; Stanford CS107 debugging guide Debug with a hypothesis
Reading a real review before your first upstream PR Missing Semester 2026, Beyond the Code Lecture 2, open-source track
AI use as “Encouraged / Required / Not OK” Stanford CS224G, Winter 2026 (course site) AI use at a glance
Short, ungraded random check-offs before the final discussion MIT 6.5840 check-offs; Stanford CS329Z oral checks Meetings 11–12 (instructor pacing)

Check yourself: which design choice explains why every “Predict first” in this course has a hidden answer you open only after writing your own?

Check your answer

Retrieval practice with feedback (and PRIMM’s predict step): committing to an answer before seeing one makes you retrieve what you know, and the hidden answer gives immediate feedback on it. Reading the answer first turns the question back into re-reading, which helps far less.

AI policies differ; ours is our own

The courses this page cites set very different rules for AI tools. Their rules apply to their students; ours are in the course guide.

Course (latest published) AI policy (checked 17 October 2026) How understanding is checked
MIT 6.102 Software Construction, Spring 2026 Generative AI for writing code or text is prohibited on coursework (collaboration policy) Reading exercises, short start-of-class quizzes, code review then revision, exams
MIT 6.1800 Computer Systems Engineering, Spring 2026 Generative AI may not create text beyond a single word; spelling, grammar and search help are allowed (grading and policies) Exams, communication assignments, participation
MIT 6.5840 Distributed Systems, Spring 2026 An assistant writing lab code means you learn correspondingly less; you must be able to explain all submitted code (general information) Randomly chosen lab check-offs, questions before lectures, exams
MIT 6.1040 Software Design, Fall 2026 LLMs encouraged as a skill, but attempt problem sets and new skills without them first, and never use one for reflections (class guide) Competency levels per skill, reflections in your repository
Stanford CS329Z Engineering AI Agents, Fall 2026 AI-generated code allowed if you can validate and explain it; AI may not write reports (logistics) Oral examinations, quizzes after each homework, peer review
Stanford CS107, Autumn 2026 AI treated like a classmate: high-level questions allowed, AI-written code or answers prohibited (collaboration policy) Similarity detection, truthful citation
Stanford CS190 Software Design Studio, Winter 2024 ChatGPT and other AI assistants not permitted (course site) Code reviews and revision of your own code

EASS borrows these courses’ specification, testing, review and verification methods, not their AI rules. The course guide is the authority for ours.

Check yourself: a friend taking MIT 6.102 says, “EASS lets me use an assistant, so I can use one on my 6.102 problem set too.” What is wrong with that reasoning?

Check your answer

Each course’s policy governs work submitted to that course. 6.102 prohibits generative AI on its coursework, so its rule applies there regardless of what EASS allows. The same holds in reverse for upstream projects: follow each project’s own AI-use policy when you contribute.

Course sites by topic

Statuses are as of 17 October 2026. Terms and URLs change; if a link breaks, search the course number on the university’s site rather than a mirror.

Tools and workflow

Software construction and design

Web applications and security

Guiding questions for the AI agent security lecture

Answer them for your product after Lecture 6:

  1. Which of your agent’s tools could text inside a pasted recipe (or your domain’s input) trigger?
  2. Which data could flow from that input to which output: a saved record, a log, a page another user sees?
  3. What do your Pydantic schema and your validators not prevent?

There is no single right answer; a good answer names a concrete tool, a concrete field, and one check you would add.

Systems and distributed systems

Three self-check questions on lost replies and end-to-end checks

Read the 6.5840 RPC notes or the end-to-end reading page first, then answer for the course’s Recipe Box (POST /recipes/from-text):

  1. Which component can confirm that a recipe was actually saved?
  2. Why does the backend, not the AI service, decide whether a candidate recipe is accepted?
  3. If the frontend retried after a timeout, where could a duplicate appear?

Model answers:

  1. Only the backend, because it owns the database and the commit. The frontend sees only the reply; if the reply is lost, it cannot know.
  2. The AI service only proposes a candidate; the backend holds the contract and the data, so the check must live where the data is written. An end-to-end check belongs at the endpoint that owns the outcome.
  3. In the database: if the first request was committed but its reply was lost, a blind retry inserts a second row. That is why the course separates “nothing was sent” from “outcome unknown” (Lecture 9).

Building with coding agents

  • Stanford CS146S: The Modern Software Developer (Fall 2026). In progress: weeks 1–4 slides sit behind a newsletter prompt; transcripts are posted for 24 September, 29 September and 1 October; weeks 5–10 are topic outlines only (planned). Its grading includes a 30% open-source contribution component. Read for: coding-agent internals, context and tool design, agent-ready repositories, code review with agents. The assignment repository has no license: read only. Earlier term: Fall 2025.
  • MIT 6.S950 Agency with AI (Fall 2026). In progress: slides for week 9 are announced for 17 November and week 10 for 24 November (planned, not reviewed). Strict machine-learning and algorithms prerequisites. Read for: delegation judgment (Lab 1), evaluation as experimental design, and auditing judges.

Engineering agentic systems and evaluation

Models, transformers and inference

ML systems

Engineering sources to work through

Added and reviewed 18 October 2026. Use the Systems reasoning clinics to turn these primary resources into an original worked example, diagram, runnable lab or calculation. All are optional; no cloud account is needed.

Read for a specific question, state the source’s assumptions, then bring back one check that could disprove your proposed application. Reputation helps find material; it does not establish that a pattern is needed in your product.

Inference engineering book and companion

Added and checked 18 October 2026. Philip Kiely’s Inference Engineering is publicly readable online without registration. Start with Chapter 1’s product and measurement questions, then use the visual course companion for a three-sitting route through Lectures 6–10, ten original diagrams and worked prediction exercises. Quantization, caching, batching and production measurement connect to Recipe Box; GPU kernels, multi-GPU serving and extra modalities remain optional depth.

Gergely Orosz’s What is inference engineering?, 31 March 2026 introduces the area with material adapted from Kiely’s book. These are industry perspectives, not university endorsements or independent guarantees of performance. Follow the companion’s links to the official engine documentation and primary papers; test an optimization against a fixed task and workload. No subscription, model download, GPU or extra account is required.

Research papers

The primary sources behind How this course was designed, plus reviews for context. DOIs were checked against publisher metadata on 17 October 2026; several papers were read at abstract level only.

Teaching methods

  • Sentance, Waite & Kallia (2019). Teaching computer programming with PRIMM: a sociocultural perspective. Computer Science Education 29(2–3). doi:10.1080/08993408.2019.1608781
  • Sweller & Cooper (1985). The use of worked examples as a substitute for problem solving in learning algebra. Cognition and Instruction 2(1). doi:10.1207/s1532690xci0201_3
  • Atkinson, Derry, Renkl & Wortham (2000). Learning from examples: Instructional principles from the worked examples research. Review of Educational Research 70(2). doi:10.3102/00346543070002181
  • Renkl & Atkinson (2003). Structuring the transition from example study to problem solving in cognitive skill acquisition. Educational Psychologist 38(1). doi:10.1207/S15326985EP3801_3
  • Kirschner, Sweller & Clark (2006). Why minimal guidance during instruction does not work: An analysis of the failure of constructivist, discovery, problem-based, experiential, and inquiry-based teaching. Educational Psychologist 41(2). doi:10.1207/s15326985ep4102_1
  • Chi, Bassok, Lewis, Reimann & Glaser (1989). Self-explanations: How students study and use examples in learning to solve problems. Cognitive Science 13(2). doi:10.1207/s15516709cog1302_1
  • Margulieux, Guzdial & Catrambone (2012). Subgoal-labeled instructional material improves performance and transfer in learning to develop mobile applications. ICER. doi:10.1145/2361276.2361291
  • Morrison, Margulieux & Guzdial (2015). Subgoals, context, and worked examples in learning computing problem solving. ICER. doi:10.1145/2787622.2787733
  • Margulieux, Morrison & Decker (2020). Reducing withdrawal and failure rates in introductory programming with subgoal labeled worked examples. International Journal of STEM Education 7. doi:10.1186/s40594-020-00222-7 (open access)
  • Roediger & Karpicke (2006). Test-enhanced learning. Psychological Science 17(3). doi:10.1111/j.1467-9280.2006.01693.x
  • Karpicke & Blunt (2011). Retrieval practice produces more learning than elaborative studying with concept mapping. Science 331. doi:10.1126/science.1199327
  • Cepeda, Pashler, Vul, Wixted & Rohrer (2006). Distributed practice in verbal recall tasks: A review and quantitative synthesis. Psychological Bulletin 132(3). doi:10.1037/0033-2909.132.3.354
  • Dunlosky, Rawson, Marsh, Nathan & Willingham (2013). Improving students’ learning with effective learning techniques. Psychological Science in the Public Interest 14(1). doi:10.1177/1529100612453266
  • Parsons & Haden (2006). Parson’s programming puzzles: a fun and effective learning tool for first programming courses. Proceedings of ACE 2006 (CRPIT 52). Cited from the literature; no DOI.
  • Ericson, Margulieux & Rick (2017). Solving Parsons problems versus fixing and writing code. Koli Calling. doi:10.1145/3141880.3141895
  • Du, Luxton-Reilly & Denny (2020). A review of research on Parsons problems. ACE. doi:10.1145/3373165.3373187
  • Crouch & Mazur (2001). Peer Instruction: Ten years of experience and results. American Journal of Physics 69(9). doi:10.1119/1.1374249
  • Porter, Bailey Lee & Simon (2013). Halving fail rates using peer instruction: a multi-institutional study of computing courses. SIGCSE. doi:10.1145/2445196.2445250
  • Lister et al. (2004). A multi-national study of reading and tracing skills in novice programmers. ACM SIGCSE Bulletin 36(4). doi:10.1145/1041624.1041673
  • Lopez, Whalley, Robbins & Lister (2008). Relationships between reading, tracing and writing skills in introductory programming. ICER. doi:10.1145/1404520.1404531
  • Murphy, Fitzgerald, Lister & McCauley (2012). Ability to ‘explain in plain English’ linked to proficiency in computer-based programming. ICER. doi:10.1145/2361276.2361299
  • Xie et al. (2019). A theory of instruction for introductory programming skills. Computer Science Education 29(2–3). doi:10.1080/08993408.2019.1565235
  • Kulik, Kulik & Bangert-Drowns (1990). Effectiveness of mastery learning programs: A meta-analysis. Review of Educational Research 60(2). doi:10.3102/00346543060002265
  • Edwards et al. (2024). Early experiences with specifications grading in introductory CS courses. IEEE FIE. doi:10.1109/FIE61694.2024.10893554
  • Loksa, Ko, Jernigan, Oleson, Mendez & Burnett (2016). Programming, problem solving, and self-awareness: effects of explicit guidance. CHI. doi:10.1145/2858036.2858252
  • Michaeli & Romeike (2019). Improving debugging skills in the classroom: The effects of teaching a systematic debugging process. WiPSCE. doi:10.1145/3361721.3361724
  • Ko et al. (2019). Teaching explicit programming strategies to adolescents. SIGCSE. doi:10.1145/3287324.3287371
  • Prather et al. (2020). What do we think we think we are doing? Metacognition and self-regulation in programming. ICER. doi:10.1145/3372782.3406263
  • Hundhausen, Agrawal & Agarwal (2013). Talking about code: Integrating pedagogical code reviews into early computing courses. ACM TOCE 13(3). doi:10.1145/2499947.2499951

Generative AI and assessment

  • Prather et al. (2023). The robots are here: Navigating the generative AI revolution in computing education. ITiCSE Working Group Reports. doi:10.1145/3623762.3633499
  • Lau & Guo (2023). From “Ban it till we understand it” to “Resistance is futile”: How university programming instructors plan to adapt as more students use AI code generation and explanation tools. ICER. doi:10.1145/3568813.3600138
  • Denny et al. (2024). Computing education in the era of generative AI. Communications of the ACM 67(2). doi:10.1145/3624720
  • Prather, Reeves, Leinonen et al. (2024). The widening gap: The benefits and harms of generative AI for novice programmers. ICER. doi:10.1145/3632620.3671116 (preprint)
  • Kazemitabaar et al. (2023). Studying the effect of AI code generators on supporting novice learners in introductory programming. CHI. doi:10.1145/3544548.3580919
  • Denny et al. (2024). Prompt Problems: A new programming exercise for the generative AI era. SIGCSE. doi:10.1145/3626252.3630909
  • Liu, Zenke, Liu, Holmes, Thornton & Malan (2024). Teaching CS50 with AI: Leveraging generative artificial intelligence in computer science education. SIGCSE. doi:10.1145/3626252.3630938
  • Stanford Office of Community Standards. Generative AI Policy Guidance (adopted 16 February 2023): without a course policy, generative AI counts as help from another person.

Accessibility standards

This site follows these W3C documents: diagrams have a short alt plus a text version, nothing requires dragging, and motion respects your system setting.

What we could not verify

On 17 October 2026 we could not confirm the following, so the entries above avoid claims about them:

  • MIT web.lab (6.9620): the next edition’s schedule, public materials, stack and AI policy; only its home page was readable.
  • Stanford CS104, the successor to CS45: no public course site was found.
  • Stanford CS190 offerings after Winter 2024, and CS142 offerings after Spring 2023.
  • Stanford CS329S: whether a current offering exists; the catalog entry shows no sections.
  • Stanford CS329A: whether an Autumn 2026 offering exists.
  • MIT 6.1040: whether its Fall 2026 title is “Software Design” (its site) or “Software Studio” (the EECS teaching list).
  • MIT 6.5940: a Fall 2025 course page.
  • Stanford CS146S: the content of its Fall 2026 slides, which sit behind a newsletter prompt.
  • MIT 6.S950 week 9 and week 10 slides, which are planned for 17 and 24 November 2026.

Turn a conference idea into evidence

Source snapshot: 17 October 2026. Conference programs are useful maps of practitioners’ concerns. A session title or abstract is not independent evidence that a technique improves your product. The references here were checked as official programs and abstracts; this review does not claim to have watched every recording or reproduced a speaker’s results.

Official source Relevant published topics A bounded course experiment
AI Engineer World’s Fair 2026, 29 June–2 July Software factories, harnesses, context, evaluations, local AI, inference, sandboxes; listed recordings include production evals and tool selection Compare focused context/tool exposure with the same agent’s broader catalog on the same cases; keep denied-action checks in the tool runner
USENIX SREcon26 Americas: The Ironies of AI², 25 March Interaction between automation, AI and operators during incidents Rehearse an AI-service outage: separate observed evidence from an assistant’s hypothesis, keep the human release owner, and verify recovery

Choose one optional experiment after the core product works. Use the factory lab for delivery evidence, local inference for serving tradeoffs, sandboxes for enforced permissions, or the system walkthrough for a service-failure rehearsal. You do not need a conference ticket or commercial tool subscription.

Keep a six-line research note:

  1. Source and status: primary URL, author/date, and whether you read a syllabus, abstract, paper, docs, or watched a recording. Mark planned material as planned.
  2. Claim: one precise behavior, with the environment and limitations in which it is supposed to hold.
  3. Hypothesis: what should improve in your product, compared with what simpler baseline?
  4. Experiment: fixed case IDs, component changed, permissions, budget, and a check that could disprove the claim.
  5. Observed result: counts by slice plus failures, latency/usage where relevant; distinguish measured, simulated, and untested claims.
  6. Decision: adopt, revise, or reject, with a remaining limitation and the exact revision.

For example, “a smaller tool catalog helps” becomes a comparison of task completion, wrong-tool attempts and usage on the same scenarios. Removing a tool the task actually needs may reduce success. A faster run with the wrong final state is a failure. For the outage rehearsal, an agent’s plausible explanation is a hypothesis until a health probe, trace, or controlled reproduction supports it. Read-only investigation and permission to restart or deploy are separate authorities.