---
title: "Deja de estorbarle a tu IA"
description: "A veces la IA necesita una herramienta. Otras, dejar atrás una instrucción. Cómo distinguir qué añadir, qué retirar y qué conservar sin perder el control."
language: es
translationKey: unhobbling-your-ai
kind: essay
canonical: "https://lucashenry.dev/es/notas/deja-de-estorbarle-a-tu-ia/"
markdown: "https://lucashenry.dev/es/notas/deja-de-estorbarle-a-tu-ia/index.md"
alternate: "https://lucashenry.dev/en/notes/stop-hobbling-your-ai/"
alternateMarkdown: "https://lucashenry.dev/en/notes/stop-hobbling-your-ai/index.md"
publishedAt: 2026-09-07
updatedAt: 2026-09-07
topics: ["agentic-systems","harness-engineering","prompting","evaluation"]
tags: ["agentes","unhobbling","instrucciones","evaluación"]
aiAssisted: true
---
# Deja de estorbarle a tu IA
> A veces la IA necesita una herramienta. Otras, dejar atrás una instrucción. Cómo distinguir qué añadir, qué retirar y qué conservar sin perder el control.
Imagina que le pides a una IA corregir una fórmula en una planilla. La fórmula que propone parece razonable, pero no puede abrir el archivo ni comprobar el resultado. Le repites que sea más cuidadosa. Le escribes instrucciones más largas. El problema sigue ahí: le falta una forma de probar lo que propone.
Ahora imagina lo contrario. Ya puede trabajar sobre una copia de la planilla, pero conserva una lista de instrucciones que le exige explicar cada paso varias veces. Quizás ese procedimiento evitaba errores antes. Quizás hoy solo demora la tarea. Para saberlo, hay que comparar.
Estos ejemplos ilustran dos problemas distintos: **algo que falta y algo que podría sobrar**. Ambos pueden hacer que una IA capaz rinda por debajo de lo esperado.
> **La idea en una frase**
>
> Un buen sistema le da a la IA lo que necesita para trabajar, comprueba qué instrucciones siguen ayudando y mantiene claros los límites de lo que puede hacer.
## La IA también depende de lo que la rodea
El **modelo** es la parte de la IA que interpreta tu pedido y genera una respuesta. Un **agente** es un sistema que utiliza ese modelo para elegir acciones, usar herramientas y observar qué pasó antes de continuar. Por ejemplo: abrir una copia del archivo, cambiar una fórmula, calcular el resultado y decidir si necesita corregirla otra vez.
Anthropic distingue cuatro componentes: modelo, instrucciones y controles, herramientas y entorno de ejecución. Al conjunto de instrucciones y controles lo llama *harness*. En este artículo basta con recordar algo más sencillo: lo que una IA consigue depende también de cómo está equipada y organizada. [Anthropic Research: 2026-04-09, How agents work: modelo, harness, herramientas y entorno](https://www.anthropic.com/research/trustworthy-agents "Trustworthy agents in practice — How agents work: modelo, harness, herramientas y entorno")
### Una forma de comprobar
**¿Puede probar lo que propone?**
> **Conclusión:** Las herramientas pueden habilitar un ciclo de corrección y comprobación; el resultado todavía debe evaluarse.
```mermaid
---
config:
look: handDrawn
handDrawnSeed: 8939767
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
%% ¿Puede probar lo que propone?
model(["Mismo modelo
Misma tarea: corregir una fórmula."]):::amber
chat(["Solo conversación
Puede proponer una corrección."]):::muted
tools(["Con herramientas
Puede trabajar en una copia autorizada."]):::sage
proposal(["La persona lo prueba
Aplica la fórmula y comprueba el resultado."]):::muted
edit(["Cambiar la fórmula
Modificar la copia de trabajo."]):::sage
test(["Calcular
Obtener el resultado de la fórmula."]):::sage
feedback(["Comprobar el resultado
Volver a corregir si hace falta."]):::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
```
*Ejemplo ilustrativo: dar una herramienta permite intentar una comprobación. No garantiza acertar.*
Claims relacionados: `claim-06`, `claim-10`
Pedirle más cuidado no le da acceso a un archivo. Darle acceso tampoco garantiza que encuentre el error. Son intervenciones distintas y conviene evaluar cada una por lo que realmente permite hacer.
La palabra *unhobbling* significa quitar trabas. En su ensayo de 2024, Leopold Aschenbrenner la usó también para describir mejoras que **añaden** herramientas o formas de aprovechar las capacidades de un modelo. Quitar una traba puede consistir en poner algo que faltaba. [Situational Awareness: I, Unhobbling: herramientas y scaffolding](https://situational-awareness.ai/from-gpt-4-to-agi/ "I. From GPT-4 to AGI: Counting the OOMs — Unhobbling: herramientas y scaffolding")
## Una instrucción útil puede dejar de serlo
Supongamos que una versión anterior de tu asistente cometía errores porque se saltaba un paso. Añadiste una instrucción para recordárselo y el resultado mejoró. Meses después cambias de modelo, pero conservas esa regla junto con todas las demás.
Es razonable preguntarse si todavía sirve. Su antigüedad no demuestra que sobre; el problema que resolvía puede seguir existiendo. Tampoco demuestra su utilidad que alguien la haya escrito por una buena razón hace un año.
Boris Cherny, creador de Claude Code, contó que su equipo eliminó alrededor del **80% de las instrucciones de sistema** —el texto que orienta el comportamiento general del asistente— al preparar el producto para Opus 5. También describió pruebas en las que retiran instrucciones y las reincorporan para observar su efecto. [YC Startup Library: UN, Transcripción: reducción del system prompt, simple mode y ablación](https://www.ycombinator.com/library/UN-boris-cherny-building-claude-code "Boris Cherny: Building Claude Code — Transcripción: reducción del system prompt, simple mode y ablación")
Ese porcentaje es un testimonio sobre su producto, no una receta para borrar el 80% de nuestras reglas. La charla no aporta una comparación reproducible que permita trasladar ese número a cualquier agente. Cherny también explica que mantienen código dedicado a seguridad, permisos, revisión automática del código e interfaz. [YC Startup Library: UN, Transcripción: qué conserva el harness de Claude Code](https://www.ycombinator.com/library/UN-boris-cherny-building-claude-code "Boris Cherny: Building Claude Code — Transcripción: qué conserva el harness de Claude Code")
A retirar una pieza para estudiar su efecto se le llama **ablación**. El nombre es técnico; la pregunta es simple: ¿qué cambia cuando pruebo sin esto?
## Tres decisiones: retirar, conservar o añadir
Propongo ordenar la revisión con tres preguntas. Los ejemplos de la planilla son ilustrativos, no resultados de un experimento.
**¿Hay una instrucción que podría sobrar?** Prueba sin ella en una copia recuperable de la configuración. Si mantienes la calidad y reduces trabajo innecesario, tienes una razón para retirarla. Si empeora el resultado, esa regla todavía cumple una función.
**¿Hay una pieza que ayuda o define un límite?** Consérvala. Puede ser una comprobación que detecta errores o una regla que exige trabajar sobre una copia del archivo. Que la IA sepa modificar la planilla no significa que tenga permiso para enviársela a otra persona.
**¿Falta algo necesario para la tarea?** Añade lo mínimo que permita comprobar esa hipótesis. En nuestro ejemplo, podría ser una herramienta para calcular la fórmula. Después observa si realmente mejora el resultado.
### Cada pieza necesita una razón
**¿Qué retirar, conservar o añadir?**
> **Conclusión:** La función de la pieza y lo observado deciden el cambio; una sospecha por sí sola no basta.
```mermaid
---
config:
look: handDrawn
handDrawnSeed: 10705220
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
%% ¿Qué retirar, conservar o añadir?
delete[["Retirar si sobra
Una explicación repetida: probar sin ella. Retirar si reduce trabajo y mantiene calidad y límites."]]:::amber
keep[["Conservar si ayuda
Una comprobación útil o trabajar sobre una copia: conservar su función. El permiso no se amplía para mejorar la prueba."]]:::rust
add[["Añadir si falta
No puede calcular la fórmula: probar una herramienta de cálculo y evaluar si mejora el resultado."]]:::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
```
*Guía propuesta con ejemplos ilustrativos. Sin evidencia suficiente, primero investiga; no borres por antigüedad.*
Claims relacionados: `claim-03`, `claim-04`, `claim-08`, `claim-10`, `claim-11`
Las propias guías de Opus 5 recomiendan retirar instrucciones que provocan revisiones excesivas y, al mismo tiempo, mantener explícito el alcance del pedido y acotar la delegación de trabajo. Es una recomendación específica de ese modelo. [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")
Aquí importa una distinción: pedir que repita una revisión una y otra vez es una estrategia de trabajo; exigir que el resultado cumpla lo acordado es el criterio de aceptación. Podemos cambiar la primera sin rebajar el segundo.
## A veces hace falta más apoyo
Anthropic reportó dos intentos con Opus 4.5 de construir una aplicación para crear videojuegos: un agente solo gastó 9 dólares en 20 minutos; un sistema con planificación y revisión gastó 200 dólares en seis horas y produjo una aplicación más completa y funcional, aunque con defectos. [Anthropic Engineering: 2026-03-24, Running the harness: tabla Solo / Full harness y revisión de resultados](https://www.anthropic.com/engineering/harness-design-long-running-apps "Harness design for long-running application development — Running the harness: tabla Solo / Full harness y revisión de resultados")
La comparación también cambió tiempo, costo y alcance: el planificador amplió el pedido inicial. Es un caso exploratorio; no aísla cuánto aporta cada pieza ni demuestra que gastar más mejore cualquier tarea. Sí ofrece un contrapunto a la idea de que todo apoyo adicional sobra.
> **Qué conviene medir**
>
> Una IA puede trabajar durante más tiempo sin resolver mejor el problema. Compara la calidad del resultado, el tiempo y el costo por separado, incluyendo las correcciones que todavía tiene que hacer una persona.
## Cómo probarlo sin engañarnos
Este es el procedimiento que usaría para evaluar una instrucción sospechosa de sobrar:
1. **Elige tareas y define qué cuenta como éxito.** Para la planilla, podría ser calcular correctamente varios casos conocidos y conservar intacto el archivo original.
2. **Prepara dos versiones.** Una con la configuración actual y otra sin una sola instrucción. Mantén iguales el modelo, los archivos, las herramientas, los permisos y el presupuesto disponible.
3. **Prueba ambas varias veces.** Revisa los resultados con los mismos criterios. Anota errores, tiempo, consumo y ayuda humana necesaria. Una ejecución favorable puede ser casualidad.
4. **Decide con lo que observaste.** Conserva el cambio si aporta una mejora sin perder lo que exigías al resultado. Si empeora o no está claro, vuelve a la versión anterior e investiga.
### Cambiar una cosa para aprender
**¿Esa instrucción todavía ayuda?**
> **Conclusión:** Dos versiones, una sola diferencia y los mismos criterios permiten evaluar mejor el efecto del cambio.
```mermaid
---
config:
look: handDrawn
handDrawnSeed: 10186892
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
%% ¿Esa instrucción todavía ayuda?
controls(["La misma prueba
Mismo modelo, tareas, herramientas, permisos, presupuesto y criterios de aceptación."]):::muted
baseline(["A · Como está hoy
La configuración actual."]):::muted
candidate(["B · Sin una instrucción
Copia de A: retirar solo la instrucción que quieres evaluar."]):::amber
measure(["Repetir y comparar
Errores, tiempo, consumo y ayuda humana en ambas versiones."]):::ink
decision(["¿Hay una mejora clara?
Sin perder la calidad exigida ni incumplir límites."]):::ink
promote(["Conservar el cambio
Adoptar B si la evidencia lo justifica."]):::sage
restore(["Volver a la anterior
Si empeora o no está claro, conservar A e investigar."]):::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
```
*Procedimiento propuesto, no resultados medidos. Si cambia el modelo o la prueba, necesitas una nueva comparación.*
Claims relacionados: `claim-03`, `claim-11`
Esto es una propuesta de evaluación, no un experimento que yo haya ejecutado aquí. Su utilidad está en poder atribuir una diferencia al cambio que estás probando. Si cambias de modelo, reescribes todas las instrucciones y añades herramientas a la vez, será mucho más difícil saber qué ayudó.
> **Mi criterio**
>
> Antes de escribir otra instrucción, quiero poder responder qué problema intento resolver y cómo sabré si mejoró. Si falta información, busco una forma de obtenerla. Si sospecho que una regla estorba, la pongo a prueba. Si protege una decisión que corresponde a la persona, la mantengo fuera de ese experimento.
Dejar de estorbarle a tu IA empieza por entender dónde se atasca. En la planilla, eso puede significar darle una herramienta para calcular, retirar una explicación repetida o conservar la obligación de trabajar sobre una copia. La mejor configuración será la que permita hacer bien el trabajo y comprobarlo.
## Fuentes completas
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`.
## Transparencia editorial
> Este artículo fue investigado y redactado con asistencia de IA. Lucas definió el ángulo, verificó las fuentes y conserva la responsabilidad editorial.