A development harness for coding agents

I work across recruitment products with separate repositories, requirements and release workflows. Before changing code, a coding agent needs to identify the product, find the relevant sources and understand which rules apply to the task.

I asked for a shared development harness that could support multiple products while retaining their separate workflows. My contribution is defining those requirements, directing agent-assisted implementation and testing the workflow against real work.

A product groups projects; each project declares its repositories and guidance. The selected context brings together code structure, requirements, designs and delivery information, keeping each tied to its source.

The harness installs the instructions and skills relevant to that selection. A workspace saves its repositories and guidance, so a later dashboard filter or configuration change cannot redirect work already underway. Projects can share a repository while retaining different branches or delivery rules.

Agents work through their native clients. The dashboard holds connections, project settings, workspaces and release drafts. A draft records planned work; the merge, build or deployment follows the selected product workflow and its authorization.

I write and refine operating instructions, review the results and decide what needs to change. Relay and Figma Lens address related problems in human review and design inspection, with public source that visitors can inspect.

The earlier harness sometimes drew agents into workspace administration and tooling repair. After comparing that experience with a task delivered through native tools, I asked for a simpler design. Context remained central, and optional helpers became easier to leave behind when they failed.

The revised guidance preserves the task’s scope and required checks while letting an agent continue through a supported native route. Accepted review and verification evidence can be reused when its source has not changed. New behavior and meaningful conflict resolutions receive the checks they need.

In the synthetic example, a task asks Search App to keep selected job filters when a visitor opens a job and returns to the results. The saved workspace contains Search App, its Shared UI dependency and the selected requirement, design and routing guidance. Profile App stays outside the task.

A later dashboard switch to Profile App does not retarget that saved workspace. Its original repositories and guidance remain attached to the work. This illustrates documented context behavior; it is not a claim that the fictional filter task was executed against an employer product.

The useful review evidence is the saved repository selection and guidance before and after a dashboard change. For the proposed filter change, a reviewer would inspect the scoped diff, a focused restoration check and screenshots against the synthetic requirement.

The second version is used locally across two recruitment products and is still stabilizing. Focused tests, temporary repositories and independent review have checked context selection and installation boundaries. Another product was added in a synthetic fixture through declarations without changing the shared core.

An accepted code change, a successful build and a confirmed running release describe different states. The harness keeps those distinctions visible. Authenticated application journeys still have incomplete coverage, and local use does not establish broader organizational adoption.

I continue evaluating how much coordination the workflow needs.