Your Deep Agents build is the CS50P final project. Submit it as such if you want the certificate later. It's the only part of the course with no starter file, no given signature, and no spec — which is exactly why it's the real work rather than an assignment.

6.006 is an MIT sophomore course that lists discrete mathematics as a prerequisite, and lecture one opens with models of computation and proving solutions correct. Coming off CS50P you'd burn your energy fighting the framing rather than learning the structures — and the framing isn't what you're here for yet.

The Runestone book is built for exactly this gap. Its own preface says it assumes you may still be struggling with basics from a first course and are ready to go further anyway. It's Python, it's free, and the code runs in the browser, which suits how you learn better than a lecture hall recording does.

6.006 isn't discarded — it moves to week six, as a sharper second pass over material you've already built. Read that way it lands as tightening rather than teaching. And the proofs it does are the ones you'll be equipped for after Phase 02.

Handed an unfamiliar problem, your first instinct is to ask what structure it wants — and you're usually right.

The concrete test: twenty problem statements you haven't seen, and for each one you name the structure and justify the choice in a sentence, without solving any of them. If you're above sixteen, you're done. Below twelve, you skipped the implementing.

When you're stuck on a proof, the question is almost never "what's the clever idea." It's "which shape is this." Work down the table: can I go direct? Is the contrapositive easier? Is there a smallest counterexample to rule out? Is there a recursive structure to induct on?

Nine times in ten, choosing the right shape does most of the work, and the rest is bookkeeping.

Not typed. Handwriting is slower, and the slowness is the mechanism — you can't autocomplete your way past a step you don't understand. This is also the one phase where the assistant does the most damage. Struggling with a proof is how the skill forms; watching someone else's finished proof is how you learn to recognize proofs without being able to write one.

Hammack develops proofs the way you'd actually think them through rather than presenting them finished, and there are fully written-out solutions in the back. That combination is the whole reason it's the right book here — but only if you write your attempt before you look. Reading a worked proof feels like learning and isn't.

Given a recursive function, you can write a correctness proof by induction without a template in front of you.

The concrete test: take a recursive function you wrote in Phase 01 that you haven't proved anything about — the BST search, or the recursive flatten. State precisely what it returns, then prove it. Base case, inductive hypothesis, inductive step, no reference material. If you can do that in twenty minutes, Phase 03 will work.

Each week's twenty-minute task is the minimum; the better version is a small implementation that uses the week's idea on data you care about. Karatsuba on big integers. Dijkstra on your own dependency graph. Edit distance on two versions of a file you wrote. It takes an hour and it's the difference between having read about an idea and having used one.

Go down the list, not to your favourite. The single most common failure is reaching for dynamic programming when a greedy choice is provably safe, or reaching for greedy when it isn't — and the second one produces code that passes your tests and is wrong.

When you can't tell, write the brute-force recursion first. It's always correct, it makes the subproblem structure visible, and if the subproblems overlap you've just discovered you're in dynamic programming territory. That path is the whole design of weeks 3 through 5.

You can look at a proposed system and give a defensible answer on whether it scales — before it's built.

The concrete test, in three parts. Given an unfamiliar problem: name the paradigm and justify the choice. Write the recurrence and solve it for a bound. And when the honest answer is that no efficient algorithm exists, recognise that and propose an approximation instead of searching for one that isn't there. The third part is the one that separates this from interview preparation.

When something is slow or wrong, walk down rather than sideways. Most debugging failure is staying at the language level — rereading your code — when the symptom is actually a cache miss, a page fault, a linker mismatch, or a cgroup limit. The symptom tells you the layer if you know what each one sounds like.

That's the whole reason this phase exists, and it's why the two layers you already met in Phase 00 sit near the top of the table rather than at the bottom.

You can profile something slow and form a real hypothesis about why, rather than guessing at the code.

The concrete test: take a program that's underperforming and, before changing anything, name the layer you think is responsible and say what evidence would confirm it. Then go get the evidence. Being right isn't the bar — having a falsifiable hypothesis instead of a hunch is.

The exit criterion for this phase is reading the linear algebra in an ML paper as description rather than as noise. That's a translation skill: the notation is dense, but it's describing operations on shapes, and the shapes are what you're building intuition for.

When you hit an unfamiliar expression, ask what it does to the space rather than what it computes. That question is answerable from four weeks of work; the arithmetic question mostly isn't, and mostly doesn't matter.

You can read the linear algebra in an ML paper as description rather than as noise.

The concrete test: open a paper on something you actually care about — retrieval, attention, embeddings — and read the equations. For each one, say what it does to the space in a sentence. You don't need to derive anything. If you can narrate the shapes, you're done.

You can write gradient descent from scratch on a function of two variables — no library, no reference — and explain out loud what every term in it is doing and why the minus sign is there.

That single program uses all four things this phase exists to give you: derivative as rate of change, the chain rule, partial derivatives, and the gradient. If you can write it cold, you're done. If you can't, you know exactly which of the four is missing.

Read the middle column first and ask which one describes your situation. Almost everyone reaches for the normal distribution by reflex, and it's frequently the wrong answer — latency isn't normal, retry counts aren't normal, and assuming otherwise is how confident people produce badly wrong estimates.

When none of the stories fits, that's real information too: it means you should simulate rather than reach for a closed form. Which is the whole method of this phase anyway.

You can quantify uncertainty in a system you built, and you reach for simulation before you reach for a closed form.

The concrete test: take a claim you'd want to make about your own work — this agent is better, this change reduced latency, this failure rate is acceptable — and state it with an honest interval around it. Say how many observations you'd need to believe it, and what would change your mind. If you can do that without looking anything up, the core is finished.

Nine months, 383 hours, eight phases. What comes next is on the electives page: probe three in mid-May, then one concentration with real depth. Neuromatch's prerequisites are Python, linear algebra, probability, statistics and calculus — you'll have finished the last of those the week before their July cohort opens.

Worth doing on the last day: reread the plan page. Not for nostalgia — to notice which of the things that looked hardest in August turned out not to be, because that recalibration is what you'll use to scope the next thing you decide to learn.

The concentration question and the business school question are the same question in different clothes. If the honest end state is research-adjacent work connected to neuroscience, an MBA is a strange instrument for getting there. If it's leading AI organisations, it's a very good one.

That's not a call anyone else should make. But notice the sequencing: probe one lands in early October 2026, probe two in March 2027, and the concentration in the summer. Every one of those produces information the Darden decision needs, and all of them arrive before it has to be made.

The worst version is deciding by default — letting the deadline choose because the probes never happened.