harness-maker: Side vs Production

I run side projects and production projects at the same time. On one side I write a small log tool. On the other I build a product headed for commercial release. Both use AI agents like a team. And every time I tried to run the same setup on both, something came out slightly wrong.

The problem with a fixed harness

Most AI coding setups start from a generic template. You find a good AGENTS.md and copy it into every repo. It starts drifting from the first day. A throwaway script and a production service end up with the same reviewers, the same gates, the same flow. One is over-gated, and the other is too loose.

The trouble shows when I hold several projects of different character. On a weekend log parser, if five reviewers pile onto every commit and a SPEC is demanded, I stall. On a production product with a single reviewer, what I missed only surfaces after it ships. Either way, the harness ends up fighting the project.

Side and production want different workflows

At some point I realized my workflow needed to be different for side work and for production work.

On a side project, fast development matters most. Quality comes after. The point is to try an idea quickly, so a thick review pipeline only gets in the way. I have no reason to sit and wait for five reviewers to agree.

A production project is the opposite. Reliable, high-quality work comes before speed. A shipped product is hard to undo. Here the gates work as a safety net, and I want them.

One fixed harness could not satisfy both at once. Tune it for side work and production goes loose. Tune it for production and side work gets locked down.

Two levels are not enough

Looking back, even side versus production is too coarse. Every project wants its own level and its own taste.

One project wants its work notes saved to Obsidian automatically. One wants an extra review from just one of codex or antigravity, with no need for both. One wants worktree isolation, and another wants a feature branch by default.

None of these has a single right answer. It depends on the project’s risk and the shape of the team. A fixed bundle makes that decision for me ahead of time, and it usually makes it the wrong way for my project.

One flow, six stages

The development flow harness-maker stands for has six stages. It opens at research, moves through plan, execute, review and verify, and closes at wrapup. Each stage has to clear its own gate before the next one runs.

What a preset decides is where in that flow the gates sit and how hard they pull. Production adds a SPEC gate before plan and walks all six stages. That is the spec-driven loop I run on embedded work. Side skips that gate and passes through lightly.

Same tool, different harness

Two of my own projects make the difference visible. log_agent is a small Python log tool I write alone, so I picked the Side preset. spoton is a project headed for commercial release, so I picked Production. Same person, same base stack, yet once the harness.yaml answered different questions, the workflow split like this.

Dimension	Side · log_agent	Production · spoton
dev_mode	task-driven	spec-driven
Agent model	sonnet	opus + sonnet
Active reviewers	1	5
Review grade bar	B	A
Review rounds	2	3
worktree scope	[execute]	[execute, plan]
Cross-model review	none	yes (codex etc.)

None of these values were tuned by hand. They came from the interview each project answered once, and they re-render deterministically. The log tool runs fast on one reviewer and sonnet. The commercial project raises the reasoning agents to opus and locks to grade A with five reviewers (code, security, performance, ux, concurrency), a feature branch worktree, and cross-model review (codex, antigravity).

It reads the repo, and keeps its shape

The tool reads the project first. It looks at 12+ stack and CI signals, settles the rest with a 10-dimension interview, and then renders a harness that fits. It does not quietly lay down generic defaults. On the production side the reviewers are read-only, so they cannot touch the code directly. Mechanical checks like lint and tests gate the LLM reviewer before a token is spent, the same verification gate I put in front of AI-written firmware. On a side project I just shave those gates down.

The harness also keeps its shape as the project moves. When I edit an agent or a CLAUDE.md by hand, the @hm:user:* markers carry that edit across a re-render. Memory collects project-specific patterns and proposes new guardrails when a failure keeps coming back. All of it renders from one harness.yaml to Claude Code, Cursor, and Codex.

Generate, don’t copy

A static template gives you a starting point. The one harness-maker gives is a little different: it knows who it was made for, and it updates without losing my edits. I have come to think a good harness grows out of each project, more than it is a starting point handed to everyone alike.

I stopped keeping one personal master setup. The side project runs fast, the way a side project should, and the production project runs solid, the way a production project should. What went away was the chore at the start of every new repo: copy the last project’s CLAUDE.md, then trim the reviewers and gates that did not fit. The interview does that now.

The tool is at github.com/Ecro/harness-maker. The full render evidence and how to reproduce it is in the showcase diff.