A project is where the four competencies the lectures build — theoretical mastery, technical fluency, AI-augmented implementation, and critical validation — meet a real research problem. There are four tracks; pick one.
Each is scoped for a few weeks of part-time work, alone or in a small group, and each rests entirely on public data. Nothing here needs a grader: the tracks come with their own validation checklists, so you can tell for yourself whether the thing works.
The one rule that governs all four tracks: replicate first, explore second. Your baseline deliverable is to faithfully reproduce and verify a known result — a classical solution, a published number, a documented benchmark — on public data or at small scale. Finding “something more interesting” is the stretch goal, and it only counts once the replication validates. This mirrors how real research works, and it is how Lectures 9–10 teach you to use AI: build the trusted benchmark, then extend.
Each track serves a different research taste, and each connects to an active research area in the field. Click a card to jump to its full description.
Solve the workhorse growth model with a neural net; verify it against the classical solution.
Best if you like macro modeling, dynamic programming, PyTorch. Builds on Lec 3, 4, 5.
Read Track A →Construct & validate a task-level AI-exposure index from public data.
Best if you like empirical work, data engineering, labor/macro. Builds on Lec 2, 7, 10.
Read Track B →Turn a text corpus into a validated quantitative measure with a small RAG.
Best if you like NLP, measurement, finance/policy text. Builds on Lec 7, 8.
Read Track C →Build a small typed-retrieval system or a validated agent skill.
Best if you like tooling, retrieval, methodology. Builds on Lec 8, 9, 10.
Read Track D →Every lecture pushes one idea: you are the Research Architect. AI handles the bricks — syntax, boilerplate, data wrangling, refactoring — while you own the theory, the validation, and the interpretation. A project succeeds in that spirit. Code an agent wrote is not the achievement; a correct result you can defend, a benchmark you verified by hand, and a clear account of who did what — that is.
The 5-pillar workflow from Lecture 9 is your scaffold on every track:
These hold on every track, and the self-assessment is built directly on them.
Use Claude Code, an IDE agent, or a chat model across the whole pipeline: scoping, data acquisition, coding, debugging, drafting. That is the point of the course. What does not count is shipping anything you cannot read, explain, and defend.
AI_LOG.md)Keep a short running log of the substantive ways you used AI: the prompts that mattered, the decisions you made, where the AI was wrong and how you caught it, and an honest split of human vs. AI contribution. This is the artifact that shows you were the architect — and, months later, the only record of why the code looks the way it does. A trimmed transcript export is fine as an appendix.
For every headline result:
β ∈ (0,1);
Euler-equation errors below threshold; an index's occupation ranking passes the smell
test; signs match theory).Public data only (see each track's data section). No PII,
IRB-, or HIPAA-protected data. No API keys committed to the repo (.env +
.gitignore). Cite every source; distinguish your contribution from prior work
honestly. One command should reproduce your results: provide git history, fixed
random seeds, an environment.yml/requirements.txt, a
CLAUDE.md describing the project for the next agent (and human), and a
README with run instructions.
Aim for a complete reproducibility package — the same bundle a journal or a co-author would ask for:
CLAUDE.md, README, pinned
environment, fixed seeds, and one-command reproduction.AI_LOG.md — the AI-collaboration log./review-paper skill: cite exact passages,
assert only what you can support, separate “must fix” from
“suggestions,” and stay constructive. Reviewing someone else's replication is the
fastest way to see the holes in your own.Not a grade sheet: a way to check you spent your effort where it matters. The weights say how much each dimension should shape the project, and roughly what a strong one looks like.
| Dimension | Weight | What a strong project shows |
|---|---|---|
| Economic framing & question | 15 | A precise, well-motivated question; correct estimand/equilibrium concept |
| Replication correctness | 20 | The baseline reproduces the benchmark/known result and is verified |
| Validation rigor | 20 | Hand-checks, benchmarks, sanity checks; honest about what failed |
| Reproducibility & provenance | 15 | One-command repro; clean data pipeline; pinned env |
| AI-collaboration quality | 10 | Architect, not consumer; informative AI_LOG.md; honest attribution |
| Communication | 10 | Clear write-up & talk; figures that tell the story |
| Peer review quality | 10 | Specific, fair, well-evidenced referee report (if you do one) |
| Stretch finding | +10 (bonus) | A credible, validated extension beyond replication |
A project that only replicates — but does so correctly, with rigorous validation and clean reproduction — is a success. The stretch is upside.
Each track follows the same template: Pitch · Who it's for · Connections · Goal · Baseline (replicate & verify) · Stretch · Data · Tools · AI-usage guidance · Validation checklist.
Pitch. Solve the single workhorse of dynamic macro — the optimal growth model — with a neural network, and prove it is right by lining it up against the classical value-function / Euler-iteration solution.
Who it's for. Students drawn to macro modeling, dynamic programming, and PyTorch; people who want to understand a deep-learning solver rather than treat it as a black box.
Connections. Lecture 3 (neural nets, training), Lecture 4 (the
optimal growth model is the running example; Euler-equation-as-supervised-loss; actor–critic),
Lecture 5 (RL framing; Bellman, VFI vs. Euler iteration). The Lecture 4 dynamic-model labs
(Lab4A/4B_Dynamic_Models.ipynb, on the Labs page) are your
starting point.
Goal. A neural solution to the deterministic (then optionally stochastic) optimal growth model whose Euler-equation errors are at or below the classical benchmark, with a written account of the method and its accuracy.
Baseline — replicate & verify.
Σ βᵗ u(cᵗ)
subject to kₜ₊₁ = f(kₜ) − cₜ, with CRRA
utility and Cobb–Douglas production. State the Euler equation
u'(cₜ) = β f'(kₜ₊₁) u'(cₜ₊₁).c = πθ(k)
(and/or value Vθ(k)) with a small network. Train it two ways and compare:
Euler-equation-as-supervised-loss (minimize the mean squared Euler residual
on sampled states — Lec 4, T3) and actor–critic (critic
learns V, actor improves π — Lec 4, T2).Stretch (modest, pick one). Add a stochastic TFP shock
(zₜ Markov) and re-validate; add a second state (a second
capital good or a simple labor choice); or an AI-as-capital / automation twist
— a productivity shift that raises the return to capital, traced through the savings policy
(a thematic bridge to Track B).
Data & tools (all public). The Lecture 4 lab notebooks; QuantEcon Cass–Koopmans and the QuantEcon lecture series; Maliar, Maliar & Winant (2021), Deep learning for solving dynamic economic models (JME). Python, PyTorch (autograd for Euler residuals), NumPy/SciPy, Matplotlib; an agentic coding tool to scaffold the solver and validation harness — then you read and verify every line.
AI-usage guidance. Let the agent write the boilerplate. You own the
Euler-residual loss derivation, the sampling distribution over states, and the accuracy comparison.
A great AI_LOG.md shows the agent proposing a subtly wrong loss and you catching it
with the classical benchmark.
Validation checklist.
Pitch. Build, on fully public data, a task-level index of AI exposure across occupations, and show it holds up against external benchmarks.
Who it's for. Empiricists and data engineers; students interested in AI & labor markets, the economics of automation, and measurement.
Connections. Lecture 2 (AI as cognitive capital; measuring AI exposure via task-level deployment, Anthropic Economic Index × O*NET), Lecture 10 (Case 2 MEPS — the agentic empirical pipeline: discover data → harmonize → weight → validate against an external benchmark). This is measurement work of exactly the kind the AI-and-labor literature is now built on.
Goal. A reproducible pipeline that produces an occupation-level AI-exposure index, plus a short validation showing it behaves sensibly and lines up with published measures.
Baseline — replicate & verify.
G, its magnitude |G|, and an effective
task fraction 1/Herfindahl) and an importance-weighted usage
intensity.Stretch (pick ≥1). Link to employment — merge with IPUMS-CPS (or BLS OES) and estimate whether the index predicts employment-share change (WLS, robust SEs); probe whether the effect is an interaction (usage × concentration), concentrated in some demographic groups, or appears in the household survey but not payroll. Or improve the index — add O*NET task-frequency weighting, build a time-varying version across index releases, or test robustness to weighting and time-window choices.
Data & tools (all public). Anthropic Economic Index (HF) · O*NET · IPUMS-CPS · BLS OES · FRED · Eloundou et al. (2023), GPTs are GPTs. Python, pandas, statsmodels/linearmodels (WLS, robust SEs); an agent for the acquisition + harmonization pipeline — exactly the MEPS-case workflow.
AI-usage guidance. This track lives or dies on crosswalk and weighting
correctness, precisely where agents make silent errors. Let the agent build the
download + merge pipeline; you verify every join, re-derive one occupation's index by
hand, and validate totals against an external source. Your AI_LOG.md should highlight
a crosswalk or weighting bug you caught.
Validation checklist.
Pitch. Turn a corpus of economic text into a quantitative measure — a policy-stance index, a firm-level exposure score, a narrative index — and prove it works by validating against an external benchmark. Build a small RAG pipeline along the way.
Who it's for. Students interested in NLP, measurement, finance, and monetary/policy text.
Connections. Lecture 7 (tokenization, embeddings, transformers, LLMs as measurement instruments; FinBERT vs. CentralBankRoBERTa; the validation checklist), Lecture 8 (RAG: chunking → embeddings → vector store → retrieval; RAGAS evaluation). The Lecture 7–8 FOMC labs are your starting point.
Goal. A measurement instrument that reproduces a known text-based result and is validated against an external benchmark — plus a small RAG pipeline over the same corpus for question-answering / retrieval.
Baseline — replicate & verify (pick one corpus & target).
Steps: (1) acquire and clean the corpus; (2) build the measure two ways — a lexical / TF-IDF baseline and an embedding-based version — and a small RAG pipeline (chunk → embed → FAISS/Chroma → retrieve → grounded answer); (3) validate: embedding-geometry sanity checks, correlation with the external benchmark, and an out-of-sample / held-out-period test; (4) audit for bias and, for the RAG component, evaluate faithfulness with RAGAS.
Stretch. A novel index, a multi-corpus comparison, or a head-to-head that surfaces where the embedding measure beats (or loses to) the lexical baseline and why.
Data & tools (all public). FOMC materials · SEC EDGAR · BIS speeches · FRED. Models: FinBERT, CentralBankRoBERTa, sentence-transformers. RAG stack: FAISS, Chroma, RAGAS, Lewis et al. (2020), RAG.
AI-usage guidance. Embeddings and RAG make it easy to get a plausible-looking number that means nothing. You own validation: does the embedding geometry pass known analogies? Does the measure correlate with the benchmark out of sample? Is the RAG answer faithful to the retrieved text (RAGAS), or hallucinated? Document a case where the naive measure looked fine but failed validation.
Validation checklist.
Pitch. Build a piece of research infrastructure: either a small condition-aware GraphRAG over an economics literature, or a reusable, validated agent skill for a recurring research task.
Who it's for. Students who like tooling, retrieval systems, evaluation methodology, and the meta-question of how AI should be wired into research.
Connections. Lecture 8 (RAG, GraphRAG, and the GRAM case study — “wrong-by-prominence” vs. condition-aware retrieval), Lecture 9 (project harness; skills, agents, rules; validation gates), Lecture 10 (Case 1 paper-review skill).
Goal. A small but genuinely working artifact with a measured comparison against a sensible baseline. Choose one flavor:
/replicate-table,
/solve-model (the 5-step model→equilibrium→algorithm→
pseudocode→code workflow), or /referee.Data & tools (all public). Corpus: arXiv /
NBER / RePEc PDFs;
extraction MinerU or pypdf;
retrieval with open embeddings (sentence-transformers, bge),
FAISS /
Chroma,
Microsoft GraphRAG,
HippoRAG;
Claude Code and the
Lecture 9 project-harness patterns.
AI-usage guidance. This is the most “meta” track — you are
engineering how AI does research. The Lecture 9–10 discipline is the deliverable:
confidence gates, quote verification, validation harnesses, honest evaluation. Your
AI_LOG.md should read like an engineering log of the harness itself.
Validation checklist.
Alone or in a small group. Two to four people works well, with mixed skill sets (one strong on theory, one on data/code). Solo is entirely feasible — scope the stretch goal down, not the validation.
| Stage | Done when |
|---|---|
| M1 — Proposal | One page: track, question, the specific result you will replicate, data sources, division of labor. |
| M2 — Data / infra up | Acquisition pipeline runs end-to-end; benchmark/ground-truth in hand; CLAUDE.md + repo scaffolded. |
| M3 — Replication verified | Baseline result reproduced and validated — the core of the project. Stretch scoped. |
| M4 — Write-up, repo, talk | Full reproducibility package assembled; peer review exchanged if you have a partner. |
Use your agent to plan, then you decide. For example:
I'm doing Project Track <A/B/C/D>. The result I want to replicate first is
<X>. Help me: (1) restate it precisely (estimand or equilibrium concept);
(2) list the exact public data/inputs and how to fetch them by script;
(3) propose a minimal pipeline; (4) propose how I will VALIDATE the
replication against a known benchmark before I attempt any extension.
Do not write the full solution yet — I want the plan, and I will verify it.AI_LOG.md and your validation results at every milestone — those two
documents, not the amount of code, tell you whether the project is actually progressing. If you
cannot name the benchmark your result is checked against, that is the next task.