Agent Development Harness
A six-phase development pipeline for AI coding agents, with a gate between every phase. Each gate answers a failure that kept recurring in my own PR reviews. It carries a three-tier audited memory layer and a custom Bitbucket MCP server. Search runs on ast-grep and LSP, which cuts tokens by 70%. A reviewer returns its own go or no-go verdict. I use it on my own engineering work.
Overview
Most AI coding workflows optimize the wrong variable. They tune prompts, swap models, and chase context windows. Then they ship the same defects the human-only workflow shipped, only faster. The harness holds the model constant and engineers the process around it, the way you would engineer a deploy pipeline.
The harness runs a six-phase lifecycle: Requirements, Plan, Stress-Test, Implement, Self-Review, Completion. A gate sits between each phase, and none of them can be skipped. Every gate answers a failure I saw at least three times in my own pull-request review history. Reviewers kept catching scope creep, so the Plan phase exists. They kept catching design choices that collapsed under a follow-up question, so the Stress-Test phase exists. They flagged thirteen categories more often than any others, so Self-Review runs thirteen ordered checks across four parallel agents.
A supporting stack sits underneath the lifecycle. ast-grep and LSP queries replace grep, which cuts tokens per task by about 70%. difft produces structural diffs that sub-agents can parse. A three-tier memory layer (LLM Wiki, Obsidian, and a JSONL session graph) is audited by three independent linters. A custom Bitbucket MCP server fills a gap where no official plugin existed, and shellcheck runs as a hard PostToolUse hook. All of it lives in ~/.claude/, with no company code and no proprietary infrastructure.
Architecture
- A six-phase lifecycle: Requirements → Plan → Stress-Test → Implement → Self-Review → Completion. No phase can be skipped, and each gate traces back to a failure that kept recurring in PR review.
- Completion requires evidence. No success claim passes without raw command output, so the lint and test logs themselves are the artifact.
- Self-review runs thirteen checks across four parallel agents. Findings are classified AUTO, BATCH, or MANUAL, and written to Obsidian before completion is allowed.
- An autonomous reviewer, dd-reviewer, runs the full thirteen-check pass on any PR and returns a go or no-go report. It reads /project-commands.md at runtime, so the review logic stays current.
- Token-cost engineering: ast-grep and LSP replace grep across the search layer, cutting tokens per task by about 70%. difft replaces text diffs so sub-agents can parse them.
- Three-tier audited memory: an LLM Wiki on a weekly garbage-collection cycle, an Obsidian second brain, and a JSONL session knowledge graph. Three auditors check them independently: lint-memory, lint-skills, and system-gc.
- A custom Bitbucket MCP server, built from scratch because no official plugin existed. It powers PR-Pulse, which tracks live PR state.
- The safety boundary is three layers: Claude Code sandbox mode, a shellcheck PostToolUse hook, and a human kept in the loop on every review.
- Async observability: Slack integration across all routines for status reporting when away from the machine.
- Scope so far: about 10 of my own tickets shipped end to end, and more than 30 external open-source PRs reviewed by dd-reviewer. All the infrastructure lives in ~/.claude/, with no company code involved.
Status
In active use. The core pipeline, the memory layer with all three tiers and three auditors, dd-reviewer, PR-Pulse, and Slack reporting all work today. A performance optimization on a 76M-row table shipped in May 2026, and its results are still pending.