Defense

Submission: Individual, held as a team session
Due: Week 7 or 9, every term
Weight: 8% of the fall grade, 10% of the winter and spring grades

Once per term, in week 7 or 9 (your TA publishes the schedule), your team meets your TA for a defense session separate from your cohort check-ins, during which each student walks through something they own and answers live questions. The session is six minutes per student plus about ten minutes for setup and wrap, so a team of three runs a little under half an hour and a team of five runs about forty minutes. Per-student time does not shrink on a larger team; the session simply runs longer. Sick or absent that week? Tell your TA before the session and you will be rescheduled, per the absence policy.

You may present a pull request you drove, a subsystem you maintain, your RFC decision, or a test or deployment strategy you built. The questions are the point: why this way and what you rejected, what breaks if X changes, where did you decide to stop and check the work yourself and why there, and what was the most useful thing you told someone whose work you reviewed.

Ground rules: your docs, your repo, and your AI tools are open for explaining (looking things up, walking through code) and closed for generating (no asking a model to produce the answer live). Notes are fine. Slides are unnecessary.

This is deliberately the assessment AI cannot do for you. If you built and understood your work, the defense is a friendly conversation about it. If you cannot explain your own contribution, no artifact will cover for that, and that is by design: your project partner will expect the same of you in every meeting.

Delegating work to AI tools is expected and is not penalized. What is assessed is the fit between how far you delegated and how strong a safety net you built: a student who let an agent drive a database migration unchecked and got lucky scores badly, and a student who stopped to validate an authentication change scores well even if some feature code has bugs. Students working with less capable tools or tighter budgets are not disadvantaged, because a weaker tool simply means tighter gates and more validation of your own, which this criterion rewards.

How the Session Runs

The speaking order is drawn at random in the room, never published in advance, and each student gets a different artifact and a different “what breaks if X” question. Hearing a teammate answer first therefore tells you very little about what you will be asked.

That is deliberate, and it is worth knowing why. Holding the defense as a team session is a choice: your teammates are the people who actually know whether your account of your own work is true, and claiming credit for something in front of them is much harder than claiming it in a one-to-one meeting. The cost of that choice is that whoever goes last has sat through several rounds of questions first. Randomizing the order and varying the questions is how that cost gets paid down.

If a score comes out borderline, or if your part of the session ran short for any reason, your TA may ask you back for a brief individual follow-up. It is routine, it is not a penalty, and it exists so that nobody’s grade depends on how the group session happened to go on the day.

Scoring

TAs and instructors score each student live on a printed sheet (the scoresheet is public: you can see exactly what is scored). Scores and notes are entered per student into Canvas after the session and retained as program assessment evidence; the printed sheet is the live instrument, Canvas is the record. Graders calibrate together on the scoresheet before defense weeks so scores mean the same thing across cohorts. No written deliverable exists; there is nothing to prepare beyond doing your work and being able to talk about it. Not every teammate holds one of the three named roles at a given time; “comparable ownership area” (a subsystem, the test suite, the deployment) satisfies the role criterion.

Rubric (100 points, per student)

Criterion	Points	Outcome
Ownership and delegation: presents work they demonstrably own, and explains what they handed to AI tools, what safety net made that reasonable, and where they stopped to validate	20	SO2, SO4
Judgment: explains why this approach, what credible alternatives were rejected, and which parts of the decision were hard to reverse	20	SO1
Technical depth: answers “what breaks if X” with correct, specific reasoning about the system’s behavior and limits	20	SO6
Role and team accountability: articulates what their named role (PM, AI Coordinator, Quality Owner) or comparable ownership area required this term, how the team’s decisions actually got made, and how work was distributed	20	SO5
Communication, both directions: clear, honest, right level of detail for the audience, handles not-knowing gracefully, and names the most useful thing they told someone whose work they reviewed and what changed because of it	20	SO3

“Handles not-knowing gracefully” is real: “I don’t know, but here is how I would find out” scores; bluffing does not.

The reviewer-side half is there because communication runs both directions, and a student who is articulate about their own work can still be useless in review. In fall and winter it is your RFC cross-team review; in spring it is code review, and your sprint note contribution lines already name the one change you asked for. Both are graded records, so this is checkable: “I left some comments” is not an answer, and neither is anything that named no line and requested no change.

Activities That Prepare This

The defense runs once a term, so these rotate.

Term	Activity	Criterion it serves
Fall	Map Your One-Way Doors	Judgment
Fall	Audit Your Safety Net	Ownership and delegation
Winter	Run a Self-Audit and an Architectural Review Pass	Ownership and delegation
Winter	Peer Technical Design Review	Technical depth
Spring	Run an Acceptance Pass	Ownership and delegation
Spring	Learn from Patrick Winston	Communication

Browse AI practice and communication when these run out.