Our Claude Code Is Different—Same Horse, Different Harness

Why does my Claude Code feel so much better to use? The answer isn’t in the model—it’s in the harness.

What a harness is

Harness originally means the tack on a horse—the saddle, reins, and stirrups strapped onto it. In the AI world it refers to everything outside the model—rules, config, the memory system, tools.

Claude Code is itself a general-purpose harness, a systematized configuration Anthropic hands to everyone. What I’m covering today is the customization I added on top of that config for my own needs.

Three core concepts

Rules—rules of behavior, like law, like Dalio’s Principles. How the model talks to me, how it changes code, what it puts first when priorities collide—rules decide all of it.

Memory—project knowledge. What each project taught me, the operation history, the core of our conversations: compressed down to the meaning and saved as documents. A knowledge base the model can pull from any time.

Hook—I think of hooks as the police. Like rules, they constrain the model, but they’re harder—when this happens, this is what must happen next, no discussion. Rules are closer to moral guidelines, elastic; a hook is a hard interception, executed to the letter.

Beyond those there are settings documents holding environment variables and API keys, plus a layer I added myself, a notes system—memory is the memory the model reads, notes are the memory I read. Every time I finish an important project, the output and the lessons become an HTML page and get saved. Saving experience as web pages has quietly become standard practice, and Anthropic recommends it too.

Four defining traits

This system is the result of four months of repeated iteration, and it also borrows from the circle theory in Lao Jin’s Meta. Four traits stand out:

Organized by category—memory and everything else is filed by kind, not dumped into one bucket.

Executability over description—what counts is how the mechanism performs once it’s live, not how well designed it looks on paper.

The scar mechanism—incidents condensed into rules. Every time my work with the AI goes wrong, it logs the failure on its own. Failures that repeat get boiled down into a rule. If the rule still gets ignored, it escalates to a hook for hard interception. Incident to rule to interception, tightening at each step.

Deliberate forgetting—when a project ends, a config changes, a server isn’t rented anymore, the matching experience and memory get archived so the model stops retrieving them. That’s what keeps hallucinations out.

A rule in practice: the values ordering

I have 19 rules; I’ll go through four.

The first is the values ordering—when the model has to decide, it sorts by my values: honor, excellence, truth, beauty, efficiency.

The output doesn’t chase efficiency first, and it isn’t “just get something out.” What it weighs is whether the thing can stand as my work, and whether I’m satisfied with it. Tech selection and architecture design follow the excellence line, without worrying about compute cost or development difficulty. The truth principle keeps the model from flattering me. Back when I used GPT, in its telling I was Tesla or Edison reborn, and that makes a self-consistency trap easy to fall into. So I require the model to hold my proposals up against feasibility and hard criticism. Beauty is a demand on both me and the AI, and I pass my aesthetic standards along to it.

The one thing I left out is cost. You can’t really max out the subscription plan, so it isn’t a worry.

If you can look it up, don’t ask

Claude Code constantly stops mid-task to ask, “what’s the key? I don’t know it.” The keys are already stored somewhere safe. So the rule is: when you hit a question like that, go look it up—don’t come ask me.

Three levels of change

Changes split into L1, L2, L3. L1 is front-end page work that can’t break anything—just do it. L2 is a small feature touching three to five files; verify after the change, then ship. L3 is a new feature or a complicated process, and it goes through the full seven-step flow—clarify the requirements, research, plan, execute, test, and so on.

Livestream redaction

I livestream with Claude Code open a lot, and the terminal prints IPs, keys, emails, and other private information. So the model is required to never print that in plaintext on screen.

Twenty-three hooks

I’ve set up 23 hooks. One splits memory into the permanently fixed kind (height, blood type, genes) and the volatile kind (computer model, server keys), then spot-checks the volatile ones against reality on a schedule. Others tell it where credentials live, intercept dangerous commands, run automatic checks after a file is edited, and force a recap at the end of a task—any lessons from failures, any reusable experience, any new process.

On memory, Claude Code only reads the first 200 lines. Too much memory doesn’t just eat context; the model’s attention only stretches so far, so some of those memories never get used at all.

Parallel invention

Plenty of people say Claude Code is copying OpenCode, copying OpenClaw, copying Amazon. I don’t think that’s what’s going on—we’re in an era of parallel invention. We all have the same needs, and we built similar features in different ways at the same time. No need to care who copied whom. Good features getting absorbed into general-purpose tools is a good thing.

Where it fits and where it doesn’t

I didn’t design this harness up front. I hit problems while using it, asked Claude Code whether anyone else had solved them and whether best practices existed, then set things up step by step and checked that they held.

It fits a one-person team running many projects especially well. It doesn’t fit team collaboration—for teams I recommend Lao Jin’s Meta project.

The harness will eventually be internalized

The harness has been on its way out since the day it appeared. It will end up folded into the model’s own capabilities. Claude Code keeps updating too.

Claude Code vs Codex

Big argument lately—Claude Code or Codex? To me both are harnesses, both are tack. My logic is dead simple: pick the faster horse—and for now that’s Claude. Then adjust the harness myself so it fits what I need, instead of slapping on a stock saddle and riding a horse that doesn’t run fast enough.

