Las cuatro ingenierías de la IA (y cómo construí la tercera sin saber que la industria iba al mismo sitio)

La industria de la IA acaba de converger en la misma arquitectura multi-agente que yo llevo apenas unas semanas construyendo a tropezones en mi propio código. Lo vi de golpe en dos charlas de YouTube: una de Sally-Ann Delucia, de Arize, sobre cómo resolvieron la gestión de contexto en sus agentes; otra de Luke Alvoeiro, de Factory, presentando una arquitectura multi-agente capaz de construir y entregar software durante días seguidos.

Las vi con una mezcla rara de reconocimiento y alivio: la sensación de estar leyendo el diseño de algo que yo ya había construido, y de pensar "entonces voy por buen camino". Porque las últimas semanas las he pasado escribiendo un plugin de orquestación de agentes en paralelo —lo llamo parallel-work— y lo hice a base de tropezar, no de leer papers. Y sin embargo ahí estaban, dos personas que no me conocen de nada, describiendo desde sus trincheras las mismas conclusiones a las que yo había llegado por el camino largo.

Este post va de eso: de las cuatro "ingenierías" que están ordenando el trabajo con IA —prompt, context, harness y loop engineering—, de lo que cuentan esas dos charlas, y —al final— de un tercer ponente que no habla de arquitectura sino de nosotros: del papel que le queda al humano cuando el código sale gratis. Y de por qué creo que esa convergencia es la señal más fiable de que una idea es correcta — con una objeción incluida que me hago yo antes de que me la hagáis vosotros.

La escalera: prompt → context → harness → loop

Le debo el marco a Addy Osmani, que ordena el trabajo con modelos en cuatro peldaños, cada uno envolviendo al anterior:

1. Prompt engineering. El razonamiento nativo del modelo. Escribes bien la petición y confías en lo que el modelo trae de fábrica. Es el peldaño donde empezamos todos y del que la industria ya está saliendo.
2. Context engineering. El agente busca y trae a su propia ventana lo que necesita: herramientas, ficheros, resultados de MCP. El foco deja de estar en qué le pides y pasa a estar en qué ve mientras trabaja.
3. Harness engineering. Un sistema externo gestiona el contexto desde fuera: parte el requisito en una lista de tareas estable y estructurada, y sobrevive a la ventana del modelo en lugar de depender de ella.
4. Loop engineering. Andamiaje externo para que el agente se auto-promptee y corra de forma continua, con el humano fuera del bucle.

También os dejo un video más explicativo y visual sobre este tema: Loop Engineering Explained in 8 Minutes

La gracia del modelo es que cada peldaño no sustituye al anterior, lo envuelve. Y si tuviera que clavar mi plugin en un punto de esa escalera, diría sin dudar que su centro de gravedad es el tercero: harness engineering. Un guiño que no me esperaba: los dos ponentes de las charlas usan, cada uno por su cuenta, esa misma palabra —Sally-Ann llama a su producto "an AI harness"; Luke se presenta como responsable del "core agent harness" de Factory—. Cuando el vocabulario converge sin que nadie se ponga de acuerdo, suele ser porque el concepto era real. Pero para explicarlo bien, primero las dos charlas.

Arize: "los agentes no fallan por el prompt, fallan por el contexto"

La charla de Sally-Ann Delucia arranca con una anécdota que da miedo por lo reconocible. En Arize construyeron un agente, Alyx, para analizar datos de trazas de su propia plataforma. El problema: cada vez que Alyx se ejecutaba, generaba más datos de traza, que engordaban su ventana de contexto, que le hacían chocar contra el límite, que le hacían fallar… y la propia traza del fallo añadía todavía más datos al siguiente intento. Un agente ahogándose en su propio rastro de datos.

La frase que se me quedó grabada: "los agentes no fallan por los prompts, fallan por el contexto" ("agents don't fail because of prompts, they fail because of context"). Es el salto del peldaño 1 al 2 dicho en una línea.

Lo interesante es lo que no funcionó. El arreglo ingenuo —truncar, quedarte con el principio— produjo amnesia: los mensajes de seguimiento perdían el hilo. El arreglo "obvio" —pedirle a un LLM que resuma— tampoco: compresión sin principio, sin control sobre qué se conservaba. Los dos atajos que a todos se nos ocurren primero, descartados con datos.

