Agentes paralelos en Zed: los probé en mi flujo real y esto cambió (y esto no)

Un caño de agua tiene diámetro fijo. Podés poner diez bombas en paralelo, cada una empujando con más fuerza, y el caudal que sale del otro lado va a ser exactamente el mismo. El problema no era la velocidad del agua — era el ancho del tubo.

Parallel agents en Zed es básicamente eso. Y una vez que lo ves así, la promesa de "varios agentes trabajando al mismo tiempo" empieza a sonar diferente.

Zed llegó a 229 puntos en Hacker News con esta feature. La discusión fue larga, entusiasta, llena de gente que ya la estaba usando en proyectos reales. Yo la vi mientras estaba revisando los logs de CrabTrap, mi proxy LLM-as-a-judge que tengo en producción hace meses. Pensé: tengo setup propio, tengo números propios, puedo hacer esta comparación con algo concreto. Lo que sigue es eso.

Qué son los parallel agents en Zed (y por qué importa el diseño)

Zed permite lanzar múltiples instancias de agente sobre el mismo codebase, de manera simultánea, con contextos separados. Cada agente ve su propia ventana de contexto, trabaja en su propio branch o conjunto de archivos, y los resultados se integran después. Es un modelo de "fork and merge" aplicado a la inferencia.

El diseño es elegante. El problema que ataca es real: cuando tenés una tarea grande — refactor de tres módulos, migración de tipos, test coverage en paralelo — ejecutarla secuencialmente en un solo agente tiene un costo de latencia enorme. Un agente hace módulo A, después módulo B, después módulo C. Con parallel agents, hacés los tres a la vez.

Mi tesis antes de empezar: la paralelización resuelve el problema equivocado si tu cuello de botella es de contexto, no de velocidad.

Mi setup actual: Claude Code + CrabTrap + Railway

Antes de mostrar la comparación, el contexto importa. No vengo de cero con agentes.

Tengo corriendo en producción:

• Claude Code como agente principal de desarrollo, sobre mi stack Next.js + TypeScript + PostgreSQL
• CrabTrap como proxy LLM-as-a-judge que evalúa outputs antes de que lleguen a producción
• Todo deployado en Railway, con logs estructurados que me permiten medir tokens por tarea real

Este setup evolucionó durante meses. Documenté parte de ese proceso cuando comparé costos contra Google TPU v8 y encontré que los números de marketing no cierran con cargas reales.

Lo que mido en cada sesión de agente:

# Extraer métricas de una sesión de Claude Code
# desde los logs de Railway

railway logs --service crabtrap --since 2h | \
  grep '"type":"agent_turn"' | \
  jq '{
    turno: .turn,
    tokens_entrada: .usage.input_tokens,
    tokens_salida: .usage.output_tokens,
    tarea: .task_label
  }'

Salida típica de una sesión de refactor mediana:

{ "turno": 1, "tokens_entrada": 8420, "tokens_salida": 1203, "tarea": "analisis_contexto" }
{ "turno": 2, "tokens_entrada": 12840, "tokens_salida": 2891, "tarea": "propuesta_cambios" }
{ "turno": 3, "tokens_entrada": 18220, "tokens_salida": 4102, "tarea": "implementacion" }
{ "turno": 4, "tokens_entrada": 22100, "tokens_salida": 891,  "tarea": "validacion" }

El número que me importa: tokens de entrada en el turno 3 ya son 18k. Y esto es una tarea chica. Para algo que toca tres módulos, estoy fácil en 40-60k tokens de entrada solo por el contexto acumulado.

Lo que Zed parallel agents cambia (con evidencia)

Probé Zed con tres escenarios concretos de casos reales.

Escenario 1: Migración de tipos TypeScript en módulos independientes

Tenía tres módulos sin dependencia directa entre sí — autenticación, métricas, y el cliente de base de datos — que necesitaban migrar de any a tipos estrictos. Con mi flujo habitual de Claude Code, lo hacía secuencialmente. Tiempo total estimado: ~45 minutos de inferencia, 3 sesiones.

