---
title: "Stop Hobbling Your AI"
description: "Sometimes an AI needs a tool. Sometimes it needs to lose an instruction. How to decide what to add, remove, or keep while staying in control."
language: en
translationKey: unhobbling-your-ai
kind: essay
canonical: "https://lucashenry.dev/en/notes/stop-hobbling-your-ai/"
markdown: "https://lucashenry.dev/en/notes/stop-hobbling-your-ai/index.md"
alternate: "https://lucashenry.dev/es/notas/deja-de-estorbarle-a-tu-ia/"
alternateMarkdown: "https://lucashenry.dev/es/notas/deja-de-estorbarle-a-tu-ia/index.md"
publishedAt: 2026-09-07
updatedAt: 2026-09-07
topics: ["agentic-systems","harness-engineering","prompting","evaluation"]
tags: ["agents","unhobbling","instructions","evaluation"]
aiAssisted: true
---
# Stop Hobbling Your AI
> Sometimes an AI needs a tool. Sometimes it needs to lose an instruction. How to decide what to add, remove, or keep while staying in control.
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.
> **The idea in one sentence**
>
> A good system gives an AI what it needs to work, checks which instructions still help, and keeps clear boundaries around what it may do.
## 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](https://www.anthropic.com/research/trustworthy-agents "Trustworthy agents in practice — How agents work: model, harness, tools, and environment")
### A way to check
**Can it test what it proposes?**
> **Takeaway:** Tools can enable a cycle of correction and checking; the result still needs evaluation.
```mermaid
---
config:
look: handDrawn
handDrawnSeed: 1806511
theme: base
markdownAutoWrap: true
themeVariables:
background: "#f3f0e8"
primaryColor: "#fffdf7"
primaryTextColor: "#171813"
primaryBorderColor: "#92551d"
secondaryColor: "#dce5d3"
tertiaryColor: "#f0dcc2"
lineColor: "#73583f"
fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace"
---
flowchart TB
%% Can it test what it proposes?
model(["Same model
Same task: fix a formula."]):::amber
chat(["Conversation only
Can suggest a correction."]):::muted
tools(["With tools
Can work on an authorized copy."]):::sage
proposal(["A person tries it
Applies the formula and checks the result."]):::muted
edit(["Change the formula
Edit the working copy."]):::sage
test(["Calculate
Obtain the formula result."]):::sage
feedback(["Check the result
Revise again if needed."]):::sage
model --> chat
chat --> proposal
model --> tools
tools --> edit
edit --> test
test --> feedback
feedback -.-> edit
classDef ink fill:#171813,stroke:#d6a36e,color:#f7f2e8,stroke-width:2px
classDef amber fill:#f0dcc2,stroke:#92551d,color:#171813,stroke-width:2px
classDef sage fill:#dce5d3,stroke:#526149,color:#171813,stroke-width:2px
classDef rust fill:#ecd0c6,stroke:#8b3d24,color:#171813,stroke-width:2px
classDef muted fill:#ebe7dd,stroke:#75756c,color:#34352f,stroke-width:2px
linkStyle default stroke:#9a7654,stroke-width:2px
```
*Illustrative example: a tool enables an attempt to check the work. It does not guarantee success.*
Related claims: `claim-06`, `claim-10`
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](https://situational-awareness.ai/from-gpt-4-to-agi/ "I. From GPT-4 to AGI: Counting the OOMs — Unhobbling: tools and scaffolding")
## 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](https://www.ycombinator.com/library/UN-boris-cherny-building-claude-code "Boris Cherny: Building Claude Code — Transcript: system-prompt reduction, simple mode, and ablation")
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](https://www.ycombinator.com/library/UN-boris-cherny-building-claude-code "Boris Cherny: Building Claude Code — Transcript: what remains in the Claude Code harness")
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.
### Every piece needs a reason
**What should stay, go, or be added?**
> **Takeaway:** A component’s function and observed effects guide the change; suspicion alone is insufficient.
```mermaid
---
config:
look: handDrawn
handDrawnSeed: 12678669
theme: base
markdownAutoWrap: true
themeVariables:
background: "#f3f0e8"
primaryColor: "#fffdf7"
primaryTextColor: "#171813"
primaryBorderColor: "#92551d"
secondaryColor: "#dce5d3"
tertiaryColor: "#f0dcc2"
lineColor: "#73583f"
fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace"
---
flowchart TB
%% What should stay, go, or be added?
delete[["Remove if redundant
A repeated explanation: try without it. Remove if work falls while quality and boundaries hold."]]:::amber
keep[["Keep if useful
A useful check or working on a copy: preserve its function. Do not broaden permission to improve the test."]]:::rust
add[["Add if missing
Cannot calculate the formula: try a calculation tool and evaluate whether results improve."]]:::sage
delete ~~~ keep
keep ~~~ add
classDef ink fill:#171813,stroke:#d6a36e,color:#f7f2e8,stroke-width:2px
classDef amber fill:#f0dcc2,stroke:#92551d,color:#171813,stroke-width:2px
classDef sage fill:#dce5d3,stroke:#526149,color:#171813,stroke-width:2px
classDef rust fill:#ecd0c6,stroke:#8b3d24,color:#171813,stroke-width:2px
classDef muted fill:#ebe7dd,stroke:#75756c,color:#34352f,stroke-width:2px
linkStyle default stroke:#9a7654,stroke-width:2px
```
*Proposed guide with illustrative examples. When evidence is insufficient, investigate before removing anything.*
Related claims: `claim-03`, `claim-04`, `claim-08`, `claim-10`, `claim-11`
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](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5 "Prompting Claude Opus 5 — Task scope and over-verification; Controlling subagent spawning")
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](https://www.anthropic.com/engineering/harness-design-long-running-apps "Harness design for long-running application development — Running the harness: Solo / Full harness table and results review")
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.
> **What to measure**
>
> An AI can work longer without solving the problem better. Compare quality, time, and cost separately, including corrections a person still needs to make.
## How to test without fooling ourselves
Here is the procedure I would use to evaluate an instruction that might be redundant:
1. **Choose tasks and define success.** For the spreadsheet, that could mean calculating several known cases correctly while leaving the original file intact.
2. **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.
3. **Try both several times.** Assess the results against the same criteria. Record errors, time, consumption, and human help. One favorable run could be chance.
4. **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.
### Change one thing to learn
**Does that instruction still help?**
> **Takeaway:** Two versions, one difference, and the same criteria make the effect of the change easier to evaluate.
```mermaid
---
config:
look: handDrawn
handDrawnSeed: 4663386
theme: base
markdownAutoWrap: true
themeVariables:
background: "#f3f0e8"
primaryColor: "#fffdf7"
primaryTextColor: "#171813"
primaryBorderColor: "#92551d"
secondaryColor: "#dce5d3"
tertiaryColor: "#f0dcc2"
lineColor: "#73583f"
fontFamily: "ui-monospace, SFMono-Regular, Menlo, monospace"
---
flowchart TB
%% Does that instruction still help?
controls(["The same test
Same model, tasks, tools, permissions, budget, and acceptance criteria."]):::muted
baseline(["A · As it is today
The current configuration."]):::muted
candidate(["B · One instruction removed
Copy A and remove only the instruction being evaluated."]):::amber
measure(["Repeat and compare
Errors, time, consumption, and human help for both versions."]):::ink
decision(["A clear improvement?
Without losing required quality or violating boundaries."]):::ink
promote(["Keep the change
Adopt B if supported by evidence."]):::sage
restore(["Return to the previous version
If worse or unclear, keep A and investigate."]):::rust
controls --> baseline
controls --> candidate
baseline --> measure
candidate --> measure
measure --> decision
decision --> promote
decision --> restore
classDef ink fill:#171813,stroke:#d6a36e,color:#f7f2e8,stroke-width:2px
classDef amber fill:#f0dcc2,stroke:#92551d,color:#171813,stroke-width:2px
classDef sage fill:#dce5d3,stroke:#526149,color:#171813,stroke-width:2px
classDef rust fill:#ecd0c6,stroke:#8b3d24,color:#171813,stroke-width:2px
classDef muted fill:#ebe7dd,stroke:#75756c,color:#34352f,stroke-width:2px
linkStyle default stroke:#9a7654,stroke-width:2px
```
*Proposed procedure, not measured results. A new model or test requires a new comparison.*
Related claims: `claim-03`, `claim-11`
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.
> **My working rule**
>
> Before writing another instruction, I want to name the problem it should solve and how I will recognize an improvement. If information is missing, I look for a way to obtain it. If a rule might be getting in the way, I test it. If it protects a decision that belongs to the person, I keep it outside that experiment.
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.
## Complete sources
1. **Boris Cherny: Building Claude Code** — Boris Cherny, Diana Hu, Y Combinator. [YC Startup Library: UN](https://www.ycombinator.com/library/UN-boris-cherny-building-claude-code). Role: `primary`.
2. **I. From GPT-4 to AGI: Counting the OOMs** — Leopold Aschenbrenner. [Situational Awareness: I](https://situational-awareness.ai/from-gpt-4-to-agi/). Role: `context`.
3. **Prompting Claude Opus 5** — Anthropic. [Claude Platform Docs: Opus 5](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5). Role: `supporting`.
4. **Harness design for long-running application development** — Prithvi Rajasekaran. [Anthropic Engineering: 2026-03-24](https://www.anthropic.com/engineering/harness-design-long-running-apps). Role: `supporting`.
5. **Trustworthy agents in practice** — Anthropic. [Anthropic Research: 2026-04-09](https://www.anthropic.com/research/trustworthy-agents). Role: `context`.
## Editorial transparency
> This article was researched and drafted with AI assistance. Lucas set the angle, verified the sources, and retains editorial responsibility.