Greenfield Build Harness
Ad hoc AI-assisted development drifts: skipped planning, architectural drift, inconsistent output, weak verification, and handoffs that don't survive past a single session.
Overview
Designing an AI-native delivery system used across multiple customer-facing builds. Raw AI-assisted development is fast but inconsistent. Output drifts from intent, planning gets skipped, and agent-generated work is hard to review. I designed, maintained, and improved a governed harness that turns AI assistance into a structured, reviewable workflow, used by multiple engineers and agents across production builds.
Context
As AI coding assistants became capable enough to implement real features, the constraint shifted from 'can the model write the code' to 'can the output be trusted, reviewed, and maintained.' I needed a way to use AI assistance across real client and product work without lowering engineering standards or losing architectural control.
Problem
Unstructured AI-assisted development showed consistent failure modes: agents skipped planning and jumped straight to code, architecture drifted from established patterns over a session, output quality was inconsistent between tasks, verification was weak or skipped entirely, and handoffs between sessions (or between engineers) lost context and rationale. Reviewing agent-generated work without a structured trail was slow and unreliable.
My Role
I designed the harness architecture: structured repository instructions, shared project context, specialized agent skills, subagents for scoped subtasks, MCP integrations for external tools, and a Figma-to-code workflow. I defined the human approval gates, the verification and testing requirements, and the documentation standards. I maintained and improved the system based on real failures observed across production builds, and performed technical review on the output.
Other engineers and agents used the harness across multiple customer-facing builds; I was responsible for the system they operated within, not for every line of output it produced. I reviewed and was accountable for what shipped.
Constraints
- Real client and product deadlines: the system had to increase speed, not just add process overhead
- Multiple engineers and agents needed to use the harness consistently without a shared onboarding period
- Agent-generated work needed to be reviewable by a human without re-reading every line from scratch
- The system had to hold up across genuinely different greenfield builds, not just one codebase
Approach
I treated the harness itself as a product. I observed where unstructured AI-assisted work broke down, then designed a governed pipeline: Research, then Plan, then human approval, then Implementation, then Verification, then Documentation, so every step produced an artifact the next step (and a human) could rely on. I wrote structured repository instructions and shared project context so agents didn't have to rediscover conventions each session, built specialized skills and subagents for recurring scoped tasks, and wired in MCP integrations and a Figma-to-code path to cut out manual translation steps. I iterated the system based on where real builds actually failed, not on theoretical gaps.
System & Solution
The result is a governed Research → Plan → Implement → Verify workflow: a human request triggers research into existing context, produces a written plan, passes through a human approval gate before any implementation, is implemented against the approved plan using shared repository knowledge and skills, is verified through testing and manual checks, and is documented for durable handoff. Technical review closes the loop, feeding real failures back into the system.
- 01
Human request
A scoped problem, feature, or fix enters the system as a clear request.
- 02
Research
Agents gather context — existing code, conventions, prior decisions, and constraints.
- 03
Plan
A concrete implementation plan is produced and written down for review, not improvised inline.
- 04Human gate
Human approval gate
I review the plan and approve, redirect, or request revisions before any code changes.
- 05
Implementation
Agents implement against the approved plan using shared repository instructions, skills, and MCP integrations.
- 06Verified
Verification & testing
Automated tests and manual checks confirm the work matches the approved intent.
- 07
Documentation & handoff
Decisions, usage, and context are documented so the work survives beyond the session.
- 08
Technical review
I review the shipped result end to end; failures and friction feed back into the system.
Technical review feeds real failures and friction back into research for the next cycle — the system improves from actual usage, not from theory.
Key Decisions
- A human approval gate before implementation, not after
- Plans are reviewed and approved before any code is written, not after the fact. This turned review from 'audit a finished diff' into 'approve a stated intent' making it much cheaper to catch drift early.
- Documentation as a required output, not an afterthought
- Every build produces durable documentation of decisions and usage as part of verification, not as a separate follow-up task, because handoffs were one of the biggest failure points in ungoverned AI-assisted work.
- Skills and subagents for recurring work, not a single general prompt
- Rather than one broad instruction set, I built specialized skills and subagents scoped to recurring subtasks, which made output more consistent and easier to review than a single general-purpose agent handling everything.
Outcome
The harness has been used across multiple customer-facing greenfield builds by multiple engineers and agents. Several projects moved from design to production in under two weeks using the system. AI performed substantial research, implementation, testing, and documentation work.
Reflection
This same pattern for harness design and implementation can be applied to any AI-assisted delivery system.