Lo que sí funcionó fue una arquitectura de tres piezas:

• Truncado inteligente: conservar la cabeza y la cola de la conversación en el contexto activo.
• Un almacén de memoria recuperable para el medio: no se tira, se mueve a un sitio del que el agente puede tirar cuando lo necesita.
• Sub-agentes que se llevan las operaciones pesadas (analizar trazas, buscar) y devuelven solo el resultado destilado, manteniendo la conversación principal ligera.

Su principio de diseño lo resume perfecto: "el contexto decide qué ve el modelo; la memoria decide qué sobrevive" ("context decides what the model sees, memory decides what survives"). Y el detalle que me sorprendió: Delucia cuenta que Claude Code convergió de forma independiente en la misma estrategia de truncado y compresión. Lo dijo con gracia —cuando Anthropic publicó parte del código de Claude Code, en Arize lo leyeron esperando "robarles algún secreto" ("hoping to get a little bit of a secret from them"), y se encontraron con su mismo enfoque—. No es un truco propietario de Arize. Es un patrón que emerge cuando distinta gente empuja contra el mismo muro.

Factory: la arquitectura multi-agente que sí entrega software

La charla de Luke Alvoeiro va un peldaño más arriba. Su tesis de partida es una provocación buena: el cuello de botella de la ingeniería de software ya no es la inteligencia del modelo, es la atención humana. No nos falta capacidad de generar código; nos falta capacidad de supervisar todo el que se genera.

Su respuesta es una arquitectura —la llaman Missions— con tres roles especializados:

• Orchestrator: planifica funcionalidades e hitos y, crucialmente, escribe el "contrato de validación" (validation contract) antes de que se escriba una sola línea de código. Define qué es "correcto" con independencia de cómo se vaya a implementar. Hace de interlocutor, pregunta, cierra requisitos.
• Worker: implementa. Y lo hace con contexto fresco por funcionalidad —hereda "pizarra limpia", sin el lastre acumulado de tareas anteriores—, commitea vía Git y hace un traspaso estructurado.
• Validator: verifica, y aquí está lo fino. Son en realidad dos validadores que se lanzan al cerrar cada hito: uno de escrutinio (batería de tests, tipos, lints y un agente de revisión por cada funcionalidad) y otro de pruebas de usuario que se comporta como un QA humano —levanta la aplicación y la usa de verdad: rellena formularios, pulsa botones, comprueba que los flujos funcionan de punta a punta—. Ninguno de los dos ha visto el código antes: la validación es adversarial por diseño. Y a menudo corren sobre un proveedor de modelo distinto, para que el mismo modelo que escribió el código no sea quien lo dé por bueno.

Un par de decisiones más que me parecen las importantes. Primero, ejecución en serie: un solo worker o validator activo a la vez, porque cuando dejas correr a los agentes totalmente en paralelo "entran en conflicto, duplican trabajo y toman decisiones de arquitectura inconsistentes" ("agents conflict, duplicate work, and make inconsistent architectural decisions"). Segundo, diseño agnóstico del modelo: mínima lógica hardcodeada —toda la orquestación vive en unas 700 líneas de prompts y skills, no en una máquina de estados—, de forma que el sistema "mejora con cada nueva versión de modelo en lugar de quedarse obsoleto" ("improves with every model release rather than becoming obsolete"). Su forma de decirlo se me quedó grabada: "las misiones ponen la disciplina y los modelos ponen la inteligencia" ("missions ensure the discipline and the models provide the intelligence") —que es, palabra por palabra, cómo pienso yo el plugin: la maquinaria (hooks, skills, agentes, comandos y scripts) impone la disciplina, el modelo aporta el criterio—. El contrato de validación escrito antes del código me parece la joya de la charla, porque invierte el vicio de siempre: los tests escritos después confirman las decisiones que ya tomaste, no cazan bugs.

