Artículos
Deja de hacer 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 tirarle todas las tareas en paralelo solo amplifica las malas interpretaciones, 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 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 menos de 100,000 tokens, su precio es una vigésima parte del de Sonnet 5.5, y su latencia es la más rápida de la generación actual de Claude.
Al ser tan barato y rápido, es muy tentador pensar así: divide todas las tareas de coding y mándaselas en paralelo a un grupo de Haiku para que las saquen rápido.
Para armar un prototipo, tal vez funcione. Pero al llevarlo a un entorno de ingeniería formal en producción, te vas a topar de inmediato con tres problemas:
- Los modelos chicos no son buenos manejando la ambigüedad. El posicionamiento oficial de Haiku 5.5 apunta a tareas de alto volumen y baja latencia, como clasificación, extracción, enrutamiento y tareas de subagent. Si los requerimientos vienen con ambigüedad de negocio o requieren el contexto del sistema completo, es muy común que entregue resultados que se ven completos, pero que en realidad le atinaron a la dirección equivocada.
- Hacer que un modelo elija las respuestas genera sesgo de evaluación. Si le pasas docenas de propuestas a un modelo grande para que las revise, suele inclinarse por la versión que «se ve más bonita a nivel de arquitectura», en lugar de la que realmente tiene la lógica y ejecución correctas.
- Los permisos se multiplican junto con la cantidad de Workers. Si dejas que los subagent en paralelo instalen paquetes automáticamente o modifiquen configuraciones, al abrir N Workers estás abriendo N posibles puertas de entrada para paquetes maliciosos.
Por eso cambié a una orquestación jerárquica (Hierarchical Orchestration): cada capa hace solo aquello en lo que destaca, y la capacidad de paralelismo de Haiku solo se explota donde realmente hace falta.
En pocas palabras: Fable se encarga de pensar bien las cosas, Opus de asignar y validar la aceptación, Sonnet de la implementación principal, y Haiku únicamente de tareas mecánicas y búsquedas que se puedan validar automáticamente. Las propuestas candidatas pasan primero por CI antes de que las revise cualquier modelo.
Arquitectura de cuatro capas: criterio, orquestación, validación y aceptación#
Entrada de requerimientos
│
▼
[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 desglosar
├─► Ruta A: compleja pero con límites claros ──► Sonnet implementa
├─► Ruta B: tareas mecánicas ──► Un solo Haiku
├─► Ruta C: exploración, múltiples soluciones ──► Múltiples Haiku, cada uno en un Git Worktree
│
▼
[Capa de validación] Build, Type Check, Test, Benchmark (la Ruta C solo conserva el top 2–3)
│
▼
[Capa de aceptación] Opus consolida según los criterios de aceptación
Si falla, escala: Haiku corrige 2 veces y si sigue fallando ➔ Sonnet ➔ regresa a Opus
El rol de cada modelo en cada capa se determinó con base en su posicionamiento oficial y su precio. Estos son los números de la documentación oficial de Anthropic al 8 de octubre de 2026, con precios en dólares por millón de tokens:
| Modelo |
Posicionamiento oficial |
Latencia |
Precio de Input / Output |
| Claude Fable 5.1 |
Razonamiento de alta dificultad y trabajo agentic de larga duración |
Más lenta |
$10 / $50 |
| Claude Opus 5.5 |
Coding agentic prolongado y trabajo de conocimiento |
Media |
$4 / $20 |
| Claude Sonnet 5.5 |
El mejor balance entre velocidad y capacidad |
Rápida |
$2 / $10 |
| Claude Haiku 5.5 |
Tareas masivas de baja latencia: clasificación, extracción, enrutamiento y subagent |
La más rápida |
Desde $0.10 / $0.50 |
El precio de Haiku 5.5 tiene dos esquemas: cuando el prompt pasa de los 100,000 tokens, sube a $0.50 / $2.50.
Capa de criterio: Fable se encarga de la arquitectura y los criterios de aceptación#
No todos los requerimientos necesitan a Fable. Es la capa más cara y más lenta, así que solo recurro a ella cuando el requerimiento es ambiguo, involucra integraciones entre varios sistemas o exige decisiones de arquitectura críticas.
Fable debe entregar tres cosas:
- El diseño de la solución
- El desglose de las tareas
- Criterios de aceptación (Acceptance Criteria) que se puedan verificar con tests para cada subtarea
El razonamiento y el desglose deben resolverse en la misma capa. Solo la capa que tiene claros los puntos ciegos del sistema puede definir subtareas con límites limpios; si le dejas la arquitectura a A y el desglose a B, las definiciones de las interfaces suelen quedar borrosas.
Las tareas de seguridad son la excepción. La generación actual de modelos de Claude cuenta con clasificadores de seguridad: cuando se bloquea una petición, devuelven stop_reason: "refusal", lo que puede llegar a bloquear trabajo legítimo de ciberseguridad. El clasificador de Fable 5.1 cubre gran parte del contenido de seguridad informática y la documentación oficial aclara que no está diseñado para ese rubro; en cambio, Opus 5.5 sí permite buscar vulnerabilidades directamente en el código fuente. Por eso, para cosas como remediar vulnerabilidades de seguridad, le paso el análisis inicial directo a Opus.
Capa de orquestación: Opus solo asigna, no vuelve a desglosar#
Opus funge como la Main Session, responsable del enrutamiento y la asignación del trabajo. En esta capa no se replantea la arquitectura ni se hace un segundo desglose.
- Ruta A, compleja pero con límites claros: tareas con lógica compleja, pero cuyas interfaces ya tienen límites bien definidos, van a Sonnet. Es el caballo de batalla para la implementación.
- Ruta B, tareas puramente mecánicas: código repetitivo (Boilerplate), renombrar variables, agregar pruebas unitarias sencillas o completar documentación, se le asignan a un solo Haiku.
- Ruta C, tareas de exploración y optimización: tuning de rendimiento, probar distintas formas de escribir SQL o Regex complejos, o investigar un Flaky Test; solo ahí se dispara el Fan-out: mandamos múltiples Haiku, cada uno probando una solución distinta en un Git Worktree independiente.
Sin importar la ruta que se tome, el resultado siempre debe pasar por la capa de validación.
Capa de validación: primero las máquinas, luego el modelo#
Una práctica muy común es mandar todo el código generado en paralelo directo a Opus o Sonnet y pedirle que haga una revisión vía prompt.
El problema es que cuando un modelo lee código, suele dejarse llevar por respuestas con formato impecable y declaraciones de tipos completas, lo cual no garantiza que pasen las pruebas de casos límite. Por eso, las propuestas candidatas deben superar primero el filtro de las máquinas:
- Build y Type Check: que compile y que los tipos sean correctos
- Unit / Integration Tests: pruebas unitarias y de integración pasando
- Benchmark / Profiling: métricas de rendimiento y consumo de memoria
Lo que no pase las pruebas automatizadas se descarta de inmediato. En la Ruta C, Opus solo revisa los 2–3 mejores candidatos que hayan pasado las validaciones y tengan las mejores métricas, lo que también ahorra context window y tokens.
Capa de aceptación: Opus consolida; si falla, escala hacia arriba#
Por último, Opus consolida los resultados basándose en los criterios de aceptación fijados por la capa de criterio. Si un Worker se atora, se sigue una ruta de escalamiento (Escalation Path):
- Si Haiku falla y tras 2 intentos de autocorrección sigue sin pasar, se detienen los reintentos.
- Sonnet toma el control para resolverlo.
- Si Sonnet tampoco logra pasar la aceptación, por lo general significa que hay una contradicción en el desglose de la tarea o en las suposiciones iniciales. La tarea se le regresa a Opus para que decida si hace falta mandarla de vuelta a Fable para reestructurarla.
Tres reglas antes de llevar esto a producción#
No hagas Fan-out a ciegas#
Las tareas simples no necesitan múltiples Workers, y un modelo chico no va a resolver requerimientos altamente ambiguos. Solo vale la pena correr múltiples Haiku en paralelo cuando el espacio de soluciones es amplio y se puede verificar rápidamente mediante pruebas automatizadas.
Aísla los entornos y congela el Lockfile#
Un Git Worktree aísla los cambios en el código para que los Workers en paralelo no se sobreescriban archivos entre sí; no restringe el acceso a la red ni los alcances a los que puede acceder el proceso. Para prevenir un Supply Chain Attack, necesitas además un sandbox y prohibir que los Workers instalen dependencias no auditadas o modifiquen el Lockfile. Dar permisos de instalación a la ligera equivale a dejar que el Agent meta paquetes y scripts de origen dudoso al repositorio.
Valida con métricas cuantitativas, no con comentarios del modelo#
Los resultados de las pruebas, la cobertura, el uso de memoria y la latencia son las únicas bases reproducibles y comparables. La retroalimentación en texto que da un modelo sirve como referencia, pero jamás debe usarse como el criterio final para aceptar la calidad del código.
Los modelos baratos se deben usar donde corresponde#
Haiku 5.5 hace que el paralelismo sea barato, pero el paralelismo por sí solo no hace que el resultado sea correcto. Separa primero el criterio, la asignación, la validación y la aceptación; solo así el bajo costo y la rapidez se convierten en una verdadera ventaja.
Esta división por capas es, en el fondo, el Graph del que hablo en Los AI Agents son, en esencia, un equipo ágil: quién empieza, a quién se le entrega el trabajo y a quién se escala cuando algo sale mal.