The Missing Semester of Agentic Coding
MIT's fundamentals course finally added a lecture on agents. The mechanics you already know — here's the toolkit around them: context management, MCP, parallel agents, and where to stop trusting the confident answer.
Four rungs, one ladder
MIT's course has students do the same task four ways — hand coding, autocomplete, inline chat, agents — before touching agents seriously. Doing that comparison yourself is worth more than any explanation: each rung trades a little control for a little leverage, and the trade is easy to feel once you've done all four back to back.
You write every character. Total control, slowest, and every bug is unambiguously yours to find.
The editor guesses the next few tokens as you type. Saves keystrokes. It never restructures anything — it just finishes your sentence.
You highlight a block and ask a question or request a patch. You still apply every edit yourself — it answers, you decide.
You describe the outcome. The harness reads files, edits them, runs checks, and loops on its own until the check passes — you review the diff at the end.
You've already met the "manage it like an intern" idea in module 1. MIT's version adds the missing piece: the intern only becomes useful once you've picked the right rung for the job. A one-line rename doesn't need an agent. A cross-cutting refactor probably does.
The context management toolkit
Every model has a fixed context window. MIT's course names four specific tools for keeping it clean, beyond just "don't paste too much":
A project README written for the agent, not for humans. It loads automatically every session, so you stop re-explaining the same project quirks each time you open a new thread.
A library of instructions the agent only opens when a task actually calls for it. The baseline context stays small; the specialized knowledge is there when needed and invisible when it isn't.
A separate agent with its own context window, given one bounded job — research a library, summarize a spec — that reports back a short answer instead of handing you its entire scratchpad.
A plain-text index some sites now publish specifically for agents to read — the same information as the human page, at a fraction of the tokens.
Once a single conversation itself gets long, there are three different moves — and they are not interchangeable:
Nothing about the old thread applies to the new one. Wipe it and start clean rather than dragging dead weight into a fresh task.
Go back to an earlier point in the thread and give a different instruction, instead of piling a correction on top of a correction on top of a mistake.
The harness can auto-summarize a long thread when it gets too full. It works, but a fresh clear beats a compacted mush — same lesson as module 1's "start fresh over compacting," from a different source.
Two ways to give an agent new hands
A model that can only talk is not useful for engineering work. Two mechanisms give it hands: the shell it already has access to, and MCP, a way to plug in tools it doesn't.
"Find every file under this
folder untouched in 30 days,
and show me how big each one
is."find . -mtime +30 -exec ls -lh {} \;
You didn't need to remember the flag for "older than N days," or that -exec is how you chain a second command onto the results.
This is shell replacement: natural language in, the actual command out, and you can still read exactly what ran before you trust it.
The shell already exists on every machine, so agents got that for free. MCP standardizes the same pattern for everything else — a company's internal API, a project-management tool, a database. Build the connector once, and it works with any MCP-compatible agent, not just the one it was written for. The lecture's example: a Notion MCP lets an agent read a spec straight out of Notion and turn it into an implementation plan. Discovery directories like Pulse and Glama exist specifically for browsing what's already built before you write your own.
Running more than one agent at once
Nothing stops you from pointing several agents at the same repo at the same time — but "nothing stops you" and "it goes well" are different claims. Three habits from the lecture make it go well:
Each agent gets its own working directory checked out on its own branch, all sharing one repo's history underneath. No two agents can edit the same file on disk at the same moment, because they aren't in the same directory.
Fully autonomous, walk-away runs — "yolo mode" — belong in a container or VM with its own filesystem and no real credentials in reach, not directly on your main machine. If it goes off the rails, the blast radius is a throwaway environment, not your laptop.
Running the CLI on your own machine doesn't mean your code stays there — the model doing the actual inference almost always runs in someone else's data center. Self-hosted open-weight models exist, but need hardware most people don't have.
This is the same isolation instinct behind Embry0's per-task git worktrees and the sandboxed "yolo mode" environments used for AFK loops elsewhere in this stack. MIT is teaching the general version of a habit you already rely on.
Confident is not the same as correct
The lecture names a specific failure mode directly: an agent can run an unproductive debugging spiral while sounding completely sure of itself at every step. Watch how this actually reads:
One failed fix is normal iteration. A second confident "fixed it" that still fails is the pattern to distrust — the agent's tone doesn't change whether it's right. Stop, read the actual raw output yourself, and redirect instead of letting it try a third guess on its own momentum.
The course page cites specific artifacts — a real PR number for a sidenotes feature, specific commit hashes for a typo pass, a named student demo project. Those came through a summarized fetch of the lecture page, not a byte-for-byte re-verification against GitHub, so treat them as illustrative course flavor rather than facts to cite elsewhere. The durable part underneath is not course-specific: review every AI-written line for correctness and security before it ships, and remember — in MIT's own words — "there's still a huge class of programming tasks that AI is still incapable of doing."
Check yourself
Three questions on the toolkit and the judgment calls around it.
A teammate asks: "why bother with MCP — why not just teach the agent to call our internal API directly?"
What's the real reason MCP is worth using?
You want to run two agents on two different features from the same repo, at the same time, without them clobbering each other's edits.
What should you set up first?
An agent has said "fixed it" twice in a row, sounding equally sure both times. The same test still fails.
What's the right move now?
Pick one real project and write it an AGENTS.md or check its CLAUDE.md for gaps — the one thing the agent can't know by reading the code alone. Then next time you catch yourself piling a third correction onto a failed fix, rewind instead: go back, and give the instruction differently.