El resultado que enseñan: un clon de Slack construido en una "misión" sostenida de 16 días, con el 90% del código cubierto por unos tests que, al final, son la mitad de las líneas del repositorio. Y un dato honesto de la propia charla: la validación casi nunca pasa a la primera —el sistema tiene que abrir funcionalidades de corrección una y otra vez—, y el grueso del tiempo de reloj de una misión no se va en generar código, sino esperando a que el validador de pruebas de usuario ejercite la aplicación viva. Que la mitad del código final sean tests y que verificar se lleve el reloj no es el peaje del sistema: es el sistema.

Dónde encaja mi plugin

Y aquí es donde volví a mis propias notas con una mezcla de vértigo y alivio. Porque parallel-work lo escribí sin haber visto ninguna de las dos charlas, tropezando en runs reales, y sin embargo la correspondencia es casi uno a uno.

parallel-work es un plugin de Claude Code que codifica una metodología de agentes en paralelo dirigida por un coordinador: Intake → Design Lock → carriles en worktrees → revisor por PR → QA → auditoría de arquitecto → merge una sola vez. Cinco roles.

¿Y por qué un plugin de Claude Code, y no un sistema propio desde cero? Por dos razones, una de diseño y otra más prosaica. La de diseño encaja con todo lo anterior: el harness de Claude Code ya es muy maduro y muy bueno —gestión de contexto, herramientas, permisos, hooks, sub-agentes—, así que construir mi capa de coordinación encima de ese harness, en vez de reinventar la base, es la decisión de ingeniería correcta. Yo aporto el peldaño que me interesa —el harness de orquestación multi-agente— y Claude Code pone los de debajo. La prosaica: así aprovecho mi propia suscripción de Claude Code en lugar de levantar y pagar una infraestructura aparte. Menos andamiaje que mantener, más tiempo en el problema que de verdad quiero resolver.

Y hay una pregunta hermana, la que me hacía yo el primero: si Anthropic ya ofrece Claude Code Teams —su propia capa nativa de orquestación multi-agente—, ¿por qué montarme la mía? Porque la probé antes de decidirlo. Hace un tiempo puse Teams a trabajar sobre un servicio NestJS en producción, con cuatro tickets de Linear que eran las cuatro capas de una misma funcionalidad, y lo conté en el blog. El código salió sólido, pero los fallos fueron los reveladores: el supervisor era demasiado pasivo; el "team lead" aprobó planes por su cuenta sin escalármelos, saltándose protocolos que yo había dejado explícitos; y los agentes trabajaron en paralelo aunque las dependencias eran secuenciales. Tres grietas que, mira por dónde, son exactamente las tres cosas que parallel-work convierte en invariantes duras: el humano clavado en el Design Lock y en la puerta de merge —esta última forzada por un hook, no por la buena voluntad del modelo—, las olas que ordenan en el tiempo lo que depende de otra cosa, y unas puertas de verificación independientes que no dependen de que nadie se acuerde de mirar. No es que Teams esté mal —es una base sólida—; es que tengo de serie lo que Teams me da y, además, justo las piezas que su propia prueba me señaló que faltaban. En lo que llevo corriendo el plugin se comporta mucho mejor para mi forma de trabajar —con el caveat de siempre: es mi experiencia de primera mano, no un benchmark, pero es justo la experiencia que me hizo elegir—.

Si pongo mi vocabulario al lado del de Factory y Arize, esto es lo que sale:

Dos confesiones sobre la tabla, para que no me la compréis entera. La primera: la pieza de Factory que aún no tengo es la diversidad de modelo del validador —que el verificador corra sobre un proveedor distinto del que escribió el código—. Mi independencia se construye con otro mecanismo: contexto fresco (el revisor no ha visto razonar al builder, así que no puede racionalizar sus decisiones) más solo-lectura forzada en la definición del agente. Defiendo ese mecanismo, pero no es el mismo eje, y añadir la diversidad de modelo está en mi backlog, no en mi código. La segunda: "agnóstico del modelo" no significa agnóstico del executor. El plugin está deliberadamente acoplado a Claude Code, porque su capa de enforcement —los hooks que hacen físicamente imposible que un builder mergee— es justo la parte que no portaría limpia a otra plataforma, y es también el activo diferencial. La disciplina sobrevive a cada versión de modelo; no pretende sobrevivir a un cambio de executor, y esa es una decisión, no un descuido.

