🧭 Elegir el modelo adecuado para cada tarea
El uso más directo de la regla: ajustar el perfil del modelo a la tarea. Sonnet 4.6 piensa antes de actuar solo 10% de las veces y usa pocas herramientas (2,23 por turno) — perfecto para lo rápido, mecánico y barato. En cambio, Opus 4.8 (piensa 54%) y Fable 5 (piensa 85%, prueba después de editar 41%) destacan en el trabajo que exige planificar y cerrar el ciclo.
| Modelo | Perfil (números canónicos) | Mejor uso |
|---|---|---|
| Sonnet 4.6 | piensa 10% · 2,23 herramientas/turno · conciso | tareas rápidas, mecánicas y baratas |
| Opus 4.8 | piensa 54% · prueba 2% · 7,96 herramientas/turno | trabajo que exige planificar de antemano |
| Fable 5 | piensa 85% · prueba 41% · 10,45 herramientas/turno | trabajo que exige planificar + probar (cerrar el ciclo) |
💡 Ejemplo práctico
¿Renombrar un campo en 30 archivos? Sonnet: es mecánico, y gastar Fable en eso es un desperdicio. ¿Refactorizar un módulo con migración de schema y suite de pruebas? Fable u Opus: quieres que planifique y ejecute la prueba. La escala indica qué perfil encaja; Fable no es "económico": él usa MÁS herramientas por turno a propósito.
🩺 Diagnosticar TU modelo
La vara no sirve solo para comparar modelos famosos: mide tú. Ejecútala sobre tu propio historial y mira dónde tropieza tu sesión. Si tu Opus prueba después de editar solo 2% de las veces, la mayor palanca no es "pensar más": es cerrar el ciclo. El número señala el verdadero cuello de botella, no el que imaginas.
Mide, no adivines
Ejecuta el medidor en tus ~/.claude/projects. Observa pensar antes, probar después y herramientas/turno: los tuyos, no los del dataset.
Activa la palanca correcta
Probar el 2% es el límite que más te frena. Inyectar «ejecuta la prueba después de editar» rinde mucho más que pedir «piensa más».
💡 Ejemplo práctico
Crees que tu agente «no piensa lo suficiente». Mides y descubres que piensa en el 60%, pero solo prueba en el 3%. La imagen cambia la prescripción: el problema no era la reflexión, era no cerrar el loop. Diagnóstico antes del remedio.
👥 Incorporación del equipo
El buen ritmo no debería depender de que cada dev lo recuerde. Inyectas el pensar-antes + testar-depois por defecto —
mediante hook SessionStart o un CLAUDE.md versionado en el repo — y
toda la sesión del equipo ya empieza con el playbook activado. El principiante hereda el ritmo desde el primer día, sin entrenamiento.
hook SessionStart o CLAUDE.md en el repo
todo desarrollador, desde el día 1
pensar-antes + testar-depois por default
✓ Con el playbook inyectado
- ✓Ritmo estandarizado entre todos los devs.
- ✓Versionado en el repo: cambia una vez y sirve para todos.
- ✓No depende de que alguien recuerde el buen hábito.
✗ Sin nada inyectado
- ✗Cada desarrollador tiene su propio ritmo; la calidad es irregular.
- ✗El buen hábito muere cuando la persona lo olvida.
- ✗La incorporación se convierte en un documento que nadie lee.
📈 Demostrar que un cambio funcionó
"Creo que mejoró" no es evidencia. La regla convierte una impresión en un número: guarda un baseline fechado ANTES, aplica el playbook, y mide DESPUÉS con suficientes muestras. El delta se convierte en prueba. Solo ten cuidado con el dilución: si echas las sesiones nuevas al mismo saco que las antiguas, la señal desaparece — aísla las sesiones nuevas.
| Paso | Qué hacer | Cuidado |
|---|---|---|
| 1. Antes | baseline fechado en un lugar duradero (no /tmp) | muestra lo bastante grande para ser estable |
| 2. Cambio | aplica el playbook (hook/skill/CLAUDE.md) | cambia una cosa a la vez |
| 3. Después | mide de nuevo y compara la diferencia | aísla las sesiones nuevas — no las mezcles con el historial |
🔎 Ejemplo práctico
Baseline de junio: probar-después en 5%. Inyectas la regla de cerrar el ciclo y lo ejecutas durante dos semanas. Mides SOLO las sesiones nuevas: 38%. Ahora sí tienes un número que puedes defender: no "parece mejor", sino +33pp medido, en el recorte adecuado.
🌐 Va más allá de Fable/Opus
El método no es exclusivo del par Fable/Opus. Funciona con Codex y modelos de código abierto — basta con tener los logs
en el formato de eventos (pasos con herramienta, pensamiento, edición). La clave es el campo
model: es lo que te permite distinguir quién es quién y medir a cada uno con la misma vara.
# o que importa é o formato de eventos + o campo model { "model": "claude-opus-4-8", "type": "tool_use", "name": "Edit" } { "model": "gpt-5-codex", "type": "thinking" } { "model": "qwen-2.5-coder", "type": "tool_use", "name": "Bash" } # mesma régua, agrupando por model: python compare_models.py --a codex --b opus
Codex, código abierto
logs en eventos
campo model
la misma de siempre
💡 Ejemplo práctico
¿Quieres comparar un modelo local (Qwen Coder) con Codex en TU flujo? Ejecuta ambos en las mismas tareas, recopila los eventos, agrúpalos por model y mide pensar antes / probar después. El criterio es independiente del proveedor: solo necesita el formato.
🛡️ Antídoto contra el hype
El uso más valioso de todos: la regla es antídoto contra el hype. Antes de creer cualquier afirmación como «el modelo X es mejor que Y», exige muestra grande. Así fue exactamente como derribamos el +45pp: el número salió de 7 sesiones (99% vs. 54%) y, en una muestra grande de HF (4.892 pasos), se convirtió en 85% vs 54% (+31pp) — sólido, defendible, sin ilusiones.
✗ Lo que hace el hype
- ✗Concluye a partir de 7 sesiones: «+45pp, el modelo X arrasa».
- ✗Compara muestras de diferentes tamaños.
- ✗Confunde la presencia de «thinking» con la calidad del contenido.
✓ Lo que exige la regla
- ✓Muestra grande de ambos lados antes de creer (4.892 pasos).
- ✓Tamaños equilibrados — limita por el n.º de pasos (~950).
- ✓Mide la presencia, no el contenido (el razonamiento viene cifrado).
⚠️ La muestra pequeña engaña en AMBAS direcciones
Infló el «pensar» (99 → 85) Y ocultó el «probar después de editar» (el recorte local daba 0%, el real es 41%). Por eso el criterio no sirve solo para bajar una cifra inflada: sirve para descubrir qué había ocultado la muestra pequeña.
🔎 Ejemplo práctico
Apareció una publicación: «¡El modelo Z piensa el 99% de las veces!». Preguntas: ¿cuántas sesiones? ¿Ambos lados tienen la misma muestra? Si la respuesta es «7 sesiones», ya lo sabes: pide la muestra grande antes de cambiar nada. La vara es tu filtro contra el hype.
🧰 Resumen del módulo
model.Fin de la ruta:
Cerraste el ciclo completo de Fable Lite: los logs son oro (T1), el trabajo práctico extrae el delta (T2), el delta se convierte en un playbook inyectado (T3) y la prueba real mide sin engañarse (T4). La regla no es un truco de comparación: es tu hábito de exigir un número antes de creer. Elige el modelo, diagnostica el tuyo, estandariza el equipo, demuestra el cambio y rompe el hype. El método es tuyo; ejecútalo con tu historial e itera.