Remote Frog

Boris Cherny, el creador de Claude Code en Anthropic, compartió hace poco su flujo de trabajo donde ejecuta 5+ agentes de IA en paralelo: un planificador, desarrolladores de backend y frontend, testers, documentadores… todos coordinándose para abordar tareas complejas. Se parece más a dirigir a Data desde el puente del USS Enterprise que a programar de toda la vida.

Claro, tenía que probarlo. Llevo unas semanas ejecutando y afinando una configuración multiagente para distintos tipos de tareas. Sigo haciendo mejoras, pero he llegado a un setup que sí que me hace más productivo —y con el que me siento cómodo. Esto último importa más de lo que parece.

Este post es largo, así que aquí va el TL;DR:

• Las ganancias de velocidad son reales para tareas complejas —pero no mágicas.
• Inviertes tiempo en especificaciones en lugar de en código.
• La descomposición multi-agente es una herramienta de productividad y fiabilidad, no de ahorro de costes (aunque ahorres tiempo).
• La carga cognitiva puede ser brutalmente alta.
• Revisa. Todo. Por favor.
• Algunas explicaciones de los agentes son innecesariamente charlatanas —o sea, muchos tokens tirados.

Qué ha cambiado realmente en mi flujo de trabajo

Después de unas semanas trabajando así en tareas medianas-grandes —y mejorando el flujo iterativamente— puedo decir que mi flujo de desarrollo se ha acelerado de verdad. Pero la clave no es la velocidad. Es el cambio en lo que realmente hago.

Paso más tiempo pensando en qué quiero. Más tiempo haciendo rubber ducking con los agentes. Más tiempo dialogando con el planificador sobre enfoques. Y, por supuesto, menos tiempo tecleando. Muy poco tiempo depurando sintaxis.

Con algunos ajustes, podría ser más rápido. Probablemente un poco. Pero no creo que pueda ir mucho más lejos todavía sin perder el control y la propiedad del proceso y los resultados. Y no estoy seguro que merezca la pena cambiar foco, alcance o calidad por aún más velocidad.

¿El pero? No voy a decir que es relajante. Al final del día, mi cerebro a veces está a punto de derretirse. No estoy descargando trabajo cognitivo —lo estoy comprimiendo. Lo que antes llevaba días de esfuerzo repartido ahora ocurre en una sesión intensa.

Vamos con todo lo que he aprendido.

La arquitectura: cinco agentes, tres chats

Adapté el concepto de Cherny a mi propio flujo de trabajo y herramientas (uso Cursor). Después de probar varios enfoques, me quedé con 3 ventanas de chat simultáneas, cada una con diferentes roles de agente.

La estructura es así:

        Chat 1: Planner → Orchestrator → Documenter
                   ↓↑
                workflow_[ID].md (shared state DOC)
                   ↓↑                    ↓↑
        Chat 2: Developer          Chat 3: Tester 

Un chat cambia de rol a medida que avanza el flujo: empieza como planificador, se convierte en orquestador y finalmente se transforma en documentador. Los otros dos chats manejan desarrollo y testing respectivamente.

¿Podría ejecutar múltiples desarrolladores o testers? Por supuesto —la arquitectura lo soporta. El archivo markdown de coordinación permite marcar propiedad de tareas, así que los agentes pueden distribuir trabajo entre ellos. Sería definitivamente más rápido.

Pero aquí está la cosa: serían más rápidos que mi capacidad de revisar y validar lo que están haciendo. Y no creo que sea el momento de abdicar de ese control. Todavía. Quizás en el futuro, pero hoy no.

Así es la /multiagent-multichat action:

/multiagent-multichat AGENT-NAME "task description" --workflow-id ABC123  --preview-mode

AGENT-NAME: Can be planer (Orchestrator → Planner → Documenter flow), developer, tester or documenter
"task" - Required. Task description or @file reference. It's a complete description of the task used by AGENT planner to create a Workflow with detailed instructions for each other agent
--workflow-id [ID] - Required. The workflow ID created from planner
--preview-mode - Optional. Makes changes but waits for user approval before marking complete

¿Por qué chats paralelos en lugar de subagentes?

