Agentes especializados y colaboración
Más agentes no significan automáticamente un mejor resultado. La calidad nace de encargos independientes, límites de escritura, pruebas comparables y una síntesis que resuelve las contradicciones.
Qué trabajarás, paso a paso
Descomponer por resultado, no por etiqueta
Añadir agentes no hace automáticamente que el trabajo sea más inteligente. A menudo solo hace que sea más difícil de seguir. La pregunta correcta no es «¿cuántos agentes puedo usar?», sino «¿qué resultado autónomo puedo delegar sin crear solapamientos?». De ahí parte una buena delegación.
Un subagente nombrado suele partir con un contexto aislado: no ve automáticamente toda la conversación ni todos los archivos que ya ha leído el coordinador. Un fork explícito puede heredar más contexto, pero no sustituye un encargo claro. Por eso debe recibir un resultado autónomo, como un mapa de archivos o una revisión de seguridad, no «ocúpate del backend».
Cada encargo declara fuentes, salida, límites y prueba. Si el coordinador no puede verificar la salida sin repetir todo el trabajo, el contrato es demasiado débil.
Task Notes importa dos veces la misma tarea. Quieres usar varios agentes, pero el bug todavía no está localizado y no quieres que todos modifiquen el repositorio.
- Asigna a un Explorer una misión de solo lectura: reproducir el defecto, seguir el dato y entregar archivos, símbolos y pruebas relacionadas.
- Después del mapa, asigna al Implementer un único resultado: corregir la causa en el archivo identificado, sin limpiar otro código.
- Pide al Tester que añada el caso duplicado a la suite, trabajando sobre el archivo de prueba acordado y partiendo del contrato del parche.
- Haz que un Reviewer lea el diff y los resultados sin modificar nada y que cite cada hallazgo con archivo, línea e impacto.
Resultado: Tienes cuatro contribuciones distintas, pero una sola historia verificable: reproducción, causa, parche, prueba. Cada paso tiene una salida y nadie recibe un genérico «haz lo que haga falta».
Dependencias y paralelismo real
Paralelizar solo es útil cuando dos trabajos de verdad pueden avanzar sin esperarse. Abrir más agentes para luego dejarlos parados sobre el mismo prerrequisito es paralelismo sobre el papel. Primero dibuja las dependencias; después decide qué puede arrancar a la vez.
Dos búsquedas independientes pueden empezar a la vez. Las pruebas que dependen de una API nueva deben esperar al menos al contrato de la implementación. Dibujar el grafo de dependencias evita el falso paralelismo y las esperas ocultas.
El paralelismo tiene un coste: arranque, contexto duplicado, síntesis y posibles conflictos. Si dos ramas de verdad tienen que escribir en paralelo, worktrees separados pueden aislar sus archivos; aun así habrá que integrar y verificar. Para una tarea pequeña, un solo agente con un plan claro suele ser más rápido.
- Descompón el resultado en artefactos verificables, no en títulos genéricos.
- Dibuja las dependencias y separa los trabajos realmente independientes.
- Asigna un único propietario de escritura para cada archivo.
- Inicia en paralelo solo las ramas sin dependencias ni conflictos.
- Reúne pruebas y divergencias en una síntesis controlada.
Debes añadir una prioridad a las tareas de Task Notes. Hace falta una decisión sobre el formato de datos, una modificación del parser, pruebas y una verificación de la interfaz.
- Haz arrancar a la vez el mapa del formato guardado y la búsqueda de los puntos donde se muestra la prioridad: son dos lecturas independientes.
- Bloquea la implementación hasta que el formato esté decidido, porque parser y migración deben compartir el mismo contrato.
- Inicia las pruebas del parser después del contrato, pero en paralelo con la modificación de la vista, asignando archivos distintos.
- Reúne las ramas en una comprobación end-to-end solo cuando datos, parser e interfaz hayan producido artefactos compatibles.
Resultado: El tiempo se reduce donde existe independencia real. En los puntos de unión no adivinas: esperas el artefacto que define el contrato y luego verificas la integración.
Propiedad de los archivos y conflictos
El peor conflicto no es el que Git señala en rojo. Es el que pasa inadvertido porque dos agentes reescriben el mismo archivo con ideas distintas y la última versión sigue pareciendo válida. El ownership sirve para saber quién puede escribir, quién propone y quién controla.
Si dos agentes modifican el mismo archivo, el último resultado puede borrar o reinterpretar el primero. Asigna la propiedad de escritura, serializa los cambios o haz que uno de los dos produzca solo una propuesta.
La lectura puede compartirse con más facilidad que la escritura. Un reviewer analiza el diff sin modificarlo; el implementador conserva la responsabilidad del parche hasta que se aceptan los hallazgos.
El Implementer está corrigiendo `importer.py`; el Reviewer observa que el nombre del archivo cargado no se normaliza. Ambos querrían intervenir de inmediato.
- Mantén `importer.py` bajo ownership del Implementer hasta el cierre del parche actual.
- Pide al Reviewer un hallazgo de solo lectura con entrada peligrosa, función implicada, impacto y comportamiento esperado.
- Haz que el Implementer integre el hallazgo en un segundo diff distinguible, añadiendo la prueba propuesta.
- Devuelve el diff completo al Reviewer para comprobar que el riesgo está cubierto sin introducir regresiones.
Resultado: La observación de seguridad no se ignora, pero tampoco se transforma en una modificación concurrente. Siguen siendo legibles el autor, la intención y la prueba de cada paso.
Síntesis basada en pruebas
Una síntesis no es un collage de informes. El coordinador debe hacer el trabajo más delicado: entender dónde coinciden las pruebas, dónde divergen las conclusiones y qué afirmación puede sostenerse de verdad. Cuatro agentes seguros de sí mismos pueden compartir la misma suposición equivocada.
El coordinador no concatena simplemente los informes. Compara los archivos citados, las pruebas, las suposiciones y los límites; señala las divergencias y decide qué evidencia es la más pertinente.
Una buena entrega final separa lo que está implementado, lo que está verificado y lo que sigue abierto. Los subagentes informan al coordinador; en un agent team experimental, en cambio, los teammates también pueden comunicarse entre sí y compartir tareas. Son modelos de coordinación distintos, y en ambos la seguridad del tono vale menos que las pruebas.
El Explorer atribuye la importación doble al parser; el Reviewer cree que el problema está en el guardado. Ambos citan código real, pero ninguno tiene una prueba concluyente.
- Pon en una tabla las dos hipótesis con los archivos citados, la entrada usada y la observación esperada si cada una fuera cierta.
- Busca el primer punto del flujo en el que el duplicado sea observable: salida del parser o contenido del store.
- Ejecuta una prueba dirigida a esa frontera, sin modificar el código para favorecer una de las hipótesis.
- Actualiza la síntesis con el resultado, descarta la hipótesis refutada y conserva el límite de las verificaciones que aún no se han realizado.
Resultado: La divergencia se convierte en un experimento, no en una votación. La conclusión final nace de la frontera observada y sigue siendo proporcional a las pruebas disponibles.
Equipo para Task Notes
La nueva importación requiere comprensión, parche, casos límite y control final.
Explorer → mapa de parser, store y pruebas (solo lectura)
Implementer → posee parser.py
Tester → posee test_parser.py después del contrato
Reviewer → lee el diff y cita hallazgos
Coordinator → compara pruebas, diff y riesgos; no inventa consenso