Aprender

La respuesta corta

La configuración más publicitada de Claude Code —el "esfuerzo" de razonamiento— importa menos que la disciplina que aplicas antes de lanzar un prompt. Tres controles resuelven tres problemas diferentes:

• Nivel de esfuerzo — cuánto debe deliberar Claude.
• Modo plan — cuándo debe Claude esperar aprobación antes de editar.
• Modo /goal — cuándo debe Claude seguir trabajando sin que se lo pidan.

Las herramientas se confunden entre sí, así que vale la pena separarlas. Si aprendes estos tres en Claude Code, el mismo modelo mental se aplica a Codex y a otras herramientas agente de programación, que están convergiendo en la misma superficie de control.

Los niveles de esfuerzo son deliberación presupuestada, no inteligencia

Los niveles de esfuerzo se sitúan sobre lo que Anthropic llama la curva de compute en tiempo de prueba: el modelo puede razonar antes de actuar, generando más o menos pasos internos y evaluando enfoques más amplios o más restringidos. Un mayor esfuerzo usa más tokens para comprobar más y distintos enfoques. Esa es toda la historia: max no es mágico, es simplemente más tokens que medium.

Dos patrones importan:

• El esfuerzo se satura: en la curva precisión-vs-tokens, xhigh captura la mayor parte del poder y el salto a max es insignificante.
• Los modelos más nuevos desplazan la curva: lo que necesitaba max en una generación de modelo puede necesitar medium en la siguiente.

La regla práctica es: escala el esfuerzo al peso del razonamiento, no a la importancia percibida de la tarea.

• low — encontrar un archivo, explicar una función, ejecutar un comando conocido.
• medium — correcciones de errores estándar, añadir tests, refactorizaciones sencillas (un valor predeterminado bien calibrado).
• high/xhigh — decisiones arquitectónicas, migraciones entre múltiples archivos, depuración con causa raíz poco clara, código sensible a la seguridad, cambios en APIs públicas.

Cambiarlo es un comando: /effort, luego las flechas y Enter.

Modo plan: corrige malentendidos antes de que se incorporen al código

La forma más común en que los agentes de programación fallan es por timing, no por razonamiento. El modo plan crea una frontera de fase:

inspeccionar → razonar → proponer plan → esperar

El agente explora y propone sin editar. Escribe el plan en un área de preparación que puedes leer, de modo que corrijes malentendidos en el momento más barato posible. El flujo de trabajo de buenas prácticas de Anthropic tiene cuatro fases — Explorar → Planificar → Implementar → Verificar — y el modo plan hace cumplir la frontera entre Planificar e Implementar.

El beneficio más profundo: el modo plan cambia la pregunta que haces. Sin él, la pregunta es "¿Lo hizo Claude correctamente?" Con él, la primera pregunta es "¿Es este el plan correcto?" — mucho más fácil de responder antes de que los archivos cambien.

El modo plan es el predeterminado adecuado para cualquier cosa que toque más de dos archivos, implique arquitectura o tenga un coste de reversión no trivial. Sáltatelo solo cuando el cambio sea una única línea inequívoca, o cuando pidas una explicación en lugar de una implementación.

Modo /goal: una línea de meta hacia la que Claude avanza por su cuenta

/goal (Claude Code v2.1.139+, mayo de 2026) establece una condición de finalización y Claude sigue trabajando entre turnos hasta que la condición se cumple. El bucle es trabajar → comprobar → continuar o completar, no trabajar → esperar → tú decides → continuar.

El mecanismo clave: después de cada turno, un modelo pequeño y rápido (Haiku por defecto) comprueba si tu condición declarada se cumple. Si sí, el goal se cierra y vuelve el control; si no, Claude inicia otro turno. Ese evaluador es independiente del modelo que realiza el trabajo: la finalización la decide un modelo fresco, no el que ha estado trabajando. Combina /goal con el modo automático para llamadas a herramientas sin supervisión.

La pega: /goal solo es tan bueno como el goal que le des. Un goal vago produce un bucle vago. "Mejorar la calidad del código" no le da al evaluador nada que comprobar.

Escribir un goal con línea de meta

Un goal bien formado tiene cinco partes:

• Resultado — qué debe ser cierto al terminar
• Superficie de verificación — cómo confirmarlo (un comando para ejecutar, un artefacto, una métrica)
• Restricciones — qué no debe cambiar
• Límites — qué archivos/directorios están en el alcance
• Condición de parada — cuándo detenerse e informar un bloqueo en lugar de intentar indefinidamente

/goal Make tests/auth/test_login.py pass on the current branch,
verified by running pytest tests/auth/test_login.py with exit code 0.
Preserve the existing public API. Only modify files under src/auth
and tests/auth. If a test requires external credentials not available
locally, stop and report which credential and what step failed.

Una restricción que conviene conocer: el campo de condición tiene un límite de 4.000 caracteres — generoso para un goal bien estructurado.

Cuatro combinaciones prácticas

• Bajo esfuerzo + solo inspección — exploración sin efectos secundarios. Rápido y barato.
• Alto esfuerzo + modo plan — decisiones arquitectónicas y migraciones; entender el alcance completo antes de tocar archivos.
• Plan → revisar → goal — el patrón más fiable para trabajo sustancial: dedica un turno a dejar el plan bien, revísalo, y luego deja que un /goal lo ejecute de forma autónoma.
• Goal con límites estrictos — trabajo iterativo en un alcance bien definido donde quieres que Claude siga avanzando pero no se disperse.

Cuándo NO usar estos modos

• Evita alto esfuerzo cuando la tarea es simple y obviamente correcta. xhigh en un cambio de nombre gasta tokens y añade latencia sin beneficio.
• Evita modo plan cuando realmente hay un único enfoque sensato: el ida y vuelta no aporta valor.
• Evita modo goal cuando la línea de meta es vaga sin un comando de verificación, o cuando el trabajo podría causar cambios amplios no intencionados antes de un punto de control humano. El modo goal reduce la supervisión turn‑by‑turn — una ventaja para reparar tests, un riesgo para cualquier cosa que toque producción.

Conclusión

Deja de pensar en estos como ajustes separados a configurar. Trátalos como preguntas que responder antes de cada tarea no trivial:

1. ¿Qué tan complejo es el razonamiento? → ajusta el esfuerzo en consecuencia.
2. ¿Se conoce el camino? → si no, planifica primero.
3. ¿El trabajo necesita iteración? → escribe un goal con una línea de meta.

Un prompt bien acotado con el nivel de esfuerzo correcto y un plan claro supera a una cadena elaborada de instrucciones ingeniosas casi siempre.

---

Fuentes primarias: documentación de Claude Code — Keep Claude working toward a goal, configuración de modelos y buenas prácticas. La versión de /goal (2.1.139, mayo de 2026) y el mecanismo del evaluador fueron verificados contra la documentación oficial el 2026-08-07.