AI Harness Engineering · Essay Twelve (rebuild) · Derek Wang
Put two systems side by side. One answers almost anything and never blinks. The other occasionally stops and tells you it might have this one wrong. Ask yourself which one you would trust with core business, and most of us pick the first — no one likes the one that keeps making trouble. It took delivering hundreds of thousands of lines of code against real projects before we saw the honest answer: the second one is the one watching your back. A system's strength was never how often it is right. It is whether it can recognize when it is wrong, and name what it does not know at all.
Psychology names this exactly. It is the Dunning-Kruger effect: the people worst at something are the most sure they did it well, because the skill they lack is the very skill it takes to judge the work. If you are bad at logic, you cannot tell your own argument is bad. You are not just wrong; you are structurally unable to discover from the inside that you are wrong.
Put that on a machine and it stops being a personality quirk and becomes an engineering fact. An AI system with no constraints and no evaluation is not merely "not good enough." It cannot even form the sentence "I am not good enough." There is no organ in it that holds its own failure, so the thought has nowhere to live. That is the whole point every layer in this series has been circling.
Certainty is a ladder, but maturity is two axes
Thirty years ago the Software Engineering Institute built a model that outlived every fad by ranking organizations not on what they could do but on whether they could repeat it. CMM's five levels were never a ladder of talent. They are a ladder of certainty: level five is not where nothing goes wrong. It is where, when something goes wrong, you already know who fixes it, how, and why it will not surprise you again. That first lesson was not wrong.
But it is only half the story, and the younger half is where most teams quietly die. A pipeline that ships a 62% fraud rate and never notices until an audit catches it [ORIGINAL DATA] is not short on capability, and it may not even be short on certainty — it is utterly, Dunning-Kruger-certain it is fine. The gap it is bleeding from is none of those. It is self-knowledge. Certainty answers "is this run trustworthy?" Self-knowledge answers one floor deeper: "am I the kind of system that could be wrong and not know it?" A system can be certain and catastrophically wrong at the same time. That is precisely the Dunning-Kruger outcome. So maturity has two axes and you get to read both: what the machine can do, and how honestly it can name the edges of what it cannot.
This is why removing constraints and evaluation does not just make a system less reliable. You remove the one organ that would have told it. A system with no gates, no contracts, no memory of its own mistakes is one that literally cannot ask the honest question about itself. Every layer we have built — constraints that localize a failure, gates that refuse a bad result entry, memory that keeps a lesson from evaporating, causal tracing that finds which layer misled, the tests and self-growth that stop an unrecognized failure from pretending to be fine — was never about making the AI smarter. It was about giving a runaway engine the organ to read its own dashboard. That organ, and nothing else, is what "maturity" finally means.
The G0-G6 ladder, read as what a system finally admits it lacks
The easy reading of CMM is a promotion list: finish constraints, level up; finish gates, level up again. That is the fastest way to misuse a maturity model. The levels are not a dungeon to climb for badges. They are a chart — less "be proud you reached G6," more "this is where we are drifting, the wind is this way, the reef is over there." So we built our own vertical scale, G0 to G6 [ORIGINAL DATA], and we deliberately wrote every rung as what the system has finally admitted it lacks:
G0 — no restraints; agents run ad-hoc. It does not know what it does not know.
G1 — a strategy exists; it knows why. It admits "I first need a direction."
G2 — architecture and contracts exist; output has a boundary. It admits "my output must be held."
G3 — gates exist; bad results get refused. It can say "this result is not good enough."
G4 — idempotency and graceful degradation exist; failures do not stop the business. It can survive "I am wrong, but I must not collapse."
G5 — memory, causal tracing, and tests exist; lessons harden into assets. It actively re-reads "where did I go wrong."
G6 — self-diagnosis and evolution exist. It can ask "how can I still be better."
Watch the clock under all seven rungs. It is never counting how many tools were added. The tick of maturity is not the addition of constraints; it is the emergence of self-knowledge. From "I do not know what I do not know," to "I know I do not know," to "I know exactly where I do not know," to "I actively go close the gap" — that is the only instrument this ruler is really reading.
The same story, four projects
The abstraction gets honest when you watch one identity run through four projects with different restraint thickness. An early project, constraints unformed, an agent working alone — it does not know what it does not know, and the moment the human who rescues it walks away, it settles into chaos. A core business, all five layers alive, memory and tracing running — it knows exactly where it is weak, delivers steadily, and owns its own mistakes. A tamed system, contracts thick and gates strict — it knows it must obey, high certainty, yet it does not volunteer its own problems. A young system evolving, gates and self-growth just born, direction chosen — it knows where it is going and treats "how can I be better" as a live question.
Four slices, one truth: when we did not know the maturity target, the harness felt like nothing but limits — restraint that made us afraid to push. The moment we designed for it deliberately, the harness became the road that shows the system how to be better. The same machinery, under different constraint thickness, is standing on different maturity slices. And that is the counterintuitive claim stated plainly: maturity lives in certainty, and certainty lives one floor up in self-knowledge.
Over-engineering is not too much maturity; it is too little self-knowledge
Cold water, aimed at the whole model. Maturity is not a race to the top. G6 is expensive, and a small system that burns itself building full self-correction it does not need is trading certainty for ceremony — the same disease as resilience built for decoration. Musk once waved roughly in this direction: the cleverest engineers waste themselves on requirements that were never sane. Read that honestly and it is the dark side of this essay. Over-engineering is not a symptom of being too mature; it is a symptom of being immature and un-self-aware. A system that knows which rung it belongs on knows exactly what to add next and what to leave alone. A system dragged upward by maturity anxiety adds everything and knows none of it serves it. The test stays the one we have used all series: does this layer change the answer to last quarter's real incidents? If it does not, it is a badge, not a moat.
Engineers never run out of work, and sometimes the most responsible thing is to stop, set the direction, and only then push forward. With an AI agent beside us, one engineer may hold what used to take an army — which makes the question we face more fundamental, not less: can we look at our own harness without flinching? Not because it is smart, but because it can tell us, unprompted, what it does not yet know. If we can see our own maturity level clearly, we dare to hand it heavier work and longer roads. If we cannot, then no matter how capable it is, we never quite let go of the worry. And that — the ability to say back to the machine "here is what you do not know" — is where the whole series was steering us.
Top comments (0)