Writing code remains an important part of the job, but it is no longer the only bottleneck. AI assistants and agents can already propose implementations, refactor files, and handle repetitive tasks very quickly. That does not remove the need for engineering; it shifts the focus toward defining the problem, setting boundaries, and verifying that a solution deserves to reach production.
This is where the harness comes in: the set of context, rules, environments, and feedback loops that guide the work — whether it is done by a person or assisted by AI. It turns a broad request into a change that can be run, observed, and reviewed.
From testing to a system of work
In testing jargon, a test harness is the structure that lets a system run under controlled conditions: it prepares dependencies, injects data, invokes the code, and observes the result. In a team that uses agents, the idea expands. The harness also includes a definition of what is acceptable, security constraints, trusted commands, and the checks that support a delivery.
AI accelerates; the harness provides direction
Language models are excellent at exploring alternatives, but they do not have guaranteed understanding of business rules, operational consequences, or the details of a repository. A result that compiles can still violate a product rule, expose sensitive data, or break an infrequently exercised integration. The goal, then, is not to ask AI to “do everything”; it is to provide a safe path for it to produce small, verifiable changes that are easy to challenge.
A good harness does not replace technical review or product decisions. It reduces uncertainty and produces evidence. When tests fail, the agent receives a specific signal to correct; when they pass, the team still assesses whether the solution meets the intended outcome, security, and future maintenance needs.
What makes up a good harness
The implementation varies by project, but these components usually make a meaningful difference:
- Versioned specification and context: business requirements, repository conventions, acceptance criteria, and real examples close to the code. Short, specific instructions are more useful than a generic request to “implement this.”
- Reproducible environment: dependencies, example variables, and clear commands to run the project. Containers and startup scripts help bring local development, CI, and production closer together.
- Automated quality gates: formatting, types, linting, unit, integration, UI tests, and builds. Each check should be fast enough for the development loop and reliable enough not to become noise.
- Access boundaries: least-privilege permissions, secrets kept out of agent context, and care with instructions found in untrusted content. The more autonomy an agent has, the more explicit its limits for files, network access, and commands must be.
- Change observability: a small diff, useful logs, command results, and a clear explanation of what changed. This makes human review faster and rollback less risky.
Tools are interfaces, not the process
Claude Code, VS Code agents, and platforms such as Google Antigravity can read a project, change files, run commands, and iterate on feedback. These capabilities become dependable only when they encounter a well-prepared project. The same harness should work with any tool: the model or IDE may change, but quality criteria should not.
| Without a clear harness | With a well-designed harness |
|---|---|
| A broad request and context scattered across conversations | Acceptance criteria and conventions kept close to the code |
| A large change that is hard to review and reproduce | A small diff, deterministic commands, and fast feedback |
| Confidence based on “it seems to work” | Evidence: types, tests, build, review, and monitoring |
The skill that is growing in importance is not only writing the next piece of code. It is designing a system of work in which good solutions become the easiest path and failures appear early. AI can accelerate execution; responsibility, judgment, and context remain human.