01 Punto de partida: no reescribas todo
La guía oficial de Anthropic para Sonnet 5.5 parte de una idea tranquilizadora: los prompts que ya funcionaban con Sonnet 5 deberían seguir funcionando sin cambios. Lo que conviene hacer es identificar el síntoma que ves y aplicar solo el ajuste correspondiente. La palanca principal no es el texto, sino el nivel de esfuerzo.
| Dónde pegar las instrucciones | Cuándo |
|---|---|
| CLAUDE.md del proyecto | Claude Code: reglas que deben cumplirse en todas las sesiones de ese repositorio |
| Instrucciones de un Proyecto en claude.ai | Trabajo recurrente de un cliente o área |
| Preferencias personales de claude.ai | Comportamientos que quieres en todas tus conversaciones |
| System prompt | Si construyes tu propia aplicación con la API |
| El propio mensaje | Ajustes puntuales para una sola tarea |
02 La palanca principal: el esfuerzo
Los niveles de esfuerzo de Sonnet 5.5 están recalibrados: el mismo nombre no produce la misma cantidad de razonamiento que en Sonnet 5. En Claude Code y las apps arranca en medium; en la API, en high. Anthropic recomienda empezar en medium para tareas de agente bien especificadas, subir a high en las más difíciles o largas y usar medium o low en chat cuando importa la rapidez.
En low
Piensa poco y a veces da un cambio por hecho sin comprobarlo.
En low y medium
En tareas largas tiende a parar y preguntar antes de terminar.
En xhigh y max
Es muy minucioso: puede lanzar rondas extra de revisión, incluso con subagentes, y arreglar cosas que no pediste.
Lo que no funciona
Decirle que piense menos. Si quieres respuestas más rápidas, baja el nivel con /effort.
03 Síntoma: se para a preguntar antes de terminar
Ocurre sobre todo en esfuerzo bajo o medio con tareas de varias partes: confirma un plan que ya estaba claro, pregunta algo que podría resolver solo o se detiene tras la primera parte. Prueba primero a subir un nivel de esfuerzo. Si prefieres no hacerlo, añade una instrucción como esta. Ten en cuenta que las sesiones serán más largas y consumirán algo más.
Sigue trabajando hasta completar todo lo que te he pedido. Interrúmpete solo si no puedes avanzar sin mí o antes de un paso arriesgado o irreversible. Cuando hayas terminado y comprobado el trabajo, para y dame un resumen.04 Síntoma: añade cosas que no pediste
Sonnet 5.5 tiende a sumar tests, documentación o pequeños archivos de apoyo que encajan con las convenciones del repositorio, más cuanto mayor es el esfuerzo. A muchos equipos les viene bien; si prefieres cambios estrictamente limitados a lo pedido, acótalo. En xhigh y max, además, puede empezar por su cuenta rondas de revisión; según Anthropic, frenar eso redujo el coste de las sesiones en torno a un tercio sin perder calidad.
Cuando termines lo que te he pedido y las comprobaciones pasen, para e informa. No añadas funciones, tests, archivos, documentación ni refactorizaciones que no te haya pedido. Si crees que algo extra aportaría valor, menciónalo al final como sugerencia, sin hacerlo.Cuando la tarea esté hecha y sus comprobaciones pasen, no inicies rondas adicionales de revisión o endurecimiento ni lances subagentes revisores salvo que te lo pida. Si crees que merece una revisión más profunda, dímelo al final.05 Síntoma: le pides ideas y te construye algo
Ante peticiones abiertas del tipo «enséñame qué se puede hacer con esto», puede ponerse a montar una presentación, un informe o un prototipo cuando solo querías opciones. Dilo en la petición o déjalo fijado en tus instrucciones.
Cuando te pida ideas, opciones o un plan, dame exactamente eso y detente. No empieces a construir ni a modificar nada hasta que te diga que adelante.06 Síntoma: da el código por terminado sin probarlo
En esfuerzo bajo puede saltarse la verificación, por ejemplo porque faltan dependencias para ejecutar los tests. Si en la conversación no ves salida de tests o de compilación, añade esta regla a tu CLAUDE.md. Anthropic indica que una instrucción de este tipo hace raras las comprobaciones omitidas con un coste apenas mayor.
Si cambias código que se puede ejecutar, compilar o comprobar con tipos, ejecuta antes de darlo por terminado una comprobación real que pruebe el cambio: los tests del proyecto, el verificador de tipos, la compilación o el propio comando modificado. Una revisión de sintaxis o un comando que no llegó a arrancar no cuentan. Si solo faltan las dependencias declaradas, instálalas con el gestor de paquetes y el lockfile del proyecto, nunca con sudo ni con el gestor del sistema. Si no puedes ejecutar ninguna comprobación, dime cuál no has podido hacer y por qué en lugar de dar el trabajo por cerrado.07 Otros ajustes útiles
Responde con datos desactualizados
Elimina de tus instrucciones frases como «usa herramientas solo si es imprescindible» y pídele que compruebe con la búsqueda lo que puede haber cambiado: precios, requisitos, normativa.
Cálculos o reglas que devuelve en JSON
En tareas con varios pasos tiende a responder sin pensar. Añade al final de tus instrucciones que razone el problema antes de responder, o sube a xhigh.
Gráficos densos o planos técnicos
Rinde mucho mejor si puede recortar, ampliar o analizar la imagen con código. Dale esas herramientas antes que subir el esfuerzo.
Se niega a mostrar su razonamiento
Pedir que copie su razonamiento interno en la respuesta puede activar una negativa. Pide un resumen de los pasos o de las decisiones tomadas.
Usa la búsqueda para comprobar cualquier dato que pueda haber cambiado desde tu entrenamiento, como precios, requisitos o lo que está permitido, aunque creas saberlo. Para informes o comparativas, reúne fuentes actuales en lugar de redactar de memoria y cita de dónde sale cada dato.Preguntas frecuentes
No. La guía oficial indica que deberían funcionar bien. Revisa el nivel de esfuerzo y añade solo los ajustes de los síntomas que observes.
Porque esa instrucción no reduce su razonamiento de forma fiable. La forma efectiva es bajar el nivel de esfuerzo; en low se salta el razonamiento en la mayoría de peticiones sencillas.
En el CLAUDE.md del proyecto si deben aplicarse siempre en ese repositorio, o en tu CLAUDE.md de usuario si las quieres en todos tus proyectos.
Las de alcance, verificación y búsqueda suelen ayudar, pero cada modelo tiene su propia guía de prompting y comportamientos distintos según el esfuerzo. Pruébalas antes de generalizarlas.
Claude entiende ambas igual de bien. Escríbelas en el idioma en el que trabaja tu equipo para que todos puedan mantenerlas.
Sobre el autor
Equipo editorial de appyweb
Marketing, SEO y desarrollo con IA
Especialistas de appyweb en SEO, publicidad, desarrollo web y automatización con IA.