Better Harness Blog

Lately we have been trying to improve one capability in Better Harness: automatic SKILL distillation — recognizing the recurring work paths inside an agent's real sessions, and then deciding which of them are worth capturing as a reusable SKILL. Once we actually started, we found the problem was far harder than "just analyze a session."

For a real software task, an agent's behavior never happens in isolation. It starts from a requirement or a user story, moves through understanding the intent, exploring context, editing code, and verifying the change, and only then produces a contribution someone can review. Looking at the session alone, you can see what the agent did, but it is hard to tell why those actions happened, or which of them actually made it into the final delivery.

So we began treating a single agent delivery as one continuous chain. Today, you only need to run this inside a project directory:

npx @qoder-ai/better-harness inspector

and you get a local, read-only Harness Inspector page that puts the project's agent sessions, file activity, and Git commits into one interactive view.

Writing a capability into a SKILL.md and packaging it as an Agent plugin is not hard. The hard part comes later: once that capability is invoked over and over by different users, in different projects, and on different Agent hosts, how do you guarantee that it is still triggered, executed, and verified correctly? And how do you prove that a change made it better rather than worse?

Drawing on how Better Harness is actually developed, this post walks through five engineering practices - spec-driven behavior, context orchestration, deterministic verification, behavioral evaluation, and the evidence loop - that move a plugin capability from "it works when I run it" to a software asset that is verifiable, maintainable, and safe to evolve.

Last week, we built Better Harness into Qoder Desktop. After launch, many users asked the same question: Will this be open source?

In its first three days, 100,000 people tried Better Harness.

The answer is yes.

Today, Better Harness is officially open source. You can find the project at github.com/QoderAI/better-harness.

Better Harness is an open-source analysis and continuous-improvement tool for coding-agent workflows. It connects the engineering practices, evaluation model, and runtime capabilities of Harness Engineering and Loop Engineering. The initial open-source release supported Claude Code, Codex, Qoder, and Cursor with one shared judgment model, although session analysis, evidence coverage, and output capabilities were not yet identical across the four hosts. Qoder, which had already been exercised repeatedly in real development workflows, was the most complete reference implementation at launch.

Today's coding agents can read requirements, modify code, run tests, and even submit pull requests. But being able to do many things is not the same as being able to do them well.

An agent usually cycles through understanding the task, taking action, checking the result, and adjusting its next step. That is the Agent Loop. A reliable loop does more than keep the agent moving: it gives the agent a clear goal, defines what it must not touch, explains how to judge the result, and provides a recovery path when something fails. Without those boundaries, an agent may change a great deal of code and run many tests while still being unable to prove that the task is actually complete.

This is the problem that Loop Engineering and Harness Engineering address. They equip the agent with project context, relevant development tools, effective verification methods, and explicit safety boundaries so that every loop moves closer to a reliable delivery.

Building on Qoder's internal experience and the broader community's work on coding agents, agent loops, and software engineering, we introduced Better Harness (Beta).