Cómo revisar prompts y arneses antes de migrar a Claude Opus 5

El material proporcionado presenta Claude Opus 5 como un modelo adaptado al trabajo cotidiano empresarial y con agentes, y sostiene que, con la nueva generación de Claude, es necesario rediseñar los prompts y los arneses existentes. Sin embargo, las fechas de lanzamiento, los precios y el rendimiento de Claude Opus 5, Fable 5 y Sonnet 5, así como las declaraciones de socios mencionadas en el material, no se han verificado de manera independiente únicamente con la información proporcionada en este artículo. En particular, primero debe comprobarse en la lista oficial de modelos si Fable es una denominación oficial de un modelo de Anthropic.

Por lo tanto, en lugar de repetir esa información de lanzamiento como un hecho confirmado, este documento organiza por separado los aspectos que deben verificarse en la documentación oficial y los procedimientos de validación que pueden aplicarse a una migración real de modelos.

Información de lanzamiento que debe verificarse primero

Antes de aplicar un modelo nuevo a la API, la aplicación Claude o Claude Code, deben contrastarse los siguientes aspectos con la documentación oficial de Anthropic y con la pantalla de selección de modelos del servicio utilizado.

Si el nombre o el precio de un modelo no aparece en la documentación oficial, no debe utilizarse para configurar la API ni calcular presupuestos. Si se utiliza un proveedor de nube o un servicio de reventa, el ID del modelo, el precio y la fecha de disponibilidad también podrían diferir de los de la API directa de Anthropic.

Criterios de decisión que deben cambiar al migrar de modelo

1. Medir la eficiencia por tarea, no solo el máximo rendimiento

Procesar todas las solicitudes con el modelo más caro puede elevar rápidamente los costes cuando un agente llama repetidamente a varias herramientas y subagentes. El modelo no debe elegirse por su nombre o categoría, sino teniendo en cuenta conjuntamente los siguientes indicadores.

• Tasa de éxito: porcentaje de tareas que cumplen los requisitos sin que una persona tenga que corregirlas
• Coste total: coste que incluye no solo la solicitud inicial, sino también los reintentos, las llamadas a herramientas y las llamadas a subagentes
• Tiempo de finalización: tiempo que incluye la espera y el tiempo de revisión y corrección de una persona
• Coste de los fallos: impacto causado por fallos como vulnerabilidades de seguridad, despliegues incorrectos o análisis incompletos
• Consistencia: grado de variación de los resultados al repetir el mismo tipo de tarea

El coste por tarea no debe juzgarse únicamente por el precio unitario de los tokens. Conceptualmente, puede calcularse de la siguiente manera.

Coste total por tarea = coste del modelo principal + coste de los subagentes + coste de las herramientas + coste de los reintentos + coste de la revisión humana

2. Separar los benchmarks públicos de las evaluaciones propias

Los benchmarks públicos constituyen un punto de partida para comparar las características generales de los modelos, pero no garantizan el éxito en una base de código, un formato documental o unas reglas operativas específicos. Las organizaciones deben crear un conjunto propio de evaluación mediante la anonimización de tareas reales.

Un buen conjunto de evaluación incluye conjuntamente los siguientes casos.

• Tareas representativas que deben completarse con normalidad
• Casos límite en los que el modelo se equivoca con frecuencia
• Tareas con requisitos ambiguos que exigen preguntas adicionales
• Tareas que requieren llamadas a herramientas o la consulta de fuentes externas
• Tareas de alto riesgo en las que debe detenerse la ejecución o solicitarse la aprobación de una persona
• Tareas en las que debe guardarse y recuperarse el estado durante una ejecución prolongada

Para que la comparación sea posible, deben aplicarse a cada modelo las mismas entradas, herramientas, límites de tiempo y criterios de éxito. Es más seguro registrar la tasa de éxito y la distribución de costes obtenidas tras varias repeticiones que basarse en uno o dos resultados llamativos.

3. Evaluar el modelo y el arnés como un único sistema

Un arnés (harness) es el entorno de ejecución que rodea al modelo. Incluye el prompt del sistema, las instrucciones del proyecto, la búsqueda, la memoria, las herramientas, las Skill, los subagentes, la gestión de permisos y la lógica de validación y reintentos.