Te preguntarás: ¿por qué no hacer que el orquestador lance otros agentes como subagentes? Podrías hacerlo, pero en Cursor funcionarían como una caja negra. ¿Más rápido? Sí. Pero no ves qué está pasando hasta el final, cuando ya puede ser demasiado tarde -haciendote finalmente perder mucho más tiempo del necesario para alguna corrección-.

Con ventanas de chat paralelas, consigo tanto paralelización como visibilidad. Puedo ver al desarrollador implementar cambios en tiempo real en una ventana, ver al tester crear y ejecutar tests en otra, y seguir el progreso general en la ventana del orquestador —todo simultáneamente.

En mi opinión, esta visibilidad no es solo un nice-to-have. Es esencial para mantener el control y pillar problemas antes de que se acumulen.

Markdown como capa de coordinación

El setup es sorprendentemente simple. Un agente planificador pide aclaraciones, confirma enfoques y luego descompone las tareas. Crea un archivo de estado compartido —un archivo .md plano— y coordina agentes de desarrollo y testing que trabajan de forma independiente en ventanas de chat separadas.

La magia está en las dependencias a nivel de tarea en lugar de bloqueo a nivel de agente: un tester puede empezar a trabajar en test1 en cuanto todas sus tareas prerrequisito (ej., dev1, dev2, dev7) se completan, incluso mientras dev3 sigue en progreso. Aquí es donde la paralelización realmente compensa.

Toda la coordinación ocurre a través de este archivo markdown compartido. Incluye qué agente está a cargo de cada tarea y las precondiciones para cada una. Los agentes hacen polling a intervalos regulares para esperar su turno y actualizan el archivo cuando terminan.

No se necesita infraestructura compleja —solo un archivo .md que puedes abrir en cualquier momento para ver exactamente cómo van las cosas. El orquestador monitoriza este archivo, esperando a que todo esté dentro de la misma conversación antes de cambiar a modo documentador.

Este es el aspecto que tiene el archivo de plan:

# Workflow: NAMEEXAMPLE

**Title**: Lo que hace en 1 frase
**Description**: Descripción un poco más larga, pero concisa  
**Source**: `fichero md donde expliqué al planner lo que quiero hacer` = SPECS  
**Created**: timestamp  
**Updated**: timestamp  
**Status**: planned | working | completed  
**Tags**: 

---

## Tasks

### dev1 - descripción de la tarea atómica en 1 frase
**Agent**: developer  (o tester o documenter...)
**Status**: waiting for dependencies | working on it | completed  
**Started**: timestamp 
**Completed**: timestamp
**Dependencies**: nombre de tareas de las que depende (o ninguna, none)  
**Blocking**: test1

**Description**:
Descripción un poquito más larga, pero concisa

**Files modified**:
- ``

**Notes**: Si se necesitan

---

### dev2 - descripción de la tarea atómica en 1 frase
... etc  

La estructura de archivos

Por si te gusta ver cómo se organizan las cosas (aunque esto es solo un ejempo, ya que desde que hice el draft de este post, ya ha cambiado, sigo experimentando):

## 📁 File Structure
 
**Action** (how to use):
- `.cursor/local/actions/multiagent-multichat.mdc` - Command reference (135 lines)
 
**File Structure**
 
.cursor/local/multiagent-multichat/
├── INDEX.md                     # This file (system overview)
├── agents/
│   ├── planner.md               # Complete planner guide (283 lines)
│   ├── developer.md             # Complete developer guide (143 lines)
│   ├── tester.md                # Complete tester guide (253 lines)
│   └── documenter.md            # Complete documenter guide (191 lines)
└── plans/
    ├── workflow_EXAMPLE.md      # Reference example
    └── workflow_[ID].md         # Active workflows (Markdown format)
 
**Generated output**:
- `.cursor/local/docs/PRs/` - PR documentation
- `.cursor/local/docs/projects/` - Feature documentation

El sistema se basa en el descubrimiento progresivo: cada agente lee solo su propia guía (menos líneas), lo que reduce el contexto requerido en un 71–86% en comparación con sistemas monolíticos. Los agentes se coordinan a través del archivo de plan compartido en formato Markdown, en el que cada agente actualiza solo sus propias tareas, evitando conflictos de estado.

Las especificaciones se convierten en tu producto

Pasarás significativamente más tiempo en especificaciones. ¿Y sabes qué? Estoy totalmente convencido de que eso es una feature, no un bug.

