Artículos
Basta de Fan-out a ciegas: arquitectura de orquestación en cuatro capas con Claude Haiku 5.5 en producción
Claude Haiku 5.5 es rápido y económico, pero lanzarle todas las tareas en paralelo solo magnifica los errores de juicio, el sesgo de evaluación y los riesgos de Supply Chain. En este artículo desglosamos una arquitectura por capas con Fable para el criterio, Opus para la orquestación, Sonnet y Haiku para la implementación, validación por CI y aceptación con Opus, además de analizar qué tareas realmente justifican un Fan-out.
· 8 min de lectura
Claude Haiku 5.5 se lanzó el 7 de octubre de 2026. Con un prompt de hasta 100,000 tokens, su precio es una vigésima parte del de Sonnet 5.5, y su latencia es la más baja de la generación actual de Claude.
Al ser tan rápido y asequible, resulta tentador caer en lo fácil: descomponer todas las tareas de programación, lanzarlas en paralelo a una legión de Haiku y dar el trabajo por terminado.
Al crear prototipos, puede que funcione. Sin embargo, al llevarlo a un entorno de ingeniería en producción, no tardan en aparecer tres problemas:
- Los modelos pequeños no gestionan bien la ambigüedad. El posicionamiento oficial de Haiku 5.5 son las tareas de clasificación, extracción, enrutamiento y subagent con alto volumen y baja latencia. Cuando los requisitos arrastran ambigüedad de negocio o exigen el contexto de todo el sistema, tiende a entregar resultados con apariencia impecable, pero orientados en la dirección equivocada.
- Pedirle a un modelo que elija la mejor respuesta introduce sesgo de evaluación. Si le pasas decenas de propuestas a un modelo grande para que las revise, tenderá a escoger la versión con la arquitectura más atractiva a la vista, en lugar de la que realmente tiene la lógica y la ejecución correctas.
- Los permisos se multiplican con el número de Worker. Si permites que los subagent en paralelo instalen paquetes automáticamente o modifiquen la configuración, desplegar N Worker abre N nuevas puertas de entrada para paquetes maliciosos.
Por eso he pasado a una orquestación jerárquica (Hierarchical Orchestration): cada capa se dedica únicamente a lo que mejor sabe hacer, y la capacidad en paralelo de Haiku se reserva solo para los casos donde de verdad aporta valor.
En resumen: Fable se encarga del análisis riguroso, Opus de la asignación y la aceptación, Sonnet de la implementación principal, y Haiku solo asume tareas mecánicas y tareas de exploración con validación automática. Las propuestas candidatas pasan primero por la CI antes de que las examine el modelo.
Arquitectura en cuatro capas: criterio, orquestación, validación y aceptación#
Entrada de requisitos
│
▼
[Capa de criterio] Fable: decisiones de arquitectura, desglose de tareas, criterios de aceptación
│
▼
[Capa de orquestación] Opus Main Session: solo asigna, no vuelve a descomponer
├─► Ruta A: compleja pero con límites claros ──► Implementación con Sonnet
├─► Ruta B: tareas mecánicas ──► Un único Haiku
├─► Ruta C: exploratoria, múltiples enfoques ──► Varios Haiku, cada uno en su Git Worktree
│
▼
[Capa de validación] Build, Type Check, Test, Benchmark (en la Ruta C solo pasan las 2–3 mejores)
│
▼
[Capa de aceptación] Opus consolida según los criterios de aceptación
Si falla, escala: Haiku corrige 2 veces y sigue fallando ➔ Sonnet ➔ Vuelve a Opus
La asignación de cada modelo a su capa responde a su posicionamiento oficial y a su coste. A continuación se muestran los datos de la documentación oficial de Anthropic a fecha de 8 de octubre de 2026; los precios se indican en dólares por millón de tokens:
| Modelo |
Posicionamiento oficial |
Latencia |
Precio Input / Output |
| Claude Fable 5.1 |
Razonamiento de alta complejidad y trabajo agentic de larga duración |
Más lenta |
$10 / $50 |
| Claude Opus 5.5 |
Programación agentic y trabajo de conocimiento de larga duración |
Media |
$4 / $20 |
| Claude Sonnet 5.5 |
El mejor equilibrio entre velocidad y capacidad |
Rápida |
$2 / $10 |
| Claude Haiku 5.5 |
Tareas de clasificación, extracción, enrutamiento y subagent masivas y de baja latencia |
La más rápida |
Desde $0.10 / $0.50 |
La tarificación de Haiku 5.5 tiene dos tramos: cuando el prompt supera los 100,000 tokens, pasa a $0.50 / $2.50.
Capa de criterio: Fable toma las decisiones de arquitectura y define los criterios de aceptación#
No todos los requisitos necesitan Fable. Es la capa más cara y más lenta; solo recurro a ella ante requisitos ambiguos, integraciones complejas entre sistemas o decisiones estructurales clave.
Fable debe entregar tres cosas:
- El diseño de la solución
- El desglose de tareas
- Los criterios de aceptación (Acceptance Criteria) verificables mediante tests para cada subtarea
El razonamiento y la descomposición deben resolverse en la misma capa. Quien detecta los puntos ciegos del sistema es quien mejor delimita las subtareas; encargar la arquitectura a A y el desglose a B suele desdibujar las interfaces.
Las tareas de ciberseguridad son la excepción. La generación actual de modelos Claude incorpora clasificadores de seguridad que devuelven stop_reason: "refusal" cuando bloquean una petición, lo que a veces interrumpe labores legítimas de seguridad. El clasificador de Fable 5.1 abarca la mayor parte del contenido de seguridad y la documentación oficial señala que no está concebido para este ámbito; Opus 5.5, en cambio, sí permite analizar código fuente en busca de vulnerabilidades. Por tanto, para corregir vulnerabilidades de seguridad, derivo el análisis inicial directamente a Opus.
Capa de orquestación: Opus solo asigna, no vuelve a descomponer#
Opus actúa como Main Session y se encarga del enrutamiento y el reparto del trabajo. Esta capa no cuestiona la arquitectura ni realiza un segundo desglose.
- Ruta A, compleja pero con límites claros: tareas con lógica intrincada cuyas interfaces ya están bien acotadas se asignan a Sonnet. Es el motor principal de la implementación.
- Ruta B, tareas puramente mecánicas: código repetitivo (Boilerplate), renombrado de variables, tests unitarios sencillos o actualización de documentación se delegan a un único Haiku.
- Ruta C, tareas exploratorias y de optimización: optimización de rendimiento, redacción de consultas SQL o Regex complejas con varios enfoques, o depuración de Flaky Test. Aquí sí se activa el Fan-out: se lanzan múltiples Haiku, cada uno probando una solución distinta en un Git Worktree independiente.
Sin importar la ruta elegida, todos los entregables deben pasar por la capa de validación.
Capa de validación: primero las máquinas, luego los modelos#
Una práctica muy extendida consiste en pasar todo el código generado en paralelo a Opus o Sonnet para que lo revise mediante un prompt.
El problema es que, al leer código, los modelos se dejan deslumbrar con facilidad por un formato impecable y un tipado riguroso, lo cual no garantiza que superen los casos límite. Por eso, las propuestas deben superar primero el filtro automatizado:
- Build y Type Check: compila sin errores y los tipos encajan
- Unit / Integration Tests: pasa las pruebas unitarias y de integración
- Benchmark / Profiling: medición de rendimiento y consumo de memoria
Lo que no supere los tests automatizados se descarta de inmediato. En la Ruta C, Opus solo revisa las 2–3 mejores opciones que hayan superado las comprobaciones y muestren las mejores métricas, ahorrando además context window y token.
Capa de aceptación: Opus consolida; si algo falla, escala#
Por último, Opus consolida los resultados basándose en los criterios de aceptación fijados en la capa de criterio. Si un Worker se bloquea, se activa la vía de escalado (Escalation Path):
- Si Haiku falla y no lo resuelve tras 2 correcciones automáticas, se detienen los reintentos.
- Sonnet toma el relevo para solucionar el problema.
- Si Sonnet tampoco supera la aceptación, suele indicar una contradicción en el desglose de la tarea o en las premisas de partida. La tarea regresa a Opus, que decide si debe remitirla de nuevo a Fable para una nueva descomposición.
Tres reglas de oro antes de pasar a producción#
No hagas Fan-out a ciegas#
Las tareas sencillas no necesitan varios Worker, y los modelos pequeños no resuelven tareas muy ambiguas. Solo aquellas tareas de exploración con un espacio de soluciones amplio y verificables con rapidez mediante tests automatizados justifican ejecutar varios Haiku en paralelo.
Aísla el entorno y bloquea el Lockfile#
Git Worktree aísla los cambios de código para evitar que los Worker en paralelo sobreescriban archivos entre sí; no restringe el acceso a la red ni el alcance de lo que puede ejecutar el proceso. Para prevenir un Supply Chain Attack, se necesita además un sandbox y prohibir que los Worker instalen dependencias no auditadas o alteren el Lockfile. Dar manga ancha a las instalaciones equivale a dejar que el Agent cuele paquetes y scripts de origen desconocido en el repositorio.
Acepta con métricas, no con opiniones del modelo#
Los resultados de los tests, la cobertura, el uso de memoria y la latencia son criterios reproducibles y comparables. Las valoraciones textuales del modelo pueden servir de orientación, pero no bastan para validar la calidad del código.
Los modelos económicos deben usarse donde corresponde#
Haiku 5.5 abarata la ejecución en paralelo, pero el paralelismo por sí solo no garantiza la corrección. Separar con claridad criterio, asignación, validación y aceptación es lo que convierte la velocidad y el bajo coste en una ventaja competitiva real.
Esta estructura por capas no es más que el Graph del que hablo en Los AI Agents son, en el fondo, un equipo ágil: quién empieza, a quién se le entrega el relevo y a quién se escala cuando surgen problemas.