diff --git a/blog/2026-05-09-cuatro-fuentes-mismos-principios.md b/blog/2026-05-09-cuatro-fuentes-mismos-principios.md new file mode 100644 index 0000000..f51bdf3 --- /dev/null +++ b/blog/2026-05-09-cuatro-fuentes-mismos-principios.md @@ -0,0 +1,147 @@ +--- +slug: cuatro-fuentes-mismos-principios +title: "Cuatro fuentes independientes, los mismos cuatro principios" +authors: [TellMeAlex] +tags: [ia, agentes, harness, orquestación, arquitectura, investigacion] +image: /img/blog-header.jpg +--- + +# Cuatro fuentes independientes, los mismos cuatro principios + +Cuando cuatro grupos que no se coordinan entre sí llegan a las mismas conclusiones, algo es verdad. + +Anthropic. OpenAI. Factory. La academia (Tsinghua y Stanford). Cuatro equipos con enfoques distintos, incentivos distintos y metodologías distintas, trabajando en paralelo durante 2025 y principios de 2026. Ninguno citando a los otros en tiempo real. Y sin embargo, al final del periodo, los cuatro habían convergido en el mismo conjunto de principios sobre cómo deben funcionar los sistemas de agentes. + + + +Eso no es tendencia. Es física del problema. + +Este artículo documenta las cuatro fuentes, los cuatro principios en los que convergieron y qué implica cada convergencia para quien diseña sistemas con agentes hoy. + +--- + +## Las cuatro fuentes + +| Fuente | Quién | Cuándo | Qué aportaron | +|---|---|---|---| +| **Anthropic** | Prithvi Rajasekaran | Marzo 2026 | Generator-Evaluator-Planner + Sprint Contracts | +| **OpenAI / Lopopolo** | Ryan Lopopolo | Abril 2026 | Repo como prompt persistente + persona-based reviewer agents | +| **Factory** | Luke Alvoeiro | Mayo 2026 | Missions: 16 días, serial+, Validation Contracts, Droid Whispering | +| **Academia** | Tsinghua + Stanford | Marzo 2026 | NLAH (+16.8 pts), Meta-Harness (6× varianza explicada por harness) | + +Cuatro voces. Cuatro contribuciones distintas. Un conjunto de principios compartidos. + +--- + +## Principio 1 — El harness importa más que el modelo + +Esta es la convergencia más disruptiva porque contradice el instinto colectivo de la industria: cuando un sistema falla o rinde poco, la primera pregunta es "¿qué modelo usamos?" Cuatro fuentes independientes responden: probablemente no es el modelo. + +**Tsinghua (NLAH)**: migrar un sistema existente a representación NLAH sin cambiar ni el modelo ni la lógica produjo +16.8 puntos de accuracy. El factor fue la representación del harness. + +**Stanford (Meta-Harness)**: la varianza del harness explica 6× más diferencia de rendimiento que la varianza del modelo. Un harness auto-optimizado llevó a Haiku 4.5 al puesto #1 de TerminalBench, por encima de sistemas construidos a mano con Opus. Haiku batiendo a Opus no con mejor modelo — con mejor harness. + +**Lopopolo (OpenAI)**: "el código es gratis". El trabajo del ingeniero se desplaza a estructurar el repo, los tests, los lints y los reviewer agents. El valor que un engineer aporta hoy está en la calidad del harness, no en el código que el agente puede generar por sí solo. + +**Factory Missions**: la arquitectura que hace posible una misión de 16 días continuos no es un modelo más inteligente — es Orchestrator-Workers-Validators con handoffs estructurados y Validation Contracts. La misma arquitectura con un modelo peor o mejor produce resultados escalados por la arquitectura, no al revés. + +**La implicación práctica**: si tu sistema rinde mal, antes de cambiar el modelo examina el harness. Si el harness no tiene separación de contextos, estado externalizado y verificación adversarial, probablemente sea el bottleneck. + +--- + +## Principio 2 — Generación y verificación deben estar separadas + +Esta es la convergencia más fácil de entender y la más difícil de implementar porque contradice la optimización local obvia: ¿por qué usar dos agentes cuando uno puede hacer las dos cosas? + +Porque el agente que implementó tiene confirmation bias. Quiere que funcione. Lee lo que espera leer. + +Las cuatro fuentes llegaron a la misma arquitectura desde ángulos distintos: + +**Anthropic**: Generator (implementa) ≠ Evaluator (verifica). Sprint Contracts definen el criterio de éxito antes de que empiece la implementación, para que el Evaluator tenga una referencia independiente. + +**Factory**: Worker (implementa) ≠ Validator (verifica). La condición explícita: el Validator nunca ha visto el código que va a verificar. Dos tipos de validadores — Scrutiny (code review automatizado) y User Testing (QA funcional end-to-end). + +**Lopopolo (OpenAI)**: persona-based reviewer agents. Cada rol del equipo de ingeniería tiene su propio agente revisor con un contexto independiente. El agente "senior engineer" revisa diferente al agente "security specialist". Sin apego al código del implementador. + +**Academia**: el patrón adversarial validado empíricamente en 70 proyectos open source. La separación de contextos entre generación y evaluación es estadísticamente significativa en todos los benchmarks. + +**La implicación práctica**: el evaluador no puede ser el implementador. No es una preferencia de arquitectura — es la única forma de evitar el self-evaluation trap. Si tu sistema no tiene esta separación, no tiene QA real, tiene QA que confirma decisiones. + +--- + +## Principio 3 — La lógica vive en prompts, no en state machines + +Este es el principio con las implicaciones más estratégicas a largo plazo. + +La pregunta es simple: ¿dónde codificas el comportamiento de tu sistema? En código (state machines, grafos de flujo, condiciones hardcodeadas) o en texto (prompts, skills, contratos en lenguaje natural). + +Las cuatro fuentes eligieron texto, por razones distintas: + +**Factory Missions**: ~700 líneas de texto definen toda la estrategia de orquestación. Cuatro frases pueden cambiar radicalmente cómo el sistema maneja fallos o replanificaciones. Sin tocar código. Cuando salió una nueva versión del modelo base, el sistema se benefició automáticamente. La arquitectura no compite con los modelos — los usa mejor según mejoran. + +**Lopopolo (OpenAI) / 12-Factor Agents**: Factor 8 — "own your control flow". No escondas el workflow en el framework. Pero sí exprésalo en prompts versionados, no en grafos hardcodeados. La distinción es importante: no delegar el control, sino expresarlo en un formato que mejora con el modelo. + +**NLAH (Tsinghua)**: Execution Contracts son function signatures textuales para agentes. El harness es texto. La evidencia empírica: el mismo algoritmo expresado en lenguaje natural estructurado vs. en código produce +16.8 puntos de diferencia. La representación textual no es solo más legible — es más ejecutable por LLMs. + +**Anthropic**: AGENTS.md, skills, Sprint Contracts — todo texto que el modelo lee, interpreta y ejecuta. La capa determinística del sistema es delgada; la inteligencia está en el texto. + +**La implicación práctica**: las abstracciones que hardcodean el comportamiento quedan obsoletas cuando mejora el modelo. Los prompts que describen el comportamiento mejoran con el modelo. Esta no es una diferencia de filosofía — es una diferencia de vida útil del sistema. + +Concretamente: si tu arquitectura de agentes requiere refactoring de código cada vez que cambias de modelo, tienes lógica en el lugar equivocado. + +--- + +## Principio 4 — El estado es externo y estructurado + +El context window de un agente tiene tres problemas fundamentales como almacén de estado: se satura, se reinicia y no es compartible entre agentes. Las cuatro fuentes llegaron a la misma solución desde ángulos distintos. + +**Factory Missions**: Structured Handoffs. Cuando un worker termina, no pasa el resultado informalmente al siguiente — escribe un documento con cinco campos: qué se completó, qué quedó pendiente, comandos ejecutados y exit codes, issues descubiertos, ¿se siguieron los procedures? El siguiente worker lee ese documento. La misión no depende de que nadie recuerde nada. + +**NLAH (Tsinghua)**: File-Backed State. El estado del agente es un fichero con una dirección en disco. `required_outputs`, `output_paths`, `completion_conditions` son referencias a ficheros, no estados en memoria. Sobrevive a truncación, reinicios y delegación entre agentes. La evidencia: −97% de llamadas al LLM en la migración de OS-Symphony a NLAH, en parte porque el agente ya no tiene que reconstruir contexto que podría haber leído directamente. + +**Lopopolo (OpenAI)**: el repo como prompt persistente. El estado del sistema está en el código, los tests, los lints y los documentos del repo. No en la memoria de ningún agente. Cada agente que se conecta al repo encuentra el estado completo del sistema sin necesidad de que nadie se lo explique. + +**12-Factor Agents (Horthy)**: Factor 12 — "stateless reducer". El agente es una función pura: recibe estado externo + input → produce output + nuevo estado externo. El agente no recuerda nada entre invocaciones. Todo lo que necesita saber está en el estado que recibe. + +**La implicación práctica**: si el estado de tu sistema vive en el context window de un agente, ese estado desaparece cuando el agente se reinicia, se trunca o se delega. Para tareas cortas (minutos), esto puede no importar. Para tareas largas (horas o días), es una bomba de tiempo. + +El estado externalizado no es overhead burocrático — es lo que hace posible la resiliencia, la delegación y la verificación adversarial. Sin él, los tres principios anteriores son mucho más difíciles de implementar. + +--- + +## La matriz completa + +| | **Harness > Modelo** | **Separar Gen/Eval** | **Lógica en texto** | **Estado externo** | +|---|:---:|:---:|:---:|:---:| +| **Anthropic** | ✓ | ✓ | ✓ | ✓ | +| **OpenAI / Lopopolo** | ✓ | ✓ | ✓ | ✓ | +| **Factory** | ✓ | ✓ | ✓ | ✓ | +| **Academia** | ✓ | ✓ | ✓ | ✓ | + +Cuatro equipos. Cuatro filosofías distintas. El mismo conjunto de principios. + +--- + +## Qué significa la convergencia + +La convergencia es evidencia de que estos principios no son preferencias de diseño — son restricciones del problema. + +Los agentes basados en LLMs tienen un conjunto de limitaciones conocidas: el context window es finito, el modelo tiene confirmation bias, las asunciones sobre capacidades del modelo caducan. Cada uno de los cuatro principios es una respuesta directa a una de estas limitaciones: + +- El estado externo responde a la finitud del context window. +- La separación de generación y evaluación responde al confirmation bias. +- La lógica en texto responde a la caducidad de las asunciones. +- El harness como activo principal responde a la variabilidad del rendimiento entre sistemas con el mismo modelo. + +Cuatro grupos llegaron a los mismos principios no porque se copiaran entre sí, sino porque los cuatro se toparon con los mismos obstáculos. La convergencia no es tendencia — es la geometría del problema. + +--- + +## Recursos + +- Presentación completa con matriz de convergencias: [Patrones de Orquestación — Código Sin Siesta](https://codigosinsiesta.github.io/orquestacion-patrones-presentation/) +- NLAH: Pan et al., Tsinghua, marzo 2026 +- Meta-Harness: Khattab et al., Stanford, marzo 2026 +- Factory Missions: Luke Alvoeiro, AI Engineer World's Fair 2026 +- 12-Factor Agents: Dexter Horthy, HumanLayer +- Harness Engineering: Ryan Lopopolo, OpenAI diff --git a/blog/2026-05-09-diez-niveles-complejidad-agentes-ia.md b/blog/2026-05-09-diez-niveles-complejidad-agentes-ia.md new file mode 100644 index 0000000..8bfa036 --- /dev/null +++ b/blog/2026-05-09-diez-niveles-complejidad-agentes-ia.md @@ -0,0 +1,201 @@ +--- +slug: diez-niveles-complejidad-agentes-ia +title: "Los 10 niveles de complejidad de los agentes IA: una taxonomía evolutiva" +authors: [TellMeAlex] +tags: [ia, agentes, orquestación, patrones, arquitectura, multi-agente] +image: /img/blog-header.jpg +--- + +# Los 10 niveles de complejidad de los agentes IA: una taxonomía evolutiva + +El término "agente IA" cubre demasiado. Cubre un chatbot con una tool de búsqueda y cubre un sistema que lleva 16 días ejecutando en producción sin supervisión humana continua. Llamarlos igual es como llamar "vehículo" a una bicicleta y a un Airbus A380. + +La industria necesita un vocabulario de complejidad. Este artículo propone uno. + + + +Diez niveles, ordenados de menor a mayor complejidad. Cada nivel **resuelve el límite del anterior** — no son patrones intercambiables, son una escalera donde cada peldaño existe porque el anterior tenía un techo claro. La recomendación es simple: empieza donde estás. No saltes niveles. + +--- + +## La escalera + +``` +Nivel 10 ── Puppeteer / RL Orchestration ← frontier +Nivel 9 ── Missions (composición de patrones) ← producción avanzada +Nivel 8 ── Swarm / Mesh ← sin coordinador central +Nivel 7 ── Hierarchical + Broadcast ← coordinación a escala +Nivel 6 ── Creator-Verifier ← validación adversarial +Nivel 5 ── Orchestrator-Workers ← delegación dinámica +Nivel 4 ── Routing ← clasificar → especialista correcto +Nivel 3 ── Pipeline / Prompt Chaining ← secuencia fija de etapas +Nivel 2 ── Reflexion ← aprender de intentos fallidos +Nivel 1 ── ReAct loop ← el agente piensa antes de actuar +``` + +--- + +## Nivel 1 — ReAct loop + +**En una frase**: el agente verbaliza su razonamiento y lo entrelaza con sus acciones. + +Yao et al. (2022) formalizaron lo que parece obvio en retrospectiva: un agente que solo actúa es ciego, y un agente que solo razona sin ejecutar nunca actualiza su plan con información real del entorno. ReAct fusiona los dos en un loop atómico: + +``` +Thought → Action → Observation → Thought → ... +``` + +El razonamiento es legible. Cuando el agente falla, puedes leer exactamente dónde se torció. Eso solo — la interpretabilidad del loop — ya justifica empezar aquí. + +**Cuándo subir al nivel 2**: cuando el agente falla frecuentemente en el primer intento de tareas iterables y no tiene forma de aprender de ese fallo. + +--- + +## Nivel 2 — Reflexion + +**En una frase**: el agente genera una autocrítica verbal después de cada intento y la inyecta en el siguiente. + +ReAct mejora dentro de un intento. Reflexion añade mejora *entre* intentos. Tres componentes: Actor (ejecuta con ReAct), Evaluador (valora el resultado), Reflector (genera la crítica: "fallé porque X, la próxima vez haré Y"). La crítica se almacena en memoria episódica y alimenta el contexto del siguiente intento. + +Sin fine-tuning. Sin modificar el modelo. El "aprendizaje" es textual — de ahí el nombre del paper original: "verbal reinforcement learning". + +Resultado: 91% pass@1 en HumanEval, superando GPT-4 (80%) con el mismo modelo base. + +**Límite**: la memoria episódica vive en el context window. Si los intentos son largos o numerosos, el contexto se satura. Aquí empieza a necesitarse estado externo. + +**Cuándo subir**: cuando el flujo de trabajo tiene múltiples pasos especializados que siempre se ejecutan en el mismo orden. + +--- + +## Nivel 3 — Pipeline / Prompt Chaining + +**En una frase**: varios agentes especializados en secuencia fija, cada uno procesa el output del anterior. + +El primer patrón realmente multi-agente. La topología es estática — se define en diseño time, no cambia con el contenido del input. Agente A procesa el input, pasa el resultado al Agente B, que lo pasa al C. + +Es el patrón correcto para flujos ETL, procesamiento de documentos o CI/CD agéntico donde los pasos son siempre los mismos y en el mismo orden. + +**Límite**: la topología es rígida. Si el flujo correcto depende del contenido del input, un pipeline fijo tomará siempre el mismo camino aunque no sea el adecuado. + +**Cuándo subir**: cuando diferentes inputs necesitan diferentes rutas de procesamiento. + +--- + +## Nivel 4 — Routing + +**En una frase**: clasificar la intención del input y enviarlo al agente especializado correcto. + +El insight detrás del Routing es empírico: un agente con más de 15 tools disponibles tiene menos del 80% de precisión en selección de tool. No porque el modelo sea malo — sino porque el espacio de decisión es demasiado grande. La solución es distribuir: múltiples agentes especializados con 3-5 tools cada uno, y un router que decide a cuál enviar. + +Cuatro variantes según el trade-off velocidad/precisión: +- **Embedding similarity** — 50ms, sin llamada al LLM +- **LLM-based** — 1-2s, más preciso +- **Cascading** — el router barato primero, el caro solo si el primero no tiene suficiente confianza +- **Cost-aware** — decide según presupuesto disponible en el momento + +**Límite**: el routing es estático. Una vez enviado el input al especialista, la ejecución es lineal. No hay coordinación dinámica entre agentes. + +**Cuándo subir**: cuando necesitas que el resultado de un agente informe qué hacer a continuación, de forma dinámica. + +--- + +## Nivel 5 — Orchestrator-Workers + +**En una frase**: un orchestrator recibe la tarea, la descompone dinámicamente en subtareas y delega a workers sin estado. + +Este es el patrón de producción más común. Domina el 70% de los deployments multi-agente reales. La diferencia clave con el Pipeline: la descomposición ocurre en runtime, no en diseño time. El orchestrator decide en función del input qué workers necesita y en qué orden. + +Los workers son apátridas por diseño — no acumulan contexto entre tareas. Esto es lo que los hace composables y substituibles. + +**Límite**: no hay verificación adversarial. El orchestrator coordina, pero nadie verifica que el resultado del worker sea correcto antes de darlo por bueno. + +**Cuándo subir**: cuando los errores del agente que implementa son difíciles de detectar por el mismo agente que los cometió. + +--- + +## Nivel 6 — Creator-Verifier / Generator-Evaluator + +**En una frase**: el agente que implementa y el que verifica tienen contextos completamente separados. La verificación es adversarial por diseño. + +Este es el salto más importante de la escalera. No porque sea técnicamente complejo, sino porque resuelve un problema cognitivo fundamental: **el agente que escribió el código tiene confirmation bias**. Quiere que funcione. Ve lo que espera ver. Un agente fresco, sin haber visto la implementación, encuentra los bugs con mucha más frecuencia. + +Es el mismo principio por el que los humanos hacemos code review: el revisor no tiene apego al código. + +Anthropic lo implementa como Planner-Generator-Evaluator. Factory lo implementa como Orchestrator-Worker-Validator, con la condición explícita de que el Validator nunca ha visto el código antes de verificarlo. + +**Cuándo subir**: cuando las tareas son tan largas que un solo worker no puede mantener la atención y calidad durante toda la ejecución. + +--- + +## Nivel 7 — Hierarchical + Broadcast + +**En una frase**: un orchestrator maestro coordina sub-orchestrators especializados; el estado global se difunde a todos via broadcast. + +Cuando la escala del problema supera lo que un orchestrator puede coordinar, la respuesta natural es añadir capas. El orchestrator maestro no ejecuta nada — coordina sub-orchestrators que a su vez coordinan workers. + +El broadcast es el mecanismo que mantiene coherencia: cuando el estado global cambia (nuevo constraint, nueva información, replanificación), todos los agentes del sistema reciben la actualización. Sin broadcast, los agentes en diferentes ramas del árbol jerárquico toman decisiones inconsistentes. + +**Límite**: el orchestrator maestro es un single point of failure. Si cae o se corrompe, todo el sistema se detiene. + +**Cuándo subir**: cuando quieres eliminar ese single point of failure. + +--- + +## Nivel 8 — Swarm / Mesh + +**En una frase**: dos patrones sin coordinador central. Swarm: la topología emerge en runtime por reglas locales. Mesh: conexiones peer-to-peer fijas en diseño time. + +La promesa es atractiva: sin coordinador central, sin single point of failure, máxima resiliencia. La realidad en ingeniería de software es más complicada. + +**La trampa del Swarm en software**: los agentes comparten estado — el codebase. Cuando dos agentes modifican los mismos ficheros simultáneamente sin coordinación, los cambios se pisan. El Swarm solo funciona cuando las tareas son verdaderamente independientes y no comparten estado. En software, eso es raro. + +El Mesh es más predecible — las conexiones están definidas — pero tiene el overhead de gestionar todas las comunicaciones peer-to-peer. + +**Cuándo tiene sentido**: Swarm para tareas de análisis donde los agentes solo leen (nunca escriben) estado compartido. Mesh para pipelines donde los roles están muy bien definidos y no cambian. + +**Cuándo subir**: cuando necesitas combinar varios de estos patrones en un workflow de larga duración. + +--- + +## Nivel 9 — Missions + +**En una frase**: composición deliberada de cuatro patrones (Delegación + Creator-Verifier + Broadcast + Negociación) en un workflow que corre durante días o semanas sin degradación. + +Factory documentó la arquitectura de Missions en producción. Los números de la misión más larga registrada: **16 días continuos, 185 agent runs, 778M tokens, 89% de coverage de tests**. Eso no es posible con ninguno de los patrones anteriores por separado. + +Lo que hace que las Missions escalen donde los sistemas simples se degradan son tres decisiones de diseño no obvias: + +**1. Ejecución serial, no paralela.** La intuición dice "más agentes en paralelo = más velocidad". Factory lo probó y descubrió que los agentes en paralelo se pisan los cambios, duplican trabajo y toman decisiones arquitectónicas inconsistentes. La ejecución serial con paralelismo interno solo en operaciones read-only es más lenta en el papel y más rápida en producción porque no hay que deshacer trabajo. + +**2. Handoffs estructurados.** Cuando un worker termina, no pasa el resultado al siguiente — escribe un documento estructurado con: qué se completó, qué quedó sin hacer, comandos ejecutados y sus exit codes, issues descubiertos. El sistema no depende de que nadie recuerde nada. La memoria es externa y estructurada. + +**3. Validation Contracts escritos antes del código.** El contrato define qué significa "done" de forma independiente a la implementación. Los tests escritos después del código confirman las decisiones tomadas; el contrato escrito antes verifica la intención original. La diferencia es sustancial: la validación nunca pasa al primer intento, y eso no es un bug — es evidencia de que el QA loop está funcionando. + +--- + +## Nivel 10 — Puppeteer / RL Orchestration + +**En una frase**: un orchestrator entrenado con reinforcement learning aprende qué secuencia de delegaciones produce mejores resultados para cada tipo de tarea. + +El frontier del campo a mayo de 2026. No hay método publicado para la decisión de cuándo parar el entrenamiento. Los requisitos para que tenga sentido son altos: necesitas suficientes ejecuciones históricas como para que el entrenamiento valga más que un harness bien diseñado a mano. + +La diferencia con los niveles anteriores es cualitativa: en lugar de seguir una arquitectura fija (por sofisticada que sea), el orchestrator aprende la arquitectura óptima para cada clase de problema a partir de los datos de ejecuciones reales. + +--- + +## Dónde está la industria + +La mayoría de equipos trabajan entre el nivel 3 y el 5. Eso no es malo — el Orchestrator-Workers resuelve el 70% de los casos reales. El problema es cuando se intenta saltar al nivel 8 o 9 sin haber consolidado el 6. + +El salto más difícil de la escalera no es el más alto — es el de 5 a 6. Pasar de "el agente hace el trabajo" a "hay un agente que verifica adversarialmente el trabajo de otro agente" requiere un cambio de mentalidad más que un cambio técnico. Requiere aceptar que el agente que implementa no puede ser el que verifica, por bueno que sea. + +Una vez cruzado ese umbral, los niveles 7, 8 y 9 son variaciones del mismo principio: separación de contextos, estado externo, verificación adversarial a mayor escala. + +--- + +## Recursos + +- Presentación completa con diagramas: [Patrones de Orquestación — Código Sin Siesta](https://codigosinsiesta.github.io/orquestacion-patrones-presentation/) +- ReAct: Yao et al., ICLR 2023 +- Reflexion: Shinn et al., NeurIPS 2023 +- Factory Missions: Luke Alvoeiro, AI Engineer World's Fair 2026 diff --git a/blog/2026-05-09-harness-engineering-vale-mas-que-el-modelo.md b/blog/2026-05-09-harness-engineering-vale-mas-que-el-modelo.md new file mode 100644 index 0000000..e167a2f --- /dev/null +++ b/blog/2026-05-09-harness-engineering-vale-mas-que-el-modelo.md @@ -0,0 +1,199 @@ +--- +slug: harness-engineering-vale-mas-que-el-modelo +title: "El harness vale más que el modelo: lo que dos papers de 2026 demuestran" +authors: [TellMeAlex] +tags: [ia, agentes, harness, investigacion, arquitectura] +image: /img/blog-header.jpg +--- + +# El harness vale más que el modelo: lo que dos papers de 2026 demuestran + +Mismo modelo. Mismo benchmark. **6× de diferencia en rendimiento.** + +Esa es la cifra que abre este artículo y que lo justifica. Stanford la documentó en TerminalBench. LangChain la reprodujo en su coding agent, pasando del puesto 30+ al 5 sin cambiar el LLM. La pregunta es obvia: si el modelo es el mismo, ¿de dónde viene la diferencia? + +De lo que envuelve al modelo. De su harness. + + + +Dos papers de marzo de 2026 — uno de Tsinghua, otro de Stanford — lo demuestran con experimentos controlados por primera vez. Lo que antes era intuición de equipo ahora tiene ablación, métricas y reproducibilidad. Este artículo desempaqueta qué encontraron y qué implica para quien diseña sistemas con agentes hoy. + +--- + +## Qué es el harness + +LangChain lo define en una ecuación: **Agent = Model + Harness**. + +Si no eres el modelo, eres el harness. Es todo lo que no son pesos del modelo: los prompts, las tools, la lógica de orquestación, la gestión de memoria, los mecanismos de verificación, las políticas de safety. Es la diferencia entre una CPU sin sistema operativo y una máquina que hace trabajo útil. + +La metáfora más honesta: el LLM en crudo es un caballo desbocado. Potente, pero sin dirección. El harness — contexto, tools, memoria, validación — es el arnés que lo convierte en trabajo productivo. Cuatro piezas que toda arquitectura de agente tiene que resolver, explícita o implícitamente. + +Anthropic ha identificado cinco patrones canónicos en los que se combinan estas piezas: prompt chaining, routing, parallelización, orchestrator-workers, evaluator-optimizer. Todo agente en producción es una combinación de varios. Las decisiones sobre cuál usar, cuándo y cómo son exactamente las que generan ese gap de 6×. + +--- + +## El problema previo: sin representación explícita no hay ciencia + +Antes de 2026, el harness se construía de forma caótica. Dos sistemas que "diferían en una decisión arquitectónica" en realidad diferían simultáneamente en prompts, tools, gates de verificación y semántica de estado. Sin una forma de separar variables no había ablación posible, y sin ablación no hay ciencia — solo intuición de equipo que no se transfiere. + +Anthropic documentó dos modos de fallo que se repetían en todos los sistemas sin harness explícito: + +- **One-Shotting**: el agente intenta resolver todo de una vez y agota el contexto antes de terminar. +- **Premature Completion**: una sesión posterior ve progreso parcial y declara victoria sin terminar el trabajo real. + +La solución que fue emergiendo en la industria — arquitectura GAN de tres agentes (Planner → Generator → Evaluator) — funcionaba, pero a un coste 20× mayor y sin ser portable ni ablarable. OpenAI lo usó para producir 1 millón de líneas de código con 1.500 PRs, cero escritas a mano. El veredicto del campo fue claro: *productivo pero ad hoc*. Hacía falta hacer el harness explícito y ejecutable. + +--- + +## Paper 1 — NLAH (Tsinghua): la representación que permite ciencia + +### Una arquitectura en tres capas + +Natural-Language Agent Harnesses (Pan et al., Tsinghua, marzo 2026) propone separar la lógica del agente en tres capas con responsabilidades distintas: + +| Capa | Tipo | Qué contiene | +|---|---|---| +| **NLAH** | Intercambiable por tarea | Contracts, Roles, Stages, taxonomía de fallos | +| **Runtime Charter** | Universal y fijo | Cómo se vinculan contratos, cómo persiste el estado, cómo se gestionan agentes hijo | +| **Backend** | Infraestructura | Terminal tools, interfaz multi-agente, primitivas de spawn y wait | + +Esta separación da al campo algo que nunca había tenido: **experimentos controlados**. Intercambias el NLAH manteniendo el Charter fijo y estás testeando el diseño del harness. Fijas el NLAH y cambias el Charter y estás testeando la política del runtime. Ablación limpia por primera vez. + +### Los dos mecanismos que lo hacen funcionar + +El paper descansa sobre dos primitivas: + +**Execution Contracts** — function signatures para agentes: `required_outputs`, `budgets`, `permissions`, `completion_conditions`, `output_paths`. Convierten completions difusas ("haz esto") en llamadas acotadas con criterios de éxito verificables. + +**File-Backed State** — la memoria del agente es un fichero con una dirección en disco. Sobrevive a truncación del context window, a reinicios y a delegación entre agentes. No depende de que nadie recuerde nada. + +### El hallazgo que cambia el cálculo + +Los investigadores migraron un sistema existente (OS-Symphony, harness expresado en código) a representación NLAH — mismo algoritmo, mismo modelo, distinta forma de expresarlo: + +| Métrica | OS-Symphony | NLAH | Cambio | +|---|---|---|---| +| Accuracy | 30.4% | **47.2%** | +55% | +| Tiempo de runtime | 361 min | **141 min** | −61% | +| Llamadas al LLM | 1.200 | **34** | −97% | + +**+16.8 puntos de accuracy solo cambiando la representación.** Sin tocar la lógica. Sin cambiar el modelo. Solo cambiar cómo se escribe el harness. + +### La ablation surprise + +El hallazgo más contraintuitivo del paper viene de los experimentos de ablación con GPT-5.4 al máximo razonamiento en SWE-Bench Verified. + +Con 6 módulos activos: ~75% de tareas resueltas, 16.3M tokens, 642 llamadas, 32 minutos. +Con solo LLM + tools básicas: ~75% de tareas resueltas, 1.2M tokens, 51 llamadas, 7 minutos. + +Mismo resultado. **14× el cómputo.** + +El módulo a módulo revela el patrón: +- Verificadores automáticos: −8.4 puntos ❌ +- Búsqueda multi-candidato: −5.6 puntos ❌ +- Self-evolution (retry con criterio de aceptación): **+4.8 puntos** ✅ + +> **Disciplined narrowing beats expensive broadening every time.** + +La intuición de añadir más verificaciones y más candidatos es natural para un ingeniero. El paper dice que es cara y contraproducente. El único módulo que consistentemente añade valor es el que estrecha el loop del propio agente con un criterio de aceptación explícito. + +--- + +## Paper 2 — Meta-Harness (Stanford): el harness es optimizable + +### Lo que DSPy no puede hacer + +Omar Khattab (también autor de DSPy) publicó Meta-Harness en Stanford en el mismo mes. La distinción es importante: DSPy tunea prompts dentro de un pipeline fijo. Meta-Harness **reescribe el pipeline entero** — estructura, retrieval, memoria, topología. No ajusta parámetros, cambia la arquitectura. + +### El loop de optimización automática + +Un **Agentic Proposer** (Claude Opus) lee traces de ejecuciones fallidas, diagnostica qué rompió y escribe un harness nuevo completo. Un **Evaluator** lo testea contra el benchmark. Los traces y scores se acumulan en un filesystem creciente. Se repite. + +La escala: 10M tokens por iteración de optimización, 400× más señal de feedback que cualquier método anterior. Y hay un detalle crítico que el paper documenta: **resumir los traces destruye la diagnosticabilidad**. Eliminar traces baja el rendimiento del 50% al 34.6%. Sustituirlos por resúmenes: 34.9%. La señal vive en los detalles en bruto, no en las abstracciones sobre ellos. + +### Los resultados que reordenan el leaderboard + +| Modelo | Sistema | Tipo | Score en TerminalBench | +|---|---|---|---| +| Opus 4.6 | Meta-Harness | Auto-optimizado | **76.4%** | +| **Haiku 4.5** | **Meta-Harness** | **Auto-optimizado** | **37.6% — puesto #1*** | +| Haiku 4.5 | Goose | Hand-engineered | 35.5% | + +*\*Un modelo más pequeño en el primer puesto, por encima de sistemas construidos a mano con modelos más grandes.* + +### El hallazgo sobre transferibilidad + +El dato más relevante para quien diseña productos: **un harness optimizado sobre un modelo se transfirió a otros 5 modelos y mejoró todos ellos**. Sin reoptimización. + +Esto invierte la lógica habitual. El asset reutilizable no es el modelo — es el harness. Cambiar de proveedor o subir de versión deja de ser el evento disruptivo que era. Si el harness está bien diseñado, se beneficia automáticamente de cualquier mejora de modelo. + +--- + +## Las tres eras + +El campo ha pasado por tres momentos con límites bastante claros: + +``` +Harness Engineering (2026) + └── Context Engineering (2024) + └── Prompt Engineering (2022) +``` + +Cada era absorbe la anterior. El harness engineering incluye saber escribir buenos prompts y gestionar el contexto, pero añade orquestación, memoria, verificación y safety como problemas de primer orden que merecen diseño explícito. + +### El oficio de sustracción + +Hay una paradoja en cómo madura este campo: los sistemas mejoran quitando cosas, no añadiéndolas. + +> *"Cada componente del harness codifica una asunción sobre lo que el modelo no puede hacer solo, y esas asunciones caducan."* — Anthropic + +Tres casos documentados: +- Anthropic eliminó context resets cuando Claude dejó de necesitarlos. +- Manus reescribió su harness 5 veces en 6 meses. +- Vercel quitó el 80% de las tools de un agente → resultados mejores. + +El espacio del harness no se encoge cuando los modelos mejoran. **Se mueve.** El trabajo maduro es tanto sustracción como adición, y saber cuándo quitar es más difícil que saber cuándo añadir. + +--- + +## El arnés mínimo accionable + +La parte que falta en la mayoría de charlas sobre este tema: ¿qué escribes el lunes? + +Una estructura mínima de harness que cubre las bases: + +``` +proyecto/ +├── AGENTS.md ← quién eres, qué puedes hacer, cómo colaboras +├── CLAUDE.md ← wrapper de proyecto con contexto específico +├── init.sh ← setup del entorno que el agente puede ejecutar +├── featurelist.json ← estado de tareas externalizado, fuera del context window +└── progress/ + ├── leader.md ← el orchestrator escribe aquí su plan + ├── implementer.md ← el worker escribe su handoff estructurado + └── reviewer.md ← el evaluador escribe sus findings +``` + +La separación de roles en ficheros físicos no es burocracia — es la implementación más simple de estado externalizado y separación de contextos que los papers identifican como los dos mecanismos que marcan la diferencia. + +--- + +## Cinco conclusiones + +**1. El paradigma ha cambiado.** La pregunta operativa ya no es *"¿qué modelo elijo?"* sino *"¿qué estructura quito?"*. Esto invierte el reflejo natural del ingeniero. + +**2. El harness es el activo de primer nivel.** Si transfiere entre modelos, vale más que cualquier modelo individual. Invertir en harness rinde más que esperar al próximo modelo. + +**3. La representación es una decisión arquitectónica.** El +16.8 puntos solo por cambiar de código a lenguaje natural estructurado es el dato más incómodo del paper. La elección entre código nativo, YAML, DSL o prose-as-code no es preferencia de equipo — es un parámetro de rendimiento. + +**4. La verificación naive es una trampa cara.** Añadir verificadores y búsqueda multi-candidato empeora el rendimiento mientras dispara el coste. Solo añade valor estrechar el loop del agente con criterios de aceptación explícitos. + +**5. La disciplina es de sustracción.** El harness no es un edificio que se construye — es una asunción que se mantiene viva podándola. Cada componente que ya no hace falta es deuda técnica que resta rendimiento. + +--- + +## Recursos + +- Presentación completa: [Harness Engineering — Código Sin Siesta](https://codigosinsiesta.github.io/harness-engineering-presentation/) +- Pan et al. — Natural-Language Agent Harnesses — Tsinghua, marzo 2026 +- Khattab et al. — Meta-Harness — Stanford, marzo 2026 diff --git a/blog/2026-05-09-patron-correcto-para-cada-problema.md b/blog/2026-05-09-patron-correcto-para-cada-problema.md new file mode 100644 index 0000000..c29863c --- /dev/null +++ b/blog/2026-05-09-patron-correcto-para-cada-problema.md @@ -0,0 +1,142 @@ +--- +slug: patron-correcto-para-cada-problema +title: "El patrón correcto para cada problema: 6 dolores reales y sus soluciones" +authors: [TellMeAlex] +tags: [ia, agentes, orquestación, patrones, multi-agente, arquitectura] +image: /img/blog-header.jpg +--- + +# El patrón correcto para cada problema: 6 dolores reales y sus soluciones + +El error más caro al diseñar sistemas con agentes no es usar el patrón equivocado. Es no saber que existe el correcto. + +La mayoría de los problemas que aparecen en producción con agentes IA no son bugs del modelo — son consecuencias predecibles de arquitecturas que no están diseñadas para el problema que tienen que resolver. Y lo predecible tiene solución conocida. + + + +Este artículo no va de taxonomías. Va de síntomas. Empieza con el dolor que ya tienes — o el que tendrás en cuanto escales — y lleva directo al patrón que lo resuelve y por qué funciona. + +--- + +## Problema 1 — El agente no detecta sus propios errores + +**Síntoma**: el agente implementa algo, lo revisa, dice que está bien. No está bien. Los tests pasan. En producción falla. + +**Por qué ocurre**: confirmation bias. El agente que escribió el código quiere que funcione. Lee lo que espera leer. Ve lo que espera ver. No es un fallo del modelo — es un fallo cognitivo estructural que también tienen los humanos, y por eso hacemos code review con personas distintas al autor. + +**El patrón**: Creator-Verifier / Generator-Evaluator. + +El agente que implementa y el que verifica tienen **contextos completamente separados**. El verificador nunca ha visto el código antes de revisarlo. Sin apego. Sin memoria de las decisiones que llevaron a esa implementación. + +Anthropic lo formaliza como Planner-Generator-Evaluator. Factory lo implementa como la condición explícita de que el Validator nunca ha visto el código que va a verificar. El principio de diseño subyacente es el mismo: **la evaluación adversarial requiere separación de contextos**. + +Una consecuencia práctica que Factory documentó en producción: la validación **nunca pasa al primer intento**. Siempre se generan follow-up features. Eso no es un bug del sistema — es evidencia de que el QA loop está funcionando. Un sistema que siempre pasa validación al primer intento no está validando nada real. + +--- + +## Problema 2 — La calidad cae en tareas largas + +**Síntoma**: el agente trabaja bien las primeras horas. Pasadas 3-4 horas (o al día siguiente), los resultados degradan. Pierde el hilo, repite trabajo, toma decisiones inconsistentes con decisiones anteriores. + +**Por qué ocurre**: el context window se satura. La atención del modelo no es uniforme sobre todo el contexto — se degrada hacia los extremos. En tareas largas, el contexto acumula tanto ruido que el agente literalmente pierde de vista parte del trabajo previo. + +**El patrón**: Context Isolation + Structured Handoffs. + +Cada worker arranca con un contexto limpio. No hereda la conversación completa de los workers anteriores — hereda un documento estructurado con exactamente lo que necesita saber: qué se completó, qué quedó pendiente, qué problemas se encontraron, qué decisiones arquitectónicas se tomaron y por qué. + +El estado del sistema no vive en el context window de ningún agente. Vive en disco, en ficheros estructurados que cualquier agente puede leer sin necesidad de haber estado presente cuando se escribieron. + +Factory documentó la misión más larga del campo: **16 días continuos, 185 agent runs**. Sin degradación de calidad entre el día 1 y el día 16. El aislamiento de contextos es lo que lo hace posible — no un modelo más grande ni un context window más largo. + +--- + +## Problema 3 — Los agentes en paralelo se pisan los cambios + +**Síntoma**: lanzas varios agentes en paralelo para acelerar. Acaban pisándose los cambios, duplicando trabajo o tomando decisiones arquitectónicas inconsistentes entre sí. El overhead de merge acaba siendo mayor que el tiempo ahorrado. + +**Por qué ocurre**: los agentes comparten estado — el codebase — sin coordinación. Dos agentes modificando los mismos ficheros simultáneamente es una race condition. La intuición de "más agentes en paralelo = más throughput" viene de paralelismo de CPU, donde las tareas son independientes. El software raramente tiene tareas verdaderamente independientes. + +**El patrón**: ejecución serial con paralelismo interno solo en operaciones read-only. + +La ejecución de features es secuencial: Feature 1 → Feature 2 → Feature 3. Dentro de cada worker, el paralelismo es válido donde no hay escritura compartida: buscar en el codebase, consultar documentación, investigar APIs. Dentro de la validación: revisar Feature A, Feature B y Feature C en paralelo está bien porque los validators solo leen. + +El resultado parece más lento en el papel. En producción es más rápido porque la tasa de error es dramáticamente menor. En tareas de varios días, la corrección **se compone**: un error que no se comete el día 1 no se propaga al día 16. El coste de revertir trabajo mal hecho supera con creces el coste del throughput perdido. + +--- + +## Problema 4 — Los tests no atrapan los bugs que importan + +**Síntoma**: los tests pasan. La suite está verde. Hay cobertura alta. Y aun así el sistema tiene bugs que importan. Los tests confirman que el código hace lo que el código hace, no que el código hace lo que debería hacer. + +**Por qué ocurre**: los tests fueron escritos por el mismo agente que implementó. Ese agente codificó sus propias decisiones de diseño en los tests. Los tests confirman esas decisiones en lugar de verificar la intención original del requisito. + +**El patrón**: Validation Contracts escritos antes del código. + +El contrato define qué significa "done" **antes de que empiece la implementación**, de forma independiente a cómo se vaya a implementar. Para un proyecto complejo: cientos de assertions. Cada feature debe satisfacer al menos una. La suma de features debe cubrir todas las assertions. + +``` +Sin contrato: + Implementación → Tests (shaped by implementation) → Tests pasan → Drift silencioso + +Con contrato: + Contrato → Implementación → Tests de contrato → Sin drift +``` + +Esto es Spec-Driven Development llevado al nivel de harness verificable automáticamente. El contrato es el artefacto que permite que el Validator tenga criterios objetivos de evaluación sin haber visto la implementación. + +--- + +## Problema 5 — El sistema queda obsoleto con el próximo modelo + +**Síntoma**: sale una nueva versión del modelo. Hay que revisar toda la lógica de orquestación porque está hardcodeada en state machines que asumen comportamientos específicos del modelo anterior. El sistema que funcionaba bien con GPT-4 se comporta diferente con GPT-5. + +**Por qué ocurre**: la lógica de orquestación vive en código que codifica asunciones sobre las capacidades actuales del modelo. Cuando el modelo cambia, las asunciones quedan desactualizadas. + +**El patrón**: lógica en prompts y skills, no en state machines. + +La capa determinística del harness debe ser **delgada**: ejecutar validación, bloquear progreso cuando hay issues sin resolver, hacer bookkeeping de estado. Lo mínimo que no puede expresarse en texto. + +La inteligencia del sistema vive en texto: cómo descomponer features, cómo manejar fallos, cómo ajustar la estrategia. Factory tiene ~700 líneas de texto que definen toda su estrategia de orquestación. Cuatro frases pueden cambiar la estrategia de ejecución radicalmente, sin tocar código. + +Cuando sale un modelo mejor, ese texto se ejecuta mejor automáticamente. La arquitectura no compite con los modelos — los usa mejor según mejoran. El mismo sistema, más capaz, sin refactoring. + +Este es el principio que Lopopolo formalizó en los 12-Factor Agents: "own your control flow" — pero exprésalo en texto versionado, no en grafos hardcodeados. + +--- + +## Problema 6 — Supervisar agentes es a tiempo completo o inútil + +**Síntoma**: o te quedas mirando la pantalla todo el tiempo para intervenir cuando algo va mal (HITL bloqueante), o delegas completamente y te enteras de los problemas cuando ya hay daño hecho (HOTL superficial). Los dos extremos son inviables. + +**Por qué ocurre**: no hay diferenciación por riesgo. No todas las acciones de un agente tienen el mismo coste de error. Un agente que borra un fichero de configuración en producción necesita confirmación humana. Un agente que genera un borrador de texto no la necesita. + +**El patrón**: Autonomy Spectrum + supervisión diferenciada por riesgo. + +El gate bloquea lo irreversible: acciones destructivas, cambios en sistemas compartidos, decisiones con consecuencias que no se pueden deshacer. El monitoreo observa el resto sin interrumpir. + +En la práctica: define explícitamente qué categorías de acciones requieren gate humano y cuáles no. Los agentes con este diseño pueden correr durante días enviando notificaciones de progreso sin bloquear, y detenerse específicamente cuando llegan a una acción que merece revisión. + +Mission Control de Factory es la implementación más madura de esto: una vista asíncrona donde el humano actúa como project manager (revisa handoff summaries, aprueba replanificaciones en milestone boundaries) sin necesidad de estar presente en cada paso de implementación. No es supervisión en tiempo real — es supervisión en los momentos que importan. + +--- + +## Los 6 principios que los unen + +Detrás de los seis problemas hay seis principios de diseño. Son el patrón detrás del patrón: + +1. **Separación de contextos** — el verificador no puede haber visto la implementación. +2. **Estado externalizado** — lo que el sistema sabe no puede vivir solo en un context window. +3. **Corrección serial** — un error que no ocurre en el día 1 no se propaga al día 16. +4. **Spec antes que código** — los tests escritos después confirman decisiones; los contratos escritos antes verifican intención. +5. **Lógica en texto, no en grafos** — el sistema se beneficia automáticamente de cada mejora de modelo. +6. **Supervisión por riesgo** — el gate bloquea lo irreversible; el monitoreo observa el resto. + +Si diseñas un sistema multi-agente y puedes responder a cada uno de estos seis puntos con una decisión explícita, tienes una arquitectura. Si no puedes responderlos, tienes intuición — y la intuición escala mal. + +--- + +## Recursos + +- Presentación completa con diagramas: [Patrones de Orquestación — Código Sin Siesta](https://codigosinsiesta.github.io/orquestacion-patrones-presentation/) +- Factory Missions: Luke Alvoeiro, AI Engineer World's Fair 2026 +- 12-Factor Agents: Dexter Horthy, HumanLayer diff --git a/blog/2026-05-09-seis-meses-construyendo-en-publico.md b/blog/2026-05-09-seis-meses-construyendo-en-publico.md new file mode 100644 index 0000000..c390659 --- /dev/null +++ b/blog/2026-05-09-seis-meses-construyendo-en-publico.md @@ -0,0 +1,98 @@ +--- +slug: seis-meses-construyendo-en-publico +title: "Seis meses construyendo en público: inventario honesto de lo que hemos hecho" +authors: [TellMeAlex] +tags: [ia, agentes, harness, orquestación, graphify, spec-driven-development] +image: /img/blog-header.jpg +--- + +# Seis meses construyendo en público: inventario honesto de lo que hemos hecho + +Llevamos sin escribir en el blog desde febrero. No es que no hayamos producido nada — al contrario. Hemos estado con la cabeza metida en presentaciones, talleres y herramientas mientras el blog esperaba. + +Toca hacer inventario. No para celebrarlo, sino para que sepas qué existe, qué aprendimos haciéndolo, y qué viene ahora. + + + +## Lo que hemos publicado + +### Presentaciones interactivas + +Todo lo que listamos abajo son **presentaciones web** — no slides de PowerPoint. Cada una es un repo independiente con Astro 5 + Svelte 5, navegación por teclado, animaciones GSAP y notas de ponente completas. Puedes abrirlas en el móvil. + +**[Vibe Coding vs Software Engineering](https://codigosinsiesta.github.io/ai-presentation/)** *(diciembre 2025)* +El punto de partida: 21 slides sobre por qué el 85% de los equipos usa IA pero solo el 32% confía en la calidad que produce. Introduce el **Framework 4R** (Risk, Readability, Reliability, Resilience) como respuesta. Con Jose David. + +**[Coding Agents](https://codigosinsiesta.github.io/coding-agents-presentation/)** *(diciembre 2025)* +11 slides sobre agentes como compañeros de programación: qué son de verdad, cómo evitar alucinaciones y cómo gestionar el contexto cuando el agente lleva horas de sesión. + +**[MCP Servers](https://codigosinsiesta.github.io/mcp-servers-presentation/)** *(enero 2026)* +Model Context Protocol en 10 slides: primitivas, diferencia entre FastMCP y SDK, casos de uso reales y cuándo un MCP server merece la pena frente a una tool directa. + +**[Spec-Driven Development](https://codigosinsiesta.github.io/spec-driven-development-presentation/)** *(febrero 2026)* +9 slides sobre escribir specs antes del código. No es TDD ni BDD — es el puente entre los dos. Incluye una matriz comparativa de las 5 herramientas del ecosistema SDD con nuestra recomendación por defecto. + +**[Subagentes y Skills](https://codigosinsiesta.github.io/subagents-skills-presentation/)** *(febrero 2026)* +16 slides sobre cómo dividir un agente monolítico en agentes especializados. Qué son las skills, cómo se componen con subagentes y los errores más comunes al orquestar sistemas multi-agente. + +**[Harness Engineering](https://codigosinsiesta.github.io/harness-engineering-presentation/)** *(abril 2026)* +16 slides sobre por qué el **harness ahora pesa más que el modelo**. Mismo modelo, mismo benchmark, 6× de diferencia en rendimiento. ¿De dónde viene esa diferencia? De lo que rodea al LLM, no del LLM en sí. Basado en dos papers de 2026 (NLAH de Tsinghua y Meta-Harness de Stanford). + +**[Patrones de Orquestación](https://codigosinsiesta.github.io/orquestacion-patrones-presentation/)** *(mayo 2026)* +El más reciente: 22 slides en 3 módulos independientes. Una taxonomía evolutiva de 10 niveles de complejidad, 6 dolores reales con el patrón que los resuelve, y la convergencia de 4 fuentes independientes (Anthropic, OpenAI, Factory, academia) en los mismos principios de arquitectura. + +### Talleres hands-on + +**[Taller: IA, Agentes y MCP](https://github.com/CodigoSinSiesta/taller-ia-agentes-mcp)** *(enero 2026)* +90 minutos donde los asistentes construyen 2 agentes y 2 MCP servers en TypeScript. Sin teoría — código desde el minuto 1. + +**[Taller: LLM Wiki](https://github.com/CodigoSinSiesta/taller-llm-wiki)** *(febrero 2026)* +Montar un wiki personal mantenido por Claude Code. Frontmatter, Dataview, obsidian-git y el ciclo completo de captura → clasificación → recuperación. Basado en el workflow que usamos internamente. + +**[Taller: Graphify](https://github.com/CodigoSinSiesta/taller-graphify)** *(abril 2026)* +El más técnico de los tres: indexar un repositorio o un corpus heterogéneo con Graphify, leer el grafo resultante e integrarlo como skill en tu agente. Incluye un cuadrante de decisión honesto — cuándo Graphify compensa y cuándo no. + +### Infraestructura + +**[@codigosinsiesta/theme](https://github.com/CodigoSinSiesta/theme)** *(abril 2026)* +Un sistema de diseño compartido que ahora alimenta todos los decks: CSS tokens, preset de Tailwind, componentes Svelte (Hero, TOC, Terminal, Resources…). Lo que antes era copiar-pegar entre repos es ahora un `npm install`. + +--- + +## Lo que aprendimos haciéndolo + +### El sistema de diseño fue la mejor inversión + +Empezamos copiando el mismo boilerplate entre presentaciones. Cuando llevábamos 4 decks, cualquier cambio visual había que aplicarlo en 4 sitios. El tema compartido lo resolvió en una tarde. Si haces contenido técnico en serie, **la coherencia visual no es estética — es velocidad de producción**. + +### Graphify sobre wikis curados no compensa + +Lo documentamos en el taller y lo decimos aquí también: probamos Graphify sobre este mismo wiki y el resultado fue decepcionante. Para un corpus curado con MOCs manuales y wikilinks bien mantenidos, el coste en tokens de extracción semántica (~$0.50 por re-pase) no justifica el ahorro en contexto. El grafo no aporta nada que `rg` + un MOC bien escrito no haga gratis. + +El sweet spot de Graphify es otro: corpus heterogéneo y volátil donde el material mezcla código, documentos y papers que ninguna herramienta AST puede indexar sola. + +### SDD como prerequisito para trabajar con agentes en equipo + +En solitario puedes salirte con la tuya sin specs. Con dos personas y un agente en el loop, sin specs escritas el agente y los humanos trabajan con modelos mentales distintos del mismo requisito. Las specs no son burocracia — son el contrato que hace que el agente ejecute lo que tú tienes en la cabeza, no lo que él infiere. + +--- + +## Lo que viene + +Volvemos al blog. Los temas de las presentaciones son demasiado densos para quedarse solo en slides — merecen artículos donde haya espacio para el matiz. En las próximas semanas: un artículo sobre el gap del 6× en harness engineering, y una serie sobre los patrones de orquestación con el detalle que no cabe en 22 slides. + +--- + +## Por dónde empezar según tu perfil + +Si acabas de llegar a Código Sin Siesta y no sabes por dónde entrar: + +| Perfil | Empieza aquí | +|---|---| +| Desarrollador usando IA por primera vez | [Vibe Coding vs Software Engineering](https://codigosinsiesta.github.io/ai-presentation/) | +| Dev construyendo su primer agente | [Coding Agents](https://codigosinsiesta.github.io/coding-agents-presentation/) | +| Dev queriendo conectar herramientas externas | [MCP Servers](https://codigosinsiesta.github.io/mcp-servers-presentation/) | +| Tech lead con equipo usando IA | [Spec-Driven Development](https://codigosinsiesta.github.io/spec-driven-development-presentation/) | +| Arquitecto diseñando sistemas multi-agente | [Subagentes y Skills](https://codigosinsiesta.github.io/subagents-skills-presentation/) + [Patrones de Orquestación](https://codigosinsiesta.github.io/orquestacion-patrones-presentation/) + [Harness Engineering](https://codigosinsiesta.github.io/harness-engineering-presentation/) | + +Todo el código está en [github.com/CodigoSinSiesta](https://github.com/CodigoSinSiesta). Licencia MIT.