The Harness Is the Moat: Why That Doesn't Contradict 'Harnesses Aren't IP'

Since 2013, a single consultant named Kyle Kingsbury has pointed a testing harness called Jepsen at most of the major distributed databases on the market. It has found serious correctness violations in the large majority of them: data loss under network partitions, transactions that silently vanished, systems advertised as linearizable that demonstrably were not, isolation levels that quietly weakened when a node went down. The databases were built by teams of specialists with doctorates and years of runway. Jepsen was one person and a checker. It won so consistently that a clean Jepsen report became a marketing asset vendors now commission on purpose.

What made Jepsen devastating was not cleverness, and it was not the code: the test harnesses themselves are, individually, not that complicated. What Kingsbury built was a way to turn a fuzzy, argued-about constraint (this database should stay consistent when the network misbehaves) into a cheap, fast, mechanical verdict that no vendor could talk their way around. Once you own a predicate like that, you can grade everyone’s database, forever, with almost no marginal effort. The databases were the hard, expensive artifacts. The predicate was the leverage. When the cost of building the artifact collapses toward zero, the scarce and valuable act is turning a fuzzy constraint into a trusted test signal, and whoever operationalizes the constraint gets to delegate everything downstream of it.

What follows: why trading engineering hours for tokens is not the linear trade it looks like, why the specification work that trade forces into the open was always the expensive part, and how “the harness is the moat” can be true at the same time as the claim (made on this very blog) that a harness is not an asset you can own.

The strongest version of “the harness is just plumbing”

There are two serious arguments that the harness is not where the value is, and I hold both of them in other contexts, so let me put them at full strength. The first is the bitter lesson: whatever scaffolding you build today, the next model absorbs. Chain-of-thought prompting was a clever harness in 2022 and became native “thinking” in two years. Tool-calling was scaffolding and became a first-class API. On this reading, an eval harness is just the next thing to get eaten; build it and watch it dissolve into a model capability you didn’t have to write.

The second argument is sharper and comes from a companion essay on this blog, which argues almost the opposite of my title: that agents don’t have IP, workflows do, that the defensible surface is your operating position and configuration depth, not any artifact you can point at, and specifically that the eval harness is not the moat. That essay is correct. You cannot own a test harness the way you own a patent. Anyone can rebuild it. It is not a protectable asset, it does not appear on a balance sheet, and treating it as proprietary IP is a category mistake.

Concede both, completely. The specific harness you build is absorbable and un-ownable: a depreciating artifact, exactly like the model it grades. If that were the whole story, “the harness is the moat” would be a slogan and a wrong one.

The category error

The error is collapsing two different things into the word “harness.” One is the artifact: a particular suite of tests and checks, which the bitter lesson absorbs and IP law refuses to protect. The other is the act: operationalizing a constraint, being the one who turned a fuzzy requirement into a cheap trusted predicate first, and doing it again the moment a new constraint appears. The artifact is absorbable. The act is renewable, and it is exactly the scarce human contribution this series keeps circling.

The two claims live on different axes, which is why they don’t collide. “The harness is not IP” is a claim about ownership: you can’t fence it off. “The harness is the moat” is a claim about leverage: whoever operationalizes the constraint gets to delegate everything downstream of it, and that position is worth more than any artifact, precisely because the artifact is cheap. Kingsbury does not own linearizability testing. Anyone could write Jepsen. Nobody did, for years, and the leverage went to the person who operationalized the constraint first and kept doing it as new databases appeared. The moat was never the code. It was being the one who could turn “is this correct?” into a verdict on demand.

The trade is not linear

Here is the claim the whole post rests on, and it is the one worth arguing with: trading engineering hours for tokens is not a linear trade. Implementation hours collapse toward zero. Specification and validation hours do not shrink at all, and the reason is not that AI is bad at them. It is that those hours were always there, hidden inside implementation, and AI removes the mechanism that used to hide them.

Think about how a competent engineer actually builds something under-specified. They start, hit an ambiguity the spec didn’t resolve, and make a judgment call, silently, from experience, without escalating. Then another, and another. By the time they’re done, they have resolved a hundred small under-specifications through accumulated judgment, and almost none of it got written down, because the resolution was the implementation. The specification work was real and expensive; it was just invisible, discovered incrementally and paid for in the same motion as the typing.

An AI loop deletes that mechanism. The loop does not resolve ambiguity from professional judgment and lived context; it resolves it by producing something fluent and plausible, and if the predicate is missing, it produces something fluently, plausibly wrong. All the specification that used to get discovered incrementally now has to exist up front, explicit, because the entity doing the implementation is not going to quietly supply it for you. This is why teams adopting AI-heavy development so often report the same surprise: the model is great, and yet the work got harder to hand off, because the organization discovered its specs were never written down. They lived in senior people’s heads and got applied silently, and the loop cannot read a head.

I’ve argued elsewhere that evals are the product spec, that the presence or absence of an evaluation harness is the single best predictor of whether an LLM product survives. This is the same claim, one level up and made general. The eval is a special case of the predicate. The predicate is the specification made checkable. And the specification was always the expensive part; it only looked cheap because it was smeared invisibly across implementation hours you were paying for anyway. AI un-smears it, drags it to the front, and makes you look at it. That is uncomfortable, and it is the single most valuable thing the technology does, because it converts a hidden liability into an explicit, ownable asset.

What this requires architecturally

If the leverage is in operationalizing constraints, then the infrastructure worth building is infrastructure that makes operationalizing a constraint cheap and repeatable. That is what a spec-driven development harness is for. In DevFlow, the unit of work is not a vague ticket; it is a technical requirements document with explicit completion criteria, and the verification step performs goal-backward analysis; it checks whether the objective’s goal was actually met, not whether a task was marked done. That is the discipline from this essay turned into machinery: force the predicate to exist before the loop runs, then hold the output against it. The value is not that it makes the recombination faster. It is that it makes writing the predicate down the default rather than the thing nobody got around to.

This is also the thesis AOCyber is built on, stated plainly: capability commoditizes; trust infrastructure compounds. A model is a depreciating asset. So is any single harness. What compounds is the accumulated ability to take a new constraint (a new regulation, a new adversary, a new correctness requirement) and turn it into a trusted, automatable check faster than anyone else. The direction the whole product line points (toward answers that arrive with verifiable receipts rather than just assertions) is the same bet: that in a world where generating output is free, the durable advantage is being able to check it.

What to do first

Take the next thing you are about to hand to an AI loop and try to write the predicate for “done and correct” before you start. Not a vibe, not “looks good”: a check you could run, cheaply, that you would actually trust to gate a release. If you can write it, you have found the real work, and everything downstream of it genuinely is tokens: hand it over and walk away. If you cannot write it, you have just discovered that this task was never specified (that it depended on a human resolving ambiguity mid-stream from judgment you never captured) and that human is exactly who you were about to remove from the loop. That gap is not a reason to keep doing the work by hand. It is the work. It is where your attention should have been all along.

None of this makes the harness something you can own, and I’m not claiming it does. The harness you build will be absorbed by the next model, and anyone can rebuild it, and it will never be an asset on your balance sheet. Being the one who builds it (first, again, and again as each new constraint arrives) is a different thing entirely, and it is the thing that lasts. The tokens are cheap. The predicate is the moat.