If you follow conversations about AI engineering, you have probably seen the word “harness” everywhere lately. Mitchell Hashimoto named the discipline, LangChain dissected its anatomy, HumanLayer called our failures a skill issue, Anthropic published how it designs harnesses for long-running work, and Addy Osmani pulled the threads together.

I think this is genuinely good news. Harness engineering is becoming a real discipline, and an important one. As more people study it, document it, and share what they learn, the practice will continue to improve.

If you need a refresher, harness engineering means treating everything around the model as an engineered artifact: prompts, tools, hooks, sandboxes, memory files, feedback loops, and the rules that connect them.

Agent = Model + Harness.

The central habit is simple. Every time an agent makes a mistake, you change the surrounding system so that mistake becomes harder to repeat. A commented-out test slips into a pull request, so your AGENTS.md gains a rule, your pre-commit hook gains a grep check, and your reviewer sub-agent gains a blocker. Every rule traces back to a real failure. It is a ratchet, and it only turns one way.

I agree with almost everything in these guides. That is not what this post is about.

The Missing Chapter

Here is my actual problem with these documents: they are missing a prerequisites section. Almost every practice they recommend rests on an unstated assumption. The human running the harness is already a calibrated judge of good and bad code.

Think about the ratchet principle: “Every mistake becomes a rule.” That only works if you notice the mistake.

Osmani’s own example reveals the problem. The agent ships a commented-out test, and he writes, “I merge it by accident.” He catches the failure because twenty years of scar tissue set off an alarm. An early-career engineer might merge the same pull request and discover the problem three weeks later in production. They might never discover it at all. For them, the ratchet does not turn.

“Earn each line” has the same problem. Every rule in your AGENTS.md is supposed to trace back to a real past failure, and you cannot use someone else’s rules because the right harness is shaped by your own failure history. True. But an early-career engineer has not yet had much time to accumulate that history.

LLM-generated code often presents itself convincingly. It may have clean naming, familiar patterns, tidy abstractions, and confident explanations. For engineers who are still building experience, these surface signals can reasonably carry more weight because they have not yet encountered the full range of hidden failure modes that experience reveals.

More experienced engineers are often able to evaluate additional layers: how the code behaves under unusual conditions, how it interacts with the larger system, which assumptions it makes, and what may be missing. This is not a difference in intelligence or care. It is largely a difference in accumulated exposure.

In the past, weak code often announced itself through awkward structure, inconsistency, or obvious confusion. AI-generated code can remove many of those visible warning signs without necessarily resolving the deeper problems. As a result, early-career engineers may be asked to evaluate work that appears polished before they have had enough time to develop the instincts needed to challenge it.

Harness engineering therefore places people in the role of reviewer very early. Yet critically reviewing the work of a fluent and confident author is itself an advanced skill. Harnesses amplify judgment. They do not create it.

If you are early in your career, that is the gap you are standing in. Here is what I think you can actually do about it.

The Prerequisites

1. Be Opinionated

This is the most important one. An early-career engineer’s central problem is that they have little against which to compare the agent’s output. Fluent code fits perfectly into the space created by having no opinion. An opinion, even a wrong one, gives you a falsifiable target. Wrong opinions eventually collide with reality and get corrected. No opinion simply nods along.

So form stances. “Comments should explain why, not what.” “This service should not know about the database schema.” “Errors should be handled where there is enough context to do something meaningful about them.”

The goal is not to be right about everything. The goal is to make your thinking checkable. When you review an agent’s output, you should be able to say, “This violates my view about X.” The agent can then correct the code, challenge your reasoning, or explain where your rule breaks down. You are not trying to prove that you are always right. You are trying to become capable of judgment.

2. Learn the Core of Your System

You cannot outlearn an agent across an entire codebase, and you should not try. Instead, identify the load-bearing core: the domain model, the data flow, the security boundaries, the path the money takes, or whatever absolutely must remain correct. Build real mental models there. Read it. Trace it. Draw it. Learn the invariants, the edge cases, the failure modes, and the way critical libraries are being used.

Sometimes you will encounter an area you do not understand well enough to hold an informed opinion. That is fine. But it is not a signal to defer to the agent. It is a signal to educate yourself, return to the problem, and form a position. The moment you consistently skip that step is the moment the agent begins to become the owner of your code. I have written before about where that road ends.

3. Get Your Certainty from Execution, Not Reading

Especially early in your career, you may not be able to determine whether LLM-generated code is correct simply by reading it. You can, however, judge it through evidence.

Write the failing test before the agent writes the implementation. In many cases, that changes the entire nature of the problem. You define the expected behavior first, and “correct” becomes something the machine can check rather than a feeling you have to assess. Run the code. Trace the data. Test the boundaries. Poke the edge cases yourself.

Here is another small habit that takes about thirty seconds: before reading the agent’s diff, write one sentence predicting what you expect to see. “I expect this to change X in file Y.” Every mismatch tells you something important. Either the agent went somewhere unexpected, or your mental model of the system is incomplete. Both are useful forms of feedback, and both are easy to miss when you passively accept the diff.

4. Never Merge What You Cannot Narrate

The senior-oriented guides often optimize for throughput. Your version of a harness rule may need to begin as a speed limit. Do not accept a diff you cannot walk through and explain. You should understand why each meaningful piece is there, what behavior it changes, and what assumptions it makes. If the agent produces 800 lines and you can confidently narrate only 200, then the acceptable change was 200 lines. Ask for less.

While you are at it, question the author. The same model that wrote the code can explain its reasoning, identify alternatives, and describe what might break under load or unusual input. Ask:

  • “Why did you choose this approach?”
  • “What would the naive version look like?”
  • “What input would break this?”
  • “What assumptions are you making?”
  • “What did you choose not to change?”

One caution: models tend to grade their own work generously. Use a separate session with clean context for review rather than relying entirely on the conversation that produced the code.

5. Borrow Scar Tissue

The guides say that you cannot download a harness. That is true. But you can apprentice inside one. Your team’s AGENTS.md is compressed senior experience. Ideally, every line traces back to a story, a failure, or a painful lesson. Ask for those stories.

  • “Why does this file say never to touch /legacy?”
  • “What happened that made this check necessary?”
  • “What kind of bug is this rule trying to prevent?”

Questions like these are the fastest judgment-transfer mechanism available. Start your own ratchet on day one, but point it at yourself as well as the agent. Every bug that gets past you should produce two entries: a rule for the agent and a note about why you missed it. The first improves the system; the second improves the judge.

6. Keep a No-AI Zone

Set aside time every week to work without any AI. No agent, no autocomplete, no chat window. Pick a real task and work through it by hand.

Skills you stop using move out of the active part of your brain. Regular unassisted work keeps reading, writing, and debugging code in active memory. It is also how you discover what you truly understand.

The struggle is the mechanism. It is how mental models form.

To Sum Up

The harness engineering guides are right, and you should read them. But they document the practice, not the prerequisite. The ratchet, the earned rules, the hooks, the memory files, and the feedback loops are all mechanisms for encoding judgment into a system. They work beautifully when the judgment already exists.

If you are early in your career, your first job is not to build a more sophisticated harness. Not yet. Your first job is to become the kind of engineer whose observations, decisions, and mistakes are worth encoding into one.

Manufacture certainty through execution. Borrow judgment from experienced people. Develop your own through reading, testing, failure, and reflection. Build it one informed opinion at a time.

🍳 Fun Fact: I don't cook, but I love chefs; I consider every good restaurant bill an investment in the arts.