Dar demasiada libertad a Claude Code lo hace peor, no mejor

Hay una trampa en la que caen casi todos los usuarios cuando empiezan a trabajar con Claude Code: darle acceso a todo el repositorio, instrucciones amplias y libertad para decidir cómo abordar un problema. La intuición dice que más contexto y más autonomía deberían producir mejores resultados. La práctica dice lo contrario.

Eso es exactamente lo que documenta este artículo de XDA, publicado el 30 de mayo: el autor constata que Claude Code se volvió menos útil —más errático, más propenso a sobreingeniería— cuando lo dejó operar con pocas restricciones. Y describe qué cambios concretos lo devolvieron a un comportamiento predecible y útil.

El problema: la ventana de contexto no es gratis

Claude Code puede manejar ventanas de contexto muy amplias, especialmente con Claude Opus 4.7 y su millón de tokens. Pero capacidad no equivale a conveniencia. Cuando el agente recibe un repositorio entero, decenas de archivos abiertos y un objetivo vago, ocurre lo previsible: empieza a tomar decisiones de alcance que nadie le pidió. Refactoriza módulos que no eran parte de la tarea. Introduce abstracciones porque «a largo plazo tiene sentido». Genera diff enormes que son difíciles de revisar.

El autor de XDA lo llama, con cierta ironía, "el síndrome del colaborador demasiado entusiasta": Claude Code intenta ser útil más allá del encargo, y ese exceso de celo acaba siendo un problema de supervisión humana.

Qué funciona: restricción deliberada

Las soluciones que describe el artículo no son complejas, pero requieren cambiar la mentalidad con la que se interactúa con el agente:

• Acotar el contexto de ficheros: en lugar de abrir el proyecto completo, pasar únicamente los archivos relevantes para la tarea concreta. Claude Code trabaja mejor cuando no tiene que inferir qué partes del código importan.
• Instrucciones de alcance explícitas: especificar no solo qué hacer, sino qué no tocar. Frases como «modifica solo este fichero» o «no alteres la interfaz pública» reducen drásticamente los cambios no solicitados.
• Tareas atómicas en lugar de sesiones largas: en vez de una sesión donde el agente encadena decisiones durante media hora, dividir el trabajo en pasos discretos con revisión humana entre ellos. Esto encaja con el uso de subagentes especializados: delegar una tarea concreta a un subagente, revisar, continuar.
• Aprovechar los hooks para validar antes de ejecutar: los hooks de Claude Code —eventos como `PreToolUse`— permiten interceptar acciones antes de que se apliquen. El artículo sugiere usarlos para introducir checkpoints de confirmación en operaciones de escritura sobre ficheros críticos.
• CLAUDE.md como contrato de comportamiento: el archivo `CLAUDE.md` en la raíz del proyecto actúa como contexto persistente de sesión. Definir ahí reglas claras («esta es una librería pública, no cambies firmas de métodos sin confirmación») establece un marco que el agente respeta consistentemente.

Por qué importa esto ahora

Estamos en un momento en el que muchos equipos están incorporando Claude Code a flujos reales de producción, no solo para exploración o prototipado. En ese contexto, la predecibilidad del agente importa tanto como su capacidad. Un cambio inesperado en código crítico que pasa el linter pero rompe una invariante de negocio puede costar horas de depuración.

La discusión que abre este artículo es relevante también para quienes diseñan skills o plugins sobre Claude Code: cuanto más abierto es el contrato de una skill, más varianza introduce en el comportamiento del agente que la invoca. La especificidad no es una limitación, es una feature de diseño.

Para equipos que recién empiezan con Claude Code, el consejo práctico es contraintuitivo pero claro: empieza con más restricciones de las que crees necesarias y aflójalas solo cuando entiendas bien el comportamiento del agente en tu contexto específico.

---

La paradoja que describe XDA no es un fallo de Claude Code: es una consecuencia esperada de trabajar con agentes capaces en entornos complejos. El control no está reñido con la potencia; está reñido con la pereza en el diseño de las instrucciones. Dicho esto, sería deseable que Claude Code incorporase mecanismos más explícitos de confirmación de alcance antes de actuar, sin necesidad de que el usuario los configure manualmente mediante hooks.