Incluso un mismo modelo puede producir resultados diferentes según el arnés. Por ejemplo, si el propio modelo crea y ejecuta pruebas y el arnés también impone la misma validación, puede duplicarse el trabajo. Por el contrario, resulta peligroso dejar al criterio autónomo del modelo incluso las etapas que requieren controles deterministas, como la aprobación de despliegues o las comprobaciones de seguridad.

El principio fundamental es distinguir entre el razonamiento que el modelo realiza bien y los controles que el sistema debe garantizar obligatoriamente.

6 aspectos que revisar en los prompts y el arnés

1. Eliminar de manera experimental las instrucciones duplicadas de validación y comprobación

Eliminar incondicionalmente frases como Después de terminar, asegúrate de comprobarlo de nuevo no es necesariamente la solución correcta. Primero debe rastrearse si las validaciones que realiza espontáneamente el modelo se solapan con las etapas de validación del arnés.

• Si la revisión del propio modelo solo se repite sin mejorar la calidad, se reduce el prompt.
• Las comprobaciones que pueden automatizarse, como las pruebas, la validación de esquemas y el análisis estático, se mantienen en el arnés.
• La aprobación de tareas de alto riesgo, como pagos, despliegues o eliminación de datos, no se sustituye por la validación del propio modelo.

2. Definir las condiciones y el límite máximo de llamadas a subagentes

Los subagentes son útiles para realizar investigaciones en paralelo o separar áreas especializadas, pero delegarles incluso tareas pequeñas incrementa los costes y la latencia. Pueden especificarse políticas como las siguientes.

• Utilizar subagentes únicamente para tareas que puedan dividirse de manera independiente.
• Limitar el número de subagentes que pueden ejecutarse simultáneamente en una solicitud.
• Asignar a cada subagente un resultado esperado y unas condiciones de finalización claros.
• Evitar que varios agentes exploren de manera redundante el mismo material.
• Solicitar la aprobación de una persona si el coste o el tiempo estimados superan el umbral.

3. Convertir las prohibiciones detalladas en criterios de decisión

Las listas extensas de prohibiciones pueden entrar en conflicto entre sí o no contemplar situaciones nuevas. En ámbitos de bajo riesgo, como el estilo, puede dejarse que el modelo decida tras interpretar el contexto circundante.

• Prescriptiva: Nunca escribas docstrings de varios párrafos.
• Delegación del criterio: Sigue la densidad de comentarios, el formato de los docstrings, la nomenclatura y los modismos del código existente.

No obstante, las reglas cuyo incumplimiento tenga un coste elevado, como las relativas al tratamiento de datos personales, la seguridad o las obligaciones legales, deben mantenerse mediante restricciones explícitas y comprobaciones programáticas.

4. Especificar directamente la longitud de la respuesta y el formato de salida

Los recursos utilizados para razonar y la longitud de la respuesta visible para el usuario no son el mismo concepto. Aunque el cliente ofrezca una opción de intensidad de razonamiento como effort u otra similar, si se necesita una respuesta breve deben definirse por separado las condiciones de salida.

Estos son algunos ejemplos.

• Escribe primero la conclusión y resume los fundamentos en un máximo de tres puntos.
• Redacta la respuesta final con un máximo de 500 caracteres.
• Devuelve únicamente un objeto JSON válido, sin explicaciones.
• Informa únicamente de los archivos modificados, los motivos principales y los riesgos restantes.

5. Recalibrar la intensidad de razonamiento con tareas reales

La intensidad de razonamiento o el valor predeterminado de effort utilizado con el modelo anterior no debe aplicarse sin cambios al modelo nuevo. La curva de costes se mide comenzando con una configuración baja y aumentándola únicamente cuando la calidad sea insuficiente.

Dado que el nombre exacto de las opciones y su compatibilidad pueden variar según la versión de la API y el producto, debe consultarse la documentación oficial.

6. Dividir el contexto por función y revelarlo progresivamente