Trabajar así te obliga a entender realmente el problema. Hablas con stakeholders, anticipas casos edge, piensas en cómo quieres que las cosas funcionen y lo escribes todo. Estas especificaciones se convierten en el input del proceso, pero también son excelente documentación del proyecto que puede discutirse con stakeholders y sobrevivirá a la implementación.

Las especificaciones se centran en el qué, no en el cómo. ¿Qué queremos conseguir? ¿Qué restricciones funcionales o de diseño existen? ¿Qué fuentes de datos debemos usar? Los agentes se encargan del cómo. Y de ciertas decisiones de diseño que pueden contrastar o validar contigo. O no.

Qué deben cubrir unas buenas specs

Tus especificaciones deberían abordar (directamente o referenciando archivos .md existentes en el repo):

• Requisitos funcionales: ¿Qué debe hacer el agente?
• Datos de entrada y salida: esquemas, fuentes, restricciones de privacidad si son relevantes, y outputs esperados
• Requisitos no funcionales: seguridad, manejo de privacidad/PII, acceso, fiabilidad, observabilidad, otras restricciones
• Reglas de dominio y negocio: qué está permitido y qué prohibido en el espacio del problema
• Estilo de código e interacción: Referenciando guías de estilo existentes

Algunas partes de estas especificaciones se definen para todo el proyecto y no deberían duplicarse. En su lugar, el agente debe saber dónde encontrar los archivos Markdown relevantes.

Las specs te fuerzan a estudiar tu dominio

Este enfoque requiere que estudies tus fuentes de datos en profundidad —su contenido, casos edge, inconsistencias, posibles duplicados. Aprovecho esta oportunidad para limpiar y documentar tablas, columnas o esquemas, ayudando a la descubribilidad de datos a medio plazo tanto para humanos como para modelos de IA. Este es el tipo de beneficio secundario que no aparece en las métricas de productividad, pero que se acumula con el tiempo.

El diálogo antes del plan

Antes de que el orquestador divida el trabajo en tareas atómicas, hay un paso crucial: discutir el enfoque y las decisiones de diseño de alto nivel.

Fomento este diálogo, incluyendo alternativas en mis especificaciones y pidiendo explícitamente al orquestador diferentes enfoques —incluso cuando ya he decidido el mío— solo para asegurarme de que no me estoy perdiendo algo interesante. La definición del agente también incluye invitaciones a pedir aclaraciones o sugerir enfoques alternativos.

Así que ambas partes (yo y el orquestador) estamos determinados a iniciar un diálogo donde yo tengo la última palabra, pero merece la pena cuestionar tus propias suposiciones. El orquestador a veces sugiere enfoques que genuinamente me sorprenden —cosas que no habría considerado por mi cuenta.

Solo después de esta conversación el planificador divide el trabajo en tareas atómicas para ser llevadas a cabo por el desarrollador, el tester y el documentador.

Gestión de contexto: menos es más

Cada agente maneja mucho menos contexto que un agente único. El desarrollador no necesita conocer detalles de testing. El tester no necesita entender cada decisión de implementación. Esta separación de responsabilidades no es solo organizativa: poda el contexto y enfoca la atención de cada agente.

Complementariamente, uso descubrimiento progresivo tanto como es posible: los agentes reciben información solo cuando la necesitan, no todo de entrada. Piénsalo como lazy loading para el contexto. El planificador conoce el panorama general; los trabajadores reciben justo lo que necesitan para su tarea específica cuando/si lo necesitan.

¿Y cuando un agente no hace lo que quiero? No arreglo el código —arreglo los archivos markdown o el contexto y pido al agente que lo intente de nuevo. La corrección se convierte en memoria, reforzando al agente y trascendiendo lo que sería un parche puntual.

Pro tip: En lugar de añadir el contexto tú mismo, prueba a explicar al agente qué salió mal y pídele que complete uno de los archivos de contexto para que no vuelva a pasar. Así, el agente aprende y el conocimiento persiste.

Modo preview: la red de seguridad

El sistema soporta dos modos:

• Auto-ejecución: Los agentes completan tareas autónomamente
• Modo preview: Los agentes hacen cambios pero esperan tu aprobación antes de marcar tareas como completadas

