Lecture Schedule

This schedule is tentative and subject to change. Check back often for updates.

Lectures are Tuesdays and Thursdays, 2:00-3:20pm, in Design and Innovation Building (DIB) 122. The quarter has two halves. In Weeks 0-5 we work on idlelib (part of CPython) and build our skills by hand. In Weeks 6-10 we work on OpenRefine and use agentic AI tools, applying the same skills to code we have never seen.

Week 0 is the first Thursday of the quarter. For assignment, Skill Demo, and Group Project dates, see the Course Calendar. For how each assignment works, see Assignments. For grading, see the Syllabus.

Part 1: Traditional software engineering (idlelib)

Week 0

Lecture 0, Thu 9/24: Welcome to large codebases | Slides

  • Introductions: the instructor, the tutors, and your classmates
  • Introduction to the course: why it exists, the syllabus, how the course works (the three competencies, the two halves, working in a team all quarter)
  • What makes a large codebase different from a class project: no design docs, conventions you did not choose, real users, code by people who have left
  • Why idlelib: real, actively maintained, moderate size, written in Python
  • The process journal: write down what you tried and why, not only the result

Week 1

Lecture 1, Tue 9/29: Environments and building from source

  • Development vs production environments
  • Building CPython from source and running idlelib from your own build

Lecture 2, Thu 10/1: Navigating large codebases

  • Code search and navigation: go to definition, find all references, global search
  • Opportunistic searches: searching for a word or string you notice while reading, to see where else it appears
  • Going back and forward in a function call hierarchy: to callers and to callees

Week 2

Lecture 3, Tue 10/6: Code reviews

  • What reviewers look for: correctness, style, scope, tests, security
  • Giving feedback the author can act on, and receiving it
  • Writing PR descriptions and commit messages that explain why, not only what
  • Reviewing a small change as a checklist exercise

Lecture 4, Thu 10/8: Documenting, explaining, and presenting a change

  • Building a mental model of a feature and writing it down
  • Lightweight UML diagrams (class and sequence) to document a change
  • Explaining a change to a teammate with no background on it
  • Presenting a technical change: structure, a short demo, and answering a question on your own
  • Code as comments, and modular code structure (a function should do one thing and do it well)

Week 3

Lecture 5, Tue 10/13: When your change breaks the tests

  • Running IDLE’s tests with the Python you built, and reading the output
  • Predicting which tests cover your change, and whether they will pass
  • A failing test: is the code wrong or is the test out of date?
  • Looking for side effects: Find All References vs global search, and why they can differ
  • Blast radius: finding what else could break before you change something
  • Reviewing your own diff like a reviewer: naming, order of statements, and a simpler way to do the same thing

Lecture 6, Thu 10/15: Testing: writing tests | Handout

  • Finding the existing tests for a feature you changed
  • Which existing tests break after a change, and whether the code or the test is out of date
  • Deciding what is worth testing: the edges of the allowed range
  • Writing new tests that follow the conventions already in idle_test: file, class, and test naming
  • Checking that your tests can fail: break the code on purpose and see which test catches it

Week 4

Lecture 7, Tue 10/20: Testing: mocking

  • Why tests use fake objects: testing your logic without a window, a display, or the rest of the program
  • What a mock is (unittest.mock): it makes up attributes, returns what you tell it to, and remembers how it was called
  • Class diagrams of the real dialog and of the test’s fake: what the fake stands in for, and what it borrows
  • What a mock cannot tell you: it returns the same answer whatever you ask, so a wrong call can still pass
  • Checking that your tests can fail: asserting on how a mock was called

Lecture 8, Thu 10/22: Testing: GUI tests

  • GUI tests: driving the real dialog and a real widget, and reading errors raised inside a button click
  • Fixing a GUI test that gives the dialog the wrong kind of parent, and adding a new one
  • Choosing a fake or the real thing, and checking that your tests can fail

Week 5

