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 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] (Trustworthy agents in practice)
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] (I. From GPT-4 to AGI: Counting the OOMs)
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] (Boris Cherny: Building Claude Code)
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] (Boris Cherny: Building 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.
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] (Prompting Claude Opus 5)
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] (Harness design for long-running application development)
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.
Cómo probarlo sin engañarnos
Este es el procedimiento que usaría para evaluar una instrucción sospechosa de sobrar:
- 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.
- 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.
- 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.
- 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.
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ó.
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.