Accelerating Feature Delivery: Harness AI‑Driven Development Cuts One‑Day Work to Two Hours

In order to ship features faster, the team built a Harness workflow inspired by OpenAI’s approach. Previously, they used a "Vibe Coding" model where AI wrote code but humans still coordinated requirements, module integration, and testing. The new Harness model treats the code repository as the single source of truth and lets autonomous agents flow through the development stages.

Background

The project consists of a React front‑end ( versus-fe) and a Go back‑end ( versus-server) each maintained by a dedicated developer. Initial development of a feature took about one day.

From Vibe Coding to Harness

Vibe Coding replaces human coding with AI‑generated code while humans still manage the workflow. The team found that long prompts and repeated manual adjustments slowed them down, leading to the decision to adopt a fully autonomous pipeline.

Single‑Repository Refactor

Using Git Submodule, the two existing repositories were merged into a parent monorepo ( versus) that contains the submodules versus-fe and versus-server. Global knowledge for the whole project lives in CLAUDE.md at the root, while each submodule has its own CLAUDE.md describing front‑end or back‑end specifics.

versus/                     # parent repo
├── versus-server/         # Go + Gin backend
│   └── CLAUDE.md         # backend knowledge
├── versus-fe/            # React + Vite frontend
│   └── CLAUDE.md         # frontend knowledge
├── scripts/               # management scripts
│   ├── setup.sh
│   ├── pull-all.sh
│   └── status.sh
├── .claude/               # Claude‑Code config & agents
│   ├── settings.json
│   └── agents/            # 6 Sub‑Agent definitions
└── CLAUDE.md              # project‑wide knowledge

Six Sub‑Agents and Their Roles

requirement‑designer

go‑api‑implementer

frontend‑engineer

test‑case‑designer

integration‑test‑runner

e2e‑test‑executor

Each agent receives a well‑defined prompt, produces output files (e.g., PRD, code, test cases), and appends an ---AGENT-HANDOFF--- block that describes its status, output paths, and the next step.

Agent Handoff Protocol

When an agent finishes, it writes a handoff block like the following:

---AGENT-HANDOFF---
requirement-id: REQ-021
status: awaiting_review
output: docs/requirements/REQ-021/PRD.md
next-step: wait_for_human_approval
after-approval-next-step: launch go-api-implementer
after-approval-prompt: "Implement backend API for REQ-021 based on PRD."
review-message: "Please review PRD at docs/requirements/REQ-021/PRD.md"
---END-HANDOFF---

The main agent parses these blocks, updates the session state, and triggers the next Sub‑Agent automatically. If a test reports has_bugs, the bug list is examined and the appropriate coding agent (backend or frontend) is invoked to fix the issue, after which the relevant test agent is re‑run. The loop continues until the status all_passed is reached.

Test Case Generation

The test‑case‑designer agent creates JSON‑formatted API and E2E test specifications without executing them. Its output is stored under docs/requirements/REQ‑ID/ and triggers parallel execution of integration‑test‑runner and e2e‑test‑executor.

E2E Testing with Chrome DevTools MCP

The E2E agent uses the Chrome DevTools MCP plugin to control a headless browser. Core commands include navigate_page, take_snapshot, take_screenshot, list_console_messages, and evaluate_script. For each test step the agent navigates, captures snapshots, performs actions (click, fill, type), takes screenshots, and finally compares the observed state with the expected result.

Limitations Discovered

E2E testing weakens detection of UI bugs: In practice >90% of defects were caught by API tests; visual regressions (e.g., element overlap after a label change) were missed because the agent does not evaluate aesthetics.

Requirement changes can be omitted: During a feature split, the “model management” page was not updated because the PRD itself missed the change, and the human reviewer could not feasibly read 600+ lines of generated text.

ROI and Conclusion

Across four feature upgrades the Harness pipeline reduced delivery time from ~1 day to ~2 hours, a 4× efficiency gain. Although still behind OpenAI’s reported 10× boost, the approach eliminated most front‑end/back‑end hand‑off friction and demonstrated a viable AI‑first development model. Future work includes integrating the documentation‑code consistency checker into the closed‑loop and improving E2E visual validation.