{"slug": "per-project-ai-agent-harness-side-vs-production", "title": "Per-Project AI Agent Harness: Side vs Production", "summary": "Developer Dmitry Vinnik built a per-project AI agent harness generator that creates a distinct workflow for each repository, addressing the mismatch of fixed templates across side and production projects. The tool, which generates a harness.yaml per project, uses a six-stage flow (research, plan, execute, review, verify, wrapup) with configurable gates, and has been applied to his side project log_agent (using the Side preset with one reviewer and sonnet model) and his commercial product spoton (using the Production preset with five reviewers, opus model, and spec-driven mode). Vinnik argues that a single fixed harness cannot satisfy both fast development and production-grade quality, and that two levels (side vs production) are insufficient because each project has unique needs.", "body_md": "[← Essays](/blog/)/Post · 02 of 22 ·\n\n[Embedded Dev](/blog/?category=embedded-dev)\n\n# Per-Project AI Agent Harness: Side vs Production\n\nI run side and production projects at once, so the workflow has to differ. Most harnesses are fixed, so I built one that generates a harness per project.\n\n## On this page\n\nI 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. But every time I tried to run the same setup on both, something was off.\n\n## The problem with a fixed harness\n\nMost AI coding setups start from a generic template. You find a good `AGENTS.md`\n\nand copy it into every repo. It drifts from day one. A throwaway script and a production service get the same reviewers, the same gates, the same flow. One ends up over-gated, the other too loose.\n\nThe trouble shows up when you hold several projects with different characters. On a weekend log parser, if five reviewers pile onto every commit and a SPEC is demanded, you stall. On a production product with a single reviewer, what you missed surfaces only after it ships. Either way, the harness fights the project.\n\n## Side and production want different workflows\n\nAt some point I realized my workflow should differ between side and production.\n\nOn a side project, the thing that matters most is not quality but fast development. The point is to try an idea quickly, so a thick review pipeline is friction, not safety. There is no reason to sit waiting on a five-reviewer consensus.\n\nA production project is the opposite. Reliable, high-quality work comes before speed. A shipped product is hard to undo. Here the gates are not friction, they are a safety net. I want those gates.\n\nOne fixed harness cannot satisfy both at once. Tune it for side and production goes loose. Tune it for production and side gets locked down.\n\n## Two levels are not enough\n\nSide versus production is still too coarse. Every project wants a different level and a different taste.\n\nOne project wants its work notes saved to Obsidian automatically. One wants an extra review from just one of `codex`\n\nor `antigravity`\n\n, not both. One wants worktree isolation, and one wants a feature branch by default.\n\nThere is no single right answer to these. It depends on the project’s risk and the shape of the team. A fixed bundle makes that decision for me in advance, usually the wrong way for my project.\n\n## One flow, six stages\n\nThe development flow harness-maker espouses is six stages. It opens at research, moves through plan, execute, review, verify, and closes at wrapup. Each stage has to clear its own gate before the next one runs.\n\nWhat the 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, which is the [spec-driven loop](/blog/embedded-linux-dev-flow-ai-agents/) I run on embedded work. Side skips that gate and moves through lightly.\n\n## Same tool, different harness\n\nTwo of my own projects show it. `log_agent`\n\nis a small Python log tool I write alone, so I picked the `Side`\n\npreset. [ spoton](/blog/spoton-harness-cofounder/) is a project headed for commercial release, so I picked\n\n`Production`\n\n. Same me, same base stack, but the `harness.yaml`\n\nanswered different questions and the workflow splits like this.| Dimension | Side · log_agent | Production · spoton |\n|---|---|---|\n`dev_mode` | `task-driven` | `spec-driven` |\n| Agent model | `sonnet` | `opus` + `sonnet` |\n| Active reviewers | 1 | 5 |\n| Review grade bar | `B` | `A` |\n| Review rounds | 2 | 3 |\n| worktree scope | `[execute]` | `[execute, plan]` |\n| Cross-model review | none | yes (codex etc.) |\n\nNone of these are hand-tuned. They came from the interview each project answered once, and they re-render deterministically. The log tool runs fast on one reviewer and `sonnet`\n\n. The commercial project bumps the reasoning agents to `opus`\n\nand locks to grade A with five reviewers (`code`\n\n, `security`\n\n, `performance`\n\n, `ux`\n\n, `concurrency`\n\n), a feature branch worktree, and cross-model review (`codex`\n\n, `antigravity`\n\n).\n\n## It reads the repo, and keeps its shape\n\nThe tool reads the project first. It looks at 12+ stack and CI signals, locks the rest with a 10-dimension interview, then renders a harness that fits. It does not quietly ship generic defaults. On the production side the reviewers are read-only, so they cannot touch code directly, and mechanical checks like lint and tests gate the LLM reviewer before a token is spent, the same [verification gate](/blog/llm-firmware-gates/) I put in front of AI-written firmware. On a side project you just shave those gates down.\n\nThe harness also keeps its shape as the project moves. Edit an agent or a CLAUDE.md by hand and the `@hm:user:*`\n\nmarkers carry that edit across a re-render. Memory accumulates project-specific patterns and proposes new guardrails for recurring failures. All of it renders from one `harness.yaml`\n\nto Claude Code, Cursor, and Codex.\n\n## Generate, don’t copy\n\nA static template gives you a starting point. harness-maker gives you a starting point that knows who it was created for, and one that updates without losing your edits. A good harness is not the same starting point for everyone. It grows out of each project.\n\nI 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 vanished 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.\n\nThe tool is at [github.com/Ecro/harness-maker](https://github.com/Ecro/harness-maker). The full render evidence and how to reproduce it is in the [showcase diff](https://github.com/Ecro/harness-maker/blob/main/docs/assets/showcase-diff.md).\n\n## Comments\n\nLoading comments...", "url": "https://wpnews.pro/news/per-project-ai-agent-harness-side-vs-production", "canonical_source": "https://edgelog.dev/blog/project-shaped-agent-harness/", "published_at": "2026-08-07 00:00:00+00:00", "updated_at": "2026-08-11 08:49:56.761503+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-agents", "ai-products"], "entities": ["Dmitry Vinnik", "log_agent", "spoton", "codex", "antigravity", "Obsidian"], "alternates": {"html": "https://wpnews.pro/news/per-project-ai-agent-harness-side-vs-production", "markdown": "https://wpnews.pro/news/per-project-ai-agent-harness-side-vs-production.md", "text": "https://wpnews.pro/news/per-project-ai-agent-harness-side-vs-production.txt", "jsonld": "https://wpnews.pro/news/per-project-ai-agent-harness-side-vs-production.jsonld"}}