A coding agent is a model plus a harness. The model writes the code. The harness is everything around it: what the agent is told, what it is allowed to touch, what checks its work, what it remembers, and who decides it is finished.
Harness engineering is the practice of building that second part on purpose. The term caught on because teams kept noticing the same thing. Swap in a better model and the results improve a little. Change the harness and the results change a lot. On one public benchmark, the same model scored noticeably higher inside one harness than inside another, with nothing else different.
So the question for a team is no longer which model to use. It is what surrounds the model, and who maintains it.
What a harness is made of
Ask ten people for a definition and you get ten lists. They overlap more than they differ. A harness that holds up on real work has seven parts.
Instructions sized to the moment. The agent needs to know what you are building and what step it is on. It does not need your whole wiki pasted into every session. Too little context and it guesses. Too much and the important line is buried under the unimportant ones. This part is what most people now call context engineering.
A written plan before any code. What the product is for, how it is put together, what each feature must do, written down with acceptance criteria someone can check. This is spec-driven development. Without it the agent fills every gap with a plausible guess, and plausible guesses are expensive to find later.
Limits that act before the mistake. Some actions should simply not happen: editing outside the agreed area, deleting what was not asked about, committing to the wrong branch. A rule in a prompt is a request. A hook that refuses the action is a limit. This is the part people mean by guardrails.
Checks that run on what was written. Tests the agent did not get to mark as passing itself. Lints that were proven to work by breaking them on purpose once. Something that runs after each edit, not once at the end.
A reviewer who did not write the code. The agent that wrote a change is the worst-placed reader of it, for the same reason a person is. A second agent with fresh context and no stake in the work finds things the first one walks past. Its findings go in a record, so they are dealt with and not just mentioned.
More than one agent, coordinated. Larger work splits into tasks with dependencies between them. Some can run side by side, each in its own copy of the code so they do not collide. Something has to decide what runs next and put the pieces back together. This is multi-agent orchestration, and done badly it produces the same mess faster.
Memory that outlasts the session. What went wrong last time, and what fixed it. Without this, every session starts as a new hire on their first morning.
Why one piece on its own does not hold
Most writing on harness engineering covers one of these parts well. That is useful, and it is also where teams get stuck, because each part depends on the others.
A reviewer with no spec has nothing to review against, so it reviews style. Checks with no plan test whatever the agent decided the feature was. Hooks with no plan block the obvious accidents and none of the expensive ones. Orchestration with no independent review multiplies whatever the first agent got wrong across eight workers. Memory with nothing feeding it stays empty.
The pieces are a system. Put three of them in place and you get some of the benefit and most of the maintenance.
That maintenance is the part nobody budgets for. A harness is software. Its hooks need updating when the agent’s tools change. Its instructions drift as the project grows. Its checks need testing themselves, or one day they quietly stop checking. Teams that build their own usually find the harness has become a second product with no owner.
The part a homemade harness cannot do
There is one more property, and a team cannot build it alone however good they are.
A harness built in-house learns from one team’s mistakes. When a project implementation goes wrong, the useful things to keep are the cause and the fix. Keep only the cause and you have a warning. Keep both and you have an answer.
If the harness is served instead of copied, both reach every other project automatically. From your side that gives two outcomes. Most problems of that kind never arrive on your project at all. The few that do arrive with the answer already attached, because someone else hit them first. And the list keeps growing, so a harness you copied last month is already behind.
What travels back from a project is the shape of a problem, never the code or the documents. We do not train on anyone’s work.
What Halfcycle is
Halfcycle is a harness that ships with all seven parts already working together. You run one command in your project, open it in Claude Code or OpenAI Codex, and say what you are building.
From there:
- Planning comes first. You are interviewed one decision at a time, then the product plan, the architecture and each feature’s spec are written, with acceptance criteria. A separate agent reviews the spec before any code exists.
- The agent gets only what the current step needs, and is told what comes next, so nobody has to remember the order.
- Risky actions are blocked before they happen, by hooks rather than polite instructions. Checks run after edits, and those checks were themselves tested by breaking them on purpose.
- Tests have to fail before the code is written and pass after, and the harness runs them itself.
- Work is split into tasks with their dependencies. A coordinator runs workers in parallel, each in its own worktree, and puts the results back together.
- Each change is reviewed by an agent that did not write it. Findings are recorded and closed, not just listed. At the end of a phase the whole goal is checked, not only the individual tasks, and a merge does not count as delivery until it has been checked on the delivered product.
- What went wrong and what fixed it is remembered across sessions and, through the method Halfcycle serves, across projects.
It also sizes itself to the work. A two-screen internal tool and a payments integration in the same repository get different amounts of process, because the method is served against the state of your actual project rather than read from a folder that cannot tell them apart. Small changes take a short path.
The result is less rework and less time spent steering. You describe what you want, answer the questions that are genuinely yours to answer, and the rest of the team around your coding agent is already there.
Where it is not the right choice
Some honest limits, since you will find them anyway.
Halfcycle needs a connection, because the method is served and not stored in your repository. If you need to work fully offline, it is not for you today. You also cannot yet plug your own hooks or presets into it. And if your work is one small script, a good set of instructions in a single file is probably all the harness you need.
For anything bigger, the question is not whether you need a harness. You do. It is whether you want to build and maintain one, or start with one that is already working and keeps getting better.
Getting started
npx halfcycle
Run that in the folder you want to work in, then open it in Claude Code or OpenAI Codex and say what you are building. Needs Node 20 or newer. There is nothing to learn first, and it tells you what is next when it is next.