CODEX MEETING · MAYO 2026
Spec-Driven Development
+ orquestación multi-agente
Cómo administrar el context window
y escalar agentes que no se sabotean a sí mismos
Ramiro Carnicer · Search Backend
LA TESIS
El context window es el cuello de botella de los agentes.
SDD lo administra como recurso escaso.
La orquestación multi-agente lo escala
en contextos frescos y aislados.
Juntos, hacen que la IA pase de asistente que sugiere a
equipo que entrega.
1 · El problema
Context window: la "RAM" del modelo
El modelo NO tiene memoria.
Cada turno relee TODO el historial desde cero.
Y cuando el contexto se llena…
todo se degrada — antes de llegar al techo.
UNA SESIÓN REAL
200K tokens
≈ 500 páginas
System prompt
5K
Tools / MCPs
10K
Conversación
60K
Libre
125K
Suena mucho — hasta que abrís un repo real con 165K líneas de código.
1 · El problema
Context rot: la degradación silenciosa
✕
Olvida instrucciones
Lo que le dijiste
10 mensajes atrás
ya no está.
≈
Confunde archivos
Mezcla clases
con nombres
parecidos.
↻
Repite errores
Vuelve a meter
el mismo bug
ya corregido.
?
Inventa APIs
Llama métodos
que no existen
en tu codebase.
No es que el modelo se vuelva tonto. Es que se distrae.
2 · La solución base
SDD: Spec-Driven Development
Antes de escribir código, escribimos especificaciones que el agente puede leer, validar y descomponer en tareas.
Vibe Coding
"Hacé un endpoint que…"
- el agente improvisa
- 30% sale bien
- 70% hay que refactorizar
SDD
ticket → spec → plan → código → review
- cada paso es un artefacto leíble
- el agente nunca improvisa
- el contexto se mantiene comprimido
2 · La solución base
Los 4 documentos del SDD
1
proposal.md
¿Qué problema
resolvemos?
PARA
PM + tech lead
2
functional.md
¿Cómo se ve
desde afuera?
PARA
QA + producto
3
technical.md
¿Cómo lo
construimos?
PARA
Devs
4
tasks-breakdown.md
¿En qué orden
entregamos?
PARA
Quien codea
Cada documento constrains al siguiente.
2 · La solución base
Por qué este orden no es opcional
Cuando el agente codea el task #3,
NO necesita leer el ticket original.
Solo necesita el tasks-breakdown.md y el slice relevante de technical.md.
TOKENS CARGADOS AL CODEAR EL TASK #3
SDD es compresión semántica del contexto.
2 · La solución base
SDD se aplica como una skill
TICKET JIRA
CODEX-001
Generador de
changelog desde
git log
→
SKILL
SDD
Spec-Driven
Development
→
📄 proposal.md
📄 functional.md
📄 technical.md
📄 tasks-breakdown.md
workspace/sdds/CODEX-001/
⚡
Hasta acá: cero código.
El 60% del trabajo intelectual ya está hecho — y leíble por humanos.
3 · Orquestación multi-agente
Pero un agente único no escala
AGENTE MONOLITO
Hace TODO
analiza ticket
escribe spec
codea
se revisa a sí mismo
abre PR
1. Context bleed
Spec, código y review viven en el mismo contexto.
La review está sesgada.
2. Token blow-up
Al task #4, ya hay 80K tokens
de historial irrelevante.
3. Sin punto de retorno
Si la review falla, el agente no puede pensar de nuevo —
su cabeza está llena.
3 · Orquestación multi-agente
Un sub-agente = un .md o un .toml
Un agente con un rol acotado, su propio contexto, sus tools permitidas y su system prompt.
En la práctica: un Markdown o un TOML.
📄 explorer.md
---
name: explorer
model: gpt-5.2
tools: Read, Glob, Grep
---
Sos un agente read-only.
Leés el repo y devolvés contexto comprimido. Nunca escribís nada.
📄 implementer.toml
name = "implementer"
model = "gpt-5.3-codex"
tools = ["Edit", "Write", "Bash"]
Implementás cambios con flujo TDD. Reportás archivos tocados y evidencia. No te revisás a vos mismo.
Cambiar un agente = editar un .md o .toml. Sin redeploy. Sin SDK.
3 · Orquestación multi-agente
Una sesión principal + 5 sub-agentes
| ROL | QUÉ HACE | QUÉ NO HACE |
|---|
| explorer |
✓ Lee y comprime contexto del repo (read-only). |
✕ Escribe nada. |
| documentator |
✓ Escribe specs en docs/ (funcional + técnica). |
✕ Toca código. |
| planner |
✓ Convierte spec en plan de tasks + checklist. |
✕ Codea. |
| implementer |
✓ Codea con flujo TDD, reporta evidencia. |
✕ Se revisa a sí mismo. |
| tester_reviewer |
✓ Tests + checks + handoff (report-only). Contexto FRESCO. |
✕ Modifica código. |
Un agente · un rol · un objetivo · un contexto.
3 · Orquestación multi-agente
El invariante crítico: freshContext
IMPLEMENTER
Codea + commit
reporta evidencia
crea .reviewing lock
🧱
FIREWALL
freshContext: true
TESTER_REVIEWER
Tests + checks + handoff
solo lee: spec + plan + diff
NO ve el resto
VERDICT
- accept
- request-changes
- block
POR QUÉ IMPORTA
El tester_reviewer NO sabe lo que el implementer intentó hacer. Solo ve el resultado.
Esto replica lo que hace un humano en code review: lee el diff, no el debugger.
Si el implementer alucinó, el tester_reviewer lo cacha — porque no comparte la alucinación.
🔒 Enforzado por hook pretool_allowlist.py — bloquea writes mientras existe el .reviewing lock.
3 · Orquestación multi-agente
El flow completo end-to-end
→
→
DOCUMENTATOR
specs en docs/
→
PLANNER
spec → plan tasks
→
BUILD LOOP
impl ⇄ tester × N
→
↻ por cada task
Cada caja es un agente con su propio context window.
Ningún agente ve más de lo que necesita.
Es un pipeline de software, no una conversación.
4
DEMO EN VIVO
git-changelog-gen
Vamos a la terminal.
Ticket → SDD → impl ⇄ review × 4 → CHANGELOG.md → PR
Si algo falla en vivo, lo van a ver fallar.
Esto NO es un video. Es el sistema corriendo. Ojo a los handoffs.
5 · Cierre
Las 3 cosas que hacen los buenos agentes
1
Comprimen el contexto antes de gastarlo.
→ SDD: 4 archivos antes de codear
2
Aíslan roles para evitar context bleed.
→ Multi-agente: un rol, un contexto
3
Verifican con contexto fresco.
→ Review chain: no se creen a sí mismos
Compresión · Aislamiento · Verificación
LA IDEA
El context window es ingeniería, no magia.
SDD lo administra.
La orquestación lo escala.
Si se llevan UNA cosa, que sea esta.
PERO OJO
Los agentes hacen.
Vos los orquestás.
Y para orquestar bien hay que haber metido mano en el código y saber lo que estamos haciendo.
No es magia. No "vibe codeamos". Es ingeniería de agentes.
GRACIAS
Ramiro Carnicer Souble
Backend Engineer · Founder-minded Builder · Buenos Aires
Backend Software Engineer en MELI. Building Khora, Infer y experimentos varios.
Backend systems, AI products, and thoughtful internet experiments.
EL REPO
github.com/ram4-dev/multi-sdd-team