Si todas las instrucciones se incluyen en un único prompt del sistema o archivo CLAUDE.md, cada solicitud puede incorporar también información irrelevante. Resulta práctica una estructura jerárquica como la siguiente.

1. Instrucciones del sistema y del producto: reglas siempre necesarias, como la función, los límites de seguridad y el contrato de salida
2. Instrucciones ligeras del proyecto: comandos de compilación, estructura de directorios y métodos de trabajo comunes
3. Skill que se cargan cuando son necesarias: procedimientos condicionales, como despliegues, cambios en bases de datos o frameworks específicos
4. Referencias técnicas: esquemas de API, ejemplos de código, documentos de diseño y especificaciones que puedan someterse a pruebas

Esto puede denominarse revelación progresiva. Debe permitirse que el modelo busque o cargue los materiales necesarios para la etapa actual, pero es preciso registrar qué materiales ha utilizado para garantizar la reproducibilidad y la auditabilidad.

Procedimiento de migración recomendado

Paso 1: Fijar el estado actual

Se guardan los prompts, las versiones de las herramientas, la tasa de éxito, el uso de tokens, la latencia y los casos de fallo del modelo existente. Sin una línea base, resulta difícil determinar si el modelo nuevo supone realmente una mejora.

Paso 2: Verificar la información y los permisos del modelo

Se comprueban el ID oficial del modelo, el precio, el límite de contexto, la compatibilidad con herramientas y la política de conservación de datos. En el entorno de pruebas, se limitan los permisos de escritura, eliminación y despliegue.

Paso 3: Probar sin cambios el arnés existente

Al principio no debe cambiarse todo a la vez. Si solo se sustituye el modelo y se compara con la línea base, puede aislarse el impacto del cambio de modelo.

Paso 4: Eliminar una por una las instrucciones duplicadas

Se eliminan de uno en uno los distintos tipos de instrucciones de validación, reglas de estilo prolijas, ejemplos innecesarios y referencias que se inyectan siempre. Tras cada cambio, se vuelven a medir la calidad y el coste.

Paso 5: Crear una política de enrutamiento

El modelo se selecciona según la dificultad del trabajo, el riesgo, el contexto previsto y el límite de tiempo. Las funciones por modelo propuestas en el material proporcionado deben probarse como hipótesis después de confirmar los nombres oficiales y el rendimiento, y no deben adoptarse sin más como política operativa.

Paso 6: Empezar el despliegue con tráfico limitado

Primero se aplica a algunos usuarios o a tareas sin riesgo. El alcance se amplía después de observar la tasa de fallos, los reintentos, el número de subagentes, los errores de herramientas y el tiempo de corrección humana.

Lista de comprobación operativa

• Se han confirmado el nombre oficial del modelo y su ID de modelo de API.
• Se han confirmado las tarifas realmente aplicables de entrada, salida, caché, lotes y otros conceptos.
• Existe un conjunto propio de evaluación compuesto por tareas reales.
• Las etapas de validación del modelo y del arnés no se duplican.
• Existen criterios para llamar a subagentes, un límite de ejecuciones simultáneas y un presupuesto máximo.
• Se han especificado la longitud de la respuesta y el esquema de salida.
• Se han comparado la calidad, el coste y la latencia según la intensidad de razonamiento.
• Se mantienen comprobaciones deterministas y la aprobación de una persona para las tareas de alto riesgo.
• El contexto está dividido entre instrucciones permanentes, Skill y referencias.
• Están preparados el modelo y la configuración anteriores para una reversión.

Conclusión

La clave de la migración a un modelo nuevo no consiste en acortar incondicionalmente los prompts ni en ampliar incondicionalmente la autonomía. Lo esencial es comprobar primero la información oficial del producto y volver a dividir las funciones del modelo y del arnés mediante evaluaciones con trabajo real.

Las cifras y denominaciones relativas a Claude Opus 5 incluidas en el material proporcionado deben tratarse como información provisional hasta que se confirmen sus fuentes oficiales. Sin embargo, eliminar validaciones duplicadas, limitar los subagentes, establecer contratos de salida claros, revelar progresivamente el contexto y aplicar un enrutamiento basado en evaluaciones propias son principios de migración aplicables con independencia de la generación del modelo.