Cómo pedirle cosas a los modelos v5 de Anthropic: reglas prácticas para cloud

Cada generación de modelos de Anthropic trae una revisión de las recomendaciones para escribirles prompts, y la quinta no es una excepción. Un ingeniero de cloud ha destilado esa guía en un puñado de reglas pensadas para quien escribe Terraform, Azure Policy o módulos de PowerShell, y el resultado se aparta del consejo genérico de "sé claro y específico". El material cubre Sonnet 5, Fable 5.1 y Opus 5 —el titular habla de "Open 5", que casi seguro es una errata—. No es un anuncio de la compañía: es la lectura de su documentación oficial por parte de alguien que la usa a diario.

Dale el motivo, no solo la orden

La primera regla es la que más cambia el resultado. Un modelo generaliza a partir del porqué, así que prohibir algo sin explicar la razón deja fuera los casos que no estaban en el prompt. El ejemplo que usa el texto es una pipeline de Azure DevOps.

Mal:

Don't use Write-Host in the script.

Bien:

Don't use Write-Host: this script runs as an Azure DevOps pipeline task where only the streams are captured, and Write-Host output is invisible in the job log.

De ahí salen varias reglas más. Escribe el contrato de salida de forma explícita —tipos, nombre del cmdlet aprobado, qué emite cada objeto, qué no debe emitir— en lugar de confiar en que el modelo adivine tu convención. Da entre tres y cinco ejemplos reales en vez de describir tu estilo. Formula instrucciones positivas: una prohibición dibuja un espacio del que salir, una instrucción marca dónde ir. Y en contextos largos, coloca los documentos antes de la pregunta, algo que según las mediciones de Anthropic aporta hasta un 30% de mejora. Para cerrar, pon un techo a la complejidad: "añade un reintento con backoff exponencial solo a esta llamada, no refactorices la función de alrededor" funciona; "sé simple" no.

Tres modelos, tres manías

Opus 5 verifica su trabajo sin que se lo pidas, así que las instrucciones de "revisa antes de responder" se apilan encima de ese comportamiento y producen sobreverificación. También deja de necesitar mayúsculas y urgencia en las llamadas a herramientas.

Sonnet 5 respeta el parámetro effort al pie de la letra: en los niveles bajos hace exactamente lo pedido y nada más, de modo que pedirle "piensa paso a paso, considera todos los casos límite" ahí es gastar tokens para nada. Para trabajo duro de código y de agentes, el texto recomienda subir a high o xhigh.

Fable 5 puede ejecutar acciones que nadie le pidió. La recomendación es marcar la frontera: describir un problema y pedir un diagnóstico, con parada explícita antes de tocar nada, y exigir que cualquier comando que cambie estado esté respaldado por la evidencia. Nunca hay que pedirle que reproduzca o explique su razonamiento interno: eso dispara la categoría de rechazo reasoning_extraction y puede cortar la sesión.

Lo relevante para quien mantiene prompts en producción es que la idea de una plantilla única que sirve para toda la familia se cae. Si tu herramienta interna llama a varios modelos, vas a acabar manteniendo prompts separados, y los escritos para generaciones anteriores no valen tal cual. La documentación enlazada es donde comprobar si estas reglas siguen vigentes cuando aparezca la próxima.