Tag: harness engineering

The strongest idea here is progressive hardening. Context documents tell an agent what the team believes, review agents catch violations that still require judgment, and deterministic checks enforce rules precise enough to encode. Repeated agent findings should become tests, linters, or structural checks whenever possible. That moves common verification toward a cheaper and more reliable layer instead of celebrating an ever-larger pile of prompts and reviewers.

The risk is that the harness becomes its own source of ceremony and drift. A living specification, scheduled audit, or self-improvement loop cannot certify its own correctness, and dense terminology does not make a control effective. The useful implementation path starts with observed failures: identify a recurring defect, state the constraint, decide who has authority, measure the check's false positives, and preserve human review for consequences that remain ambiguous. A harness should make the system easier to govern. If operating the harness becomes harder than understanding the code, it has moved complexity rather than reduced it.

This is valuable as a concrete account of making models replaceable. Shared skills and repository instructions create a common working surface; frontier models handle exploration or difficult planning; cheaper models execute established patterns; critics challenge the result; and scripts preserve repeatable work without spending tokens again. The harness becomes the place where the developer's standards, tools, and accumulated workflow live, so switching providers does not mean rebuilding the practice from zero.

It is not a universal blueprint. Model routing, role handoffs, large plans, and multiple subscriptions can save money in one workload while adding context loss, coordination cost, and another system to debug in another. The best evidence is not the elegance of the orchestration diagram but the defects, review time, total cost, and maintainability it produces over repeated work. A good harness keeps the human's mental model intact, makes outputs auditable, and lets the team change models without surrendering its engineering process. When the workflow starts guiding the developer more than the developer guides the work, it is time to simplify it.