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

Your agent says "done" with total confidence — but can you trust it? Ada and Boris close out the failure-modes chapter with the two trust failures: the fixation loop, where the agent fixes one thing and breaks another round after round because nothing checks the whole picture, and confidence without verification, where every answer arrives equally certain even when the agent is flat-out wrong (and will happily agree with you to boot). Then they step back to the big payoff: all eight failures across the chapter are one root cause — the agent isn't broken, it's unsupported, like a brilliant new hire dropped into an empty room. The fix clusters into four kinds of infrastructure — documentation, architecture, verification, and context management — the four pillars every harness is built from.

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

Your agent's code can look perfect and still rot from the inside. Ada and Boris walk through the three ways it happens: the copy-paste explosion — the agent reinventing the same little utility instead of reusing yours, at roughly eight times the duplication rate of human-written code; phantom completions — features it cheerfully calls "done" that were never actually run; and architecture erosion — a clean, layered design quietly collapsing as the agent takes one shortcut after another. The through-line: every one is invisible at the level of a single change and only shows up when you step back and look at the whole project.

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