Harness Experiment
Harness engineering moves forward by experiment. The principle: measure first, change one thing at a time, keep what survives testing.
Companion to MCode Engineering Notes 01, 02 and 05.
1. Before changing anything
- State the hypothesis in one sentence: what you change, what you expect to improve, and what might get worse.
- Pick or build a small end-to-end eval. A handful of golden tasks is enough to start. Include tasks for every chain the agent runs in production and every rule it must not break. The checks must not be written by the agent under test; tests an agent writes for itself share its blind spots.
- Pin everything else. Same model version, same settings, same tool set, same repository state. If the model itself changes, treat that upgrade as the one change and rerun the same eval.
- Record a baseline. Run each task several times; agent runs are noisy and one run can hide a failure.
2. Make exactly one change
One prompt edit, one tool moved, one subagent merged, one threshold changed. If you need several, run several experiments.
3. Measure the same things on both sides
For baseline and candidate, record:
| Metric | Why |
|---|---|
| Pass rate per task (over repeated runs) | Quality, with noise visible |
| Flipped tasks (pass to fail, fail to pass) | Averages hide regressions |
| Model requests per task | Many wins come from fewer round trips |
| Input and output tokens | Cost and context pressure |
| Cache hit rate | A change can save tokens but break caching |
| Wall-clock time | Latency the user feels |
Only report numbers you actually measured, with run counts.
4. Read the result
- Open every flipped task and read the trajectory, not just the final answer
(see
trajectory-review). Find out why it flipped. - A change that keeps the score flat but cuts requests or tokens can be a win. A change that raises the average while breaking a must-not-break rule is not.
- If the evidence is mixed, keep the simpler version.
- Write the result down: hypothesis, change, numbers, flipped tasks, decision. Next to the code (a PR description or an experiments log) is best.
5. Re-check after model upgrades
Scaffolding built around a model's weak spots ages fastest. After each model upgrade, rerun the eval and ask which parts of the harness still earn their keep.
Output
A short experiment record: hypothesis, the single change, eval set and run count, the metric table for baseline and candidate, flipped tasks with causes, and the decision (keep / revert / iterate).
