Imagine asking an AI to fix a spreadsheet formula. Its suggestion looks reasonable, but it cannot open the file or check the result. You tell it to be more careful. You write longer instructions. The problem remains: it has no way to test what it proposes.
Now imagine the opposite. It can work on a copy of the spreadsheet, but its instructions still require it to explain every step several times. Perhaps that procedure once prevented mistakes. Perhaps it now just slows the task down. Finding out takes a comparison.
These examples illustrate two different problems: something missing and something that might be unnecessary. Either can leave a capable AI performing below expectations.
An AI depends on what surrounds it
The model is the part of the AI that interprets your request and generates a response. An agent is a system that uses that model to choose actions, use tools, and observe what happened before continuing. It might open a copy of your file, change a formula, calculate the result, and decide whether another correction is needed.
Anthropic distinguishes four components: the model, instructions and controls, tools, and the environment in which they run. It calls the instructions and controls a harness. For this article, the simpler point is enough: what an AI achieves also depends on how it is equipped and organized. [Anthropic Research: 2026-04-09, How agents work: model, harness, tools, and environment] (Trustworthy agents in practice)
Asking for more care does not provide file access. Providing access does not guarantee that the AI will find the mistake. Those are different interventions, and each should be evaluated for what it actually enables.
Unhobbling means removing impediments. In his 2024 essay, Leopold Aschenbrenner also used the term for improvements that add tools or ways to draw on a model’s capabilities. Removing an obstacle can mean supplying something that was missing. [Situational Awareness: I, Unhobbling: tools and scaffolding] (I. From GPT-4 to AGI: Counting the OOMs)
A useful instruction can outlive its purpose
Suppose an earlier assistant made mistakes because it skipped a step. You added a reminder, and the result improved. Months later, you switch models but keep that rule along with all the others.
It is reasonable to ask whether it still helps. Age does not prove that a rule is redundant; the failure it addressed may still occur. Nor does a good reason for writing it a year ago establish its usefulness today.
Boris Cherny, the creator of Claude Code, said his team removed roughly 80% of its system instructions—the text that guides the assistant’s general behavior—while preparing the product for Opus 5. He also described removing instructions and bringing them back to study their effects. [YC Startup Library: UN, Transcript: system-prompt reduction, simple mode, and ablation] (Boris Cherny: Building Claude Code)
That percentage is an account of his product, not a recipe for deleting 80% of our rules. The talk does not supply a reproducible comparison that would make the number transferable to any agent. Cherny also explains that code for safety, permissions, automated code analysis, and the interface remains. [YC Startup Library: UN, Transcript: what remains in the Claude Code harness] (Boris Cherny: Building Claude Code)
Removing a component to study its effect is called ablation. The term is technical; the question is simple: what changes when I try this without it?
Three choices: remove, keep, or add
I would organize the review around three questions. The spreadsheet examples are illustrations, not experimental results.
Might an instruction be unnecessary? Try removing it in a recoverable copy of the configuration. If quality holds and unnecessary work falls, you have a reason to remove it. If the result gets worse, the rule still serves a purpose.
Does a component help or define a boundary? Keep it. That might be a check that catches errors or a rule requiring work on a copy of the file. Knowing how to edit a spreadsheet does not confer permission to send it to someone else.
Is something essential missing? Add the minimum needed to test that hypothesis. In our example, it might be a tool that can calculate the formula. Then check whether the result actually improves.
The Opus 5 guidance itself recommends removing instructions that cause excessive verification while keeping the scope of the request explicit and limiting delegation. That recommendation is specific to that model. [Claude Platform Docs: Opus 5, Task scope and over-verification; Controlling subagent spawning] (Prompting Claude Opus 5)
A useful distinction follows. Asking for repeated review is a working strategy. Requiring the result to meet an agreed standard is an acceptance criterion. We can change the former without lowering the latter.
Sometimes more support helps
Anthropic reported two attempts with Opus 4.5 to build a game-making application. A solo agent spent $9 in 20 minutes; a system with planning and review spent $200 over six hours and produced a more complete, functional application, still with defects. [Anthropic Engineering: 2026-03-24, Running the harness: Solo / Full harness table and results review] (Harness design for long-running application development)
Time, cost, and scope also differed: the planner expanded the initial request. This is an exploratory case. It neither isolates each component’s contribution nor establishes that spending more improves every task. It provides a reason to test the value of support before assuming that all of it is redundant.
How to test without fooling ourselves
Here is the procedure I would use to evaluate an instruction that might be redundant:
- Choose tasks and define success. For the spreadsheet, that could mean calculating several known cases correctly while leaving the original file intact.
- Prepare two versions. Keep the current configuration in one and remove a single instruction in the other. Hold the model, files, tools, permissions, and available budget constant.
- Try both several times. Assess the results against the same criteria. Record errors, time, consumption, and human help. One favorable run could be chance.
- Decide from what you observed. Keep a change if it provides an improvement while preserving the required standard. If results worsen or the evidence is unclear, return to the previous version and investigate.
This is a proposed evaluation procedure, not an experiment I performed here. Its value lies in making a difference attributable to the change being tested. If you switch models, rewrite all the instructions, and add tools at once, it becomes much harder to tell what helped.
Getting out of your AI’s way starts with understanding where it gets stuck. In the spreadsheet example, that might mean supplying a calculation tool, removing a repeated explanation, or keeping the requirement to work on a copy. The best configuration is the one that lets the system do the job well and check the result.