Dev Harness
A development harness built through AI-augmented engineering: it turns a coding agent into a disciplined, phased process — 17 orchestrated agents, approval gates enforced by hooks, a red-green cycle per ticket, and a backlog synced to GitHub.
I build web, API and mobile projects mostly solo, and a raw AI coding agent is fast but drifts: it skips steps, invents libraries, quietly edits its own tests. So instead of just using an agent, I engineered how the agent works — encoding the whole delivery process as a Claude Code plugin that orchestrates specialised sub-agents behind approval gates and guardrail hooks. The harness itself was built through AI-augmented development, and the interesting part is the judgment it required: where to trust the model, where to constrain it with deterministic code, and how to keep each agent's context small enough to stay reliable. Fittingly, this case study was published through the two-skill pipeline the harness inspired.
The problem and the thesis
A bare coding agent optimizes for the next edit, not for the project, and working solo there is no reviewer to catch a skipped requirement, a hallucinated library, or a test rewritten to pass. The thesis is not "use AI to code faster" — it is "engineer the process so an AI can be trusted with it". That means specialised agents with isolated context, phases with approval gates, and hooks that physically block the wrong move, so speed never comes at the cost of correctness.
How it works: the phased pipeline
Every project moves through the same pipeline. Each phase has a specialised agent (or several), a document it must produce, and a gate that must be approved before the next phase can start.
›1 · Discovery
discovery-analyst turns a vague idea into a discovery brief: problem, users, constraints and success criteria. Nothing downstream is allowed until this is approved.
›2 · Requirements
requirements-engineer derives testable requirements from the brief. The gate hook blocks writing requirements while discovery is still a draft.
›3 · Plan
product-planner sequences the work into a plan with milestones — no sprints, because working solo the sprint is ceremony without function; the milestone already groups by release.
›4 · Design & architecture
system-architect, ux-designer and tech-researcher produce the architecture and ADRs. Hard rule: no library enters without tech-researcher verifying it exists — a model describes a real and a non-existent library with equal confidence.
›5 · Backlog & sync
epic-decomposer breaks the plan into tickets; project-sync is the only agent that may write to GitHub, and computes the delta with a deterministic script (not model reasoning) so re-runs never create phantom updates.
›6 · Red-green cycle
Per ticket: test-designer writes failing tests from the contract only (it cannot read implementation code), implementers make them pass, qa-verifier gives a binary verdict, and code-reviewer flags only what is blocking.
›7 · Deployment
devops-engineer produces the deployment plan. Release order is fixed — api → verify → web → mobile — because a client shipped before its API calls endpoints that do not exist yet.
›7.5 · Security
security-reviewer investigates the whole repo but reports only on the diff, and only high-confidence findings — a reviewer that flags twenty maybes per PR gets ignored in a week.
›8 · Release & rollback
/release and /rollback enforce the release order and carry a runtimeVersion guard: it compares the diff since the last binary and blocks an OTA update if it detects native changes — when in doubt, ship a binary.
›9 · Observability
progress-reporter (read-only, granted its tools by URL so it cannot write) reports what needs a decision first; /drift compares docs, tickets and code to surface invisible debt — closed tickets whose criteria appear in no test, decisions made in comments that never became an ADR.
The gates: where the rigor lives
The harness's value is not the agents — it is what they are not allowed to do. Two hooks enforce it physically, and two rules keep the loop honest.
›check-gate
Blocks writing a phase document while the previous phase is still in draft. Design rule: when in doubt, allow — a hook that over-blocks gets disabled, and then it protects nothing.
›protect-tests
Blocks an implementer from editing test files. The whole point of a red-green cycle evaporates if the agent can rewrite the test to pass. The block message says what to do instead, so there is no workaround to hunt for.
›Confirm why it fails
A test must be seen failing for the right reason. Failing on the assertion is correct; failing on a broken import means it is not testing anything yet. A test never seen fail correctly has proven nothing.
›Binary, not "nearly"
QA returns a binary verdict; a "nearly" forces the human to decide with information the agent already had. When a criterion admits two readings, the agent does not choose — it marks it needs-decision.
AI-augmented engineering: what it demonstrates
The harness is as much a demonstration of how to build with AI as it is a build tool. These are the engineering techniques it puts into practice.
›Multi-agent orchestration
Seventeen specialised sub-agents, each with an isolated context and a toolset scoped to its role — the writer of GitHub state can write; the reporter is handed the same tools read-only, by URL, so it cannot write even if it decides to try.
›Context engineering
Reliability drops as context grows, so context is a managed budget: the architecture doc is split into six self-contained pieces, skills load progressively, and skill descriptions are in English (~30% cheaper) because they are the only thing always loaded.
›Deterministic guardrails
Where correctness must be guaranteed, a model is not asked to decide: hooks physically block phase-jumps and test edits, and the backlog delta is a hashing script, not reasoning, so it gives the same answer every run.
›Skill design
41 in-house skills encode when-to-use knowledge (ADRs, testing strategy, data-store selection), plus thin adapter layers over Expo's and Vercel's own skills rather than reimplementing them — two sources that contradict each other is worse than one.
›Skill supply chain
Nineteen external skills are vendored and committed, each with its origin and a content hash, so every machine runs the same reviewed version and upstream changes are detectable — supply-chain hygiene for AI tooling.
›Test-first with agents + MCP
The test-designer is walled off from implementation code and a test must be seen failing for the right reason before it counts. GitHub is integrated through its MCP server, with toolsets scoped per agent by URL.
›A self-diagnostic that learns
Every real failure — a path with spaces, a .cmd that will not resolve from Node, a missing OAuth scope — becomes a check in the self-diagnostic before it is fixed, so the harness catches its own regressions instead of the user finding them one by one.
Composition: two repos, one plugin
The harness is one reusable repo; each product is another. The harness holds the process (17 agents, 41 skills, two hooks, seven Node scripts, document templates); the project repo holds the specs and code; GitHub holds execution state. Documents rule over tickets until the backlog is approved; after that, tickets rule over progress and findings flow back into the documents. It is a Claude Code plugin and its own marketplace in a single repo with source "./", versioned by commit — a git push updates it on every machine, no release step. The scripts are Node, not bash, so the same implementation runs on PowerShell, macOS and Linux.
Technical composition
AI / agent engineering
Runtime
Process
Target stack
Deploy & E2E
Tooling
Decisions and what I learned
The design records reasons, not just choices, because the reason outlives the choice. GitHub Projects over a dedicated tracker: everything next to the code, scoped per agent, no extra service. Node over bash: one implementation for every platform, since Node is already required. Security as its own layer in phase 2, not phase 7: a broken authorization model is not patched, it is rewritten. Thin skills over reimplementing Expo's and Vercel's: two sources that contradict each other is worse than one. The through-line is a way of working with AI — treat the model as a fast, fallible collaborator: give it small context and clear roles, let it move fast inside guardrails, and hand anything that must be exact to deterministic code.
Current status
The harness is now in active use: once a concept is approved, it drives the prototyping and development of the project through its phased pipeline. All nine stages are built and the self-diagnostic passes on a configured machine, and every real run keeps feeding new checks back into it. Fittingly, this portfolio entry is the harness's first published case study — generated from a contract by the two-skill pipeline built alongside it.
Want to talk about the process?
I'm happy to go deep on the agent orchestration, the gate hooks, the context-engineering choices, or why each decision went the way it did.
Contact me