Con Zed parallel agents: lancé tres agentes simultáneos, uno por módulo. Tiempo total real: ~18 minutos. Los tres módulos terminaron en paralelo, la integración tardó 4 minutos de revisión manual.

Esto es velocidad real. No hay discusión.

Escenario 2: Test coverage sobre código con dependencias cruzadas

Acá vino el primer problema. Le pedí a dos agentes en paralelo que escribieran tests para dos servicios que comparten un helper de validación. El resultado:

// Agente 1 generó esto en validationService.test.ts
// Mockeó el helper de una manera
jest.mock('../utils/validatePayload', () => ({
  validatePayload: jest.fn().mockReturnValue({ valid: true })
}));

// Agente 2 generó esto en paymentService.test.ts
// Mockeó el mismo helper de manera diferente
jest.mock('../utils/validatePayload', () => ({
  validatePayload: jest.fn().mockImplementation((data) => {
    if (!data.amount) throw new Error('missing amount');
    return { valid: true };
  })
}));

Dos mocks incompatibles del mismo módulo. Ninguno es incorrecto en aislamiento — el problema apareció al integrar. Tuve que revisar los dos archivos, entender qué asumía cada agente, y elegir una convención.

El tiempo ahorrado en inferencia lo gasté en revisión. Diferencia neta: casi cero.

Escenario 3: Refactor donde el contexto importa

Quería refactorizar el manejo de errores en mi API — algo que toca middlewares, handlers, y el cliente de Railway al mismo tiempo. Acá la paralelización directamente no aplica. Los agentes necesitan ver el estado del código después de que el agente anterior hizo cambios. Es secuencial por naturaleza.

Intenté igual. El resultado fue conflictos de merge que me llevaron más tiempo que el refactor original. Aprendizaje grabado a fuego.

Los errores que cometí (y el cuello de botella que no era velocidad)

Después de la semana de pruebas, revisar mis logs me dio una incomodidad que no esperaba.

El 70% de mis tareas de agente son del tipo "escenario 3": trabajo que depende del estado del sistema después de cada paso. Migraciones, refactors de arquitectura, cambios que propagan efectos. Para ese 70%, parallel agents no ayuda — de hecho, genera overhead de coordinación.

El 30% restante — tareas independientes en módulos sin dependencia — sí se beneficia. Y mucho. Ahí el speedup es real y medible.

Pero el cuello de botella que me estaba matando no era velocidad. Era contexto degradado. Cuando un agente llega al turno 4 con 22k tokens de entrada acumulados, empieza a perder coherencia sobre lo que decidió en el turno 1. Parallel agents no toca ese problema — de hecho, con contextos separados por agente, el problema se multiplica: cada agente tiene su propia visión parcial del sistema.

Esto conecta con algo que documenté cuando armé CrabTrap: el problema de los agentes en producción no es cuántas cosas pueden hacer al mismo tiempo, sino cuánta coherencia mantienen a lo largo de una sesión larga. Agregar carriles al autopista no arregla que cada conductor tenga un mapa diferente.

Mi setup con CrabTrap intercepta y evalúa cada output antes de que se aplique. Parallel agents de Zed no tiene ese layer. Para tareas independientes, no importa. Para tareas interdependientes, importa mucho.

Un número concreto: en mis pruebas de escenario 2, el 40% de los conflictos de integración vino de asunciones implícitas que cada agente hizo sobre el estado compartido. Ningún agente estaba "equivocado" — estaban incompletos, cada uno por su lado.

El tema del pricing de Claude Code en el plan Pro también entra acá. Si usás parallel agents con modelos de frontera, el costo se multiplica casi linealmente. Tres agentes en paralelo ≈ tres veces el costo en tokens. Para tareas independientes donde ganás velocidad, puede valer. Para tareas donde terminás rehaciendo el trabajo de integración, estás pagando tres veces por el mismo resultado.