La definición de "harness" de Osmani —"un sistema externo que gestiona el contexto desde fuera, dividiendo el requisito en una lista de tareas estable y estructurada" ("an external system that manages context from outside, dividing the requirement into a stable, structured task list")— es, literalmente, mi STATE.md más el coordinador. Sobrevive a la compactación, parte el épico en carriles y olas, y le da a cada rol contexto fresco en lugar de un contexto auto-resumido que gotea. La respuesta de Arize al problema de contexto es la memoria recuperable; mi respuesta al mismo problema es no dejar que el contexto se ensucie en primer lugar —cada rol arranca limpio—. Distintos caminos, misma montaña.

Hay otra coincidencia que me gustó especialmente. Luke enumera cinco patrones de comunicación multi-agente, y Missions usa cuatro: descarta a propósito la comunicación directa entre agentes, porque sin un coordinador el estado se fragmenta y desaparece la única fuente de verdad. En parallel-work los builders tampoco se hablan entre sí jamás: todo pasa por el coordinador y por STATE.md, que es la única fuente de verdad. Dos sistemas aterrizando en la misma regla sin conocerse —los agentes no se coordinan entre pares, se coordinan contra un estado central— es exactamente el tipo de coincidencia que me hizo escribir este post.

La divergencia honesta: serie vs paralelo

No todo encaja, y el punto donde no encaja es el más interesante de contar. Factory serializa las funcionalidades para evitar que los agentes choquen. Yo hago justo lo contrario: paralelizo los carriles. Es la palabra que le da nombre al plugin.

¿Contradicción? No, si miras cómo se resuelve el conflicto en cada caso. Factory evita la colisión ejecutando de uno en uno. Yo evito la misma colisión con aislamiento por worktree (cada builder trabaja en un árbol de git separado), una rama de integración común a la que apunta cada PR, y un merge único cuando el épico está entero. Mismo problema —agentes pisándose, decisiones de arquitectura inconsistentes—, dos soluciones válidas: ellos lo resuelven en el tiempo (serie), yo en el espacio (worktrees). Que dos diseños lleguen a respuestas distintas al mismo riesgo no debilita a ninguno; delimita cuándo elegir cada uno.

Y aquí es donde cualquiera que haya sufrido la concurrencia levanta la ceja, con razón: el worktree solo resuelve el choque físico —dos agentes editando el mismo fichero—. ¿Y el lógico, cuando el carril A cambia la firma de un método o un esquema del que depende el carril B? Ese no lo toca el worktree; lo gobiernan otras tres capas:

• El Design Lock fija los contratos compartidos antes de abrir un solo carril: el glosario y los ADRs cierran firmas, esquemas y decisiones de arquitectura comunes. Los builders no inventan interfaces divergentes; parten de las que ya están selladas.
• Las olas ordenan las dependencias en el tiempo. El coordinador paraleliza solo carriles deliberadamente independientes; lo que toca una superficie compartida va en una ola anterior, para que los dependientes hereden ya el cambio. El paralelismo es dentro de la ola, no a lo bruto.
• La QA y la auditoría del arquitecto en la costura cazan el drift que se haya colado igualmente: el arquitecto lee el conjunto convergido —no cada carril por separado— buscando precisamente la incoherencia entre carriles; la QA prueba las juntas. Y todo eso ocurre antes del merge único.

¿Y si el propio contrato resulta inviable a mitad de ejecución —el carril A descubre que la firma pactada no se sostiene? Ahí el aislamiento no significa incomunicación. Cada rol sigue corriendo dentro de sesiones interactivas de Claude Code, así que un builder que ve que el contrato choca con la realidad no sigue construyendo sobre algo roto: levanta una alerta y el usuario, o incluso el coordinador, que también tiene la capacidad de mirar el estado de los builders, pueden decidir si detener la ola y volver a la mesa de diseño con el humano para actualizar el Design Lock y el STATE.md antes de reanudar o encauzar a los builders. El plugin automatiza y paraleliza todo lo que puede, pero mete al humano en el bucle justo cuando la realidad rompe el plan. Un Design Lock que no se pudiera renegociar sería dogma; este se renegocia cuando toca.

En una frase: Factory evita el conflicto lógico no dándole la oportunidad —un agente cada vez—; yo lo evito acotando la superficie compartida por adelantado y auditándola al converger. Sin esas tres capas, paralelizar sería una temeridad; con ellas, el worktree pasa a ser la más visible de las defensas, no la única.

