AI harnesses: a fresh, observable local instance
For much better results, a coding agent must be able to:
- launch a fresh instance of the complete program locally;
- have maximal observability on that instance.
Your codebase may not be ready at all for a good AI harness.
When people talk about AI harnesses, everyone immediately thinks of AGENTS.md files, skills, lint rules, type checks…
But once you get into serious agentic development, there are two other points that are absolutely necessary for the AI to verify its work in good conditions.
1. Start the whole program locally
The AI must be able to start everything that makes up the program locally, easily. For example with an init.sh that takes care of everything.
Note that if you work with parallel agents through worktrees on the same machine… you will have to isolate everything per instance (dynamic ports, databases, volumes, Docker Compose project names…) to be able to run the complete program several times in parallel. And plan for RAM…
It is also important that the program starts in a clean state every time. Goodbye to the local database that lives on for months and months. Every startup must get its own fresh database with seeds (and potentially different sets depending on the tests).
2. An instance as observable as possible
Every complete instance of the program must be as observable as possible (logs, network, OpenTelemetry, metrics…) and every agent must have full access to the observability of its own instance.
With this development environment, agents can verify their work at runtime. And the difference in results is striking!
New instructions also become possible: “no errors in the logs”, “action under XXX ms”, and so on.
It is what I build first when a team hands me its repo.
Keep it in mind on your projects ;)
This article was first published on the Harnessers blog.