Lecture 9, Tue 10/27: Program comprehension: the debugger

  • Setting up a debugger for a multi-module project (module-based launch configs)
  • Breakpoints, stepping, inspecting state, conditional breakpoints
  • Debugging GUI and event-driven code, which does not run top to bottom
  • Strategy for unfamiliar code: reading a stack trace in code you have not seen before, print statements vs a debugger, narrowing down where a bug starts

Lecture 10, Thu 10/29: Working as a team in git

  • Branching strategy, pull requests, and merge conflicts
  • Splitting work so several people can move in parallel, as you will in the Group Project
  • Issues and project boards

Part 2: Agentic software engineering (OpenRefine)

Week 6

Lecture 11, Tue 11/3: Intro to GenAI and coding agents

  • Fundamentals of generative AI: predicting the next word from what came before, what a model is, and types of GenAI (e.g., chat-based)
  • What an agent is: vertical agents (e.g., medical, trucking), what a coding agent is, and sub-agents (e.g., writer, code reviewer, security reviewer)
  • Agents can do whatever we did in the traditional half of the course; it is not magic
  • Program comprehension using agents: asking an agent to explain a feature instead of navigating the code by hand
  • Issues: agents can hallucinate, so humans have to review the changes instead of assuming everything is ground truth

Lecture 12, Thu 11/5: Understanding a codebase and making a scoped change with an agent

  • Trying this on the idlelib features from A1 and A2, this time with an agent
  • Asking an agent to trace a feature end to end, then cross-checking it against the source and the debugger
  • Prompting for a small change that matches existing conventions: plan first, then act, in small steps
  • Writing the PR description for agent-assisted work

Week 7

Lecture 13, Tue 11/10: Verifying agent-generated code

  • What to always check before you trust an agent’s change: run it, read the diff, look at the tests
  • Tests, linters, and formatters as checks on agent output (OpenRefine’s TestNG and Cypress tests)
  • Telling a real fix from a hack that only satisfies the test

Lecture 14, Thu 11/12: Code review of an agent’s PR

  • Reviewing an agent’s diff the way you would review a teammate’s PR
  • Common agent problems: unnecessary refactors, invented abstractions, changes outside the request, weak tests
  • A review checklist for agent diffs, and feedback the author can act on

Week 8

Lecture 15, Tue 11/17: CI and CD

  • What a CI pipeline does: build, lint, and test on every PR (OpenRefine’s GitHub Actions)
  • Reading a failing CI run, and knowing when to re-check an agent’s reading of a failure
  • What CD is, and why automated checks matter more when agents write code

Lecture 16, Thu 11/19: Security and ethics

  • Safety basics: permissions, working on a branch, keeping secrets out of prompts
  • Security risks in agent output: security holes, dependencies an agent adds, license concerns
  • Ethics: disclosing AI use and who is responsible for the code

Week 9

Lecture 17, Tue 11/24: Collaboration and communication with humans and agents

  • Several people using agents on one repo: conflicts, duplicated work, keeping one shared plan
  • Explaining an agent’s work to a teammate in your own words
  • Context files such as AGENTS.md, and prompts as writing for a reader with no memory

Lecture 18, Thu 11/26: No lecture (Thanksgiving)

Thanksgiving holiday. No class.

Week 10

Lecture 19, Tue 12/1: Spec Driven Development

  • What spec driven development is: a spec written and agreed on before coding, used as the single source of truth, and how it differs from vibe coding and test-driven development
  • Writing a spec an agent can follow: what the system must do in clear, testable terms, with inputs and outputs, edge cases, and success criteria, without over-specifying the implementation
  • Keeping the spec and code in sync: checking the agent’s result against the spec with tests (in CI), and updating the spec when it was wrong, while keeping it lightweight

Lecture 20, Thu 12/3: Humans and agents: what is changing for us

  • What happens to a team’s shared understanding when agents hold the knowledge of the codebase, and to collaboration when everyone asks their own agent
  • What is happening to software engineers’ learning and skill development when agents do the work: which human skills will still matter, which agents will take over, and how beginners grow into senior engineers

Week 11

Group Project final presentations: Thursday 12/10, 3:00-5:59pm, in person, FAH 1450. There is no written final exam.