Harness Engineering vs Vibe Coding

The difference isn't speed. It's who's in the driving seat.

When vibe coding, the agent generates, and you accept or reject after the fact. The decision happens in the prompt, invisible and unaudited.

In harness engineering, the agent stops before it writes a single line of code. You review the design and approve the contract. Then it builds one task at a time, one commit per task, with evidence. Every decision is captured, reviewed, and recorded.

What's the difference? It's not about speed but who's in the driving seat.

Why vibe coding feels fine until it doesn't

Vibe coding gets a lot right. It's fast. It's satisfying. You describe what you want in plain language and watch code appear. For a prototype or a weekend project, that's often enough.

The problem pokes its head up in longer projects. In a longer build cycle, the agent makes numerous decisions. Each decision looks reasonable then but isn't written down for future reference. A few weeks later a feature ships, and nobody can say why it works the way it does, or what the assumptions behind it were.

We think it's a bug in the agent. No, it's the structure. When a decision is a conversation that's already gone, the decision never happened.

What a gate changes

A harness stops the work when it is important for a human to look at it before it proceeds.

Before a single line of code is written, the agent states its approach and its assumptions. You read them. You change what's wrong. You approve. That approved design becomes the contract the agent builds upon.

Then, before release, the agent shows you the evidence such as the tests, the acceptance criteria, the verification report. You read it. You approve.

Two gates. Everything in between, the agent handles without babysitting. But the two moments that matter are yours.

The same agent, two roles

The harness doesn't constrain the agent. It changes what the agent is asked to do at each stage.

During the define and design phase, the agent is a collaborator. It asks questions, finds gaps, challenges assumptions. It thinks with you.

During the build phase, the agent is a disciplined executor. It follows the approved task list in order. It commits after each task. It does not improvise.

Same agent, two jobs. The collaborator produces a better design. The executor produces reliable code. The gate between them is what keeps the two from falling over each other.

Who's responsible

Here's what matters. If the output is wrong, the first question is "Did we review the design carefully?" and not "Did the agent fail?"

That's the shift. In vibe coding, you are downstream of the agent's decisions. In harness engineering, you are the one making them. The agent is fast and tireless. The harness makes its speed trustworthy by putting you in control.

Who this is not for

To be blunt. If you prefer vibe coding, that's a valid choice, and this isn't for you. If you want the agent to make all the decisions, again, not for you. If you think review gates are overhead, this will feel like friction you don't want.

The harness is not about team culture. It is about your standards.

The workflow is free. Bring any agent. Keep your standards. github.com/oystro/oystro-oss