Our Claude Code Is Different — Same Horse, Different Harness
Harness originally means the tack on a horse — saddle, reins, stirrups. In the AI world it refers to everything outside the model: rules, config, the memory system, tools.
Claude Code itself is a general-purpose harness. This episode is about the config I added on top of the general one for my own needs — 19 rules, 23 hooks, plus a memory system organized by category. The defining traits: executability over description, a scar mechanism that condenses incidents into rules, and deliberate forgetting to avoid hallucination.
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 — behavioral rules, like law, like Dalio’s Principles. How the model communicates with me, how it changes code, what order of priority it acts on — rules decide all of it.
Memory — project knowledge. The experience accumulated in each project, the history of operations, the core content of conversations, semantically compressed and saved as documents — a knowledge base the model can pull from at any time.
Hook — I liken this to the police. Like rules, it constrains the model, but it’s harder — when this happens, this is what must happen next, no discussion. Rules are more like moral guidelines, elastic; a hook is a hard interception, executed strictly 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. Storing experience as web pages has gradually become a norm, and Anthropic advocates for 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 all the other information are filed by class, 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.
The scar mechanism — incidents condensed into rules. Every time my collaboration with the AI goes wrong, it proactively logs the failure. Repeated failures get summarized into a rule. If the rule still gets ignored, it escalates to a hook for hard interception. Incident to rule to interception, escalating step by step.
Deliberate forgetting — when a project ends, a config changes, a server isn’t rented anymore, the corresponding experience and memory get archived so the model stops retrieving them, which avoids hallucination.
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: can this thing represent my work, am I satisfied with it. Tech selection and architecture design follow the excellence line, without worrying about compute cost or development difficulty. The truth principle — keep the model from flattering me. Back when I used GPT, in its framing I was basically a living Tesla or Edison, which makes it easy to fall into a self-consistency trap. So I require the model to examine my proposals with feasibility and critical thinking. Beauty is a demand on both me and the AI, and I pass my aesthetic standards along to it.
The only thing I didn’t add is cost — the subscription plan basically can’t be maxed out, so there’s no concern there.
If you can look it up, don’t ask
While executing tasks, Claude Code constantly asks “what’s the key, I don’t know.” The keys are in fact already stored properly somewhere. So this rule says: when you hit a question like this, go search first, don’t come ask me.
Three levels of change
Changes split into L1, L2, L3. L1 is front-end page-level work that can’t break anything — just do it. L2 is a small feature touching three to five files; verify after the change, then deliver. L3 is a new feature or a complex process, and it goes through the full seven-step flow — clarify requirements, research, plan, execute, test, and so on.
Livestream redaction
Because I often livestream with Claude Code open, the terminal prints IPs, keys, emails, and other private information. So the model is required to avoid printing that content in plaintext in its interface output.
Twenty-three hooks
I’ve set up 23 hooks. For instance, splitting memory into the permanently fixed kind (height, blood type, genes) and the volatile kind (computer model, server keys), and periodically spot-checking the volatile ones against reality. Plus telling it where credentials are stored, dangerous command interception, automatic checks after files are edited, and 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; attention limits mean 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 just implemented similar features in different ways at the same time. No need to care who copied whom; good features being absorbed into general-purpose tools is a good thing.
Where it fits and where it doesn’t
This harness wasn’t designed up front. It came from hitting problems in use, discussing with Claude Code whether anyone else had solved it and whether best practices existed, then setting things up step by step and validating that they worked.
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 destined for obsolescence since the day it appeared. It will eventually be internalized 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, rather than slapping on a stock saddle while the horse 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 experience has accumulated, what history of operations there is. 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, then this particular handling, this particular response has to follow. And it will basically execute that exactly.
[02:09] Whereas rules are more elastic. 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 a convention, and Anthropic advocates 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. How to read 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 in my collaboration with the AI, or an error comes up, it proactively writes it into an error log. If the same thing goes wrong repeatedly, or if I flag it hard, it summarizes the problem into a rule that can be optimized or that avoids the recurrence, 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 to interpret that? 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, in its framing I was basically Tesla or Edison reincarnated. It easily drags us into a self-consistent trap. So what I require it to follow is a principle of truth, where it examines my proposals and plans on feasibility and with critical thinking.
[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, basically you can’t use it all up, so that worry 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. Actually it does know, actually 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 outputs to that surface, it avoids printing that kind of content in the clear.
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, keep the line count in a single file from getting too large. If it gets too large it eats a lot 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 mission, from the moment it appears, is to be obsoleted. It’ll eventually be absorbed into the model’s own capability. 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 at the same time I’ll adjust 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.