Outgrowing the Vibe Code

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

An agent has no institutional memory — every session it re-infers your codebase's structure from whatever code is in context. That means the erosion that takes a human team a year can happen in a single day. But constraints don't slow agents down; they make them faster. Ada and Boris walk through the foundational design pattern that turns this dynamic in your favor: layered architecture (presentation, application, domain, infrastructure), where dependencies flow downward only and the domain layer depends on nothing, giving the agent a deterministic answer to "where does this code go?" They cover the machine-readable can-depend-on mapping that lets a linter enforce these rules automatically, and bounded domains — vertical slices by business area that keep each domain self-contained and directly address the context overflow problem from Part One.
From Chapter 5 of *Harness Engineering for Vibe Coders* by J.M. Crider — hamiltonroadagility.com/vibe
## Chapters
- 0:00 — Intro- 2:15 — Architecture Erodes at Agent Speed- 4:10 — The Four Layers- 6:19 — Making the Architecture Machine-Readable- 8:04 — Bounded Domains- 10:15 — Recap- 11:27 — Wrap-up

Becoming a harness engineer doesn't mean starting over — it means your skills get re-weighted. Ada and Boris break down what stays critical (code comprehension, architecture, debugging, domain knowledge), what becomes newly critical (specification writing, constraint design, feedback-loop design, triage at scale), and what matters less than it used to (typing speed, memorizing syntax, writing boilerplate). Then come the four mindset shifts the job actually demands: from "how do I build this" to "how do I describe this so it gets built correctly"; from "fix the bug" to "fix the system that allowed the bug"; from "write it perfectly" to "iterate rapidly"; and from "I am the coder" to "I am the architect." The episode ends by naming what Part I established across four chapters — and what Part II will build, one harness component at a time.
From Chapter 4 of *Harness Engineering for Vibe Coders* by J.M. Crider — hamiltonroadagility.com/vibe
## Chapters
- 0:00 — Intro- 1:45 — Your Skills Just Got Re-Weighted- 4:05 — The Four Mindset Shifts- 6:10 — The Emotional Side- 8:08 — From Why to How- 9:36 — Recap- 10:40 — Wrap-up

The first three chapters made the case — the bottleneck isn't the model, it's the harness. Now the question is: what does building that harness actually look like on a real day? Ada and Boris walk through the full shape of harness engineering work: two complementary halves (environment building and work management) that run simultaneously, and the central reflex that defines the job — when something breaks, don't fix the code, ask what structural change would prevent the whole class of problem. The episode walks a concrete day: morning PR review where one bad PR becomes two permanent linter rules, mid-morning spec writing as the new coding, four parallel agent sessions with a fixation-loop diagnosis, and late-afternoon entropy management. End of day: eight changes merged, zero lines of application code written — and a harness that's better than it was that morning.
From Chapter 4 of *Harness Engineering for Vibe Coders* by J.M. Crider — hamiltonroadagility.com/vibe
## Chapters
- 0:00 — Intro- 1:48 — The Two Halves of the Job- 3:36 — Morning — Review and Merge- 5:45 — Spec Writing and Parallel Sessions- 7:53 — Entropy and the End of Day- 9:56 — Recap- 11:03 — Wrap-up

Here's the counterintuitive truth: giving an AI agent fewer choices makes it perform better. Vercel ran the experiment — 15 tools, 80% accuracy; 2 tools, 100% accuracy. Ada and Boris dig into why: every decision an agent makes costs tokens, and when the harness narrows the decision space, the agent spends its reasoning on the actual problem instead of navigating the meta-problem of how to approach it. The episode covers what this means practically — stop waiting for the next model, invest in the harness you have, and reframe every frustration as a harness problem — plus the "build for deletion" principle: design each harness component to be cleanly switched off as models improve, so your investment is progressively simplified, never wasted.
From Chapter 3 of *Harness Engineering for Vibe Coders* by J.M. Crider — hamiltonroadagility.com/vibe
## Chapters
- 0:00 — Intro- 1:55 — The Decision Space Problem- 4:08 — Invest In The Harness Now- 6:09 — Build For Deletion- 8:02 — The Recurring Traps- 9:47 — Recap- 11:02 — Wrap-up

The model is brilliant — but it starts every session from a blank slate, can't enforce its own boundaries, can't grade its own work, and doesn't know what it shouldn't touch. Ada and Boris name the six things an agent structurally can't provide for itself — persistent memory, architectural constraints, verification mechanisms, tool access, curated context, and governance — and show exactly what the harness has to supply in each case. The episode lands on the formula that holds the whole framework together: Agent = Model + Harness. If you're not the model, you're the harness — and that reframe changes what your job as an engineer actually is.
From Chapter 3 of *Harness Engineering for Vibe Coders* by J.M. Crider — hamiltonroadagility.com/vibe
## Chapters- 00:00 — Intro- 01:50 — Three things the agent starts without- 04:32 — Three more the harness supplies- 07:13 — Model plus harness- 09:22 — Your job just changed- 11:15 — Recap- 12:27 — Wrap-up

Every time the agent does something dumb, there's a comforting little prayer: the next model will fix it. Ada and Boris open Chapter 3 by showing why that's backwards — AI coding has compressed three eras into three years (prompt engineering, then context engineering, then harness engineering), and a frontier model that scores 90%+ in a clean test still falls apart on real work. Not because it can't reason, but because it's a brilliant new hire dropped in with no onboarding, no tests, no guardrails. With three receipts — LangChain jumping 13.7 points by changing only the harness, Vercel going 80% to 100% by cutting fifteen tools down to two, and the APEX-Agents benchmark exposing a 24% real-world pass rate from orchestration failures — they land the pattern: once a model crosses the capability threshold, more intelligence has diminishing returns while every harness improvement compounds across every future session.

From Chapter 3 of *Harness Engineering for Vibe Coders* by J.M. Crider — go deeper at hamiltonroadagility.com/vibe