La línea que no cruzo

El cuarto peldaño, loop engineering, es donde decido plantarme a propósito. La jugada que define el loop engineering es el agente prompteándose a sí mismo en un bucle cerrado, sin humano. Mi plugin tiene la maquinaria para eso —un watch loop en el que el coordinador se re-promptea para detectar carriles terminados— pero mantiene al humano clavado en dos anclas:

1. Disparar el épico y las decisiones del Design Lock.
2. La puerta de merge. Solo el coordinador puede mergear, y desde una versión reciente ni siquiera él puede hacerlo mientras el watch loop está activo: un fichero-marcador que deja el bucle bloquea el merge hasta que el bucle termina. Mergear volvió a ser un acto deliberado, no algo que el bucle hace solo.

Osmani descompone ese peldaño del loop en seis componentes. Hacer el recuento contra el plugin es la parte que más me sorprendió al ver los vídeos, porque salen cinco y medio de seis:

Y aquí está lo bonito: el único componente que dejo a medias —Automation— es exactamente el que haría falta para cerrar el bucle del todo, el que entregaría el paso irreversible a la máquina. No es una casilla que se me olvidó marcar; es la misma línea de antes vista desde otro ángulo. Tengo la escalera entera montada salvo el último peldaño, y ese hueco tiene forma de persona a propósito.

Esto conecta con la parte de Alvoeiro que más me resuena: si el cuello de botella es la atención humana, el diseño correcto no es eliminar al humano, es colocarlo donde su atención rinde más —en el objetivo y en el paso irreversible— y quitarlo de todo lo demás. Mi apuesta es que el valor está en el andamiaje —aislamiento paralelo, verificación independiente, estado durable—, no en quitar al humano del último paso. Es maquinaria de loop engineering con un agujero con forma de persona en el sitio exacto.

Y para no quedarme en la pose: en el plugin hay un instrumento de evidencia que mide precisamente esto. En el primer épico que corrió sobre sí mismo, las puertas independientes —revisor, QA, arquitecto— produjeron 18 hallazgos: ninguno crítico —15 leves y 3 medios—, pero 17 de ellos se habrían colado a producción sin esas puertas, y uno de los medios fue contra el propio coordinador — exactamente el tipo de fallo que un sistema monolítico no puede verse a sí mismo. Con el caveat honesto de que ese número es n=1, sobre un repo de shell y documentación —el test de estrés de verdad, soltar a los cinco roles en un backend desacoplado y con tipado estricto, todavía está por venir—. Desde aquel primer épico el plugin ha dirigido ya varios más, reales, que lo han ido endureciendo hasta la versión de hoy: no es un experimento de fin de semana. Pero tampoco te voy a vender que compite en madurez con Arize o Factory, productos mucho más consolidados y respaldados que lo mío. Y quizá ahí esté lo más revelador: llegar a su misma forma en apenas unas semanas, trabajando codo con codo con modelos muy capaces (Opus 4.8 y Fable 5), dice menos de mi mérito que de lo fuerte que empuja la convergencia.

Por qué me importa la convergencia

Podría contar todo esto como "mirad, yo ya lo había hecho". Pero eso no es lo interesante. Lo interesante es otra cosa: cómo puedes llegar a saber que una decisión de diseño es correcta cuando la tomas tú solo, sin nadie que te lleve la contraria.

Cuando construyes algo solo, tu mayor miedo es estar enamorado de una idea que solo funciona en tu cabeza. La evolución convergente es el antídoto: cuando gente que no se conoce, trabajando sobre problemas distintos, con incentivos distintos, aterriza en la misma forma —contexto fresco por unidad de trabajo, verificación por un agente independiente, un gestor de estado externo que sobrevive a la ventana de contexto, y un humano guardando el paso irreversible— eso deja de ser una opinión y empieza a parecerse a una restricción del problema.

