What Should Remain in Your Harness as Large Language Models Get Stronger?

When the tdsql‑harness framework was refactored, the team removed 61% of its root commands, 40% of its skills, and reduced agents from ten to six. The same pruning trend appears at the industry level: Anthropic deleted over 80% of Claude Code’s system prompts without measurable loss, and OpenAI’s GPT‑5.5 guidance explicitly tells users to drop legacy scaffolding.

Why Redundancy Turns Negative

In weak models, extra tokens merely waste budget. With strong models, redundant instructions actively harm performance because they narrow the model’s search space and are often followed literally. For example, a "be conservative" rule forces the model to under‑report issues, while explicit verification steps add noise and reduce quality (quoted from OpenAI).

"If your prompt defines the target outcome, success criteria, constraints, and available context, then let the model choose the path." – OpenAI, GPT‑5.5 prompt guidance

From Rules to Criteria

Anthropic’s experience shows that rules that merely restate what the model already knows add no value. The article proposes replacing exhaustive "must/never" rules with criteria that can be mechanically evaluated, such as:

Does the model already know this?

Is the instruction necessary for the task?

Does the token cost justify the benefit?

Positive examples (e.g., providing a concrete success condition) work better than negative directives.

Evaluation‑First Workflow

The recommended five‑step process mirrors the team’s own practice:

Run the system without any skill and record concrete failures.

Design three evaluation scenarios targeting those failures.

Measure a baseline performance without the skill.

Write the minimal skill needed to close the gap.

Iterate and compare against the baseline.

Each rule should be tied to a specific failure mode; when the model no longer makes that mistake, the rule can be safely removed.

Identifying Expired Assumptions

Every harness component encodes an assumption about what the model cannot do. As models improve, those assumptions expire. The article gives a simple decision tree:

Decision: Ask "Where does this information originate?" If it lives in public corpora or the repository, the model will eventually internalise it – delete the rule. If it resides only in human knowledge or organisational policy, keep it (L2/L3).

Two permanent categories (L3) are identified: (1) irreversible actions that must be authorised by a human (e.g., commit, push, deploy), and (2) organisational policies that cannot be expressed as code.

Where to Invest Effort

Open‑source harness frameworks mainly cover L1 – execution loops, state management, and sub‑agent orchestration – which are quickly absorbed by platform providers. Teams should focus on L2/L3: custom verification standards, gate criteria, and tooling that expose internal processes. These assets cannot be replaced by the model and provide lasting value.

Practical Recommendations

When adding a new rule, explicitly document the failure it prevents; if you cannot, discard the rule.

Audit harnesses at each model generation milestone (e.g., after a new GPT or Claude release) and ask Anthropic’s "what can I stop doing?" to prune obsolete items.

Shift effort from rewriting execution loops (L1) to codifying verification criteria, authorization boundaries, and internal tool usage (L2/L3).

Move anything that can be enforced by linters, tests, or CI gates out of the prompt layer – the instruction strength then no longer depends on how the model reads it.

In summary, the long‑term value of a harness lies not in the amount of prompt text but in the human‑only knowledge and irreversible decisions it protects. By continuously binding each rule to a concrete failure and auditing against model upgrades, teams can keep their harness lean, effective, and future‑proof.