Una nota antes de empezar. No importa en qué punto estés, si recién estás explorando el desarrollo con IA o llevas tiempo en esto. Este paper puede parecer complejo en su lectura, pero las ideas que describe no lo son tanto cuando lo que se va a construir tiene un propósito claro. Si el negocio está definido, la estructura se vuelve obvia. Si el problema es real, el contexto se organiza solo.
Esto es una propuesta para equipos que ya tienen un problema real y quieren resolverlo mejor, y no hacer tecnología por hacer. Como sabes, el trabajo individual con IA ya está bastante resuelto. Lo que todavía no está resuelto es cómo trabajan los equipos juntos.
Y este paper no viene a resolver ese problema. Viene a plantearlo, a proponer una dirección.
El desarrollo de software con IA generativa resolvió el problema individual: un desarrollador con un agente bien configurado produce en días lo que antes tomaba semanas. Pero el problema colectivo sigue abierto. Cuando cinco desarrolladores trabajan en el mismo repositorio con cinco agentes, el resultado es cinco veces más rápido hacia la incoherencia semántica.
Este documento describe cómo llegamos hasta acá, qué existe hoy para el caso individual, y por qué el caso de equipo sigue sin resolverse. Propone una dirección: el Desarrollo Guiado por Contexto Distribuido.
Es una forma de organizar el trabajo de software donde el contexto —las decisiones, contratos e intención de cada parte del sistema— vive dentro del repositorio, distribuido por módulo, y se valida automáticamente antes de que existan inconsistencias semánticas entre equipos y dentro del repositorio mismo.
No es una herramienta ni un framework. Es una forma de estructurar cómo los agentes de IA y los desarrolladores humanos trabajan juntos.
Antes de describir el problema, vale la pena ser honestos sobre la realidad. No todos los equipos están en el mismo punto. Hoy coexisten al menos tres formas de trabajar:
La mayoría: desarrollo sin IA. El flujo es el tradicional: tickets, ramas, PRs, code review humano. La IA no está en el loop o está en los márgenes. El problema de coordinación existe, pero es lento y manejable. El cuello de botella es escribir código, y eso regula naturalmente la velocidad del equipo.
Los que adoptaron IA básica: el agente como asistente. Usan Cursor, Copilot o Claude Code para acelerar la escritura. El agente genera código, el desarrollador revisa y ajusta. Sin estructura formal de contexto, sin harness, sin specs como contrato. El agente improvisa dentro de cada sesión.
Los más avanzados: desarrollo guiado por specs y contexto. Un grupo más pequeño, que incluye algunas empresas grandes y desarrolladores individuales, llegó a una forma más estructurada: specs escritas antes del código, contexto persistente entre sesiones, reglas explícitas que guían al agente. Herramientas como GitHub Speckit dieron estructura a este flujo, un punto de partida sólido, aunque limitado a la spec como documento estático sin contexto vivo ni harness. Otros adoptaron SDD (Spec Driven Development) como metodología completa.
El problema que describimos no es de la mayoría todavía. Es el problema que le espera a todos cuando avancen hacia el tercer nivel. Y van a llegar.
Entre el nivel 2 y el nivel 3 hay un territorio intermedio que mucha gente está explorando ahora mismo. Desarrolladores y equipos que combinan ideas: un poco de harness por acá, un archivo de contexto por allá, specs antes del código, hooks que mantienen todo actualizado. Cada uno llega por su cuenta a combinaciones similares, con distintos nombres, pero con el mismo objetivo: que el agente entienda el proyecto tan bien como el desarrollador que lo guía.
Lo que todas estas exploraciones tienen en común es que siguen siendo un desarrollador trabajando con su agente. El problema está contenido. El contexto es de una sola persona. Las decisiones las toma una sola mente.
El momento en que ese desarrollador se convierte en un equipo, todo cambia.
Tomemos el tercer grupo —los que ya trabajan con specs y contexto estructurado— y escalemos de un desarrollador a cinco:
Dev 1 → user story: cupones QR → toca módulo cafes/ Dev 2 → user story: perfil cafetería → toca módulo cafes/ Dev 3 → user story: geolocalización → toca módulo cafes/ + API Dev 4 → user story: reseñas → toca módulo reviews/ + cafes/ Dev 5 → user story: búsqueda → toca módulo api/ + cafes/
Cada agente arrancó leyendo el mismo contexto central al inicio de la sesión. Cuatro horas después, ese contexto ya no refleja la realidad: tres desarrolladores modificaron contratos internos, dos cambiaron el schema de la DB, uno refactorizó auth.
Y esto no pasa porque el equipo sea descuidado. Pasa porque la coordinación semántica entre múltiples agentes humanos trabajando en paralelo todavía no está resuelta de forma práctica — al menos no para este caso específico.
Git hace exactamente lo que fue diseñado para hacer: versionar texto, orquestar el flujo de código, detectar superposición de cambios. El problema no es Git. Es que todavía no existe la capa que hace lo mismo para la intención y las decisiones.
Cuando Dev 1 cambia el contrato interno de una función y Dev 2 construye su feature asumiendo el contrato anterior, Git ve dos archivos distintos que no se superponen. No hay conflicto. El merge es limpio. La incoherencia semántica es invisible.
En el nivel 1 —sin IA— el problema de coordinación existe pero es lento. Un desarrollador tarda horas en implementar una feature. Eso da tiempo para conversaciones y revisiones que actúan como sincronización implícita.
En el nivel 3 —con specs y agentes— el mismo desarrollador implementa la feature en minutos. La velocidad de producción supera ampliamente la velocidad de sincronización del equipo.
Más velocidad sin coordinación semántica no es progreso. Es deuda técnica acumulándose más rápido de lo que el equipo puede procesarla.
Los conceptos que sustentan el desarrollo guiado con IA no son nuevos. El harness tiene raíces en los años 90: en testing, control de calidad y sistemas de infraestructura era el mecanismo que envolvía el código o el sistema bajo prueba —redes, hardware, entornos de despliegue— definiendo los límites dentro de los cuales podía operar. En IA reaparece alrededor de 2020 bajo el nombre de "guardrails" —misma idea, nuevo contexto.
La trayectoria del concepto lo dice todo:
Los conceptos no mueren. Se reflotán cuando el problema que resuelven vuelve a aparecer en otro contexto. Nadie está inventando nada desde cero, está reconociendo que un problema viejo aparece en una forma nueva.
Un hito concreto: EleutherAI, fundada en julio de 2020, desarrolló el LM Evaluation Harness —un framework para envolver modelos de lenguaje con reglas explícitas de evaluación. No era un harness de desarrollo, era de evaluación. Pero la idea central ya estaba ahí: acotar al agente con un contrato explícito de operación.
Algunos creen que estas ideas nacieron con el boom de los LLMs en 2023. Pero los mismos que construyeron los modelos ya sabían lo que se venía. No nacieron ahora. Maduraron ahora.
Las specs como contrato son aún más antiguas:
SDD (Spec Driven Development) lleva esto más lejos: la spec no es solo un paso previo, es el eje que organiza todo el flujo de desarrollo. GitHub Speckit dio estructura a ese flujo, un punto de partida sólido, aunque limitado: te da la forma de la spec, no el contexto vivo que necesita el agente entre sesiones ni el harness que guía su comportamiento.
Hasta hace pocos años, un prompt bien escrito era suficiente. Los modelos tenían ventanas de contexto cortas —4k, 8k tokens— y el flujo era simple: instrucción → respuesta → fin. Todo cambió cuando los modelos escalaron a 32k, 100k, 200k tokens. El problema ya no era qué tan listo era el modelo. Era cómo alimentarlo con el contexto correcto de forma consistente a lo largo del tiempo.
En 2023 los modelos no navegaban internet, no ejecutaban herramientas, no mantenían estado entre sesiones. Solo procesaban lo que les ponías en el prompt o lo que habías embebido escaneando documentos. En ese contexto, pedirle arquitectura modular sostenida en el tiempo era pedirle algo que estructuralmente no podía dar. El resultado era siempre el mismo: un monolito. Código que funcionaba en ese momento y era inmanejable al día siguiente.
El monolito no era un fallo del modelo, era el límite natural de lo que era posible entonces.
De ese proceso surgieron preguntas concretas: ¿cómo se estructura un proyecto para que la IA trabaje en él de forma coherente entre sesiones? ¿cómo evitar que el agente improvise sin contexto? ¿cómo hacer que el código generado sea sostenible, no solo funcional en ese momento?
Nació la ingeniería de contexto: la disciplina de diseñar, estructurar y mantener el contexto que consume un agente. El harness viejo + la spec antigua + el contexto vivo nuevo. Tres ideas de distintas épocas que encontraron un propósito común.
Es importante ser honestos sobre algo: las empresas que construyeron los LLMs no estaban descubriendo hacia dónde iba esto mientras lo construían. Son parte del camino que de alguna manera ya se venía lucidando cuando empezaron a salir los modelos más grandes. Nosotros, y muchos otros, llegamos a los mismos conceptos porque el problema nos llevó ahí. Pero ellos ya sabían que íbamos a llegar.
Es imposible construir algo de esa escala sin entender las consecuencias del cambio de variable. Como las leyes de Newton: no se descubren, se deducen. Si se diseña un modelo que predice a esa profundidad, ya se sabe lo que va a necesitar para ser útil en el mundo real: estructura, contexto, contratos, harness. No es clarividencia. Es física del problema, al menos eso creo.
Las herramientas del mercado muestran dónde está el arte hoy:
CLAUDE.md persiste instrucciones entre sesiones. Pero es un archivo plano, global, sin ownership por módulo ni mecanismo de merge entre desarrolladores.El monorepo se convirtió en la unidad natural de trabajo. Todo en un solo lugar, legible por el agente en una sola sesión. El problema de contexto para un desarrollador estaba, en principio, resuelto.
Entre las herramientas del mercado y el gap del equipo hay un paso intermedio que está emergiendo: herramientas —muchas open source— que hacen seamless trabajar con distintos LLMs en el mismo flujo de desarrollo. Continue.dev, Aider, Cline, y otros apuntan en esa dirección. No resuelven el problema de equipo, pero iluminan algo importante.
Para que el contexto distribuido funcione en un equipo real, cualquier agente —independiente del modelo que use cada desarrollador— debe poder leer y operar sobre el mismo sistema de contexto. Un dev con Claude, otro con Gemini, otro con Llama. Si el contexto está atado a un solo modelo, no escala.
Eso no es una decisión técnica. Es una decisión de estándar.
El túnel es largo. Lo que viene después del caso de equipo, no lo sabemos con certeza. Y probablemente tampoco lo sepa una sola organización, porque este no es un problema de los que construyen los modelos. Es un problema de los que adoptan IA para hacer más fácil el desarrollo de software. Microsoft, GitHub, Cursor, los equipos de ingeniería que están en esa transición. Ellos están aprendiendo también, aunque con más recursos.
El patrón harness + ingeniería de contexto + spec-first resuelve bien el caso de un desarrollador + un agente + un monorepo.
Lo que ninguna de estas soluciones resuelve es la pregunta siguiente:
¿Qué pasa cuando cinco agentes toman decisiones en paralelo sobre el mismo repositorio?
El contexto central es único. Si dos desarrolladores hacen commit simultáneamente, el segundo sobreescribe al primero. Las specs son planas, sin relación explícita entre sí ni con el módulo que afectan. Dos agentes pueden tomar decisiones contradictorias sobre el mismo dominio sin saberlo.
Existe Git para versionar código. Existen vector stores para memoria de agentes. Existen orquestadores para pipelines. Hasta el momento no hemos visto una capa de coordinación semántica para equipos de desarrollo con IA, quizás existe, o alguien ya la está desarrollando. Si es así, nos interesa saberlo.
El contexto debe distribuirse siguiendo los mismos límites que la arquitectura modular. Si el código está organizado por dominios, el contexto debe estarlo también.
No se trata de reemplazar Git. Se trata de agregar una capa de validación semántica que corre antes de que el código llegue al repositorio remoto:
Flujo actual:
código → commit → push → Git remoto
Flujo propuesto:
código → commit → validación semántica → push → Git remoto
↑
esta es la capa nueva
El commit actualiza el contexto del módulo localmente. El push es el momento donde el orquestador valida que lo que se construyó sigue el estándar y no contradice lo que construyeron los demás. Sin bloquear el flujo. Sin reportar nada innecesario. Solo coherencia semántica antes de que otros lo vean.
La estructura no es arbitraria. Responde a un principio: el contexto debe seguir los mismos límites que el código. Si el código está organizado por dominios, el contexto también. Si un módulo tiene ownership de ciertos datos, también tiene ownership de su contexto.
Un contexto central único es un punto de falla. Dos desarrolladores modificándolo simultáneamente generan conflictos. Un módulo que creció tiene que compartir espacio con todos los demás. El orquestador no puede saber qué cambió en qué dominio sin leer todo.
La distribución resuelve eso: cada módulo es dueño de su contexto, el orquestador lee solo lo que necesita, y el central es el resultado del merge, no la fuente.
repo/
├── docs/
│ ├── vision/
│ ├── constitution/
│ │ ├── principles.md
│ │ └── invariants.md ← reglas globales que ningún módulo puede romper
│ ├── architecture/
│ │ ├── overview.md
│ │ └── decisions/ ← ADRs globales
│ ├── context/
│ │ └── central.md ← resultado del merge, no la fuente
│ └── modular/
│ ├── modules.yaml ← índice machine-readable de todos los módulos
│ └── [dominio]/
│ ├── module.yaml ← legible por máquina, base del orquestador
│ ├── context.md ← estado actual, corto y operativo
│ ├── contracts.md ← qué expone y qué consume
│ ├── invariants.md ← reglas duras del módulo
│ ├── decisions/ ← ADRs del módulo
│ ├── semantic-changelog.md ← qué cambió semánticamente
│ └── specs/
│
├── .context/
│ └── agents/
│ └── registry.local.yaml ← estado efímero, no se versiona igual
│
├── src/
└── scripts/
├── update_module_context.py
└── update_central_context.py
Por qué cada archivo:
module.yaml: es lo que hace al orquestador técnicamente posible. Sin un formato legible por máquina, el orquestador tiene que inferir todo del texto libre. Declara el módulo, su owner, sus contratos públicos, lo que consume de otros módulos, sus invariantes y su versión semántica.
context.md: estado actual del módulo, corto y operativo. No es documentación histórica ni archivo de decisiones. Es lo que el agente lee al arrancar su sesión para entender dónde está parado.
contracts.md: qué expone el módulo y qué consume de otros. Si cambia, el orquestador lo detecta y verifica que los consumidores estén actualizados.
invariants.md: reglas que no se pueden romper. El orquestador las usa como límite duro. Ejemplo: "solo auth/ puede exponer datos de usuarios", "location es requerido para cafés públicos".
decisions/: ADRs por módulo. El historial del por qué se decidió algo. Vive aquí y no en context.md para que este último se mantenga operativo y corto.
semantic-changelog.md: qué cambió semánticamente, no en código. Diferente al git log: registra cuándo un contrato cambió, cuándo una invariante se actualizó, cuándo el ownership de un dato se movió.
registry.local.yaml: estado efímero. Registra quién está trabajando en qué módulo ahora mismo. No se versiona igual que el resto porque "quién trabaja ahora" es información de runtime, no historial semántico.
Un ejemplo de module.yaml:
module: cafes owner: team-commerce status: active responsibilities: - perfil de cafetería - horarios y metadata pública - geolocalización public_contracts: - getCafePublicProfile - searchCafes - updateCafeProfile consumes: - auth.currentUser - geo.normalizeAddress invariants: - "Solo cafes/ puede modificar datos del perfil de cafetería" - "location es requerido para cafés públicos" semantic_version: 1 last_updated: 2026-05-26
Todo vive en el repositorio. No hay base de datos externa, no hay servicio separado, no hay infraestructura adicional que mantener. Git versiona todo: el código, el contexto por módulo, los contratos, el historial de decisiones semánticas, el orquestador mismo.
src/ → código → versionado por Git docs/modular/ → contexto por módulo → versionado por Git context/ → contexto central → versionado por Git .context/ → registry de agentes → versionado por Git scripts/ → orquestador → versionado por Git
Y hay algo más: el historial de Git se convierte en el historial semántico del proyecto. No solo es posible ver qué cambió en el código — también qué decisiones se tomaron, qué contratos se modificaron, qué conflictos semánticos se resolvieron y cuándo.
Merge de código: ya existe. Git lo resuelve. Conflictos de texto, detectables automáticamente, resolución técnica.
Merge de contexto: no existe. Conflictos de intención, no detectables por Git, requieren comprensión semántica. Ocurre cuando dos desarrolladores tomaron decisiones coherentes individualmente pero incoherentes globalmente. Solo un agente que lee ambos contextos puede detectarlo.
Al arrancar una sesión: Dev abre su editor → agente lee context/central.md (visión global del equipo) → agente lee modular/su-módulo/context.md (su dominio) → registra presencia en agents/registry.yaml → arranca con contexto real y actualizado Al hacer commit: Dev hace commit → update_module_context.py actualiza el contexto de su módulo → registra decisiones tomadas y contratos modificados → contexto del módulo queda actualizado localmente Antes del push — la capa de orquestación: Dev intenta hacer push → pre-push hook activa el orquestador → orquestador lee context/central.md → compara contra el contexto del módulo actualizado → valida que lo construido sigue el estándar → detecta si hay conflicto semántico con otro módulo → alerta si hay incoherencia — el dev decide cómo resolverlo → merge al central si todo es coherente → push procede
El orquestador no es un humano ni un manager. Es un agente cuyo único trabajo es mantener la coherencia del sistema de contexto distribuido: lee los contextos de módulo, compara contra el central, detecta contradicciones, alerta antes de que el problema llegue al código.
No escribe código. No toma decisiones de arquitectura.
Los conflictos en tiempo real no están resueltos. Si dos desarrolladores trabajan simultáneamente en módulos acoplados, el conflicto se detecta al commit, no mientras trabajan.
La resolución de conflictos sigue siendo humana. El orquestador detecta; no decide. La resolución es una conversación del equipo.
Requiere boundaries modulares claros. En repos con alta deuda técnica donde la separación de responsabilidades es ambigua, el ownership de contexto por módulo es difícil de establecer.
Es quizás la pregunta más concreta y sin respuesta definitiva todavía:
No tenemos una respuesta definitiva. Es parte de lo que queremos debatir.
Hoy la decisión de qué modelo usar es manual y arbitraria. Lo que falta es una capa de decisión:
repo pequeño + feature simple → modelo chico, rápido, barato repo grande + arquitectura → modelo grande, contexto largo refactor complejo → modelo con razonamiento spec nueva desde cero → modelo creativo validación semántica → modelo preciso, no creativo
El umbral mínimo que vemos hoy para que el estándar funcione es 128k tokens de contexto. Por debajo de eso el agente empieza a olvidar partes críticas del contexto. Ese umbral ya está disponible en modelos open source y comerciales a distintos rangos de precio — la arquitectura no está atada a ninguno.
Hay reportes de empresas de primer nivel que han consumido presupuestos anuales de IA en meses. No en años — en meses. Y no porque la tecnología sea mala, sino porque nadie planificó cómo iba a escalar el consumo cuando pasara de experimental a organizacional.
El patrón se repite: adopción rápida de agentes, sin estructura de control, con costos que crecen de forma impredecible hasta que alguien corta el presupuesto o cambia de herramienta. La decisión termina siendo financiera, no técnica.
Sin estructura, el agente parte de cero en cada sesión. Relee todo, reentiende todo, improvisa todo. El costo no baja con el tiempo. Con contexto distribuido la curva es distinta: construir de cero tiene un costo alto — es normal, se está definiendo todo. Pero las iteraciones venideras son más baratas porque el contexto hace el trabajo que antes hacían los tokens. El agente no reentiende, sigue el patrón.
No tenemos métricas propias para demostrarlo todavía. Es una de las preguntas abiertas que queremos responder con evidencia real.
¿Es el orquestador bloqueante o solo informativo? ¿Cómo se establece el ownership de módulo en equipos que rotan? ¿El patrón escala a más de un repo? ¿Puede cualquier LLM leer y operar sobre el mismo sistema de contexto sin fricciones?
Hay una conversación que se repite: la IA va a dejar a los desarrolladores sin trabajo. Hasta el momento no vemos evidencia de que eso esté pasando — al menos no de la forma que se describe.
No existe todavía un sistema autónomo que tome todos los requerimientos de un proyecto y los ejecute sin instrucción inicial, sin validación, sin coordinación humana. Los sistemas multi-agente existen, pero necesitan un harness que los acote, una instrucción que los oriente, y un humano que valide que el resultado es correcto para el negocio. Sin eso, son peligrosos.
La paradoja es esta: cuanto más autónomo se quiere que sea el agente, más importante se vuelve el humano que define el contexto, el harness y los criterios de validación.
Lo que sí está cambiando es qué tipo de trabajo hace el desarrollador:
Antes → escribe código
Con IA básica → revisa código que genera el agente
Con estructura → define intención, diseña contexto,
valida coherencia semántica,
coordina decisiones entre módulos
Los desarrolladores deben evolucionar. No desaparecer.
En 2009, cuando la virtualización empezaba a transformar la infraestructura IT, José Juan Mora Pérez documentó en Capacity Planning IT: Una aproximación práctica algo que hoy se repite con la IA: el ritmo con el que avanza la tecnología obliga a reducir el tiempo de sincronización, y las compañías deben conocer su capacidad real antes de que la demanda del negocio las alcance.
José Juan Mora Pérez criticaba algo concreto: que el Capacity Planning se hacía "desde una perspectiva puramente IT, sin tener en cuenta cuáles son las necesidades del Negocio." El mismo error se está repitiendo hoy. Las empresas adoptan IA desde la perspectiva de la herramienta —qué modelo es más potente, qué IDE tiene mejor integración— sin entender qué estructura necesita el negocio para usarla bien a escala. El resultado es el mismo que en 2009: colapso cuando la demanda llega, factura que nadie anticipó.
El recurso escaso cambió. Antes era:
CPU → cómputo RAM → memoria Storage → almacenamiento
Hoy es:
GPU → cómputo IA NVRAM → memoria de GPU, limitada por modelo Tokens → consumo de contexto por sesión
Y el problema de capacity planning se volvió más complejo porque hay dos capas simultáneas. La capa de infraestructura: GPU escasa y cara, NVRAM limitada, si no se tiene suficiente, el modelo no corre. Y la capa de consumo: tokens por sesión, contexto por agente, si no existe estructura, los recursos se desperdician.
Las empresas que cortan presupuesto de IA probablemente están fallando en ambas capas — pagando por GPU e inferencia que no necesitaban porque sus agentes sin estructura consumen de más.
El contexto distribuido bien estructurado no es solo una solución al problema semántico. Es también una solución al problema de capacity planning de IA: cada agente lee solo el contexto de su módulo, no todo el repositorio. El orquestador decide qué modelo usar según la complejidad de la tarea. El costo se vuelve predecible y justificable por equipo.
Al menos eso creo. No tenemos datos para comprobarlo todavía. Lo que sí es claro es que siempre hay un costo inicial — es normal, se está construyendo desde cero. Pero en el tiempo ese costo debería disminuir, simplemente porque el proyecto nunca vuelve al estado cero. El contexto acumulado hace el trabajo que antes hacían los tokens. Esa es la diferencia entre construir y agregar.
El principio es el mismo que en 2009. El recurso escaso cambió.
Y el problema de fondo también es el mismo: el capacity planning dependía de proyecciones de negocio que muchas veces no existían o eran imprecisas. Con IA se amplifica — no solo no sabemos cuánto va a crecer el negocio, tampoco sabemos si ese crecimiento va a venir con equipos tradicionales, con agentes, o con alguna combinación que todavía no existe. Planificar capacidad de IA sin saber hacia dónde va el negocio es tan difícil como lo era en 2009. Quizás más.
No tenemos la respuesta completa. Tampoco tenemos todavía datos propios que prueben el impacto con métricas formales. Pero sí creo que el contexto —bien estructurado, distribuido y versionado— es el punto de partida correcto, al menos hasta la fecha en que escribo esto.
No hace falta creer. Basta con mirar cómo trabajan los equipos hoy.
Una célula de cinco personas tocando el mismo repositorio, muchas veces el core del negocio. O empresas donde el producto es uno solo, separado por capacidades, dominios o módulos —como pasa en muchos ERPs—, pero donde todo termina viviendo en el mismo repo.
Antes, el problema era llegar a producción sin generar una incidencia. No era únicamente una cuestión de organización, ramas o merges. Era lograr que tantas manos tocando el mismo sistema no rompieran algo que el resto del equipo asumía como estable. Git resolvía conflictos de texto. Los tests validaban comportamientos conocidos. El code review agregaba criterio humano.
Con IA, el problema cambia de escala.
Ya no se trata solo de cuántos cambios hubo en el repo, quién los hizo o si los tests pasan. El nuevo problema es que la IA siga entendiendo el desarrollo y la estructura del sistema. Que no pierda las decisiones anteriores. Que no rompa patrones existentes. Que no trate cada sesión como si el proyecto empezara de cero. Que no construya algo que funciona en su módulo, pero contradice silenciosamente al resto.
Por eso vuelven conceptos que parecían viejos: specs, contratos, harness, guardrails, contexto. No vuelven por nostalgia. Vuelven porque el problema que resolvían reapareció en otro lugar.
Alguien podría decir que esto se resuelve con coordinación de equipo. Otro podría decir que lo importante es deployar rápido, porque la eficiencia se mide por velocidad de entrega. Tal vez los dos tengan una parte de razón.
Pero ninguno resuelve por completo la pregunta de fondo:
qué pasa cuando cinco agentes, cada uno con su propio contexto, toman decisiones distintas sobre el mismo sistema al mismo tiempo.
Ese es el problema real.
Y ese sí lo creo.
Esta versión plantea la dirección y abre el debate. La v0.2 irá más lejos en dos frentes concretos.
Auto-update distribuido basado en blueprint. Si bien la arquitectura modular distribuida y la automatización local de ganchos de contexto minimizan el impacto de las mutaciones cotidianas del código, subsiste una interrogante crítica: ¿es el aislamiento modular suficiente para garantizar la integridad del sistema a largo plazo? La experiencia preliminar sugiere que, aunque el desacoplamiento reduce los conflictos estructurales directos, la validación formal de la coherencia semántica frente a la visión central del producto sigue siendo una frontera abierta. La v0.2 explorará cómo el mismo blueprint que hoy resuelve el monorepo individual puede extenderse al entorno distribuido, generando y actualizando automáticamente toda la estructura de contexto por commit, sin intervención del desarrollador.
El orquestador como vigía de invariantes. El mayor riesgo no es el conflicto visible que Git detecta. Es el cambio silencioso: una mutación que respeta formalmente el contrato del módulo pero viola la lógica de negocio central.
La estructura de repositorio propuesta, con el contexto distribuido por módulo y el auto-update por commit, resuelve el 80 o 90% del problema de coordinación en equipos con IA. El orquestador semántico no es el sistema, es la última línea de defensa: el vigía que atrapa ese 10 o 20% restante, los cambios silenciosos que pasan todos los filtros estructurales pero violan los principios centrales del producto.
Piensa en esto: el Módulo A maneja pagos, el Módulo B maneja suscripciones. Un desarrollador, vía agente, hace un cambio en pagos que técnicamente respeta el formato del module.yaml — sigue devolviendo un string y un booleano, todo correcto estructuralmente. Pero cambió una regla de negocio: antes, si el pago fallaba tres veces, el sistema daba tres días de gracia. Ahora suspende la cuenta de inmediato.
El hook local lo procesa sin chistar. El commit es perfecto. Los tests pasan. Pero acabas de violar la constitución del producto y rompiste la lógica esperada por el módulo de suscripciones, sin que ningún test tradicional ni schema local saltara. El problema llega silencioso a producción.
El orquestador semántico es el único que puede leer ese cambio contra los principios inmutables definidos en el repositorio central — constitution, product-vision, plan, architecture — y decir: "esto viola el principio de gracia al usuario — merge bloqueado." Su trabajo no es revisar cómo está escrito el código. Es vigilar que ningún módulo rompa la lógica de visión, constitución y arquitectura que define lo que el sistema prometió ser. No opera como árbitro de opiniones entre modelos, sino como guardián de lo que está escrito en el centro. Cómo diseñar ese vigía sin romper el flujo del equipo es la pregunta que queremos responder en la próxima versión.
El paradigma no es el LLM. Es la estructura. Cualquier modelo que permita leer el contexto distribuido debería poder operar sobre él. Esa es la apuesta.