Capstone

AI-Assisted Programming for PhD Researchers

The capstone is your own project. You take a problem from your own research, point an agent at it using the workflow you practiced on the lab pipeline (spec, plan, implement, verify), and show the result to the room Day 3 afternoon.

The Assignment

Build something you actually want. You scope it Day 2 at 15:00, during the “Your Research Project” session, build it Day 3 morning, and show it Day 3 afternoon. If you do not have a suitable project of your own, pick one of the two options below; both fit the time and reuse pieces you already built in the labs.

Requirements

Core finishable in about 2 hours. That is the real build time Day 3 gives you, once you subtract the break and the Lecture IX inserts that interrupt Project Development II. Scope down until the core fits; add stretch goals on top, not instead.
A verifiable output. A figure, a table, or a passing test suite that someone else can check against your acceptance criteria without taking your word for it.
Uses the workflow. Spec → plan → implement → verify, the same sequence from Lecture 04 and Lab 2, applied to your own problem instead of the shared pipeline.
Git history tells the story. Small, verified commits rather than one giant commit at the end. It saves you preparing anything for the afternoon: the log is the story.

Your Spec

Start with this skeleton. Write it before you write any code: it is the contract you build against, and it is what you open in the afternoon when you talk about how you worked.

# Spec: [your project name]
Goal: [one sentence: what does this produce, for whom]
Why this matters for my research: [one or two sentences]
Inputs & outputs: [what goes in, what comes out]
Acceptance criteria:
- [ ] [checkable: you can look at the output and say yes/no]
- [ ] [checkable]
- [ ] [checkable]
- [ ] [checkable]
Out of scope: [what you are deliberately not doing]
Stretch goals: [what you'd add if the core finishes early]

Every acceptance criterion should be something you can check by looking at the output, not a description of effort. “Produces a deduplicated BibTeX file with 0 duplicate DOIs” is checkable; “handles deduplication well” is not.

Write a short plan alongside the spec: the steps you (and the agent) will take to go from spec to implementation. By 16:30 on Day 2, get both reviewed. A fresh agent session or a neighbor should be able to poke holes before you build tomorrow. I come around during the session, so grab me too.

Option A: Literature Manager

No project of your own in mind? Build a small tool that cleans up a reference list, using the reference-lookup skill from Lab 5 Task 3.

Input: a messy .bib file or a list of DOIs.

Pipeline: parse the input → fetch metadata the way the reference-lookup skill does (OpenAlex, cross-checked against Crossref) → deduplicate (by DOI, then by fuzzy title match for entries without one) → emit a clean BibTeX file plus a markdown reading list grouped by topic.

Try it against the sample: the starter repository ships capstone/liter/sample.bib: 20 entries with 3 planted duplicates (same paper, different key or formatting) and 2 entries with deliberately broken DOIs. A good acceptance criterion: your tool round-trips this file down to 17 unique entries and flags the two dead DOIs and proposes the corrected ones, instead of silently dropping or mishandling them.

Option B: Parameter Study

No project of your own in mind, and prefer simulation over literature work? Build a small parameter sweep.

Pick one small model:

M/M/1 queue: Poisson arrivals at rate λ, exponential service at rate μ, utilization ρ = λ/μ. Expected number in system L = ρ/(1−ρ); expected wait W = L/λ. Stable only for ρ < 1.
SIR epidemic: dS/dt = −βSI/N, dI/dt = βSI/N − γI, dR/dt = γI, with basic reproduction number R₀ = β/γ.

Sweep two parameters over a grid (for the queue: λ and μ; for SIR: β and γ), produce a heatmap of a summary statistic (mean wait time; peak infected fraction) across the grid, and a findings table summarizing the interesting cases.

Acceptance ideas: results are deterministic under a fixed random seed, and the heatmap is regenerable by a single command (for example python run_sweep.py --seed 42).

Working Mode Day 3

09:00: build the core. Follow your spec; don’t add anything not on it.
11:00: is the core done? If yes, start a stretch goal. If not, stop adding scope and get what you have into a working state.
12:15: stop. Whatever runs at that point is what you show.

I am in the room all morning. Pull me over when the agent does something strange, when you are unsure whether to trust an output, or when you want a second opinion on scope. That is the part of the day that is hardest to get from a website.

Nothing needs preparing for the afternoon. See Showing Your Work for how the session runs.