I built a harness that argues back
A dev harness for Claude Code, and the case for how it's built. Every claim here points at a running system, not a whiteboard.
A while ago I asked it to add a billing settings page. Nothing crazy - show a user their plan, and let them update a payment method. One view, and one new API call. This distills out to a feature request. So I did what most devs do these day - I asked Claude to make the needful. What Claude came back with had already pulled in a security review I never asked for. Payment data was in play, so the harness treated a security pass as mandatory, regardless of whatever I’d called the work. And, it was right, and I hadn’t thought about it in that moment.
And that’s the whole ~thing in one moment. I spent a good while building a dev harness for Claude Code, that I call core-dev, and the part I keep wanting to talk about isn’t the feature list. It’s that the thing has opinions, that I codified and force it exert, and it’s built so those opinions are expensive to ignore. It loads the skills a turn needs before I ask (a lot more reliably than out of the box Claude does). It blocks a commit of code nobody reviewed, or a secret I didn’t notice I’d staged. The judgment calls it leaves to me; the mechanical ones it takes off the table. Most of the time it stays out of the way, and when it doesn’t, it’s usually because I was about to do something dumb.
I’m writing this series because every one of those behaviors is a design argument, and I’d rather defend the arguments than document the buttons. It’s also the one thing most agent-tooling posts don’t offer right now: these aren’t predictions about how you should build a harness, they’re claims with a running system behind them. I built the thing, I’ve been wrong inside it plenty, and it pushes back on me in ways I want to show you.
You don’t need my plugin for any of this to make sense, I hope.. The questions underneath are the ones you hit anywhere an agent does the work - where a rule should actually live, what you let a model decide, what you never trust it with, and how you stop the agent that writes code from also being the one that runs it. I came down somewhere specific on each, and the posts are me arguing for where I landed.
Here’s the map, in order. I’ll update links to new posts as I get them published.
Cheers!
Make the right thing the default, and the wrong thing loud. You get better behavior by reducing the cost of the “right path”, not by forbidding the wrong one (hey, sometimes I just feel like stabbing myself in the eye, okay?)
Adherence is a budget. Every rule you write taxes every other rule, so route each one to the cheapest mechanism that will actually enforce it.
Plan, build, review. One feature walked from the first prompt to an open MR, with every guardrail firing in order. This is the guided tour, if you want the whole shape in one read.
A number is not a fact. A measurement isn’t mechanical just because it has a decimal point. When to gate, and when to \shrug.
The opinion with a decimal point. I built a check that looked like signal, measured it against reality, watched it predict nothing, and shipped the negative result straight into production.
If it isn’t written to disk, it didn’t happen. Just like PCAPs (or it never happened). Every step starts from nothing, so the only memory that survives is what gets written to a file.
No context holds both a shell and a pen. The one rule that is the security spine: the context that can write can’t run, and the one that can run can’t write.
The harness that tests itself. It fails open at runtime and fails closed in CI, and pointing its own review at itself caught a real bug.
Let the model decide only what it can’t get wrong. Hand the model the one judgment call it’s actually needed for, and wrap deterministic code around the rest.
Lean into the gate. A denied action isn’t the tool being difficult. It’s naming the step you skipped.
New pieces go up about once a week. If that sounds like your kind of thing, subscribe and I’ll send each one as it lands.