El modo de autoejecución funciona bien, pero yo siempre uso el modo preview. Prefiero revisar los cambios en la UI de Cursor antes de que los agentes marquen las tareas como completadas. Es la diferencia entre “creo en la IA” y “me hago responsable de mi código”.

Buscar errores en el PR es (1) demasiado tarde —crea fricción e iteraciones evitables, y, más importante, (2) me apropio de mi código y asumo responsabilidad de la robustez de mi trabajo. Enviar código a revisión de PR sin entenderlo completamente crearía alienación y exacerbaría la brecha entre lo que entiendo completamente y lo que estoy haciendo.

(Pequeña aclaración: “Lo que entiendo completamente” no es lo mismo que “Lo que soy capaz de entender completamente”. Distinción importante.)

El cuello de botella y pagar por inteligencia vs corrección

Boris Cherny lo expresa bien: “El cuello de botella en el desarrollo moderno con IA no es la velocidad de generación del token; es el tiempo humano gastado corrigiendo los errores de la IA”. En mi opinión, el flujo de trabajo debería invertir tiempo por adelantado —en especificaciones, en discusiones de enfoque, en gestión de contexto— para reducir el tiempo de corrección después. Sin embargo, en mi opinión, no se trata de hacer la IA más rápida; se trata de hacer la colaboración humano-IA más fiable.

Lo que sugiere Chrny tiene sentido. Más si eres el dueño del modelo que cobra por el uso de los modelos más inteligentes 😀 => Dice que tiene sentido pagar por un modelo más inteligente por adelantado y así evitar pagar en términos de tiempo de corrección después. Pero insisto, es que yo no eliminaría el tiempo de correción en ningún modo. Este tiempo de corrección es tiempo de digestión y de apropiación.

Reality check: qué pasa realmente

Qué significa esto para el futuro del desarrollo

He estado pensando mucho en lo que este flujo de trabajo implica para cómo trabajaremos en los próximos años.

La especificación se convierte en el producto

Cuando la IA puede implementar, la especificación -que se había adelgazado con algunas metodologías ágiles- se convierte en el artefacto más valioso. La persona que puede articular claramente qué necesita construirse —con todos los casos edge, restricciones y conocimiento de dominio— se convierte en el cuello de botella, no la persona que puede teclear código más rápido.

Este es un cambio fundamental. Recompensa la experiencia profunda en el dominio, el pensamiento claro y las habilidades de comunicación. Se trata menos de conocer sintaxis y más de conocer el espacio del problema.

La propiedad sigue importando

¿Incluso con la IA haciendo la mayor parte del tecleo, sigo sintiendo propiedad del código? En mi caso, todavía sí, porque revisé cada cambio. Porque entendí cada decisión. No porque pudiera explicar cada línea si me preguntaran.

Esto importa para la integridad profesional, pero también por razones prácticas. Cuando algo se rompe, necesitas entender el sistema. Cuando un stakeholder pregunta por qué algo funciona de cierta manera, necesitas tener una respuesta. La IA puede ayudarte a construir más rápido, pero no puede asumir la responsabilidad por ti.

El humano permanece en el bucle

Al menos por ahora, y probablemente por un tiempo más, el humano necesita permanecer en el bucle. No porque la IA no pueda hacer el trabajo —a menudo puede—, sino porque alguien necesita tomar decisiones de juicio, pillar errores sutiles y asumir la responsabilidad por el resultado.

El flujo de trabajo multiagente no elimina al humano. Cambia lo que hace el humano. Menos teclear, más pensar. Menos depurar la sintaxis, más evaluar enfoques. Menos trabajo mecánico, más trabajo de juicio.

Que eso sea mejor o peor… ¯\_(ツ)_/¯

Reflexiones finales

El insight clave para mí ha sido este: el flujo de trabajo no me hace trabajar menos. Me hace trabajar diferente. Menos teclear, más pensar. Menos depurar, más diseñar. Para mí, ha sido un balance positivo —incluso con el agotamiento cognitivo, incluso con los costes de tokens, incluso con la curva de aprendizaje. Pero tengo muchas interrogantes sobre adónde nos lleva esto.

Si tienes curiosidad, te animo a experimentar. Empieza pequeño. Mira cómo te sienta. Itera sobre lo que funciona y descarta lo que no. Y luego, recuerda…

Compartir es querer 💚