FAQ — Preguntas frecuentes sobre parallel agents en Zed

¿Parallel agents de Zed funciona con cualquier modelo de lenguaje?

Zed permite configurar el proveedor de modelo, así que técnicamente sí. En la práctica, el comportamiento varía bastante. Yo lo probé con Claude 3.5 Sonnet principalmente. Con modelos más chicos el overhead de coordinación se vuelve más evidente porque cada agente tiene menos capacidad de inferir el estado implícito del sistema.

¿Qué tipos de tareas se benefician más de la paralelización?

Las que tienen módulos con frontera clara y sin dependencia de estado compartido. Migración de tipos en módulos independientes, generación de tests para servicios desacoplados, traducción de documentación, linting y formateo. Todo lo que podés hacer en branches separados sin que un agente necesite ver lo que hizo el otro.

¿Zed parallel agents reemplaza un setup como Claude Code + CrabTrap?

No son competidores directos. Zed te da velocidad en paralelo. CrabTrap te da validación de coherencia en el output. Si tus tareas son independientes y no necesitás evaluación intermedia, Zed es más simple. Si trabajás con tareas que propagan efectos y necesitás un layer de juicio antes de aplicar cambios, necesitás algo adicional. Yo los usaría complementarios, no excluyentes.

¿Cuánto tiempo lleva la integración de los resultados de múltiples agentes?

Depende casi completamente del grado de acoplamiento entre las tareas. En mi escenario 1 (módulos independientes): 4 minutos de revisión manual. En mi escenario 2 (dependencia compartida): más de 25 minutos de resolución de conflictos. El overhead de integración es el costo oculto que los benchmarks de velocidad no muestran.

¿Parallel agents resuelve el problema de contexto largo en sesiones de agente?

No. Es el punto central de esta entrada. Contextos separados por agente significa que cada uno tiene su propia ventana, pero ninguno tiene la imagen completa. Para tareas donde la coherencia sistémica importa, esto puede ser peor que un solo agente con contexto largo. El problema de contexto degradado — que los tokens de entrada se acumulan y el agente pierde coherencia sobre sus propias decisiones anteriores — sigue siendo un problema abierto que la paralelización no toca.

¿Vale la pena cambiar mi setup actual a Zed para aprovechar parallel agents?

Si ya tenés un flujo que funciona, no lo tirés por las ventanas. La respuesta honesta es: agregá Zed para las tareas donde claramente gana (módulos independientes, trabajo de frontera), y mantené tu setup para el resto. No es una migración, es una herramienta adicional. Lo mismo que aprendí con las decisiones de deuda técnica al evaluar nuevas herramientas: el costo de adopción no es solo tiempo de setup, es el tiempo de entender dónde no aplica.

Conclusión: dos problemas distintos que se confunden

Cursé Ciencias de la Computación en la UBA mientras laburaba full time. Había materias donde llegaba directo del trabajo con el traje puesto. Una de las cosas que más me costó entender al principio fue la diferencia entre throughput y latency. Podés tener altísimo throughput y aun así esperar mucho si el cuello de botella está en el lugar equivocado.

Parallel agents en Zed mejora el throughput de tareas independientes. Eso es real, medible, y en los escenarios correctos es un speedup genuino. Pero el problema que más me duele en mis flujos de agente no es throughput — es coherencia de contexto en sesiones largas. Y para ese problema, correr más agentes en paralelo es básicamente agregar más bombas a un caño que tiene diámetro fijo.

Mi postura después de una semana de pruebas: Zed parallel agents entra en mi toolbox para un subconjunto específico de tareas. No reemplaza el stack que armé. Lo complementa donde gana, y donde no gana, no lo uso. Esa es la comparación honesta que los 229 puntos de HN no te cuentan.

Si estás explorando cómo medir el costo real de tus decisiones de agente más allá de la velocidad, el lugar para empezar es medir tokens por tarea antes de agregar más agentes. La velocidad es una métrica seductora. El contexto es la que importa.