Your agent starts out able to read files, run shell commands, and search — tools are how it reaches past that baseline to touch the outside world. Ada and Boris explain what a tool actually is, then unpack MCP, the Model Context Protocol: the open standard — think "USB for AI agents" — that lets one agent plug into any external system instead of everyone hand-wiring bespoke integrations, whether over local stdio or remote HTTP, and exposing tools, resources, and prompts. The catch: every tool's description is loaded into the context window before you type a word, so five perfectly useful tools quietly tax the counter and can make the agent slower and dumber. They close hands-on, wiring up an MCP server in Claude Code from the CLI and the .mcp.json file.
From Chapter 7 of *Harness Engineering for Vibe Coders* by J.M. Crider — hamiltonroadagility.com/vibe
## Chapters
- 0:00 — Intro- 1:43 — What a tool really is- 3:36 — MCP the universal plug- 5:43 — The hidden context tax- 7:33 — Wiring it up- 9:21 — Recap- 10:34 — Wrap-up

Knowing what belongs in an AGENTS.md and actually writing a good one are two different skills. Ada and Boris cover the four cardinal rules: keep it under sixty lines (research out of ETH Zurich found that agent-generated instruction files actually degraded performance by over twenty percent), be concrete instead of abstract, make it iterative, and don't duplicate what a linter already enforces. They walk through progressive disclosure — giving the agent the essentials up front and pointing to deeper docs only when needed — plus what never belongs (decision history, aspirational goals, personality instructions, full directory trees), and the correction-to-rule feedback loop that lets the file learn a project's failure modes from Day 1 through Month 3. They close with a quick naming note on how CLAUDE.md, AGENTS.md, and .cursorrules are the same idea under different filenames.
From Chapter 6 of *Harness Engineering for Vibe Coders* by J.M. Crider — hamiltonroadagility.com/vibe
## Chapters
- 0:00 — Intro- 1:28 — The Four Cardinal Rules- 3:17 — Progressive Disclosure- 4:56 — What Doesn't Belong- 6:39 — The Feedback Loop- 8:35 — Recap- 9:53 — Wrap-up

Every major coding agent automatically reads one file before it looks at a single line of your code — Claude Code reads CLAUDE.md, Codex reads AGENTS.md, Cursor reads .cursorrules. It's the one piece of context you're guaranteed the agent has every session, which means every line in it competes for space the agent needs to read your actual code. Ada and Boris break down the six things that actually belong in that file: build and test commands (the highest-impact section, because it lets the agent verify its own work instead of guessing), project structure as a mental model rather than a file listing, coding conventions the linter doesn't already catch, the three to five most critical architecture rules, git workflow, and a Common Mistakes section that starts empty and grows with every real correction.
From Chapter 6 of *Harness Engineering for Vibe Coders* by J.M. Crider — hamiltonroadagility.com/vibe
## Chapters
- 0:00 — Intro- 1:39 — The File the Agent Always Reads- 3:39 — Build and Test Commands- 5:20 — Structure, Conventions, and Architecture- 7:11 — Git Workflow and Common Mistakes- 8:37 — Recap- 9:51 — Wrap-up

Writing your architecture rules down isn't enough — under pressure, an agent will quietly skip them, the same way a painter drifts past their own tape line. Ada and Boris walk through the three levels of enforcement that actually hold: documentation the agent reads, a custom linter whose error messages double as fix-it instructions, and a CI/CD gate that guarantees nothing broken ever reaches main. They unpack the single machine-readable architecture file all three levels read from — including the banned-patterns section that catches behavioral violations layer rules alone can't — then walk a concrete before-and-after: the same model building a "delete user" feature two ways, once with five architecture violations in one feature, once clean and testable because the harness forced the right shape. They close with the mistakes teams make wiring this up, and why every constraint should be built to be removed later.
From Chapter 5 of *Harness Engineering for Vibe Coders* by J.M. Crider — hamiltonroadagility.com/vibe
## Chapters
- 0:00 — Intro- 1:42 — Three Levels of Enforcement- 3:38 — The Architecture File- 5:21 — Before and After- 7:36 — Common Mistakes- 9:04 — Recap- 10:08 — Wrap-up