Ahora, la objeción que prometí hacerme yo antes de que me la hagáis: ¿y si la convergencia no es del problema, sino del sustrato? Yo construí encima de Claude Code, cuyas primitivas —sub-agentes, compactación, worktrees, skills— ya te canalizan hacia esta forma; Arize cuenta que leyó el código de Claude Code; y estas charlas circulan por el mismo circuito de conferencias. Quizá no es que todos empujáramos contra el mismo muro, sino que todos caminamos por el mismo pasillo. Es una réplica seria, y baja el grado de independencia que puedo reclamar honestamente: de "tres caminos separados" a "tres caminos que comparten paisaje". Pero solo desplaza la pregunta un nivel, no la disuelve: alguien diseñó ese pasillo, y llegó ahí por su cuenta — la propia Delucia cuenta que Arize y Anthropic convergieron en la misma estrategia de contexto sin copiarse, cada uno contra su propio muro. Que el sustrato te canalice hacia una forma es también evidencia de que la forma es una restricción real; solo que la evidencia vale algo menos de lo que parece a primera vista, y prefiero descontarla yo a que me la descuentes tú.

Ninguno de los tres tiene por qué tener razón. Pero que los tres apuntemos al mismo sitio, por caminos que al menos en parte son separados, es la mejor pista que tengo de que el sitio existe.

finally { }: y aun así, alguien tiene que leer el código

Y llega el tercer ponente que prometía, el que no va de arquitectura sino de nosotros. Alex Volkov cuenta el debate que recorre la profesión: en un extremo, "el código es gratis, no te obsesiones con la implementación" ("code is free… not a thing to get hung up on anymore"); en el otro, "para el carro y lee cada línea" ("slow down… read every line"). Su giro es que la pregunta está mal planteada: no es sobre las personas, es sobre las tareas. El mismo ingeniero lee cada línea del código de pagos y suelta sin mirar el que no es crítico. Enrutas cada cambio a la prueba que necesita.

Lo que me hizo sonreír es que su "tabla de enrutado" incluye, sin saberlo, dos reglas que yo ya había convertido en código. Una: separar. No dejes que el mismo agente escriba, inspeccione y se ponga nota —"es como ponerme yo el examen, hacerlo y corregírmelo" ("it's like if I came up with an exam and then I took the exam and I scored myself on it")—. Esa es, exactamente, la razón de que mi revisor y mi arquitecto arranquen con contexto fresco y en solo lectura. Y dos: haz un sistema que construya el sistema; leer gasta tu atención una vez, pero diseñar hace que el sistema la recuerde. Eso es el plugin entero: la maquinaria que impone las reglas y ejecuta el método para que yo no tenga que vigilarlo todo a mano.

Los otros dos vídeos validaron mi arquitectura; este valida mi decisión de dejar un hueco con forma de persona. Porque, como él dice, "los bucles no eliminan el juicio humano; solo hacen que importe mucho más dónde eliges aplicarlo" ("loops don't remove judgment, but they do raise the stakes on where you put it"), y por eso dejo ese hueco donde lo dejo: no en cada línea —eso ya no escala—, sino en el objetivo y en el merge, el único sitio donde mi criterio todavía rinde. No todas las líneas de 2026 necesitan tus ojos; todos los sistemas siguen necesitando tu criterio.

Y con eso te lanzo el guante, porque son decisiones opinables y quiero que las discutas. Paralelizar en vez de serializar; prohibir que los agentes se hablen entre sí y obligarlos a coordinarse contra un estado central; poner el hueco humano justo en el merge y en ningún otro sitio. El plugin todavía es privado —no puedo enseñarte el código, pero sí el diseño, que es justo lo que he desmenuzado aquí—, así que lo que te ofrezco es la conversación: ¿tú dónde trazas la línea? ¿Cómo evitas tú las colisiones lógicas cuando varios agentes trabajan a la vez? ¿Te has chocado ya contra el muro del contexto, y cómo saliste? Cuéntamelo en los comentarios. Esto es un campo que estamos dibujando entre todos, y prefiero que me rebatas a que asientas y cierres la pestaña.

Charlas citadas:

• Sally-Ann Delucia — How we solved Context Management in Agents

• Luke Alvoeiro — The Multi-Agent Architecture That Actually Ships

• Alex Volkov — ¿deberíamos seguir leyendo código en 2026? (el continuo ZL, AI Engineer)

• Marco de las cuatro ingenierías: escritos de Addy Osmani sobre loop engineering