Lo que el sistema Task de Claude Code revela sobre el ingeniero AI-nativo

La semana pasada, Claude Code renombró discretamente Todo a Task. Parece un simple cambio de terminología, pero marca el comienzo de un sistema completamente diferente.

Todo era una lista que Claude mantenía en solitario: la memoria personal de un único agente. Task es una unidad de trabajo compartida entre múltiples agentes. Esa diferencia cambia el paradigma de las herramientas de codificación con IA.

En otras palabras, ha nacido una nueva unidad de abstracción necesaria para los enjambres de IA.

La clave es la delegación, no la automatización

El antiguo Claude Code era un cerebro único. Si le asignabas un proyecto complejo, olvidaba los pasos anteriores a mitad de camino, obligándote a reiniciar alrededor del 60% una y otra vez.

El nuevo sistema Task tiene una arquitectura fundamentalmente distinta:

• Hablas con un líder de equipo. El líder no escribe código directamente. Planifica, delega y sintetiza.
• Una vez apruebas el plan, se generan agentes especialistas que trabajan en paralelo.

Esto no es automatización, es delegación. La diferencia importa. Automatizar es programar una secuencia conocida. Delegar es definir resultados y confiar en un equipo estructurado para que encuentre el camino de ejecución.

El grafo de dependencias es el arma real

La característica central del sistema Task son las dependencias entre tareas (blockedBy). La tarea 3 no puede comenzar hasta que las tareas 1 y 2 estén completas.

¿Por qué es tan importante?

Antes, Claude tenía que mantener todo el plan en su cabeza. A medida que el contexto se alargaba, naturalmente olvidaba partes del plan. Cuanto más duraba la sesión, más se acumulaba la desviación.

Ahora el plan mismo está externalizado y estructurado. Aunque el contexto se comprima o un agente sea reemplazado, el plan sobrevive. El grafo de dependencias actúa como una capa de coordinación persistente que trasciende la memoria de cualquier agente individual.

El procesamiento paralelo viene gratis

Asigna de siete a diez tareas y el sistema ya no las procesa secuencialmente. Las tareas sin dependencias se ejecutan simultáneamente. Las búsquedas rápidas van a Haiku, la implementación a Sonnet, los juicios complejos a Opus: la asignación de modelos ocurre automáticamente según las características de cada tarea.

Esta es una consecuencia directa del diseño estructurado de tareas. Cuanto más limpia sea la descomposición y mejor definidas las dependencias, más paralelismo extrae el sistema. No optimizas el paralelismo explícitamente: lo obtienes como subproducto de una buena arquitectura de tareas.

El trabajo se convierte en orquestación

La documentación de Swarm revela patrones claros:

• Parallel Specialists: múltiples expertos revisan simultáneamente - seguridad, rendimiento, verificación de tipos, todo a la vez.
• Pipeline: investigación → planificación → implementación → pruebas - etapas secuenciales donde cada una depende de la anterior.
• Self-Organizing Swarm: los agentes toman tareas de un pool compartido, eligiendo las que no están bloqueadas ni asignadas.

El trabajo ya no consiste en escribir código. Consiste en diseñar qué agentes hacen qué, en qué orden y con qué dependencias entre ellos.

La eficiencia del Swarm depende del diseño de tareas

Hay tres palancas para optimizar el rendimiento de un Swarm:

• Granularidad de tareas: tareas más pequeñas aumentan la tasa de paralelización, pero la sobrecarga de comunicación entre agentes crece con cada división.
• Separación de roles: la especialización mejora la calidad, pero puede crear cuellos de botella en agentes con cargas desproporcionadas.
• Diseño de dependencias: estructurar qué debe terminar antes de que lo siguiente pueda arrancar sin bloqueos - esta es la topología de tu flujo de trabajo.

Según mis propios experimentos, la tercera palanca tiene el impacto más significativo. La granularidad y la separación de roles son relativamente intuitivas. El diseño de dependencias requiere pensar en la forma del trabajo en sí - lo que yo llamo diseño de topología de dependencias.

Esta es la verdadera habilidad de la era Swarm. No se trata de escribir código más rápido ni de elegir mejores modelos. Se trata de estructurar el flujo de trabajo para que el máximo número de agentes pueda operar sin esperas.

De escribir código a diseñar cómo se trabaja

La progresión es clara:

Primero, escribíamos código. Después, diseñábamos sistemas. Ahora, diseñamos la forma en que el trabajo se estructura.

No estás usando herramientas de IA. Estás dirigiendo un equipo de IA. La persona que entienda esta distinción primero dominará el próximo año del desarrollo de software.

El cambio de Todo a Task es pequeño en la superficie. Debajo, es el andamiaje de un mundo donde la producción principal del ingeniero no es código, sino la arquitectura de la colaboración entre máquinas.