Partimos de la consolidación de Opus 4.5, modelo que demostró mejor desempeño en tareas y workflows agenticos. Con más autonomía sostenida y mejor manejo de estado, ya no resulta imprescindible un Todo para encargos pequeños, mientras que los proyectos complejos sí se benefician de un plan estructurado con dependencias y memoria compartida.
Visto desde el flujo diario, ganamos tres cosas: continuidad entre sesiones, orden de ejecución mediante dependencias y trabajo paralelo sin pisarnos. Pasamos de la lista plana que se pierde al cerrar el terminal a un grafo de tareas que permanece, guía la ejecución y se actualiza en tiempo real para todos los agentes que comparten la misma lista.
La memoria del proyecto deja de vivir en el chat y pasa a vivir en el sistema de archivos, con reglas explícitas de dependencia y una vista común para todas las sesiones.
La pregunta que nos hacemos hoy ya no es si la IA puede escribir código, sino cómo coordinamos a varias instancias para que lo hagan con menos fricción. Con Tasks, podemos responder a ese problema de orquestación en Claude Code.
Qué cambia con Tasks y por qué importa
Con Tasks reemplazamos los Todos por tres pilares operativos. Primero, la persistencia. Cada tarea se guarda como archivo en ~/.claude/tasks, por lo que el plan sobrevive al cierre del terminal y al “context compaction”. Esto nos permite retomar una feature días después sin reexplicar el recorrido ni reconstruir contexto manualmente.
Segundo, las dependencias. Ya no trabajamos con una lista plana, sino con relaciones del tipo “C depende de A y B” o “D no está bloqueada por E”. En la práctica, esto impone orden de ejecución, reduce saltos innecesarios y evita comenzar lo que aún no tiene base técnica. Durante el desarrollo, la propia IA consulta el grafo para decidir qué puede avanzar de forma segura.
Tercero, la colaboración multi‑sesión. Varias instancias de Claude Code, locales o remotas, comparten la misma lista si fijamos un identificador común. Cuando una sesión marca una tarea como completada o cambia su estado, el resto lo ve al instante. En escenarios de paralelización, como una instancia en autenticación, otra en el esquema de base de datos y otra en pruebas, desaparecen los choques de contexto, las duplicaciones y los “work-in-progress” solapados.
Hay un cuarto efecto derivado: las tareas facilitan crear utilidades propias. Al ser archivos, podemos versionarlas, auditar su historia, transformarlas con scripts y relacionarlas con otros artefactos del repositorio. Esta trazabilidad es útil en entornos con requisitos de cumplimiento o revisiones formales.
Arquitectura de Tasks y flujo de trabajo propuesto
La arquitectura es simple y potente. Identificamos las listas por un ID, serializamos las tareas como archivos y su metadata incluye campos como título, descripción, estado, prioridad, responsables y dependencias. Con esa base, proponemos un flujo de trabajo centrado en “definir‑dividir‑delegar”.
Primero, definimos el alcance. Partimos de un PRD, un issue o un objetivo claro. Después pedimos a la IA que lo convierta en una lista de tareas con dependencias explícitas. Ese paso inicial conviene hacerlo en una sesión “madre”, que construye la estructura mínima del grafo. A partir de ahí, delegamos: cada subagente toma ramas del grafo que no estén bloqueadas, ejecuta y reporta su avance sobre los mismos archivos de Tasks.
Además, el CLI de Claude Code habilita modos interactivo y no interactivo. Cuando preferimos orquestación por script, el flag -p imprime resultados y nos facilita automatizar tareas en pipelines, cron o CI. Esta dualidad nos permite mantener sesiones “human‑in‑the‑loop” para decisiones delicadas y, al mismo tiempo, lanzar ejecuciones autónomas cuando los criterios de aceptación están claros.
Para visualizar el estado, hoy la vista principal está en el terminal. Podemos ocultarla o mostrarla según convenga mientras trabajamos. En equipos que piden tablero gráfico, el hecho de que Task sea un archivo nos abre la puerta a construir dashboards sobre Git o sobre un pequeño servicio interno que lea esos estados y pinte un Kanban.
Si operamos con repositorios grandes, recomendamos asociar cada bloque de tareas a una “zona de impacto” del código y a sus criterios de aceptación. Ejemplo: “auth” con tests de login y recuperación de contraseñas, “DB” con migraciones y seeds, “tests” con cobertura sobre reglas de negocio. Así, cuando una tarea se marca como “completada”, todos entendemos qué verificación la avala.
Colaboración real entre sesiones y subagentes
El engranaje clave para compartir una lista de Tasks entre sesiones es un ID común. Antes de abrir cada sesión, fijamos una variable de entorno con ese identificador y, a partir de ahí, todos vemos y actualizamos la misma lista. En la práctica, usamos CLAUDE_CODE_TASK_LIST_ID para este fin, con soporte tanto en el modo interactivo como en claude -p y el Agent SDK.
# macOS / Linux
export CLAUDE_CODE_TASK_LIST_ID="equipo-autenticacion"
claude
# Windows PowerShell
setx CLAUDE_CODE_TASK_LIST_ID "equipo-autenticacion"
claude
En equipos que trabajan en paralelo, esta configuración evita tener que “pegar” planes por chat o copiar y pegar listas en cada terminal. La sincronización es inmediata: si una sesión termina “Diseñar esquema de base de datos”, otra puede desbloquear “Crear endpoints” sin esperar a que alguien comunique el cambio.
La paralelización también se beneficia de estrategias de aislamiento. Cuando abrimos varias instancias en un mismo repositorio, conviene crear git worktrees por feature para que cada agente trabaje en su branch con dependencias instaladas y configuración propia. Este patrón es robusto, reduce conflictos y acorta contextos locales para cada subproceso.
En despliegues híbridos (por ejemplo, una sesión en nuestra laptop y otra en un runner de CI), el mismo Task List ID mantiene la coordinación sin importar el host. La ejecución no depende del lugar, sino del acuerdo compartido sobre qué tareas existen y cuál es su estado.
La IA ya no solo asiste. Forma equipo con otras instancias y con nosotros. El pegamento es una lista de tareas persistente, compartida y con dependencias explícitas.
Cómo encaja el “Ralph Wiggum loop” y qué papel le queda
Antes de Tasks, solíamos usar una técnica simple y eficaz: ejecutar a Claude en un loop que reinyecta la instrucción original hasta que “esté hecho”. Ese patrón, conocido como Ralph Wiggum loop, se asocia al trabajo de Geoffrey Huntley, quien lo usó para producir artefactos complejos durante meses con un ciclo automático de intento, verificación y reintento. La idea es directa: un “stop hook” impide que la sesión termine y vuelve a alimentar el prompt, lo que crea un bucle de mejora sucesiva.
Nos funcionó por su contundencia, aunque mostró límites: no contemplaba múltiples tareas con dependencias, ni coordinación entre varias sesiones. De ahí que surgieran proyectos de terceros que añadieron paralelismo, git worktrees y automatización de pull requests sobre la base de Ralph. Un ejemplo es el repositorio de código abierto ralph-claude-code, que orquesta ese ciclo con controles de salida inteligentes y utilidades para monitoreo.
Con Tasks integramos ese espíritu “no pares hasta terminar”, pero dentro de la arquitectura de Claude Code. Donde antes había un loop único, hoy podemos levantar diez tareas con dependencias, repartirlas entre sesiones y ver el estado de todas desde un mismo plan. En entornos que ya invirtieron en herramientas de la familia Ralph, el equilibrio práctico es claro: mantener esos workflows cuando se necesiten funciones específicas como aislar worktrees o abrir pull requests automáticos, y usar Tasks como capa nativa de coordinación y persistencia.
Al mismo tiempo, vemos que el ecosistema alrededor de Claude Code sigue evolucionando. La existencia de plugins y scripts comunitarios para hooks, worktrees y orquestación en paralelo muestra que la demanda no es solo “que la IA escriba código”, sino “que equipos de agentes trabajen como un equipo humano”. Tasks formaliza esa ambición.
Instalación
A continuación, un procedimiento mínimo para dejar Claude Code listo y aprovechar Tasks. Nos basamos en la guía oficial y en el CLI de Anthropic para un inicio rápido.
Instalar Claude Code desde el gestor que uses habitualmente. Si ya tienes Node.js 18+, la opción más directa es la instalación global por NPM. También existen instaladores nativos para macOS, Linux y Windows.
Verificar que el comando está disponible y abrir una sesión interactiva. La primera vez, el CLI solicitará autenticación con tu cuenta de Anthropic o claude.ai.
Probar el modo no interactivo para integraciones y automatización. El flag -p imprime los resultados y se adapta bien a scripting, CI y tareas desatendidas.
Activar la colaboración multi‑sesión con un ID común de lista. Antes de lanzar cada instancia que deba compartir plan, define la variable CLAUDE_CODE_TASK_LIST_ID. Así, todas verán y actualizarán el mismo conjunto de Tasks.
Pedir a Claude que convierta un objetivo en un plan con dependencias y estados claros. Desde la sesión “madre”, solicita el desglose y confirma que cada tarea tenga criterios de aceptación y pruebas asociadas.
Entre pasos, conviene crear branches por bloque de trabajo y, si vamos a correr varias instancias en paralelo, levantar git worktrees para aislar ambientes por feature. Al finalizar, pedimos a cada subagente que sincronice su estado de Task con el plan compartido y, si procede, genere el pull request correspondiente.
Buenas prácticas y casos de uso
Empezar con un PRD breve y concreto. Cuanto más claro el objetivo, mejor será el grafo de tareas. Si el PRD es largo, pidamos primero un resumen operativo que se traduzca en tareas de tamaño razonable. Los criterios de “hecho” deben ser verificables, idealmente con tests.
Mantener la trazabilidad. Al estar en archivos, las tareas pueden versionarse. Asociemos cada task a commits y issues cuando la política de la organización lo requiera. Esto simplifica auditorías y retrospectivas.
Paralelizar con cabeza. No todos los bloques se benefician del trabajo concurrente. La regla de oro es paralelizar lo independiente y secuenciar lo que arrastra efectos de diseño, como esquemas de base de datos, contratos de API y migraciones.
Usar el CLI con -p para operaciones repetibles. En pipelines de CI, el modo no interactivo evita prompts y facilita composiciones con otras herramientas. Eso sí, definamos permisos explícitos y límites de herramientas para cuidar la seguridad en entornos automatizados.
Integrar validaciones automáticas. Cuando una tarea se declara “completada”, anexemos pruebas y linters. La IA puede escribir y ejecutar esos checks, pero la señal de “listo” debe venir de verificaciones objetivas, no de una afirmación en texto libre.
Imaginemos un desarrollo típico. Creamos la feature “autenticación con factor adicional”. La sesión “madre” produce tareas: “diseñar esquema”, “endpoint de login”, “endpoint de verificación”, “UI para OTP”, “tests de integración”. Mientras una instancia trabaja en la base, otra avanza en UI sobre un worktree distinto y una tercera compone el paquete de pruebas. Con CLAUDE_CODE_TASK_LIST_ID fijado, todas comparten estado. Cuando la de base termina, la de endpoints deja de estar bloqueada y continúa. Resultado: menos espera, menos reexplicación y menos sobrescrituras.
Conclusiones
Tasks marca un punto de inflexión en Claude Code. Al mover la planificación desde la memoria de la sesión al sistema de archivos, ganar dependencias explícitas y habilitar sincronización entre instancias, conseguimos que la coordinación deje de ser un malabar y se convierta en un proceso visible y auditable. Para tareas simples, la IA seguirá resolviendo sin apoyos. Para proyectos reales, con varias piezas y semanas de trabajo, el grafo de Tasks se vuelve el “contrato” del equipo, humano y de agentes.
La evolución no nace de la nada. Llegamos aquí después de constatar que modelos como Opus 4.5 manejan horizontes más largos y que la comunidad demostró, con técnicas como el Ralph Wiggum loop, que la autonomía mejora cuando la verificación y la persistencia están bien planteadas. Hoy, esa verificación y esa persistencia son nativas. Y eso, en entornos donde el tiempo manda, marca la diferencia entre un asistente que ayuda y un conjunto de agentes que entregan.
En los próximos meses veremos tableros visuales, plugins que leen y escriben Tasks, y políticas internas que atan criterios de aceptación a estados de tarea. Lo importante es que, desde ahora, tenemos un mecanismo común para hablar de “qué queda por hacer”, “qué bloquea” y “quién puede avanzar”. Y ese mecanismo vive en archivos, con nombres, estados y dependencias que cualquiera puede leer.
En suma, pasamos de pedir “ayúdame con este bloque” a organizar “un equipo” que lo resuelve de principio a fin. Tasks es el puente que faltaba.