Source: EP0019_audio.mp3 · ASR model gemini-2.5-pro (chunked parallel) · full text of the 12:02 original recording

[00:00] Why does my Claude Code look so good to use? Today let’s talk about the harness.

So what is this harness? Harness isn’t Hermes, not that agent tool. Harness originally means tack for a horse—the saddle strapped onto the horse, the reins, the stirrups, all of that.

[00:14] In the AI world, it refers to everything besides the model itself, everything outside the model. Including our rules, our configuration, our memory system, and some tools. All of that is harness.

[00:26] And Claude Code itself is a general-purpose harness. It’s Anthropic handing every one of us a setup, a systematic setup, for calling the model better.

[00:36] What I’m covering today is mine—on top of that setup, based on my personal needs and how I use it, the extra configuration I’ve built on it myself.

Three Core Concepts

[00:47] Before I get into the system, I’ll go over a few concepts. In Claude Code, the harness mainly has these pieces that we can adjust.

[00:53] The first is rules. These are behavioral rules—they’re like law, or like Dalio’s Principles. How do they work? How we communicate with the model, how it changes code, what priority order the model follows in its behavior—all of that is decided by the rules.

[01:13] The second is memory. Memory is project knowledge—for each project, what you’ve learned along the way, what’s been done to it before. It takes all of that, including the core content out of our conversation logs, runs a semantic compression over it, pulls out the most distilled and most important parts, and saves it as documents.

[01:36] So it’s like a knowledge base the model pulls from on demand, available to the model at any time.

[01:43] Next down is the hook. Why do I compare hooks to police? Because like rules, they’re also a tool for strictly constraining the model. But their constraint is more direct, it’s a harder requirement. If this thing happens, it has to be handled this exact way, it has to respond this exact way. And it’ll follow that to the letter.

[02:09] Whereas rules are a lot more flexible. They’re more like a moral code, or a set of principles and preferences. So the thing to remember is that a hook is a harder setting.

[02:19] Next down is the settings file. That file holds some of our environment variables, or our API keys. When you hit something where you need to look up a key or look up config, that’s the place to go find it.

The Notes Layer

[02:35] Beyond those four, I’ve actually added an extra layer. Claude Code originally called it docs, meaning documents. I now keep that separate, and I call it notes.

[02:45] The way to think about it: memory is memory for the model to read, and notes are memory for me to read. Every time I finish an important project, I take my deliverables or my lessons and turn them into an HTML page, saved into a specific folder. That folder is for me.

[03:05] Or you can see the notes from my last few episodes on my blog—those are the ones I share with others. Storing this kind of experience as a web page, as web files, has slowly become the norm, and Anthropic recommends doing it this way too.

Four Core Traits

[03:19] So that’s the basic architecture here, and it comes out of four months of repeated iteration and some hard lessons. Of course I also borrow from other people’s methodology—for example, the person I talk with a lot, or learn a lot from, is Lao Jin and his whole Meta framework.

[03:38] The distinctive parts in here: first, I manage memory and this information by category. And I make it so executability beats descriptiveness. What do I mean by that? What gets measured first is how this mechanism performs once it’s live, not how beautifully complete the design looks.

[03:59] Then there’s incidents crystallizing into rules—the scar mechanism. Whenever something goes wrong while the AI and I are working together, or an error comes up, it writes that into an error log on its own. If the same thing goes wrong over and over, or if I flag it hard, it boils the problem down into a rule that either fixes it or keeps it from happening again, and saves that into the rules.

[04:22] And if it still goes wrong, meaning the rule is getting ignored, then it escalates and adds it to a hook, for hard interception.

[04:31] Then there’s the active forgetting mechanism. Some projects end, or some config gets changed, or I even stop renting a given server. When those changes happen, the corresponding experience or memory gets archived, so the model can no longer pull it, which keeps it from hallucinating around it.

Rules in Practice

[04:49] Let’s look at the real thing. On rules, I actually have 19 rules in here. I’ll upload the detailed rules to my personal blog, and you can go read them. I’ll pick a few out of this, let’s do four.

[05:04] The first is the value priority order. When the model has to make a decision, it has to order things by my values. And that order is—honor, excellence, truth, beauty, and efficiency.

[05:15] How does that play out? When it produces something, its first priority isn’t efficiency, it isn’t just get the thing out the door. What it weighs is whether the thing it made can represent me as a piece of work, whether I’d be satisfied with it.

[05:28] Then second, when it’s choosing tools or designing architecture, it should take the excellence path. Meaning it shouldn’t worry about the compute cost involved, or the difficulty or timeline of the build, but about the excellent design approach or solution that fits the requirement better.

[05:47] Third is truth. Meaning: as much as possible, keep the model from kissing up to me, from flattering me, right. Claude is actually not bad on this, but back when I was using GPT, the way it talked to me I was basically Tesla or Edison reincarnated. It’s really easy to get pulled into a self-reinforcing trap like that. So the principle I make it follow is truth—it looks hard at my proposals and my plans, whether they’re actually feasible, with a critical eye.

[06:13] And beauty goes without saying. Taste is something I demand of myself and of the AI. And this beauty is fairly subjective taste. So over the course of working with the AI, I pass along my understanding of beauty and my standard for it, and have it meet that standard.

[06:28] And efficiency goes without saying. The only thing not in there is cost. So when I call Claude Code, it never considers compute. Since it’s a subscription plan now, you pretty much can’t use it all up, so that worry just isn’t there.

Look It Up, Don’t Ask

[06:42] Next up is look it up, don’t ask. We hit this problem all the time: in the middle of a task, Claude Code says to you, what’s that key, I don’t know it. But it does know—there’s already a place where that key is properly stored. So this principle is that when it hits that kind of question, it has to search first.

Three Levels of Change

[07:01] Next, I split changes into three levels, L1, L2, L3. If it’s a page-level frontend change that isn’t going to cause any problems, it can just go do it as it suggested.

[07:10] If it’s changing three to five files, maybe a small feature, then it validates after making the change. And when the validation and testing come back clean, then it delivers to me.

[07:19] And if it’s a new feature or a complex process, then it goes through my seven-step flow. Clarifying requirements, researching, planning, then executing and testing—a whole series of seven steps like that. I’ll put those seven steps on my blog too.

Redaction for Live Streams

[07:37] Next—since I do these Claude Code live streams a lot, right. During a stream it’ll print a lot of my private stuff in the terminal. Things like my IP, keys, emails. So what I require is that when it’s printing to that screen, it doesn’t put that kind of thing out in plain text.

Hooks in Practice

[07:53] Sorry about this, I’ve got seasonal allergies, my airways get sensitive and I cough nonstop.

[07:58] Next, on hooks, I have 23 set up, 23 hooks. I’ll pick a few representative ones again.

[08:05] First, I sort memory into memory that stays fixed long-term, versus memory that might change. Like my personal info—my height, that’s probably fixed long-term, right. My blood type, that definitely won’t change. My genome, from when I was doing health management—all of that memory is fixed long-term.

[08:25] Whereas my computer model, that really might change within a year or two, right. And say my server keys, those might get rotated once a month. It spot-checks and verifies this kind of volatile memory, and if it’s changed, it goes and corrects that memory.

[08:39] Then I tell it where the credentials are stored. Then there’s some interception of dangerous commands. And there’s automatic checking after a file gets changed, and at the end of a task it does a recap—were there failures to learn from, is there reusable experience, is there a new process—that kind of self-summary.

[09:00] There are a few more points in here, like when you’re building, try not to let any one file run too many lines. If a file gets too big it eats a ton of context, right. It does make code problems easier to find, but it makes building very time-consuming.

Memory Management

[09:19] Then about memory. Because right now Claude Code as a whole organizes memory with a trim approach.

[09:26] My mic just died, let me keep going. So with memory, Claude Code does have its own trim system. Before the trim system existed, developers like me all designed our own approach, going in every two or three weeks to tidy up memory.

[09:39] Because once memory piles up, memory only reads the first 200 lines. Even if you haven’t spilled past those 200 lines nothing gets forgotten, but if you have too much memory, never mind the context it eats, there’s a chance that because of the model’s attention, some memories don’t actually get used as well as they should. So there are mechanisms in here for that too.

Parallel Invention

[10:00] And you can see that some of these mechanisms have already been folded into Claude Code’s own thinking.

[10:06] So it makes me think—a lot of people say Claude Code is copying OpenCode, copying OpenClaw, copying Amazon. But I actually don’t think that’s what’s going on. We’re in an era of parallel invention. We all have the same need, we just implemented a similar feature in different ways at the same time. So there’s no point caring about who copied whom.

[10:25] And for developers, more and more good features like this emerging and getting absorbed by a general tool like Claude Code—I think that’s a good thing.

Harness Suits One Person, Many Projects

[10:35] Now, this whole harness system wasn’t set up from the day I started using it. It came from all the problems that came up as I used Claude Code, and then I’d talk to Claude Code and ask, has anyone solved this before? Are there good best practices? What approach might work for my thinking here? It all came out of that kind of back-and-forth, set up step by step, and then validated to see whether it worked.

[11:00] And this harness is especially suited to a team of one building many projects at once. It’s not suited to team collaboration. For team collaboration I still recommend Lao Jin’s Meta project. I’ll put that project in the links on my blog later too.

Harness Will Eventually Be Absorbed

[11:18] I think the harness’s whole mission, from the day it shows up, is to become obsolete. Sooner or later it gets absorbed into what the model can do on its own. And we can see Claude Code keeps updating too.

Claude Code vs Codex

[11:34] On the fight that’s been getting loud lately—Claude Code or Codex, which should you use, right. The way I see it, these are both harnesses, both tack. So my logic is dead simple—I pick the faster horse. I’ll pick Claude, at least for now I’ll pick Claude.

[11:50] And meanwhile I’ll tune the tack myself, so it fits my needs better. Rather than slapping the official saddle on top of a horse that isn’t fast enough. So my take is, I’d still recommend Claude Code.